dev/isp panic (was Re: CAM Target Layer and dev/isp)

[Trent Nelson]

On 7/18/12 9:13 AM, "Trent Nelson" <trent at snakebite.org> wrote:

>
>On 7/17/12 12:46 PM, "Kenneth D. Merry" <ken at freebsd.org> wrote:
>
>>> port  8: id N1 Online         L-Port 1 public
>>
>>Looks like it is in loop mode.  Can your switch make a loop mode device
>>visible on another port?
>
>You know what, I have no idea what was going on there.  I can't replicate
>that behavior (getting the port to present itself to the fabric as an
>L-port) on another (almost identical) box.  And I managed to panic that
>box whilst composing this e-mail, to the point where it doesn't even get
>past the PCI BIOS routines.  (It happened when I unplugged the HBA, I'll
>paste a backtrace and CC Matt in a separate e-mail.)

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:


No idea what the panic string was.  The box stopped responding via ssh so
I logged into the serial port (via a sio mux over telnet) and simply got a
'db>' prompt -- no idea what came before that (and the vidconsole was
strangely blank).

Not sure how useful the backtrace is.  It's a Qlogic 2313 board, it was in
target mode, and the panic happened after I unplugged the HBA.  (Could be
completely unrelated -- I unplugged the HBA, waltzed back to my laptop,
and my ssh sessions were all stuck -- I.e. I didn't witness it panic
immediately after unplugging.)

I've got a few more commands like show intr|ps|thread etc in my buffer,
I'll paste if that's of any use.  I'll see if I can replicate it later
today (I've also fixed it so that I've got a proper dump device now).  Let
me know if there are any ddb commands that would be of use to you if it
happens again.

Box is running: FreeBSD s16.snakebite.net 9.1-PRERELEASE FreeBSD
9.1-PRERELEASE #0 r0: Mon Jul 16 06:28:19 UTC 2012
root at hydrogen.snakebite.net:/usr/obj/src/freebsd/9/r238513m/sys/AMD64
amd64

Also worth mentioning, heh, I manually svn merged available changes
reported in head/dev/isp to my local stable/9 branch.  The branches aren't
identical (seems there were some head changes that svn doesn't think are
eligible for merging back), but I haven't looked into the specifics.
Relevant thread: 
http://lists.freebsd.org/pipermail/freebsd-stable/2012-July/068828.html.

If I can reliably reproduce the panic, I'll revert back to a clean
stable/9/dev/isp first to see if my cowboy merging is to blame ;-)


	Trent.