I've been getting a 45 sec
pause when waking my machine up
on the first cycle using s2ram.
At first thought it was udev, but later
am not sure it is. With further looking
if I remove the isight_firmware module from the kernel
suspend wakes up the first cycle as it should.(I don't have
isight-firmware-tools installed, leading me to believe this might
be the issue with isight-firmware.ko.)
Now looking at dmesg I see:
[ 413.551845] uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23
[ 413.551855] uhci_hcd 0000:00:1d.0: setting latency timer to 64
[ 413.551887] usb usb2: root hub lost power or was reset
[ 413.551927] uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 19 (level, low) -> IRQ 19
[ 413.551937] uhci_hcd 0000:00:1d.1: setting latency timer to 64
[ 413.551967] usb usb3: root hub lost power or was reset
[ 413.552019] uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
[ 413.552029] uhci_hcd 0000:00:1d.2: setting latency timer to 64
[ 413.552058] usb usb4: root hub lost power or was reset
[ 413.552094] uhci_hcd 0000:00:1d.3: PCI INT D -> GSI 16 (level, low) -> IRQ 16
[ 413.552104] uhci_hcd 0000:00:1d.3: setting latency timer to 64
[ 413.552134] usb usb5: root hub lost power or was reset
[ 413.552172] ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 23 (level, low) -> IRQ 23
[ 413.552182] ehci_hcd 0000:00:1d.7: setting latency timer to 64
[ 413.552200] pci 0000:00:1e.0: setting latency timer to 64
[ 413.552217] ata_piix 0000:00:1f.1: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[ 413.552225] ata_piix 0000:00:1f.1: setting latency timer to 64
[ 413.554437] ata_piix 0000:00:1f.2: PCI INT B -> GSI 19 (level, low) -> IRQ 19
[ 413.554446] ata_piix 0000:00:1f.2: setting latency timer to 64
[ 413.554548] pci 0000:00:1f.3: PCI INT B -> GSI 19 (level, low) -> IRQ 19
[ 413.554559] pci 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 413.554567] pci 0000:01:00.0: setting latency timer to 64
for a bit I thought that this was also the cause of the delay
but the system wakes up as it should even with this happening to
usb.
BTW: Is CONFIG_USB_PERSIST in the kernel anymore
with 2.6.32*?(I can't seem to find that option);
--
Justin P. Mattock
Am Mittwoch, 2. Dezember 2009 23:34:30 schrieb Justin Mattock:
> for a bit I thought that this was also the cause of the delay
> but the system wakes up as it should even with this happening to
> usb.
Perhaps something does an operation that needs to time out.
Which drivers have you loaded when it works and when it doesn't work?
> BTW: Is CONFIG_USB_PERSIST in the kernel anymore
> with 2.6.32*?(I can't seem to find that option);
It is always used and switched on by default.
Regards
Oliver
On Wed, Dec 2, 2009 at 3:19 PM, Oliver Neukum <[email protected]> wrote:
> Am Mittwoch, 2. Dezember 2009 23:34:30 schrieb Justin Mattock:
>
>> for a bit I thought that this was also the cause of the delay
>> but the system wakes up as it should even with this happening to
>> usb.
>
> Perhaps something does an operation that needs to time out.
> Which drivers have you loaded when it works and when it doesn't work?
right now, the only module I removed(which was causing my s2ram pause)
is isight_firmware.ko.(need to look into why this is)
after that s2ram works good.
Now the usb issue, seems I see this every time I s2ram.
there is an external usb mouse, but makes no difference if it's connected,
or disconnected..still see the root hub lost power.
(maybe the machine is getting old: macbook pro 2yrs old)
heres lsmod:
Module Size Used by
radeon 507706 2
ttm 36164 1 radeon
drm_kms_helper 22484 1 radeon
drm 149553 5 radeon,ttm,drm_kms_helper
i2c_algo_bit 4835 1 radeon
ipt_LOG 5111 1
iptable_nat 4012 0
nf_nat 15811 1 iptable_nat
xt_state 1394 1
nf_conntrack_ftp 6068 0
nf_conntrack_ipv4 11271 4 iptable_nat,nf_nat
nf_conntrack 60809 5
iptable_nat,nf_nat,xt_state,nf_conntrack_ftp,nf_conntrack_ipv4
nf_defrag_ipv4 1329 1 nf_conntrack_ipv4
iptable_filter 1697 1
ip_tables 10159 2 iptable_nat,iptable_filter
x_tables 13623 4 ipt_LOG,iptable_nat,xt_state,ip_tables
snd_hda_codec_idt 52390 1
firewire_ohci 20906 0
firewire_core 41362 1 firewire_ohci
snd_hda_intel 20949 1
snd_hda_codec 66439 2 snd_hda_codec_idt,snd_hda_intel
ohci1394 26076 0
snd_hwdep 5088 1 snd_hda_codec
ath9k 289991 0
ieee1394 75265 1 ohci1394
evdev 7969 4
snd_pcm 64635 2 snd_hda_intel,snd_hda_codec
sky2 40051 0
button 5779 0
video 20415 0
thermal 14438 0
i2c_i801 7265 0
joydev 8766 0
ac 3489 0
battery 10367 0
ath 8766 1 ath9k
snd_page_alloc 7125 2 snd_hda_intel,snd_pcm
uhci_hcd 18963 0
ehci_hcd 31519 0
coretemp 5006 0
acpi_cpufreq 7024 0
processor 38952 3 acpi_cpufreq
appletouch 8569 0
applesmc 25995 0
>
>> BTW: Is CONFIG_USB_PERSIST in the kernel anymore
>> with 2.6.32*?(I can't seem to find that option);
>
> It is always used and switched on by default.
>
> ? ? ? ?Regards
> ? ? ? ? ? ? ? ?Oliver
>
o.k. I didn't know it is set to on by default.
--
Justin P. Mattock
On 12/02/2009 04:34 PM, Justin Mattock wrote:
> I've been getting a 45 sec
> pause when waking my machine up
> on the first cycle using s2ram.
> At first thought it was udev, but later
> am not sure it is. With further looking
> if I remove the isight_firmware module from the kernel
> suspend wakes up the first cycle as it should.(I don't have
> isight-firmware-tools installed, leading me to believe this might
> be the issue with isight-firmware.ko.)
>
> Now looking at dmesg I see:
>
> [ 413.551845] uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23
> [ 413.551855] uhci_hcd 0000:00:1d.0: setting latency timer to 64
> [ 413.551887] usb usb2: root hub lost power or was reset
Is that unexpected? It seems reasonable to me..
On 12/02/09 16:10, Robert Hancock wrote:
> On 12/02/2009 04:34 PM, Justin Mattock wrote:
>> I've been getting a 45 sec
>> pause when waking my machine up
>> on the first cycle using s2ram.
>> At first thought it was udev, but later
>> am not sure it is. With further looking
>> if I remove the isight_firmware module from the kernel
>> suspend wakes up the first cycle as it should.(I don't have
>> isight-firmware-tools installed, leading me to believe this might
>> be the issue with isight-firmware.ko.)
>>
>> Now looking at dmesg I see:
>>
>> [ 413.551845] uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 23 (level, low)
>> -> IRQ 23
>> [ 413.551855] uhci_hcd 0000:00:1d.0: setting latency timer to 64
>> [ 413.551887] usb usb2: root hub lost power or was reset
>
> Is that unexpected? It seems reasonable to me..
>
honestly I can't remember seeing this or not.
if this is normal then I'll leave it as is.
s2ram is working.. at first thought this was the cause,
but ended up not having anything todo with the real cause
of s2ram pausing.
Justin P. Mattock
Am Donnerstag, 3. Dezember 2009 01:58:46 schrieb Justin P. Mattock:
> >> Now looking at dmesg I see:
> >>
> >> [ 413.551845] uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 23 (level, low)
> >> -> IRQ 23
> >> [ 413.551855] uhci_hcd 0000:00:1d.0: setting latency timer to 64
> >> [ 413.551887] usb usb2: root hub lost power or was reset
> >
> > Is that unexpected? It seems reasonable to me..
>
> honestly I can't remember seeing this or not.
> if this is normal then I'll leave it as is.
This happens if your system cuts power to USB during S2.
It trades a small reduction in energy consumption against
losing support for all devices whose drivers don't support
reset_resume().
This is a design feature of your system or BIOS, not a bug.
Regards
Oliver
On Thu, 3 Dec 2009, Oliver Neukum wrote:
> Am Donnerstag, 3. Dezember 2009 01:58:46 schrieb Justin P. Mattock:
> > >> Now looking at dmesg I see:
> > >>
> > >> [ 413.551845] uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 23 (level, low)
> > >> -> IRQ 23
> > >> [ 413.551855] uhci_hcd 0000:00:1d.0: setting latency timer to 64
> > >> [ 413.551887] usb usb2: root hub lost power or was reset
> > >
> > > Is that unexpected? It seems reasonable to me..
> >
> > honestly I can't remember seeing this or not.
> > if this is normal then I'll leave it as is.
>
> This happens if your system cuts power to USB during S2.
It also happens if the system retains power but resets the controller
while resuming (as indicated by the log message: "lost power or was
reset".) Again, it's a BIOS thing.
And it seems to be very widespread. I haven't seen more than a handful
of systems which _don't_ cut power or reset their UHCI controllers
during S3 sleep.
Alan Stern
On 12/03/09 07:16, Alan Stern wrote:
> On Thu, 3 Dec 2009, Oliver Neukum wrote:
>
>> Am Donnerstag, 3. Dezember 2009 01:58:46 schrieb Justin P. Mattock:
>>>>> Now looking at dmesg I see:
>>>>>
>>>>> [ 413.551845] uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 23 (level, low)
>>>>> -> IRQ 23
>>>>> [ 413.551855] uhci_hcd 0000:00:1d.0: setting latency timer to 64
>>>>> [ 413.551887] usb usb2: root hub lost power or was reset
>>>>
>>>> Is that unexpected? It seems reasonable to me..
>>>
>>> honestly I can't remember seeing this or not.
>>> if this is normal then I'll leave it as is.
>>
>> This happens if your system cuts power to USB during S2.
>
> It also happens if the system retains power but resets the controller
> while resuming (as indicated by the log message: "lost power or was
> reset".) Again, it's a BIOS thing.
>
> And it seems to be very widespread. I haven't seen more than a handful
> of systems which _don't_ cut power or reset their UHCI controllers
> during S3 sleep.
>
> Alan Stern
>
>
Thanks for all the info on this.
Well, s2ram works ended up being
isight_firmware for some reason
or another. As for the reset
it is a macbook, so if theres something wrong
with the bios, then this makes sense
(something with efi);
In any case everything else seems o.k.
Thanks again for the info.
Justin P. Mattock
Am Donnerstag, 3. Dezember 2009 16:16:58 schrieb Alan Stern:
> And it seems to be very widespread. I haven't seen more than a handful
> of systems which _don't_ cut power or reset their UHCI controllers
> during S3 sleep.
Yes, nevertheless it is most annoying. I wonder whether we could
get BIOS writers to export this feature via ACPI.
Regards
Oliver
On 12/03/09 08:45, Oliver Neukum wrote:
> Am Donnerstag, 3. Dezember 2009 16:16:58 schrieb Alan Stern:
>> And it seems to be very widespread. I haven't seen more than a handful
>> of systems which _don't_ cut power or reset their UHCI controllers
>> during S3 sleep.
>
> Yes, nevertheless it is most annoying. I wonder whether we could
> get BIOS writers to export this feature via ACPI.
>
> Regards
> Oliver
>
after thinking abit on this
when using suspend on osx(apple)
you can wake the machine by pressing
the space bar.. my guess is this is why
the usb is probably doing what it's doing
(but could be wrong).
when I get time, I'll see if acpid
is capable of doing such thing.
Justin P. Mattock