[ale] USB reset error in dmesg [SOLVED]
Rich Faulkner
rfaulkner at Tux86.org
Mon Jun 18 14:01:31 EDT 2012
In this case I think it's a matter of new hardware and older drivers.
RHEL 6.x supports everything in this regard just fine. It's 5.x (final
testing done w/CentOS 5.5 baremetal install) that has the issue. I've
seen this before but in Windows; the Power Technology feature from Intel
not being well supported by power management in the OS. XP SP2 supports
it well while it is broken in SP3. (But then again, MS is just plain
broken no matter what you do to it.) I chalk it up to a necessary tweak
in the BIOS for optimal tuning for this case.
On Mon, 2012-06-18 at 13:33 -0400, Jim Kinney wrote:
> wow! underscores that some hardware platforms are just a bit "funky"
>
>
> On Mon, Jun 18, 2012 at 11:52 AM, Rich Faulkner <rfaulkner at tux86.org>
> wrote:
>
> Believe I've found the solution to this so thought I'd share
> it here...
>
> I was able to narrow down a few factors in this:
>
> 1. Issue dependent on v5 RHEL family (driver related)
> 2. Issue effected by changing feature in BIOS (memory
> related)
> 3. Issue centered around EHCI driver and visible as power
> loss in USB optical mouse (power related)
>
> This pointed me toward a BIOS feature for Intel Power
> Technology. Disabling this feature allowed proper
> functionality of the device (in this case the USB optical
> mouse). Further digging into the feature found that setting
> the Processor C State limit to [C0] provides operational
> functionality w/o power-up/down of USB optical mouse. No
> further errors observed.
>
> Waiting to hear results of field testing but I think this is
> it: that when low/high speed devices are connected through a
> USB 2.0 hub to the EHCI hub with Energy Efficiency enabled;
> the EHCI starts split transactions, but gets delayed while
> trying to access memory. Because of this, EHCI cannot
> complete the split transaction before the transaction
> translator in the hub discards the data. The hid-core driver
> retires the transaction but it also fails and the USB device
> is reset.
>
> It is notable that this behaviour is not seen using this BIOS
> and RHEL 6.x (CentOS or Scientific Linux).
>
> Cheers!
>
> RinL
>
>
>
>
> On Sat, 2012-06-16 at 04:21 -0400, Rich Faulkner wrote:
>
> > Attaching a PS/2 mouse and keyboard resolve the error but by
> > only removing the device(s) that are causing the problem.
> > That is not a solution as all USB have to be working. I
> > have recommended that the OS be migrated to 6.x but don't
> > know that this will be accepted. Another find was setting
> > the BIOS to support multi-monitor mode (an interesting
> > connection); the error is not induced. Only in
> > single-monitor mode does the USB mouse/keyboard go bugger.
> > So there is a BIOS connection here for resource allocation
> > that interacts with EHCI driver (or USB driver) and the
> > function of low-speed USB device(s).
> >
> > In the end, the mouse and keyboard are constantly
> > powering-up and down. Looks like they fail and
> > reinitialize; then fail; then initialize. Up, down, up
> > down...sand-a-floor; side-to-side...you get my drift...
> >
> >
> > On Fri, 2012-06-15 at 17:13 -0400, Jim Kinney wrote:
> >
> > > Oh. good catch! I have not had the chance to look at "the
> > > piles" here
> > >
> > > So disconnecting the mouse will stop the failures?
> > >
> > > On Fri, Jun 15, 2012 at 5:09 PM, Rich Faulkner
> > > <rfaulkner at tux86.org> wrote:
> > >
> > > The plot thickens: found the MS USB mouse is at
> > > issue...
> > >
> > > - The low speed USB device using ehci_hcd and
> > > address 3 is the Microsoft 3-Button Mouse as /
> > > class/ input/ input0 on usb-0000:00:1d.0-1.1
> > >
> > > - dmesg indicates: PCI: cache line size of 32 is
> > > not supported by device 0000:00:1d.0
> > >
> > > - I can see the USB 2.0, and EHCI 1.00 driver
> > > started for this device as well
> > >
> > > Observation of the mouse shows power blinking-off
> > > periodically. Keyboard (USB) acts like it has
> > > sticking keys periodically. I suspect this will
> > > goof-up most anything attached to the USB bus.
> > >
> > > I have been trying some kernel parameters to
> > > grub.conf but no improvement thus far to the
> > > mouse. (Only got rid of an issue concerning
> > > mtrr). Another hint in this is that when you set
> > > the BIOS for multi-monitor support the problem
> > > goes away. (Yes, I know we could set that and
> > > leave it but that's not the point. Need to find
> > > the fix for this other than a workaround like 6.x
> > > or the BIOS setting).
> > >
> > > TIA.......Rich
> > >
> > >
> > >
> > >
> > > > > Chipset is the Intel C206 (PCH). Datasheet
> > > > > for the SHB is here:
> > > > > http://www.trentontechnology.com/downloads/datasheets/trenton_tsb7053_productdatasheet.pdf
> > >
> > >
> > >
> > >
> > > > > > I have come across a problem with
> > > > > > RHEL 5.x family where I am getting
> > > > > > the following output in dmesg:
> > > > > >
> > > > > > "usb 2-1.1: reset low speed USB
> > > > > > device using ehci_hcd and address 3"
> > > > > >
> > > > > > My USB attached keyboard and mouse
> > > > > > do not function properly (lag and
> > > > > > inaccurate output). It looks like
> > > > > > there is an issue in the system
> > > > > > support of USB but it only seems to
> > > > > > exist in 5.x family. Once tested in
> > > > > > 6.x it all works. (Testing with
> > > > > > both CentOS and Scientific Linux -
> > > > > > live and installed samples)
> > > > > >
> > > > > > I am going through the debug output
> > > > > > manually but thought I'd shoot this
> > > > > > over here for a more experienced
> > > > > > perspective from those with grayer
> > > > > > beards than I...
> > > > > >
> > > > > > TIA........Rich
>
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
>
>
>
>
> --
> --
> James P. Kinney III
>
> Every time you stop a school, you will have to build a jail. What you
> gain at one end you lose at the other. It's like feeding a dog on his
> own tail. It won't fatten the dog.
> - Speech 11/23/1900 Mark Twain
>
> http://electjimkinney.org
> http://heretothereideas.blogspot.com/
>
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20120618/cc344578/attachment-0001.html
More information about the Ale
mailing list