kern/84326: Panic trying to connect SCSI tape drive via USB converter.

[Frank Mayhar]

>Number:         84326
>Category:       kern
>Synopsis:       Panic trying to connect SCSI tape drive via USB converter.
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Jul 30 01:20:22 GMT 2005
>Closed-Date:
>Last-Modified:
>Originator:     Frank Mayhar
>Release:        FreeBSD 5.4-STABLE i386
>Organization:
Exit Consulting 
>Environment:


System: FreeBSD 5.4-STABLE #6: Mon Jul 25 11:50:48 PDT 2005
    frank at realtime.exit.com:/usr/obj/usr/src/sys/REALTIME

Pretty standard dual-athlon system, 1.5G, LSI Logic SCSI, not relevant
to this issue.  USB probes and attaches thusly:

ohci1: <NEC uPD 9210 USB controller> mem 0xe8205000-0xe8205fff irq 16 at device 4.0 on pci4
usb1: OHCI version 1.0
usb1: <NEC uPD 9210 USB controller> on ohci1
usb1: USB revision 1.0
uhub1: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 3 ports with 3 removable, self powered
ohci2: <NEC uPD 9210 USB controller> mem 0xe8206000-0xe8206fff irq 17 at device 4.1 on pci4
usb2: OHCI version 1.0
usb2: <NEC uPD 9210 USB controller> on ohci2
usb2: USB revision 1.0
uhub2: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
ehci0: <NEC uPD 720100 USB 2.0 controller> mem 0xe8209000-0xe82090ff irq 18 at device 4.2 on pci4
usb3: EHCI version 0.95
usb3: companion controllers, 3 ports each: usb1 usb2
usb3: <NEC uPD 720100 USB 2.0 controller> on ehci0
usb3: USB revision 2.0
uhub3: NEC EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
uhub3: 5 ports with 5 removable, self powered
uhub4: Belkin Components product 0x0234, class 9/0, rev 2.00/1.00, addr 2
uhub4: single transaction translator
uhub4: 4 ports with 4 removable, self powered



>Description:


Trying to connect a SCSI tape drive (an HP DLT 4000) via a Belkin
USB<->SCSI translator results in near-instant panic with an integer
divide fault.  This is unfriendly.

I analyzed the crash a bit and it looks like CAM is identifying the device
as a da-type, as the panic is via dadone(), which eventually causes
cam_calc_geometry() to fall over itself trying to calculate geometry using
garbage values for sec_size and volume_size.  Here's the traceback, btw:

#22 0xc0633073 in __qdivrem (uq=Unhandled dwarf expression opcode 0x93
) at /usr/src/sys/libkern/qdivrem.c:97
#23 0xc06334be in __udivdi3 (a=1801810543, b=0)
    at /usr/src/sys/libkern/udivdi3.c:47
#24 0xc042f166 in cam_calc_geometry (ccg=0xe6f0b8f8, extended=1)
    at /usr/src/sys/cam/cam.c:376
#25 0xc0497442 in umass_cam_action (sim=0xc2ff3dc0, ccb=0xe6f0b8f8)
    at /usr/src/sys/dev/usb/umass.c:2580
#26 0xc04332e2 in xpt_action (start_ccb=0xe6f0b8f8)
    at /usr/src/sys/cam/cam_xpt.c:3076
#27 0xc043fab9 in dasetgeom (periph=0x0, block_len=0, maxsector=1801810542)
    at /usr/src/sys/cam/scsi/scsi_da.c:1741
#28 0xc043f3c2 in dadone (periph=0xc4b17900, done_ccb=0xc2f5d000)
    at /usr/src/sys/cam/scsi/scsi_da.c:1395
#29 0xc0436885 in camisr (V_queue=0xc06a1200)
    at /usr/src/sys/cam/cam_xpt.c:7074
#30 0xc04d7919 in ithread_loop (arg=0xc2c2bd00)
    at /usr/src/sys/kern/kern_intr.c:547
#31 0xc04d69b5 in fork_exit (callout=0xc04d77c0 <ithread_loop>, 
    arg=0xc2c2bd00, frame=0xe6f0bd38) at /usr/src/sys/kern/kern_fork.c:791
#32 0xc0613e1c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:209

Most of this traceback is a red herring, though, since I suspect the real
problem is identifying an sa as a da.  Someone with more knowledge of
this subsystem will have to take it further, though.

I have the dump online and can provide any further information you
require, just let me know.


>How-To-Repeat:


Do what I did.


>Fix:


I wish.


>Release-Note:
>Audit-Trail:
>Unformatted: