Date: Sun, 22 Jul 2001 00:52:23 +0100 (BST) From: Andrew Gordon <arg@arg1.demon.co.uk> To: Nick Hibma <n_hibma@qubesoft.com> Cc: Kenneth W Cochran <kwc@world.std.com>, <freebsd-scsi@FreeBSD.ORG> Subject: Re: USB/umass in addition to "other" SCSI Message-ID: <20010722000136.Q54613-100000@server.arg.sj.co.uk> In-Reply-To: <20010721160811.Y25714-100000@bluebottle>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 21 Jul 2001, Nick Hibma wrote:
> > > How do I "connect" a USB "disk" when I already have a SCSI
> > > HBA & other peripherals installed & operating?
> >
> > It should appear of its own accord when usbd sees it. However, this
> > doesn't appear to work properly at present.
>
> usbd doesn't handle umass (anymore).
Do you mean that it's now interrupt driven, or are you just drawing a
distinction between "usbd the program" and "the kernel thread supervised
by usbd"?
> > I haven't found a method that works other than to have the device present
> > at boot time.
>
> Hm, it should work at any time (as in, I use the umass driver as a
> module that I load (including CAM as a module) at runtime, then connect
> and disconnect the device many a time and that works. Could you describe
> to me in which cases it does not work?
This is a 4.3-stable system, world and kernel sources last updated about 2
days ago (though it's behaved the same for as long as I've been using this
drive). All of the USB drivers are compiled-in to the kernel rather than
being loaded as KLDs.
With the drive connected at boot time (doesn't matter if there's any media
in the drive), it appears thus:
ohci0: <AMD-756 USB Controller> mem 0xe2103000-0xe2103fff irq 9
at device 7.4 on pci0
usb0: OHCI version 1.0, legacy support
usb0: SMM does not respond, resetting
usb0: <AMD-756 USB Controller> on ohci0
usb0: USB revision 1.0
uhub0: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 4 ports with 4 removable, self powered
ukbd0: Belkin Components USB-PS2 Adapter , rev 1.10/1.20, addr 2,
iclass 3/1
kbd1 at ukbd0
ums0: Belkin Components USB-PS2 Adapter , rev 1.10/1.20, addr 2,
iclass 3/1
ums0: 5 buttons and Z dir.
umass0: Fuji Photo Film SmartMedia R/W, rev 1.00/1.00, addr 3
umass0: Get Max Lun not supported (STALLED)
....snip non-USB devices...
da1 at umass-sim0 bus 0 target 0 lun 0
da1: <GENERIC SmartMedia R/W 1.00> Removable Direct Access SCSI-2 device
da1: 650KB/s transfers
da1: 62MB (128000 512 byte sectors: 64H 32S/T 62C)
This configuration goes on to work fine; you can insert/eject media, mount
filesystems, read/write etc. with no problems. In this state, camcontrol
reports:
rocket(root)# camcontrol devlist
<IBM DRVS09V 0270> at scbus0 target 0 lun 0 (pass0,da0)
<GENERIC SmartMedia R/W 1.00> at scbus1 target 0 lun 0 (pass1,da1)
rocket(root)# camcontrol rescan 1
Re-scan of bus 1 was successful
rocket(root)# camcontrol devlist
<IBM DRVS09V 0270> at scbus0 target 0 lun 0 (pass0,da0)
<GENERIC SmartMedia R/W 1.00> at scbus1 target 0 lun 0 (pass1,da1)
rocket(root)#
If I boot without the drive connected, and then plug it in (again, doesn't
matter if there's any media in the drive), the console shows:
umass0: Fuji Photo Film SmartMedia R/W, rev 1.00/1.00, addr 3
umass0: Get Max Lun not supported (STALLED)
In this state, "camcontrol devlist" shows:
<IBM DRVS09V 0270> at scbus0 target 0 lun 0 (pass0,da0)
<GENERIC SmartMedia R/W 1.00> at scbus1 target 0 lun 0 (probe0)
If I then attempt a "camcontrol rescan 1", the camcontrol process blocks
forever waiting on "cbwait".
If I disconnect the drive (whether or not I tried to do anything with it
after plugging in), a panic results. If the system was booted with the
drive connected, and it is then disconnected/reconnected, the devlist
again shows the "(probe0)" and it doesn't work, but instead of the panic
some errors get logged:
Jul 22 00:39:22 rocket /kernel: umass0: BBB reset failed, TIMEOUT
Jul 22 00:39:27 rocket /kernel: umass0: BBB bulk-in clear stall failed,
TIMEOUT
Jul 22 00:39:32 rocket /kernel: umass0: BBB bulk-out clear stall failed,
TIMEOUT
Jul 22 00:39:37 rocket /kernel: umass0: BBB reset failed, TIMEOUT
Jul 22 00:39:42 rocket /kernel: umass0: BBB bulk-in clear stall failed,
TIMEOUT
Jul 22 00:39:47 rocket /kernel: umass0: BBB bulk-out clear stall failed,
TIMEOUT
Jul 22 00:39:52 rocket /kernel: umass0: BBB reset failed, TIMEOUT
Jul 22 00:39:57 rocket /kernel: umass0: BBB bulk-in clear stall failed,
TIMEOUT
Jul 22 00:40:02 rocket /kernel: umass0: BBB bulk-out clear stall failed,
TIMEOUT
Jul 22 00:40:02 rocket syslogd: exiting on signal 15
The dump from the panic shows the following (I've kept the dump if you
want to see any more from it):
IdlePTD 3792896
initial pcb at 305c00
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc021cc0d
stack pointer = 0x10:0xc02bb744
frame pointer = 0x10:0xc02bb764
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = Idle
interrupt mask = bio
trap number = 12
panic: page fault
syncing disks...
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x30
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01fb4e0
stack pointer = 0x10:0xc02bb56c
frame pointer = 0x10:0xc02bb574
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = Idle
interrupt mask = bio
trap number = 12
panic: page fault
Uptime: 1m8s
dumping to dev #da/0x20001, offset 1785984
dump 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111
110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90
89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65
64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40
39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15
14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
---
#0 dumpsys () at ../../kern/kern_shutdown.c:472
472 if (dumping++) {
(kgdb) where
#0 dumpsys () at ../../kern/kern_shutdown.c:472
#1 0xc0155597 in boot (howto=260) at ../../kern/kern_shutdown.c:312
#2 0xc0155914 in poweroff_wait (junk=0xc02b466f, howto=0)
at ../../kern/kern_shutdown.c:559
#3 0xc0275b29 in trap_fatal (frame=0xc02bb52c, eva=48)
at ../../i386/i386/trap.c:951
#4 0xc0275801 in trap_pfault (frame=0xc02bb52c, usermode=0, eva=48)
at ../../i386/i386/trap.c:844
#5 0xc02753eb in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi
= 0,
tf_esi = -1060317440, tf_ebp = -1070877324, tf_isp = -1070877352,
tf_ebx = -1070792452, tf_edx = 6865472, tf_ecx = -919424256, tf_eax
= 0,
tf_trapno = 12, tf_err = 0, tf_eip = -1071663904, tf_cs = 8,
tf_eflags = 66050, tf_esp = -1060317440, tf_ss = -1060317440})
at ../../i386/i386/trap.c:443
#6 0xc01fb4e0 in acquire_lock (lk=0xc02d00fc)
at ../../ufs/ffs/ffs_softdep.c:271
#7 0xc01ff550 in softdep_update_inodeblock (ip=0xc0ccd700, bp=0xc34cc2a4,
waitfor=0) at ../../ufs/ffs/ffs_softdep.c:3775
#8 0xc01fa7b9 in ffs_update (vp=0xc932b300, waitfor=0)
at ../../ufs/ffs/ffs_inode.c:106
#9 0xc0202874 in ffs_sync (mp=0xc0c3e800, waitfor=2, cred=0xc0731900,
p=0xc031d100) at ../../ufs/ffs/ffs_vfsops.c:988
#10 0xc01842b7 in sync (p=0xc031d100, uap=0x0) at
../../kern/vfs_syscalls.c:545
#11 0xc015534a in boot (howto=256) at ../../kern/kern_shutdown.c:233
#12 0xc0155914 in poweroff_wait (junk=0xc02b466f, howto=0)
at ../../kern/kern_shutdown.c:559
#13 0xc0275b29 in trap_fatal (frame=0xc02bb704, eva=0)
at ../../i386/i386/trap.c:951
#14 0xc0275801 in trap_pfault (frame=0xc02bb704, usermode=0, eva=0)
---Type <return> to continue, or q <return> to quit---
at ../../i386/i386/trap.c:844
#15 0xc02753eb in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16,
tf_edi = -1059803776, tf_esi = 0, tf_ebp = -1070876828,
tf_isp = -1070876880, tf_ebx = -1059803776, tf_edx = -1060261576,
tf_ecx = -1059803776, tf_eax = 0, tf_trapno = 12, tf_err = 0,
tf_eip = -1071526899, tf_cs = 8, tf_eflags = 66118,
tf_esp = -1059803776, tf_ss = -1059803776}) at
../../i386/i386/trap.c:443
#16 0xc021cc0d in usbd_transfer (xfer=0xc0d4ad80) at
../../dev/usb/usbdi.c:285
#17 0xc0225673 in umass_setup_ctrl_transfer (sc=0xc0d53000,
udev=0xc0cd7da0,
req=0xc0d53076, buffer=0x0, buflen=0, flags=0, xfer=0xc0d4ad80)
at ../../dev/usb/umass.c:1049
#18 0xc02256e5 in umass_clear_endpoint_stall (sc=0xc0d53000, endpt=2,
pipe=0xc0cc1c00, state=9, xfer=0xc0d4ad80) at
../../dev/usb/umass.c:1082
#19 0xc0225cf1 in umass_bbb_state (xfer=0xc0d4ae00, priv=0xc0d53000,
err=USBD_IOERROR) at ../../dev/usb/umass.c:1513
#20 0xc021d387 in usb_transfer_complete (xfer=0xc0d4ae00)
at ../../dev/usb/usbdi.c:839
#21 0xc021a4e5 in ohci_process_done (sc=0xc0729000, done=130123200)
at ../../dev/usb/ohci.c:1248
#22 0xc021a262 in ohci_intr1 (sc=0xc0729000) at ../../dev/usb/ohci.c:1065
#23 0xc021a155 in ohci_intr (p=0xc0729000) at ../../dev/usb/ohci.c:994
(kgdb)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010722000136.Q54613-100000>