Date: Wed, 18 Jul 2012 06:24:19 -0700 From: Trent Nelson <trent@snakebite.org> To: "mj@feral.com Jacob" <mj@feral.com> Cc: "freebsd-scsi@freebsd.org" <freebsd-scsi@freebsd.org>, "Kenneth D. Merry" <ken@freebsd.org> Subject: dev/isp panic (was Re: CAM Target Layer and dev/isp) Message-ID: <CC2C2ECB.32BF5%trent@snakebite.org> In-Reply-To: <CC2C0C31.32A91%trent@snakebite.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7/18/12 9:13 AM, "Trent Nelson" <trent@snakebite.org> wrote: > >On 7/17/12 12:46 PM, "Kenneth D. Merry" <ken@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 =3D acpi_timer_get_timecount+0x16 DELAY() at 0xffffffff80ce68c3 =3D DELAY+0x83 ns8250_putc() at 0xffffffff807a17ba =3D ns8250_putc+0x9a uart_cnputc() at 0xffffffff807a3b85 =3D uart_cnputc+0x75 cnputc() at 0xffffffff808e9cbc =3D cnputc+0x4c cnputs() at 0xffffffff808ea0f5 =3D cnputs+0x35 putbuf() at 0xffffffff8097400c =3D putbuf+0xac kvprintf() at 0xffffffff80972643 =3D kvprintf+0x83 vprintf() at 0xffffffff80973b15 =3D vprintf+0x85 printf() at 0xffffffff80973be7 =3D printf+0x67 isp_prt() at 0xffffffff805c15a0 =3D isp_prt+0xd0 isp_async() at 0xffffffff805c6736 =3D isp_async+0x356 isp_intr() at 0xffffffff805b854c =3D isp_intr+0x13ac isp_platform_intr() at 0xffffffff805c1fd9 =3D isp_platform_intr+0x99 intr_event_execute_handlers() at 0xffffffff80907214 =3D intr_event_execute_handlers+0x104 ithread_loop() at 0xffffffff809089a6 =3D ithread_loop+0xa6 fork_exit() at 0xffffffff809038ef =3D fork_exit+0x11f fork_trampoline() at 0xffffffff80c5139e =3D fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff9178bd3cf0, rbp =3D 0 --- db> x/s panicstr 0xffffffff8130fd08 =3D 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@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:=20 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CC2C2ECB.32BF5%trent>