On Tue, Apr 25, 2000 at 11:40:55AM -0700, Matthew Dharm wrote:
> > P: Vendor=03f0 ProdID=0107 Rev= 2.00
> > S: Manufacturer=Shuttle Technology Inc.
> > S: Product=HP USB CD-Writer Plus
> >
> > At Linux kernel 2.3.99-pre4 (plus some patches) I got as far as
> > getting the device recognized, and even probed to some extent.
> > All I did was to add following lines to "unusual" device list:
> >
> > { 0x03f0, 0x0107, 0x0200,
> > "HP USB CD-Writer Plus", US_SC_8020, US_PR_CB, US_FL_SINGLE_LUN },
Oops.. my "uname -r" says: 2.3.99-pre6-4; a bit different
than -pre4..
> Hrm... well, it certainly looks like you're moving in the right direction.
> If you do find a configuration for the unusual_dev_list that does work,
> let me know and I'll include it in the driver.
>
> So, the device is detected and shows up in /proc/scsi/scsi. Can you
> access /dev/scd0?
Yes. I can mount CDROM on /dev/scd0 with
US_SC_SCSI, UR_PR_CB, US_FL_SINGLE_LUN
...
> Oh, you might also want to try US_PR_CBI -- it might work better (or not
> at all).
I tried -- and got a *lot* of junk to my face about bad
interrupts..
> And is the SINGLE_LUN flag strictly necessary? I like to apply a few
> flags as possible, even if the device is known to be only a single-lun
> device. The flag is there for devices which improperly respond to every
> LUN.
No idea, just followed other examples.
Next will try this variant (I think it is generic USB/SCSI bridge
by the Shuttle Technology, and used by various vendors, like HP,
to implement USB devices. Checking vendor codes would tell..)
{ 0x03f0, 0x0107, 0x0200,
"USB/SCSI bridge", US_SC_SCSI, US_PR_CBI, 0},
That blows to my face with constantly repeating:
Apr 25 22:53:20 mea kernel: usb-storage.c: -- IRQ data length is 0
Apr 25 22:53:20 mea kernel: usb-storage.c: -- IRQ state is -32
Apr 25 22:53:20 mea kernel: usb-storage.c: -- Interrupt Status 0x8800
Apr 25 22:53:20 mea kernel: usb-storage.c: ERROR: Unwanted interrupt received!
Apr 25 22:53:20 mea kernel: usb-storage.c: USB IRQ recieved for device on host 1
Apr 25 22:53:20 mea kernel: usb-storage.c: -- IRQ data length is 0
Apr 25 22:53:20 mea kernel: usb-storage.c: -- IRQ state is -32
Apr 25 22:53:20 mea kernel: usb-storage.c: -- Interrupt Status 0x8800
Apr 25 22:53:20 mea kernel: usb-storage.c: ERROR: Unwanted interrupt received!
Apr 25 22:53:20 mea kernel: usb-storage.c: USB IRQ recieved for device on host 1
Something in order of 10-20 cycles per second, it seems.
(On 19th second there were 17 cycles.)
Apparently US_PR_CBI isn't liked (that text isn't used
anywhere for comparison as far as I can see..)
Trying:
{ 0x03f0, 0x0107, 0x0200,
"USB/SCSI bridge", US_SC_SCSI, US_PR_CB, 0},
Blows up too:
Apr 25 23:13:50 mea kernel: usb.c: registered new driver usb-storage
Apr 25 23:13:50 mea kernel: usb-storage.c: Searching unusual device list for (0x3f0,
0x107, 0x200)...
Apr 25 23:13:50 mea kernel: usb-storage.c: -- found matching device: USB/SCSI bridge
Apr 25 23:13:50 mea kernel: usb-storage.c: USB Mass Storage device detected
Apr 25 23:13:50 mea kernel: usb-storage.c: Endpoints: In 2 Out 1 Int 3 (Period 32)
Apr 25 23:13:50 mea kernel: usb-storage.c: Result from usb_set_interface is -58
Apr 25 23:13:50 mea kernel: usb-storage.c: -- Unknown error. Rejecting device
Apr 25 23:13:50 mea kernel: USB Mass Storage support registered.
Weird.. That *used* to work. Power cycling the device.
{ 0x03f0, 0x0107, 0x0200,
"HP USB CD-Writer Plus", US_SC_SCSI, US_PR_CB, 0},
Ok, that works for reading. I stop playing with protocol flags.
# cat /proc/scsi/scsi
...
Host: scsi1 Channel: 00 Id: 00 Lun: 00
Vendor: HP Model: CD-Writer+ 8200 Rev: 1.0f
Type: CD-ROM ANSI SCSI revision: 02
> > Which ever usb-storage setup is used, for some reason I get now system
> > load-average raised by one unit -- raising it to 1.0+ ...
>
> That's really misleading. What's happening is that every device has a
> control thread, which blocks on a semaphore. Unfortunately, that still
> counts as 'runable' in terms of calculating the load average. But, the
> thread really is sleeping.
Ok, so it is cosmetic. There are ways to do that without
jamming the load-avg up, although figuring it out now
needs more thought cycles than I can spare.
> > (Oh, and I don't like the end comment about unrealiable integrity..)
>
> Yeah... that should go away soon. I have a few more features that need to
> be added before I can really take that away -- MODE_SENSE_6/10 conversion,
> proper timeouts/aborts, and using the direction flag.
>
> > My machine is Alpha, if that has anything to do with the problem (e.g.
> > endianity issues..)
>
> As far as I know, the code paths you're using shouldn't have any endianity
> issues. US_PR_BULK has some, but I'll have a fix for those soon enough.
Hmm... ia32 and Alpha are both little-endian, thus I can propably
try also bulk-only transfers, although I think SCSI device will need
also control, and thus bulk-only won't be ok..
Indeed an attempt with US_PR_BULK blows up:
Apr 25 23:08:02 mea kernel: usb-ohci.c: OHCI Unrecoverable Error, controller disabled
Apr 25 23:08:30 mea last message repeated 199 times
Urgh :-(
Just for benchmark purposes I enabled everything possible
(of USB) as modules, and begun to compile them. Here are
some tidbits for other module keepers:
keybdev.c: In function `keybdev_event':
keybdev.c:136: warning: implicit declaration of function `emulate_raw'
A declaration inclusion missing somewhere.
usb-ohci.c: In function `ep_link':
usb-ohci.c:714: warning: passing arg 1 of `virt_to_bus' discards `volatile' from
pointer target type
usb-ohci.c:716: warning: passing arg 1 of `virt_to_bus' discards `volatile' from
pointer target type
usb-ohci.c:725: warning: passing arg 1 of `virt_to_bus' discards `volatile' from
pointer target type
usb-ohci.c:727: warning: passing arg 1 of `virt_to_bus' discards `volatile' from
pointer target type
usb-ohci.c:747: warning: passing arg 1 of `virt_to_bus' discards `volatile' from
pointer target type
usb-ohci.c:758: warning: passing arg 1 of `virt_to_bus' discards `volatile' from
pointer target type
usb-ohci.c:767: warning: passing arg 1 of `virt_to_bus' discards `volatile' from
pointer target type
usb-ohci.c: In function `td_fill':
usb-ohci.c:994: warning: passing arg 1 of `virt_to_bus' discards `volatile' from
pointer target type
Nuisance, but perhaps not fatal..
usb-ohci.c: In function `rh_submit_urb':
usb-ohci.c:1558: warning: cast from pointer to integer of different size
Urgh ?? Alpha 'int' is 32-bit, 'long' is 64-bit, pointer is 64-bit.
devio.c:1007: warning: initialization from incompatible pointer type
drivers.c:117: warning: initialization from incompatible pointer type
devices.c:521: warning: initialization from incompatible pointer type
I didn't dwell on these.
wmforce.c: In function `wmforce_probe':
wmforce.c:101: warning: left shift count >= width of type
wmforce.c:101: warning: left shift count >= width of type
wmforce.c:101: warning: left shift count >= width of type
wmforce.c:101: warning: left shift count >= width of type
wmforce.c:102: warning: left shift count >= width of type
wmforce.c:102: warning: left shift count >= width of type
wmforce.c:102: warning: left shift count >= width of type
wmforce.c:102: warning: left shift count >= width of type
wmforce.c:102: warning: left shift count >= width of type
Eh ?
> Matt Dharm
> --
> Matthew Dharm Home: [EMAIL PROTECTED]
> Senior Engineer, QCP Inc. Work: [EMAIL PROTECTED]
/Matti Aarnio <[EMAIL PROTECTED]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
