dev/isp panic (was Re: CAM Target Layer and dev/isp)
Trent Nelson
trent at snakebite.org
Wed Jul 18 15:59:10 UTC 2012
On 7/18/12 10:00 AM, "Matthew Jacob" <mj at feral.com> wrote:
>--------------
>
>db> bt
>Tracing pid 12 tid 100062 td 0xfffffe001c00f470
>acpi_timer_get_timecount() at 0xffffffff803ccfc6 =
>acpi_timer_get_timecount+0x16
>DELAY() at 0xffffffff80ce68c3 = DELAY+0x83
>ns8250_putc() at 0xffffffff807a17ba = ns8250_putc+0x9a
>uart_cnputc() at 0xffffffff807a3b85 = uart_cnputc+0x75
>cnputc() at 0xffffffff808e9cbc = cnputc+0x4c
>cnputs() at 0xffffffff808ea0f5 = cnputs+0x35
>putbuf() at 0xffffffff8097400c = putbuf+0xac
>kvprintf() at 0xffffffff80972643 = kvprintf+0x83
>vprintf() at 0xffffffff80973b15 = vprintf+0x85
>printf() at 0xffffffff80973be7 = printf+0x67
>isp_prt() at 0xffffffff805c15a0 = isp_prt+0xd0
>isp_async() at 0xffffffff805c6736 = isp_async+0x356
>isp_intr() at 0xffffffff805b854c = isp_intr+0x13ac
>isp_platform_intr() at 0xffffffff805c1fd9 = isp_platform_intr+0x99
>intr_event_execute_handlers() at 0xffffffff80907214 =
>intr_event_execute_handlers+0x104
>ithread_loop() at 0xffffffff809089a6 = ithread_loop+0xa6
>fork_exit() at 0xffffffff809038ef = fork_exit+0x11f
>fork_trampoline() at 0xffffffff80c5139e = fork_trampoline+0xe
>--- trap 0, rip = 0, rsp = 0xffffff9178bd3cf0, rbp = 0 ---
>db> x/s panicstr
>0xffffffff8130fd08 = panicstr:
>
>
>-------------
>
>Hmm. No panic string because it wasn't a panic. isp driver is trying to
>(successfully) print something and this blew up in the ACPI code.
Hmm, just to clarify, do you mean "the isp tried to print something that
blew up ACPI", or "ACPI blew up whilst isp just happened to be printing
something"?
Would knowing what isp was trying to print be of any help? (I can poke
around the *putc buffers if it happens again.)
I'm not surprised that ACPI is involved, though. This box has always
seemed to run into ACPI issues (HP ProLiant DL585 G1, quad dual-core
Opteron, 64GB RAM), like hanging on boot during the pci->bios probe stuff
from a kernel circa 2-3 months ago.
Trent.
More information about the freebsd-scsi
mailing list