Re: Bug with USB proc_bulk in 2.4 kernel

[Benjamin Cherian]

Hi Pete,

> This consideration is wholly irrelevant to the pertinent topic,
> because the very issue arises from devices being non-compliant.
> If we want them to operate, we have to apply workarounds, which
> may but us outside of the spec envelope. So I am not even going
> to argue if the spec in fact mandates this behaviour.

I understand the need to apply workarounds.  But here is why the spec is 
relevant.  By applying workarounds you have *broken* the functionality of 
Linux with respect to the USB specification.  In my opinion, workarounds 
should be constrained to fixing the problem rather than creating new ones.


> > This is exactly what I suggested in my first email. It just involves
> > adding a couple of lines of code, but I'm not sure how the unlock
> > function works in 2.4. In 2.6, the device is unlocked WITHIN proc_bulk
> > before usb_bulk_mesg is called and is locked after usb_bulk_mesg returns.
> > Therefore, the device is still locked during control transfers.
>
> I explained why this technique is not applicable to 2.4 in the part
> of the message you failed to quote. To recap, if bulk methods were
> simply to drop locks with a "couple of lines of code", they would allow
> control transfers to happen simultaneously with bulk transfers.
> It happens to work in 2.6 only because of its string caching feature.
> Indeed, Stuart Hayes of Dell reported that he can cause TEAC CD-210PU
> to break under 2.6.16 in the same way it did in 2.4.27, simply by doing
> "lsusb -v" instead of "cat /proc/bus/usb/devices". The issue is still
> with us. Greg chose to bypass it in 2.6, instead of fixing it, due
> to the amount of work involved.

Honestly, you provided very little information in your initial email.  I had 
to dig through the kernel source to make sense of what was going on.  Even 
for the above, I'm not understanding why "lsusb -v" causes problems under 
2.6.16.  Does the "-v" option cause the kernel to send control packets to the 
device?  You have to understand that the USB driver stack under Linux is not 
my domain of expertise and I'm coming to you with a problem that is not of my 
doing.  It would help a great deal to receive more details from you.


> This is a fixable issue, but it's not two lines of code. And its
> impact is very limited. If you, the person who actually suffers, are
> not willing to do the necessary work, then why would anyone else be?
> Still, I would be happy to consider your patch, if it were to emerge.

It is really looking like you are backing me into a corner to make the change 
myself.  However, before doing so I'd like to say that I am disappointed that 
the kernel developer list has not been more accommodating to this issue.  I 
understand that this problem only affects very few people.  However, please 
consider the spirit of what has happened here.  My device adheres to the 
specification.  In an effort to fix other devices that do not adhere to the 
specification you have broken my device.  Then I am being asked to make 
modifications to the OS, when clearly this is not my domain.  We all want 
Linux to be a primetime operating system and this sort of interaction with 
the developers list is *not* representative of that desire.

Besides, the device that is being broken is a 10x CD-ROM drive!  Who even uses 
these anymore? :-)

Regards,

Benjamin Cherian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/