On Wed, 26 Apr 2000, Matti Aarnio wrote:

> 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

Hrm... is this a SCSI CD-Writer with a USB/SCSI dongle, or a device that
is really a USB device?  I ask only because it affects what I'll put in
the description string.

So, to confirm, this is the line that works for you:

>       { 0x03f0, 0x0107, 0x0200,
>         "USB/SCSI bridge", US_SC_SCSI, US_PR_CB, 0},

Now, on to other problems....

> 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},

I've seen this before.  I think it might be an HCD error -- if I
physically detach the device and reattach it and it works.  I'm not sure
why this is necessary.  Does someone with more of an HCD clue have any
ideas?

Have you tried this on an UHCI system?

> > > 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.

When you figure it out, let me know.  But yes, it's cosmetic.

> > 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..

Umm... you don't understand.  You don't have a bulk-only device, so it
will blow up, regardles of any endian issues.   If you have a Zip drive,
those are bulk-only transport devices.

Transparent SCSI or not doesn't make any difference.

Matt Dharm

-- 
Matthew Dharm                              Home: [EMAIL PROTECTED] 
Senior Engineer, QCP Inc.                        Work: [EMAIL PROTECTED]

I could always suspend a few hundred accounts and watch what happens.
                                        -- Tanya
User Friendly, 7/31/1998


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to