From: Justin Piszcz <jpiszcz@lucidpixels.com>
To: Matthew Dharm <mdharm-kernel@one-eyed-alien.net>
Cc: Alan Stern <stern@rowland.harvard.edu>,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
nut-upsuser@lists.alioth.debian.org, bruce.w.allan@intel.com,
Alan Piszcz <ap@solarrain.com>
Subject: Re: 2.6.31.4: Intel P55 Chipset BUG [usbhid-raw/devices/broken?] [tested 3 different UPS']
Date: Sun, 1 Nov 2009 16:25:33 -0500 (EST) [thread overview]
Message-ID: <alpine.DEB.2.00.0911011623290.4142@p34.internal.lan> (raw)
In-Reply-To: <alpine.DEB.2.00.0911011613270.2767@p34.internal.lan>
On Sun, 1 Nov 2009, Justin Piszcz wrote:
>
>
> On Sun, 1 Nov 2009, Matthew Dharm wrote:
>
>> On Sun, Nov 01, 2009 at 12:11:44PM -0500, Alan Stern wrote:
>>> On Sat, 31 Oct 2009, Justin Piszcz wrote:
>>>
>>>> 1. 5 minutes of usbmon output on via chipset [working]
>>>> 2. 5 minutes of usbmon output on intel p55 usb chipset [ehci/not working]
>>>
>>> To summarize the differences between the logs, the Intel controller
>>> shows occasional instances of failed transfers like this:
>>>
>>> ffff8802138c8500 3487005687 S Ci:2:004:0 s 81 06 2100 0000 0009 9 <
>>> ffff8802138c8500 3487006051 C Ci:2:004:0 -32 0
>>>
>>> while the corresponding transfers worked with the VIA controller:
>>>
>>> ffff88020c46dd40 1774844264 S Ci:4:002:0 s 81 06 2100 0000 0009 9 <
>>> ffff88020c46dd40 1774855248 C Ci:4:002:0 0 9 = 09211001 21012237 04
>>>
>>> and indeed they worked in the other Intel logs (the failures appeared
>>> to be more or less at random).
>>>
>>> This does indeed look like a low-level hardware problem, but I'm
>>> hesitant to blame it on the chipset. For example, the problem might
>>> lie in the hub you've got between the UPS and the computer. I know,
>>> this doesn't explain why everything works okay with the VIA controller.
>>> Probably the only way to tell for sure what's really happening is by
>>> using an expensive bus analyzer.
>>>
>>> Have you tried bypassing that hub, and plugging the UPS directly into
>>> the computer?
>
> Hi,
>
> I do not use any hubs in this environment, everything is directly attached to
> the motheboard. Per Matthew (noted below) when I
> mention hub I am talking about your typical USB hub one would
> attach to a USB port on the board, not the integrated one on the
> motherboard. Everything is directly attached from the motherboard
> to each respective device.
>
> MOBO -> UPS
> MOBO -> KBD
> MOBO -> etc
>
>
>>
>> I think P55 chipset has an integrated hub, which is not removeable. The
>> only USB controller is EHCI, and that is connected directly to a hub in the
>> silicon which provides multiple downstream ports and does the translation
>> to 1.0 speeds. So the hub cannot be bypassed.
>>
>> Two things to note:
>>
>> 1) Not all ports on that silicon are the same. Specifically, ports 1 and 9
>> have special properties (related to USB-based debugging). You should try
>> other ports (note that I count ports starting at 0).
> I have tested every port on the motherboard (the 8 on the back and 4 off
> of the USB headers on the motherboard):
> http://home.comcast.net/~jpiszcz/20091101/ports.txt
>
> The problem occurred on every port.
>
>>
>> 2) I noticed this article:
>> http://www.theregister.co.uk/2009/10/30/iphone_p55_problems/ -- this may
>> suggest that there are other issues with P55 chipset and USB. According to
>> this article, as with this reported issue, adding an external USB hub
>> doesn't help, but an add-in PCI USB card does. We may have to consider a
>> P55 issue as a possibility here.
> Very interesting-- the C-state option for the CPU is on/enabled in the
> BIOS, it has always remained on, I never disabled it.
>
> Justin.
>
>
One note to add:
There is one final port on the motherboard itself near the CPU
but I would need to remove my motherboard and HSF/remove many cards etc
to be able to test that one.
All ports besides the one directly on the motherboard have been tested and
the error persists on them.
Justin.
next prev parent reply other threads:[~2009-11-01 21:25 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-29 14:58 2.6.31.4: Any other suggestions regarding a UPS/USB (APC1500VA) on (Intel P55KG) stale issue? Justin Piszcz
2009-10-31 11:59 ` 2.6.31.4: Intel P55 Chipset BUG [usbhid-raw/devices/broken?] [tested 3 different UPS'] Justin Piszcz
2009-10-31 15:18 ` Alan Stern
2009-10-31 23:43 ` Justin Piszcz
2009-11-01 0:07 ` Arjan van de Ven
2009-11-01 8:55 ` Justin Piszcz
2009-11-01 17:11 ` Alan Stern
2009-11-01 17:52 ` Matthew Dharm
2009-11-01 21:18 ` Justin Piszcz
2009-11-01 21:25 ` Justin Piszcz [this message]
2009-11-02 0:49 ` Matthew Dharm
2009-11-02 13:43 ` Henrique de Moraes Holschuh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.00.0911011623290.4142@p34.internal.lan \
--to=jpiszcz@lucidpixels.com \
--cc=ap@solarrain.com \
--cc=bruce.w.allan@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mdharm-kernel@one-eyed-alien.net \
--cc=nut-upsuser@lists.alioth.debian.org \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®