Am 19.12.2012 20:35, schrieb Alan Stern:
On Wed, 19 Dec 2012, [ISO-8859-1] Frank Sch�fer wrote:
I can confirm that MCP55 has this bug and it should be safe to add
MCP65-78S, too, because MCP79 still has the bug.
By the way, you mentioned that runtime suspend seemed to work okay,
right? It
Am 20.12.2012 18:34, schrieb Frank Schäfer:
Am 19.12.2012 20:35, schrieb Alan Stern:
On Wed, 19 Dec 2012, [ISO-8859-1] Frank Sch�fer wrote:
I can confirm that MCP55 has this bug and it should be safe to add
MCP65-78S, too, because MCP79 still has the bug.
By the way, you mentioned that
于 2012/12/18 4:06, Alan Stern 写道:
On Mon, 17 Dec 2012, Octavio Alvarez wrote:
On Thu, 13 Dec 2012 00:45:05 -0800, Lan Tianyu tianyu@intel.com
wrote:
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index f034716..9335f1b 100644
--- a/drivers/usb/core/hcd.c
+++
On Wed, 19 Dec 2012, Lan Tianyu wrote:
Hi Alan:
How about this patch?
Index: linux-pm/drivers/usb/host/ohci-pci.c
===
--- linux-pm.orig/drivers/usb/host/ohci-pci.c 2012-11-01
18:21:33.604460469 +0800
+++
On Wed, 19 Dec 2012, lantianyu wrote:
Oh. I forget to mention the issue also takes place on the uhci.
https://bugzilla.kernel.org/show_bug.cgi?id=42721
So we also should make such a patch for uhci.
That bug report shows clearly that it is a software problem or a device
problem, not an error
On Wed, 19 Dec 2012 07:29:23 -0800, Alan Stern st...@rowland.harvard.edu
wrote:
+ ohci_dbg(ohci, marked as bad wakeup.\n);
I'd prefer the message to be something more like enabled nVidia/SiS
wakeup quirk.
To me, the stupid end-user, both messages are useless. I don't know
that that
On Wed, 19 Dec 2012, Octavio Alvarez wrote:
On Wed, 19 Dec 2012 07:29:23 -0800, Alan Stern st...@rowland.harvard.edu
wrote:
+ ohci_dbg(ohci, marked as bad wakeup.\n);
I'd prefer the message to be something more like enabled nVidia/SiS
wakeup quirk.
To me, the stupid end-user,
On Wed, 19 Dec 2012 08:57:00 -0800, Alan Stern st...@rowland.harvard.edu
wrote:
You, the stupid end-user, would not see this message at all under
normal circumstances. It uses the ohci_dbg macro and therefore will
not appear unless your kernel is built with CONFIG_USB_DEBUG enabled.
On Wed, 19 Dec 2012, Octavio Alvarez wrote:
On Wed, 19 Dec 2012 08:57:00 -0800, Alan Stern st...@rowland.harvard.edu
wrote:
You, the stupid end-user, would not see this message at all under
normal circumstances. It uses the ohci_dbg macro and therefore will
not appear unless your
Am 19.12.2012 16:29, schrieb Alan Stern:
On Wed, 19 Dec 2012, Lan Tianyu wrote:
...
/* List of quirks for OHCI */
static const struct pci_device_id ohci_pci_quirks[] = {
{
@@ -238,6 +247,31 @@
PCI_DEVICE(PCI_VENDOR_ID_ATI, 0x4399),
.driver_data =
On Wed, 19 Dec 2012, [ISO-8859-1] Frank Sch�fer wrote:
I can confirm that MCP55 has this bug and it should be safe to add
MCP65-78S, too, because MCP79 still has the bug.
By the way, you mentioned that runtime suspend seemed to work okay,
right? It might be worthwhile testing this again,
On Wed, 19 Dec 2012 11:35:50 -0800, Alan Stern st...@rowland.harvard.edu
wrote:
As far as the OHCI hardware is concerned, there shouldn't be any
difference between runtime suspend and system suspend. This strongly
suggests that the bug doesn't lie in the controller itself but in the
firmware
On 2012年12月18日 04:06, Alan Stern wrote:
On Mon, 17 Dec 2012, Octavio Alvarez wrote:
On Thu, 13 Dec 2012 00:45:05 -0800, Lan Tianyu tianyu@intel.com
wrote:
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index f034716..9335f1b 100644
--- a/drivers/usb/core/hcd.c
+++
On Thu, 13 Dec 2012 00:45:05 -0800, Lan Tianyu tianyu@intel.com
wrote:
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index f034716..9335f1b 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2509,7 +2509,8 @@ int usb_add_hcd(struct usb_hcd *hcd,
*
On Mon, 17 Dec 2012, Octavio Alvarez wrote:
On Thu, 13 Dec 2012 00:45:05 -0800, Lan Tianyu tianyu@intel.com
wrote:
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index f034716..9335f1b 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2509,7
Am 14.12.2012 23:02, schrieb Alan Stern:
On Thu, 13 Dec 2012, Frank Schäfer wrote:
I have the MCP61 (rev. A2) with id 10de:03f1.
Further NVIDIA OHCI HCD IDs can be found at
http://openbenchmarking.org/linux/PCI/0c03.
But I'm not sure that we should blacklist them all. Maybe this bug has
On Thu, 13 Dec 2012, Frank Schäfer wrote:
I have the MCP61 (rev. A2) with id 10de:03f1.
Further NVIDIA OHCI HCD IDs can be found at
http://openbenchmarking.org/linux/PCI/0c03.
But I'm not sure that we should blacklist them all. Maybe this bug has
been fixed in newer chipset revisions /
On 2012年12月13日 04:28, Frank Schäfer wrote:
Am 12.12.2012 09:23, schrieb Lan Tianyu:
On 2012年12月12日 05:59, Frank Schäfer wrote:
Am 11.12.2012 17:48, schrieb Alan Stern:
[snip]
We really need to know which component is bad: the host controller or
the device.
It happens with all USB 1.1
Am 13.12.2012 09:45, schrieb Lan Tianyu:
[snip]
I am curious about whether disabling usb device's wakeup rather than usb
hc's would make suspend work. Can you do a test?
Go to /sys/bus/usb/devices/ and enter the usb 1,1 device
directory(normally it will be something like1-1.1.)
run echo
On Thu, 13 Dec 2012, Frank Schäfer wrote:
I write a quirk patch. Can you test?
Yes, that makes it work !
I just find one MCP51 and two MCP79 OHCI id. Can you provide more buggy
hcd id via lspci -nnvvv?
Thanks.
I have the MCP61 (rev. A2) with id 10de:03f1.
Further NVIDIA OHCI
On Thu, 13 Dec 2012 07:35:55 -0800, Frank Schäfer
fschaefer@googlemail.com wrote:
I write a quirk patch. Can you test?
Yes, that makes it work !
I just find one MCP51 and two MCP79 OHCI id. Can you provide more buggy
hcd id via lspci -nnvvv?
Thanks.
I have the MCP61 (rev. A2) with id
On 2012年12月13日 23:47, Alan Stern wrote:
On Thu, 13 Dec 2012, Frank Schäfer wrote:
I write a quirk patch. Can you test?
Yes, that makes it work !
I just find one MCP51 and two MCP79 OHCI id. Can you provide more buggy
hcd id via lspci -nnvvv?
Thanks.
I have the MCP61 (rev. A2) with id
On 2012年12月13日 23:35, Frank Schäfer wrote:
Am 13.12.2012 09:45, schrieb Lan Tianyu:
[snip]
I am curious about whether disabling usb device's wakeup rather than usb
hc's would make suspend work. Can you do a test?
Go to /sys/bus/usb/devices/ and enter the usb 1,1 device
directory(normally
On 2012年12月12日 05:59, Frank Schäfer wrote:
Am 11.12.2012 17:48, schrieb Alan Stern:
[snip]
We really need to know which component is bad: the host controller or
the device.
It happens with all USB 1.1 devices I have (several mice and a HP
Deskjet 960c printer).
The same devices do not
On Wed, 12 Dec 2012, Lan Tianyu wrote:
Hi Alan:
About your question of Does the device send a remote wakeup request
even when it is disabled for remote wakeup?, I am not very clear.
Default, device remote wakeup is disabled and if we disable device's
remote wakeup via sysfs, the
Am 12.12.2012 09:23, schrieb Lan Tianyu:
On 2012年12月12日 05:59, Frank Schäfer wrote:
Am 11.12.2012 17:48, schrieb Alan Stern:
[snip]
We really need to know which component is bad: the host controller or
the device.
It happens with all USB 1.1 devices I have (several mice and a HP
Deskjet
On Wed, 12 Dec 2012 12:28:16 -0800, Frank Schäfer
fschaefer@googlemail.com wrote:
Good information. Attaching device makes hc work abnormally during
entering into s3 since without device it can work, right?
Right.
The system successfully enters S3 (machine switches off = fan stops,
On 2012年12月12日 23:50, Alan Stern wrote:
On Wed, 12 Dec 2012, Lan Tianyu wrote:
Hi Alan:
About your question of Does the device send a remote wakeup request
even when it is disabled for remote wakeup?, I am not very clear.
Default, device remote wakeup is disabled and if we disable
Hi AlanGreg:
Since 3.1, Alan enabled usb device wakeup default, there are
a lot of problem that immediately resume when enter into s2ram/s2disk.
I have traced some these bugs. Most of these bugs are related usb1.1
device which attached to OHCI/UHCI. If disable the hc wakeup or no device
On Tue, 11 Dec 2012, Lan Tianyu wrote:
Hi AlanGreg:
Since 3.1, Alan enabled usb device wakeup default, there are
a lot of problem that immediately resume when enter into s2ram/s2disk.
I have traced some these bugs. Most of these bugs are related usb1.1
device which attached to
Am 11.12.2012 17:48, schrieb Alan Stern:
[snip]
We really need to know which component is bad: the host controller or
the device.
It happens with all USB 1.1 devices I have (several mice and a HP
Deskjet 960c printer).
The same devices do not cause other machines to wake up, so I assume
it's
On Mon, 9 Jul 2012, Octavio Alvarez wrote:
What happens if you unplug only the keyboard, or only the mouse?
The only thing I can confirm for now is that with both disconnected
the system consistently suspends and that I have seen the system NOT
suspend with either one connected.
Having
On 10/05/2012 07:56 AM, Alan Stern wrote:
On Mon, 9 Jul 2012, Octavio Alvarez wrote:
What happens if you unplug only the keyboard, or only the mouse?
The only thing I can confirm for now is that with both disconnected
the system consistently suspends and that I have seen the system NOT
Am 05.10.2012 18:44, schrieb Octavio Alvarez:
On 10/05/2012 07:56 AM, Alan Stern wrote:
On Mon, 9 Jul 2012, Octavio Alvarez wrote:
What happens if you unplug only the keyboard, or only the mouse?
The only thing I can confirm for now is that with both disconnected
the system consistently
On Sun, 08 Jul 2012 17:28:25 -0700, Alan Stern st...@rowland.harvard.edu
wrote:
Removing my pen drive cleared CCS on [6].
Okay, that explains that. More or less. Is this an old USB-1.1 pen
drive? If it is USB-2.0 then I would expect it to connect to the EHCI
controller, not the OHCI
On Mon, 9 Jul 2012, Octavio Alvarez wrote:
On Sun, 08 Jul 2012 17:28:25 -0700, Alan Stern st...@rowland.harvard.edu
wrote:
Removing my pen drive cleared CCS on [6].
Okay, that explains that. More or less. Is this an old USB-1.1 pen
drive? If it is USB-2.0 then I would expect
On Sat, 7 Jul 2012, Octavio Alvarez wrote:
On Sat, 07 Jul 2012 19:23:08 -0700, Alan Stern st...@rowland.harvard.edu
wrote:
roothub.portstatus [4] 0x0303 LSDA PPS PES CCS
roothub.portstatus [5] 0x0303 LSDA PPS PES CCS
roothub.portstatus [6] 0x0101 PPS CCS
That's normal,
On Sun, 08 Jul 2012 07:40:49 -0700, Alan Stern st...@rowland.harvard.edu
wrote:
On Sat, 7 Jul 2012, Octavio Alvarez wrote:
On Sat, 07 Jul 2012 19:23:08 -0700, Alan Stern
st...@rowland.harvard.edu
wrote:
roothub.portstatus [4] 0x0303 LSDA PPS PES CCS
roothub.portstatus [5] 0x0303
On Sun, 8 Jul 2012, Octavio Alvarez wrote:
On Sat, 07 Jul 2012 19:23:08 -0700, Alan Stern
st...@rowland.harvard.edu
wrote:
roothub.portstatus [4] 0x0303 LSDA PPS PES CCS
roothub.portstatus [5] 0x0303 LSDA PPS PES CCS
roothub.portstatus [6] 0x0101 PPS CCS
Hi, Alan!
So, after about more than a week of bisecting, and thanks to Jonathan
Nieder's
more-than-precise instructions, the results are in.
On Mon, 25 Jun 2012 11:41:31 -0700, Alan Stern st...@rowland.harvard.edu
wrote:
On Mon, 25 Jun 2012, Octavio Alvarez wrote:
On Mon, 25 Jun 2012
On Sat, 7 Jul 2012, Octavio Alvarez wrote:
If you build a kernel with CONFIG_USB_DEBUG enabled, what
shows up in /sys/kernel/debug/usb/ohci/*/registers?
[Sat Jul 07 12:49:27 -0700 -- alvarezp@octavio:/sys/kernel/debug/usb]
$ grep . ohci/*/registers
bus pci, device :00:0b.0
OHCI Host
Hi,
Quick administrivia.
Alan Stern wrote:
Yes, that commit enables wakeup for USB host controllers by default.
Before that, you had to enable wakeup by hand. The question is: Why
does the controller think it needs to wake up the system?
Yotam Benshalom from
On Sat, 07 Jul 2012 19:23:08 -0700, Alan Stern st...@rowland.harvard.edu
wrote:
Also, what does the lspci -vv output show for the controller if you
run it with superuser permissions?
[Sat Jul 07 12:50:10 -0700 -- alvarezp@octavio:/sys/kernel/debug/usb]
$ sudo lspci -vv -s :00:0b.1
Hi Octavio,
Quick instructions:
Alan Stern wrote:
It might be worthwhile tracking down the reason for the immediate
wakeup. If you build a kernel with CONFIG_USB_DEBUG enabled, what
shows up in /sys/kernel/debug/usb/ohci/*/registers? And what shows up
in /sys/kernel/debug/usb/devices?
On Sun, 24 Jun 2012, Ben Hutchings wrote:
[The full log for this bug is at http://bugs.debian.org/677472]
On Thu, 2012-06-14 at 09:28 -0700, Octavio Alvarez wrote:
Under normal circumstances the system simply does not suspend. It appears
to go all the way to suspension (screen off,
On Mon, 25 Jun 2012 07:33:11 -0700, Alan Stern st...@rowland.harvard.edu
wrote:
What happens if Octavio disables wakeup for that controller before
suspending?
echo disabled /sys/bus/pci/devices/:00:0b.0/power/wakeup
On kernel 3.2, it lets suspend work again.
For kernel 3.4, I'll
On Mon, 25 Jun 2012, Octavio Alvarez wrote:
On Mon, 25 Jun 2012 07:33:11 -0700, Alan Stern st...@rowland.harvard.edu
wrote:
What happens if Octavio disables wakeup for that controller before
suspending?
echo disabled /sys/bus/pci/devices/:00:0b.0/power/wakeup
On kernel 3.2,
[The full log for this bug is at http://bugs.debian.org/677472]
On Thu, 2012-06-14 at 09:28 -0700, Octavio Alvarez wrote:
Under normal circumstances the system simply does not suspend. It appears
to go all the way to suspension (screen off, disks off, etc.) but when it
appears that it is
48 matches
Mail list logo
