NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: misc/43182: Reboot due to system crash



The following reply was made to PR misc/43182; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: misc/43182: Reboot due to system crash
Date: Fri, 23 Apr 2010 04:51:40 +0000

 On Mon, Apr 19, 2010 at 04:30:00PM +0000, frederic%fauberteau.org@localhost 
wrote:
  > I apologize for my inexperience in bug reporting (this is my first one).
 
 You're not doing badly :-)
 
  > Mar  7 20:56:54 /netbsd: umass0: BBB bulk-out clear stall failed, IOERROR
  > Mar  7 20:56:54 /netbsd: uvm_fault(0xcc6309f8, 0, 1) -> 0xe
  > Mar  7 20:56:54 /netbsd: fatal page fault in supervisor mode
  > Mar  7 20:56:54 /netbsd: trap type 6 code 0 eip c03b0ea5 cs 8 eflags 10246 
cr2 0 ilevel 0
 
 (1)
 
  > Apr  3 07:15:22 /netbsd: fatal page fault in supervisor mode
  > Apr  3 07:15:22 /netbsd: trap type 6 code 2 eip c046a188 cs 8 eflags 10292 
cr2 cc666c84 ilevel 2
 
 (2)
 
  > Apr  3 07:15:22 /netbsd: dumping to dev 0,1 offset 3180407
  > Apr  3 07:15:22 /netbsd: dump succeeded
  > Apr  3 07:15:22 /netbsd: 
  > Apr  3 07:15:22 /netbsd: 
  > Apr  3 07:15:22 /netbsd: sd0(umass0:0:0:0): generic HBA error
  > Apr  3 07:15:22 /netbsd: fatal page fault in supervisor mode
  > Apr  3 07:15:22 /netbsd: trap type 6 code 0 eip 0 cs 8 eflags 10246 cr2 0 
ilevel 4
  > Apr  3 07:15:22 /netbsd: panic: trap
  > Apr  3 07:15:22 /netbsd: Faulted in mid-traceback; aborting...
 
 (3)
 
  > Apr 11 21:15:38 /netbsd: fatal page fault in supervisor mode
  > Apr 11 21:15:38 /netbsd: trap type 6 code 2 eip c046a188 cs 8 eflags 10292 
cr2 cc863c84 ilevel 2
 
 same as (2).
 
  > And the crash occurs all the day until today. Maybe a bug with the
  > USB mass storage ...
 
 Yes, quite likely, although (1) and (2) may actually be different
 problems, and I'm curious why in (3) it seems to be accessing sd0 on
 umass0 after doing a crashdump to wd0b. (0,1 is wd0b; ls -l /dev/wd0b.)
 Ordinarily by that point in crashing it shouldn't be touching anything
 besides the system console.
 
  > Have you some advices to help me to produce better informations to
  > understand this problem ?
 
 Some things that would probably be helpful to know:
 
 (a) What's umass0 attached to? Is it going through an ehci, uhci, or
 ohci USB controller, and what's in between? (The easiest way to answer
 this question is to forward a boot log from /var/run/dmesg.boot.)
 Also it might be useful to what your USB device calls itself, which
 will also be in the boot log.
 
 (b) Is there anything unusual you're doing with the USB device that
 might explain what's happening in case (3)? 
 
 (c) Where did crashes (1) and (2) happen? If you feel up to it, run
 "nm -n /netbsd | less" and find the last name before the EIP address
 from the crash (c03b0ea5 in case (1), c046a188 in case (2)) -- this is
 the name of the function it died in. In my kernel c03b0ea5 is between
 these:
    c03b0e60 T i4b_dl_release_ind
    c03b0f30 T i4b_dl_establish_cnf
 
 but that doesn't mean anything; it'll be different in yours. (If you
 can't do this, because you're using the prebuild 5.0.2 GENERIC kernel
 someone else can; but if you can, it saves waiting for someone else to
 get around to downloading that kernel and checking.)
 
 Note that crash (3) jumped to 0 and trying to look that up won't yield
 anything particularly interesting. :-/
 
 Unfortunately, there are a number of more-or-less known but unsolved
 problems with umass...
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost
 


Home | Main Index | Thread Index | Old Index