linux-kernel - Re: [linux-usb-devel] ThinkPad T41

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.44L0.0706121042260.7096-100000@iolanthe.rowland.org>
Date:	Tue, 12 Jun 2007 10:54:27 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Robert de Rooy <robert.de.rooy@...il.com>
cc:	Jiri Kosina <jikos@...os.cz>, Greg KH <greg@...ah.com>,
	<Joel.Becker@...cle.com>,
	USB development list <linux-usb-devel@...ts.sourceforge.net>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: [linux-usb-devel] ThinkPad T41 - Strange USB 2.0 behaviour

On Tue, 12 Jun 2007, Robert de Rooy wrote:

> Alan Stern wrote:
> > On Tue, 12 Jun 2007, Robert de Rooy wrote:
> >
> >   
> >> Yes that works.
> >> I tried to plug and unplug the device repeatedly and each time it came 
> >> up in full-speed mode.
> >>     
> >
> > Good!  I'm glad that "companion" attribute file has come in handy for 
> > someone.  :-)
> >
> > Alan Stern
> >   
> 
> Any way of passing this as a boot parameter?

Sorry, no.  Or not without difficulty, anyway.  The problem is that a
boot parameter would have to specify which EHCI controller it applied
to (some computers have more than one), which complicates things.

>  Because I also encountered 
> this when trying to boot Linux from a USB CD-ROM drive. The BIOS part 
> worked fine, but the moment Linux loaded USB support it failed, due to 
> the same problem. This is also why I asked if this failure mode could be 
> handled automatically.

If you control the contents of the CD then perhaps you can include the
necessary command as part of an initrd script.

Another thought occurred: These problems may well be the result of 
interference from an SMI BIOS.  Check your BIOS settings and see if 
there's anything which can be disabled, or see if there's a BIOS update 
available.

This particular failure mode is not amenable to automatic handling, 
since there is no simple way to distinguish it from a valid usage 
(someone plugging in a device and then unplugging it).

If somebody is motivated enough, they might add code to detect too many
connect-change events occurring on a port in a limited period of time.  
This would require storing a fair amount of extra information for each
port on each USB hub.  Then you would still need some sort of interface
for the automatic speed reduction.  It could be done, but I don't want
to work on it.

Alan Stern

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