Qlogic FC scsi_target ISP2310
Alexander Sack
pisymbol at gmail.com
Tue Sep 2 23:42:58 UTC 2008
On Mon, Sep 1, 2008 at 5:59 AM, Fuujin Networks LLC
<erich at fuujinnetworks.com> wrote:
> Alex:
>
> So here's something interesting. The target decided to panic on me just now.
> Here's the last message from the target before it rebooted:
>
> scsi_target: main loop beginning
> scsi_target: read ready
> scsi_target: event -1 done
> scsi_target: Working on ATIO 0x800b7fe20
> scsi_target: tcmd_handle atio 0x800b7fe20 ctio 0x800b85040 atioflags 0x8000
> scsi_target: INQUIRY from 0: 12 0 0 0 24 0
>
> The initiator just sits there and says the rescan was successful with no
> events or errors.....
>
>
> Here's the panic:
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address = 0x8
> fault code = supervisor read data, page not present
> instruction pointer = 0x8:0xffffffff8022f128
> stack pointer = 0x10:0xffffffffae3c1650
> frame pointer = 0x10:0xffffffffae3c16e0
> code segment = base 0x0, limit oxfffff, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags = interrupt enabled, resume, IOPL = 0
> current process = 777 (scsi_target)
> [thread pid 777 tid 100075 ]
> Stopped at isp_pci_dmasetup+0x1d8: movq 0x8(%rax),%rsi
>
> Here's the bt:
>
> Tracing pid 777 tid 100075 td 0xffffff00016e100
> isp_pci_dmasetup() at isp_dmasetup+0x1d8
> isp_action() at isp_action+0x1089
> xpt_run_dev_sendq() at xpt_run_dev_sendq+0x1c4
> xpt_action() at xpt_action+0x796
> targsendccb() at targsendccb+0x9e
> targstart() at targstart+0x130
> xpt_run_dev_allocq() at xpt_run_dev_allocq+0xd4
> targwrite() at targwrite+0x184
> giant_write() at giant_write+0x60
> devfs_write_f() at devfs_write_f+0x75
> dofilewrite() at dofilewrite+0x85
> kern_writev() at kern_writev+0x4c
> write() at write+0x54
> syscall() at syscall+0x254
> Xfast_syscall() at Xfast_syscall+0xab
> --- syscall (4, FreeBSD ELF64, write), rip = 0x800929d3c, rsp =
> 0x7fffffff4908, rbp = 0x800b83440 ---
>
> Please note the above trace was copied by hand because I couldn't get
> console redirection to stay up when this died. Does anyone know how to get
> this data into a file or out via serial (vt100 perhaps??) or is this pretty
> much a manual process??
Erich, if you had a gdb session you could log it or use print screen I
suppose. But yea it can be a pain in the butt to copy stack traces.
I don't know why you panic'ed and I haven't had a single cycle to look
a this particular issue. So it seems you and Sean (see other thread)
are having trouble using the QLA2[34]xx cards in target mode. Seems
like there needs to be more testing involved. I'll see if tomorrow I
can build target mode in on my box and reproduce the panic (a panic,
hopefully with a similar stacktrace!).
Thanks for this, stay tuned...
-aps
More information about the freebsd-scsi
mailing list