Date: Fri, 5 Jul 2002 22:59:39 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: freebsd-current@freebsd.org Subject: Re: panic broken on alpha or scsi or up Message-ID: <Pine.BSF.4.21.0207052258240.16316-100000@InterJet.elischer.org> In-Reply-To: <15654.26495.25741.948480@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
put a breakpoint at msleep+0x290 then continue.. sprinkle a few breakpoints at locations you think other processes ahould be hitting if they were to be running.. On Fri, 5 Jul 2002, Andrew Gallatin wrote: > > Hi Julian, > > When I panic an alpha these days, I end up with the random_kthread > spinning on the cpu stuck in msleep, and I never get the disks sync'ed > (or, if I disable sync'ing, I never get through a dump): > > panic: vm_page_wakeup: page not busy!!! > panic > Stopped at Debugger+0x34: zapnot v0,#0xf,v0 <v0=0x0> > db> c > > syncing disks... 3 3 > > <hang, break into debugger> > > Stopped at siointr1+0x198: br > zero,siointr1+0x330 <zero=0x0> > db> tr > siointr1() at siointr1+0x198 > siointr() at siointr+0x40 > isa_handle_fast_intr() at isa_handle_fast_intr+0x24 > alpha_dispatch_intr() at alpha_dispatch_intr+0xd0 > interrupt() at interrupt+0x110 > XentInt() at XentInt+0x28 > --- interrupt (from ipl 0) --- > msleep() at msleep+0x20 > random_kthread() at random_kthread+0xb4 > fork_exit() at fork_exit+0xe0 > exception_return() at exception_return > --- root of call graph --- > db> c > > <wait some more, get a coke, break into debugger again> > > Stopped at siointr1+0x198: br zero,siointr1+0x330 > <zero=0x0> > db> where > No such command > db> tr > siointr1() at siointr1+0x198 > siointr() at siointr+0x40 > isa_handle_fast_intr() at isa_handle_fast_intr+0x24 > alpha_dispatch_intr() at alpha_dispatch_intr+0xd0 > interrupt() at interrupt+0x110 > XentInt() at XentInt+0x28 > --- interrupt (from ipl 0) --- > critical_exit() at critical_exit+0x20 > _mtx_unlock_spin_flags() at _mtx_unlock_spin_flags+0x94 > msleep() at msleep+0x290 > random_kthread() at random_kthread+0xb4 > fork_exit() at fork_exit+0xe0 > exception_return() at exception_return > --- root of call graph --- > db> reboot > > > If I disable the randomness thing, I end up getting stuck in another > kernel process: > > db> tr > siointr1() at siointr1+0x198 > siointr() at siointr+0x40 > isa_handle_fast_intr() at isa_handle_fast_intr+0x24 > alpha_dispatch_intr() at alpha_dispatch_intr+0xd0 > interrupt() at interrupt+0x110 > XentInt() at XentInt+0x28 > --- interrupt (from ipl 0) --- > critical_exit() at critical_exit+0x20 > _mtx_unlock_spin_flags() at _mtx_unlock_spin_flags+0x94 > msleep() at msleep+0x290 > buf_daemon() at buf_daemon+0x1f4 > fork_exit() at fork_exit+0xe0 > exception_return() at exception_return > --- root of call graph --- > > > I don't have this problem on my x86 testbox, but it has > an IDE disk and is SMP. The alpha with the problem is > UP, and uses a SCSI disk (isp controller). > > Any ideas? Are people able to get crashdumps on UP SCSI x86s? > > Thanks, > > Drew > > PS: I was going to make the subject "can't take a dump", but > I thought the better of it ;) > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0207052258240.16316-100000>