On Tue, 25 Apr 2000, Matti Aarnio wrote:
> I decided to see if current infrastructure already supports
> this gadget:
>
> T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
> D: Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
> P: Vendor=03f0 ProdID=0107 Rev= 2.00
> S: Manufacturer=Shuttle Technology Inc.
> S: Product=HP USB CD-Writer Plus
> C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA
> I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=usb-storage
> E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl= 0ms
> E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl= 0ms
> E: Ad=83(I) Atr=03(Int.) MxPS= 2 Ivl= 32ms
>
>
> 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 },
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?
> Reading the kernel log (below) seems to indicate that proper SUBCLASS is
> likely US_SC_SCSI, and not this "8020" ATAPI thing which was my first
> pick...
Possibly. You're probably just going to have to try several different
options on this.
Oh, you might also want to try US_PR_CBI -- it might work better (or not
at all).
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.
> 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.
> (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.
Matt Dharm
--
Matthew Dharm Home: [EMAIL PROTECTED]
Senior Engineer, QCP Inc. Work: [EMAIL PROTECTED]
You are needink to look more evil. You likink very strong coffee?
-- Pitr to Dust Puppy
User Friendly, 10/16/1998
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
