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 mentione
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,
> righ
On Wed, 19 Dec 2012 11:35:50 -0800, Alan Stern
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 (BIOS or ACPI).
Is there
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, ju
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_dat
On Wed, 19 Dec 2012, Octavio Alvarez wrote:
> On Wed, 19 Dec 2012 08:57:00 -0800, Alan Stern
> 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
On Wed, 19 Dec 2012 08:57:00 -0800, Alan Stern
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.
Shouldn't it be exposed to dmesg
On Wed, 19 Dec 2012, Octavio Alvarez wrote:
> On Wed, 19 Dec 2012 07:29:23 -0800, Alan Stern
> 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 mes
On Wed, 19 Dec 2012 07:29:23 -0800, Alan Stern
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 means or implies. I woul
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 erro
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
> +++ linux-pm
于 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
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
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
>> 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/driv
On Mon, 17 Dec 2012, Octavio Alvarez wrote:
> On Thu, 13 Dec 2012 00:45:05 -0800, Lan Tianyu
> 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 @@ i
On Thu, 13 Dec 2012 00:45:05 -0800, Lan Tianyu
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,
* they only forward requ
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
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日 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
>>
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
On Thu, 13 Dec 2012 07:35:55 -0800, 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
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.
>
> Furthe
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 like"1-1.1"
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
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 d
On Wed, 12 Dec 2012 12:28:16 -0800, Frank Schäfer
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,
light off etc.) but it resumes im
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
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
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 de
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
On Tue, 11 Dec 2012, Lan Tianyu wrote:
> Hi Alan&Greg:
> 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
Hi Alan&Greg:
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
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
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
suspen
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.
>
>
On Mon, 9 Jul 2012, Octavio Alvarez wrote:
> On Sun, 08 Jul 2012 17:28:25 -0700, Alan Stern
> 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
On Sun, 08 Jul 2012 17:28:25 -0700, Alan Stern
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 controller.
I don't
On Sun, 8 Jul 2012, Octavio Alvarez wrote:
> >> On Sat, 07 Jul 2012 19:23:08 -0700, Alan Stern
> >>
> >> wrote:
> >>
> >> >> roothub.portstatus [4] 0x0303 LSDA PPS PES CCS
> >> >> roothub.portstatus [5] 0x0303 LSDA PPS PES CCS
> >> >> roothub.portstatus [6] 0x0101 PPS CCS
> >> >
> >
On Sun, 08 Jul 2012 07:40:49 -0700, Alan Stern
wrote:
On Sat, 7 Jul 2012, Octavio Alvarez wrote:
On Sat, 07 Jul 2012 19:23:08 -0700, Alan Stern
wrote:
>> roothub.portstatus [4] 0x0303 LSDA PPS PES CCS
>> roothub.portstatus [5] 0x0303 LSDA PPS PES CCS
>> roothub.portstatus [6] 0x00
On Sat, 7 Jul 2012, Octavio Alvarez wrote:
> On Sat, 07 Jul 2012 19:23:08 -0700, Alan Stern
> 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, except fo
On Sat, 07 Jul 2012 19:23:08 -0700, Alan Stern
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
0b.1 is the EHCI control
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 https://bugzilla.kernel.org
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
> O
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
wrote:
On Mon, 25 Jun 2012, Octavio Alvarez wrote:
On Mon, 25 Jun 2012 07:33:11 -0700, Alan Stern
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/device
On Mon, 25 Jun 2012, Octavio Alvarez wrote:
> On Mon, 25 Jun 2012 07:33:11 -0700, Alan Stern
> 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 sus
On Mon, 25 Jun 2012 07:33:11 -0700, Alan Stern
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 break it into two parts:
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
[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