Hey,
we have seen this or a very similar panic for about 1 year now once in
a while and I think I reported it before; this is FreeBSD as guest on
vmware. Seems it was a double panic this time. Could someone please
see what's going on there? It was on 8.x-STABLE in the past and this
is 8.2-RELEASE-p4.
Thanks
/bz
acd0: WARNING - READ_TOC taskqueue timeout - completing request directly
Fatal trap 12: page fault while in kernel mode
cpuid = 4; apic id = 04
fault virtual address = 0x1f4
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc08a1e9f
stack pointer = 0x28:0xe6ad5b9c
Fatal trap 12: page fault while in kernel mode
frame pointer = 0x28:0xe6ad5bb4
cpuid = 2;
code segment = base 0x0, limit 0xfffff, type 0x1bapic id = 02
= DPL 0, pres 1, def32 1, gran 1
fault virtual address = 0x1f4
processor eflags fault code = supervisor read, page not
presentinterrupt enabled,
instruction pointer = 0x20:0xc08a1e9fresume,
stack pointer = 0x28:0xe8e9e808IOPL = 0
frame pointer = 0x28:0xe8e9e820
current process code segment = base 0x0, limit 0xfffff, type
0x1b12 (swi6: task queue)
= DPL 0, pres 1, def32 1, gran 1
trap number = 12
processor eflags = interrupt enabled,
panic: page faultresume,
cpuid = 4IOPL = 0
current process KDB: stack backtrace:25162 (bsnmpd)
trap number = 12#0 0xc08e0d07 at kdb_backtrace+0x47
#1 0xc08b1dc7 at panic+0x117
#2 0xc0be4b53 at trap_fatal+0x323
#3 0xc0be4dd0 at trap_pfault+0x270
#4 0xc0be5315 at trap+0x465
#5 0xc0bcbecc at calltrap+0x6
#6 0xc08b0d86 at _sema_post+0x46
#7 0xc056fa47 at ata_completed+0x727
#8 0xc08eb97a at taskqueue_run_locked+0xca
#9 0xc08ebc8a at taskqueue_run+0xaa
#10 0xc08ebd53 at taskqueue_swi_run+0x13
#11 0xc088903b at intr_event_execute_handlers+0x13b
#12 0xc088a75b at ithread_loop+0x6b
#13 0xc0886d51 at fork_exit+0x91
#14 0xc0bcbf44 at fork_trampoline+0x8
Uptime: 5d20h1m56s
(gdb) l *ata_completed+0x727
489 (request->callback)(request);
490 else
491 sema_post(&request->done);
492
493 /* only call ata_start if channel is present */
494 if (ch)
495 ata_start(ch->dev);
496 }
497
498 void
--
Bjoern A. Zeeb You have to have visions!
Stop bit received. Insert coin for new address family.
On 16/11/2011 07:43, Bjoern A. Zeeb wrote:> Hey, > > we have seen this or a very similar panic for about 1 year now once in > a while and I think I reported it before; this is FreeBSD as guest onYes, IIRC I've also reported it before; it crashes randomly, when the machine is not doing anything with the cdrom. As a workaround, I now remove the cdrom device from vmware instances.> vmware. Seems it was a double panic this time. Could someone please > see what's going on there? It was on 8.x-STABLE in the past and this > is 8.2-RELEASE-p4. > > Thanks > /bz > > acd0: WARNING - READ_TOC taskqueue timeout - completing request directly > > > Fatal trap 12: page fault while in kernel mode > cpuid = 4; apic id = 04 > fault virtual address = 0x1f4 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc08a1e9f > > stack pointer = 0x28:0xe6ad5b9c > Fatal trap 12: page fault while in kernel mode > frame pointer = 0x28:0xe6ad5bb4 > cpuid = 2; > code segment = base 0x0, limit 0xfffff, type 0x1bapic id = 02 > = DPL 0, pres 1, def32 1, gran 1 > fault virtual address = 0x1f4 > processor eflags > fault code = supervisor read, page not presentinterrupt > enabled, > instruction pointer = 0x20:0xc08a1e9fresume, > stack pointer = 0x28:0xe8e9e808IOPL = 0 > frame pointer = 0x28:0xe8e9e820 > current process > code segment = base 0x0, limit 0xfffff, type 0x1b12 (swi6: > task queue) > = DPL 0, pres 1, def32 1, gran 1 > trap number = 12 > processor eflags = interrupt enabled, > panic: page faultresume, > cpuid = 4IOPL = 0 > current process > KDB: stack backtrace:25162 (bsnmpd) > > trap number = 12#0 0xc08e0d07 at kdb_backtrace+0x47 > > #1 0xc08b1dc7 at panic+0x117 > #2 0xc0be4b53 at trap_fatal+0x323 > #3 0xc0be4dd0 at trap_pfault+0x270 > #4 0xc0be5315 at trap+0x465 > #5 0xc0bcbecc at calltrap+0x6 > #6 0xc08b0d86 at _sema_post+0x46 > #7 0xc056fa47 at ata_completed+0x727 > #8 0xc08eb97a at taskqueue_run_locked+0xca > #9 0xc08ebc8a at taskqueue_run+0xaa > #10 0xc08ebd53 at taskqueue_swi_run+0x13 > #11 0xc088903b at intr_event_execute_handlers+0x13b > #12 0xc088a75b at ithread_loop+0x6b > #13 0xc0886d51 at fork_exit+0x91 > #14 0xc0bcbf44 at fork_trampoline+0x8 > Uptime: 5d20h1m56s > > > (gdb) l *ata_completed+0x727 > 489 (request->callback)(request); > 490 else > 491 sema_post(&request->done); > 492 > 493 /* only call ata_start if channel is present */ > 494 if (ch) > 495 ata_start(ch->dev); > 496 } > 497 > 498 void > >-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20111116/c4a1d815/signature.pgp
Hi. On 11/16/11 08:43, Bjoern A. Zeeb wrote:> we have seen this or a very similar panic for about 1 year now once in > a while and I think I reported it before; this is FreeBSD as guest on > vmware. Seems it was a double panic this time. Could someone please > see what's going on there? It was on 8.x-STABLE in the past and this > is 8.2-RELEASE-p4.The part of code reporting "completing request directly" is IMHO broken by design. It returns request completion before request will actually be completed by lower levels without any knowledge of what's going on there. There is kind of protection against double request completion, but it looks like not always working. May be because that part of code is not locked and nothing prevents that semaphore timeout and normal request timeout/completion to happen simultaneously. It is surprising to see even two traps same time, not sure what synchronized them so precisely. Simple removing that semaphore timeout is not an option, because it will cause deadlock when this wait happen within taskqueue thread that is used to handle requests completion and abort that wait. Avoid waiting inside taskqueue is also impossible without major rewrite. That's why ATA_CAM drops that code completely. -- Alexander Motin