* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
From: Andrey Rahmatullin @ 2012-04-21 21:51 UTC (permalink / raw)
To: Steven Rostedt
Cc: Alan Stern, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list
In-Reply-To: <1335034218.28106.91.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 372 bytes --]
On Sat, Apr 21, 2012 at 02:50:18PM -0400, Steven Rostedt wrote:
> > > (Does anybody know if USB wakeup works on these machines under
> > > Windows?)
> > Out of the box it doesn't work and "Allow this device to wake up the
> > computer" checkboxes on both root hubs are unchecked and grayed out.
> Where do you see those checkboxes?
Device Manager
--
WBR, wRAR
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
From: Alan Stern @ 2012-04-21 21:15 UTC (permalink / raw)
To: wrar
Cc: jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list,
Steven Rostedt
In-Reply-To: <25d7d7b05dd22d5f6e78323c1a1579b1-2RFepEojUI0HG38kr8bzl7NAH6kLmebB@public.gmane.org>
On Sat, 21 Apr 2012, wrar wrote:
> > Okay, that's good. I assume the device you plugged in then
> > functioned
> > properly?
>
> Yes.
All right. Maybe you posted this information earlier in the thread,
but it's easier to ask again than try to find it. What output do you
get from "lspci -nv -s 1a.0"?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
From: Steven Rostedt @ 2012-04-21 18:50 UTC (permalink / raw)
To: Andrey Rahmatullin
Cc: Alan Stern, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list
In-Reply-To: <20120421083751.GA4570-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
On Sat, 2012-04-21 at 14:37 +0600, Andrey Rahmatullin wrote:
> > (Does anybody know if USB wakeup works on these machines under
> > Windows?)
> Out of the box it doesn't work and "Allow this device to wake up the
> computer" checkboxes on both root hubs are unchecked and grayed out.
Where do you see those checkboxes?
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
From: Alan Stern @ 2012-04-21 17:26 UTC (permalink / raw)
To: Andrey Rahmatullin
Cc: jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list,
Steven Rostedt
In-Reply-To: <20120421083751.GA4570-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
On Sat, 21 Apr 2012, Andrey Rahmatullin wrote:
> On Fri, Apr 20, 2012 at 08:42:03PM -0400, Alan Stern wrote:
> > > > I'd like to see the dmesg log for the complete suspend/resume cycle
> > > > (naturally you'll have to resume the system by hand after plugging in
> > > > the USB device). Make sure that CONFIG_USB_DEBUG is enabled.
> > > Attached.
> >
> > It looks quite normal. Evidently USB wakeup does _not_ work on your
> > system when the controller isn't in D3 -- and the system crashes during
> > suspend if the controller _is_ in D3!
> >
> > (Does anybody know if USB wakeup works on these machines under
> > Windows?)
> Out of the box it doesn't work and "Allow this device to wake up the
> computer" checkboxes on both root hubs are unchecked and grayed out.
Ha! It seems that nobody knows how to make it work.
> > What about runtime wakeup? You can test it easily enough. Write
> > "auto" to the power/control attribute for the two controllers. This
> > should cause the controllers (or at least one of them) to go into
> > runtime suspend. Does it then wake up when you plug in a USB device?
> I wrote 'auto' to both power/control, both power/runtime_status became
> 'suspended', I plugged in a device, one of power/runtime_status became
> 'active'.
Okay, that's good. I assume the device you plugged in then functioned
properly?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
From: Alan Stern @ 2012-04-21 17:22 UTC (permalink / raw)
To: Steven Rostedt
Cc: Andrey Rahmatullin, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list
In-Reply-To: <1334969624.28106.82.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
On Fri, 20 Apr 2012, Steven Rostedt wrote:
> On Fri, 2012-04-20 at 20:42 -0400, Alan Stern wrote:
>
> > (Does anybody know if USB wakeup works on these machines under
> > Windows?)
>
> I still have my windows partition on this box. Do you happen to know how
> to tell Windows to wake up on USB?
No idea.
> > What about runtime wakeup? You can test it easily enough. Write
> > "auto" to the power/control attribute for the two controllers. This
> > should cause the controllers (or at least one of them) to go into
> > runtime suspend. Does it then wake up when you plug in a USB device?
>
> Do you want me to do this with one of you patches, or with the script
> applied?
No patches, and the script doesn't matter because the test doesn't
involve putting the computer to sleep.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: ehci_hcd related S3 lockup on ASUS laptops, again
From: Andrey Rahmatullin @ 2012-04-21 8:37 UTC (permalink / raw)
To: Alan Stern; +Cc: jrnieder, linux-pm, USB list, Steven Rostedt
In-Reply-To: <Pine.LNX.4.44L0.1204202037570.19313-100000@netrider.rowland.org>
[-- Attachment #1.1: Type: text/plain, Size: 1177 bytes --]
On Fri, Apr 20, 2012 at 08:42:03PM -0400, Alan Stern wrote:
> > > I'd like to see the dmesg log for the complete suspend/resume cycle
> > > (naturally you'll have to resume the system by hand after plugging in
> > > the USB device). Make sure that CONFIG_USB_DEBUG is enabled.
> > Attached.
>
> It looks quite normal. Evidently USB wakeup does _not_ work on your
> system when the controller isn't in D3 -- and the system crashes during
> suspend if the controller _is_ in D3!
>
> (Does anybody know if USB wakeup works on these machines under
> Windows?)
Out of the box it doesn't work and "Allow this device to wake up the
computer" checkboxes on both root hubs are unchecked and grayed out.
> What about runtime wakeup? You can test it easily enough. Write
> "auto" to the power/control attribute for the two controllers. This
> should cause the controllers (or at least one of them) to go into
> runtime suspend. Does it then wake up when you plug in a USB device?
I wrote 'auto' to both power/control, both power/runtime_status became
'suspended', I plugged in a device, one of power/runtime_status became
'active'.
--
WBR, wRAR
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: ehci_hcd related S3 lockup on ASUS laptops, again
From: Steven Rostedt @ 2012-04-21 0:53 UTC (permalink / raw)
To: Alan Stern; +Cc: jrnieder, Andrey Rahmatullin, linux-pm, USB list
In-Reply-To: <Pine.LNX.4.44L0.1204202037570.19313-100000@netrider.rowland.org>
On Fri, 2012-04-20 at 20:42 -0400, Alan Stern wrote:
> (Does anybody know if USB wakeup works on these machines under
> Windows?)
I still have my windows partition on this box. Do you happen to know how
to tell Windows to wake up on USB?
>
> What about runtime wakeup? You can test it easily enough. Write
> "auto" to the power/control attribute for the two controllers. This
> should cause the controllers (or at least one of them) to go into
> runtime suspend. Does it then wake up when you plug in a USB device?
Do you want me to do this with one of you patches, or with the script
applied?
-- Steve
^ permalink raw reply
* Re: ehci_hcd related S3 lockup on ASUS laptops, again
From: Alan Stern @ 2012-04-21 0:42 UTC (permalink / raw)
To: Andrey Rahmatullin; +Cc: jrnieder, linux-pm, USB list, Steven Rostedt
In-Reply-To: <20120419214856.GC11484@belkar.wrar.name>
On Fri, 20 Apr 2012, Andrey Rahmatullin wrote:
> > I'd like to see the dmesg log for the complete suspend/resume cycle
> > (naturally you'll have to resume the system by hand after plugging in
> > the USB device). Make sure that CONFIG_USB_DEBUG is enabled.
> Attached.
It looks quite normal. Evidently USB wakeup does _not_ work on your
system when the controller isn't in D3 -- and the system crashes during
suspend if the controller _is_ in D3!
(Does anybody know if USB wakeup works on these machines under
Windows?)
What about runtime wakeup? You can test it easily enough. Write
"auto" to the power/control attribute for the two controllers. This
should cause the controllers (or at least one of them) to go into
runtime suspend. Does it then wake up when you plug in a USB device?
Alan Stern
^ permalink raw reply
* Re: ehci_hcd related S3 lockup on ASUS laptops, again
From: Andrey Rahmatullin @ 2012-04-19 21:48 UTC (permalink / raw)
To: Alan Stern; +Cc: jrnieder, linux-pm, USB list, Steven Rostedt
In-Reply-To: <Pine.LNX.4.44L0.1204191404460.1154-100000@iolanthe.rowland.org>
[-- Attachment #1.1.1: Type: text/plain, Size: 1638 bytes --]
On Thu, Apr 19, 2012 at 02:07:47PM -0400, Alan Stern wrote:
> > > Below is a patch that will prevent any PCI device from being put into
> > > D3 during suspend. (This is meant to be used without any of the
> > > earlier diagnostic patches.) Obviously it's not the final solution;
> > > the test in the "if" statement needs to be more discriminating. :-)
> > >
> > > But before going any farther, I'd like to test if USB wakeup works.
> > > So after booting with this patch, make sure that the power/wakeup file
> > > says "enabled" in the sysfs path for each controller as well as the
> > > usb1, usb2, 1-2, and 2-2 paths under /sys/bus/usb/devices/.
> > >
> > > Then suspend the computer without using the script, and while it is
> > > asleep try plugging in a new USB device. That should cause the
> > > computer to wake up, if everything is working properly.
> > I've set "enabled" for following files:
> >
> > /sys/bus/usb/devices/usb1/power/wakeup
> > /sys/bus/usb/devices/usb2/power/wakeup
> > /sys/bus/usb/devices/1-1/power/wakeup
> > /sys/bus/usb/devices/2-1/power/wakeup
> > /sys/bus/pci/devices/0000:00:1a.0/power/wakeup
> > /sys/bus/pci/devices/0000:00:1d.0/power/wakeup
>
> Good.
>
> > yet it didn't wake up after plugging, though devices light up.
>
> You mean, the devices that you plug in light up?
Yes. An mp3 player and a flash drive.
> I'd like to see the dmesg log for the complete suspend/resume cycle
> (naturally you'll have to resume the system by hand after plugging in
> the USB device). Make sure that CONFIG_USB_DEBUG is enabled.
Attached.
--
WBR, wRAR
[-- Attachment #1.1.2: dmesg --]
[-- Type: text/plain, Size: 15676 bytes --]
[ 145.122398] PM: Syncing filesystems ... done.
[ 146.095904] PM: Preparing system for mem sleep
[ 146.110135] Freezing user space processes ... (elapsed 0.01 seconds) done.
[ 146.121637] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
[ 146.132804] PM: Entering mem sleep
[ 146.140388] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 146.188114] sd 0:0:0:0: [sda] Stopping disk
[ 146.569462] PM: suspend of devices complete after 436.593 msecs
[ 146.569638] PM: late suspend of devices complete after 0.154 msecs
[ 146.570125] ehci_hcd 0000:00:1d.0: wakeup: 1
[ 146.570159] ehci_hcd 0000:00:1d.0: wake-up capability enabled by ACPI
[ 146.570172] ehci_hcd 0000:00:1d.0: --> PCI D0
[ 146.570234] ehci_hcd 0000:00:1a.0: wakeup: 1
[ 146.570251] ehci_hcd 0000:00:1a.0: wake-up capability enabled by ACPI
[ 146.570288] ehci_hcd 0000:00:1a.0: --> PCI D0
[ 146.570399] PM: noirq suspend of devices complete after 0.747 msecs
[ 146.571068] ACPI: Preparing to enter system sleep state S3
[ 146.588943] ------------[ cut here ]------------
[ 146.588995] WARNING: at drivers/gpu/drm/i915/i915_drv.c:398 gen6_gt_check_fifodbg.isra.5+0x31/0x44 [i915]()
[ 146.589010] Hardware name: K53E
[ 146.589017] MMIO read or write has been dropped ffffffff
[ 146.589026] Modules linked in: aes_x86_64 aes_generic af_packet cpufreq_userspace cpufreq_stats cpufreq_powersave cpufreq_ondemand rfcomm bnep uinput fuse nfsd nfs nfs_acl auth_rpcgss fscache lockd sunrpc ipv6 snd_hda_codec_hdmi snd_hda_codec_realtek btusb bluetooth uvcvideo videobuf2_vmalloc snd_hda_intel videobuf2_memops snd_hda_codec videobuf2_core videodev snd_hwdep crc16 snd_pcm arc4 snd_page_alloc ath9k snd_seq_midi snd_seq_midi_event snd_rawmidi ath9k_common ath9k_hw ath mac80211 snd_seq acpi_cpufreq mperf freq_table joydev i915 asus_nb_wmi asus_wmi sparse_keymap pci_hotplug i2c_algo_bit drm_kms_helper i2c_i801 drm cfg80211 processor evdev battery wmi button i2c_core intel_agp intel_gtt psmouse video backlight snd_seq_device coretemp crc32c_intel ac agpgart snd_timer snd soundcore dm_mod ehci_hcd sr_mod cdrom usbcore usb_common atl1c thermal thermal_sys hwmon [last unloaded: scsi_wait_scan]
[ 146.589261] Pid: 2880, comm: kworker/u:11 Not tainted 3.4.0-rc2-wrar-sabine-8+ #18
[ 146.589273] Call Trace:
[ 146.589294] [<ffffffff8102a5e1>] warn_slowpath_common+0x7e/0x96
[ 146.589310] [<ffffffff8102a68d>] warn_slowpath_fmt+0x41/0x43
[ 146.589337] [<ffffffffa02143b7>] gen6_gt_check_fifodbg.isra.5+0x31/0x44 [i915]
[ 146.589365] [<ffffffffa021462e>] __gen6_gt_force_wake_put+0x19/0x1b [i915]
[ 146.589392] [<ffffffffa0214884>] i915_read32+0x61/0x82 [i915]
[ 146.589433] [<ffffffffa022e111>] ? intel_disable_plane+0x60/0x60 [i915]
[ 146.589462] [<ffffffffa02167ea>] i915_update_gfx_val+0x61/0xb9 [i915]
[ 146.589500] [<ffffffffa022e156>] intel_idle_update+0x45/0x18b [i915]
[ 146.589518] [<ffffffff810463d1>] ? need_resched+0x1e/0x28
[ 146.589551] [<ffffffffa022e111>] ? intel_disable_plane+0x60/0x60 [i915]
[ 146.589569] [<ffffffff8103c292>] process_one_work+0x13c/0x21e
[ 146.589585] [<ffffffff8103cb93>] worker_thread+0xce/0x152
[ 146.589600] [<ffffffff8103cac5>] ? manage_workers.isra.28+0x16c/0x16c
[ 146.589614] [<ffffffff8103ffab>] kthread+0x86/0x8e
[ 146.589629] [<ffffffff812f2094>] kernel_thread_helper+0x4/0x10
[ 146.589644] [<ffffffff8103ff25>] ? kthread_freezable_should_stop+0x3e/0x3e
[ 146.589658] [<ffffffff812f2090>] ? gs_change+0xb/0xb
[ 146.589668] ---[ end trace d4f42eb8f9f0177b ]---
[ 146.590280] ------------[ cut here ]------------
[ 146.590302] WARNING: at drivers/gpu/drm/i915/i915_drv.c:398 gen6_gt_check_fifodbg.isra.5+0x31/0x44 [i915]()
[ 146.590315] Hardware name: K53E
[ 146.590322] MMIO read or write has been dropped ffffffff
[ 146.590330] Modules linked in: aes_x86_64 aes_generic af_packet cpufreq_userspace cpufreq_stats cpufreq_powersave cpufreq_ondemand rfcomm bnep uinput fuse nfsd nfs nfs_acl auth_rpcgss fscache lockd sunrpc ipv6 snd_hda_codec_hdmi snd_hda_codec_realtek btusb bluetooth uvcvideo videobuf2_vmalloc snd_hda_intel videobuf2_memops snd_hda_codec videobuf2_core videodev snd_hwdep crc16 snd_pcm arc4 snd_page_alloc ath9k snd_seq_midi snd_seq_midi_event snd_rawmidi ath9k_common ath9k_hw ath mac80211 snd_seq acpi_cpufreq mperf freq_table joydev i915 asus_nb_wmi asus_wmi sparse_keymap pci_hotplug i2c_algo_bit drm_kms_helper i2c_i801 drm cfg80211 processor evdev battery wmi button i2c_core intel_agp intel_gtt psmouse video backlight snd_seq_device coretemp crc32c_intel ac agpgart snd_timer snd soundcore dm_mod ehci_hcd sr_mod cdrom usbcore usb_common atl1c thermal thermal_sys hwmon [last unloaded: scsi_wait_scan]
[ 146.590551] Pid: 2880, comm: kworker/u:11 Tainted: G W 3.4.0-rc2-wrar-sabine-8+ #18
[ 146.590563] Call Trace:
[ 146.590576] [<ffffffff8102a5e1>] warn_slowpath_common+0x7e/0x96
[ 146.590590] [<ffffffff8102a68d>] warn_slowpath_fmt+0x41/0x43
[ 146.590614] [<ffffffffa02143b7>] gen6_gt_check_fifodbg.isra.5+0x31/0x44 [i915]
[ 146.590639] [<ffffffffa021462e>] __gen6_gt_force_wake_put+0x19/0x1b [i915]
[ 146.590664] [<ffffffffa0214884>] i915_read32+0x61/0x82 [i915]
[ 146.590696] [<ffffffffa022e1ae>] intel_idle_update+0x9d/0x18b [i915]
[ 146.590728] [<ffffffffa022e111>] ? intel_disable_plane+0x60/0x60 [i915]
[ 146.590744] [<ffffffff8103c292>] process_one_work+0x13c/0x21e
[ 146.590758] [<ffffffff8103cb93>] worker_thread+0xce/0x152
[ 146.590772] [<ffffffff8103cac5>] ? manage_workers.isra.28+0x16c/0x16c
[ 146.590786] [<ffffffff8103ffab>] kthread+0x86/0x8e
[ 146.590797] [<ffffffff812f2094>] kernel_thread_helper+0x4/0x10
[ 146.590810] [<ffffffff8103ff25>] ? kthread_freezable_should_stop+0x3e/0x3e
[ 146.590823] [<ffffffff812f2090>] ? gs_change+0xb/0xb
[ 146.590832] ---[ end trace d4f42eb8f9f0177c ]---
[ 146.644755] PM: Saving platform NVS memory
[ 146.649445] Disabling non-boot CPUs ...
[ 146.651233] CPU 1 is now offline
[ 146.654012] CPU 2 is now offline
[ 146.656592] CPU 3 is now offline
[ 146.657317] Extended CMOS year: 2000
[ 146.658682] ACPI: Low-level resume complete
[ 146.658728] PM: Restoring platform NVS memory
[ 146.659118] Extended CMOS year: 2000
[ 146.659141] Enabling non-boot CPUs ...
[ 146.660262] Booting Node 0 Processor 1 APIC 0x2
[ 146.674899] CPU1 is up
[ 146.675071] Booting Node 0 Processor 2 APIC 0x1
[ 146.689611] CPU2 is up
[ 146.689735] Booting Node 0 Processor 3 APIC 0x3
[ 146.704075] CPU3 is up
[ 146.707254] ACPI: Waking up from system sleep state S3
[ 147.297244] ehci_hcd 0000:00:1a.0: wake-up capability disabled by ACPI
[ 147.333090] power_supply BAT0: parent PNP0C0A:00 should not be sleeping
[ 147.458847] ehci_hcd 0000:00:1d.0: wake-up capability disabled by ACPI
[ 147.559435] PM: noirq resume of devices complete after 432.678 msecs
[ 147.559694] PM: early resume of devices complete after 0.106 msecs
[ 147.559822] i915 0000:00:02.0: setting latency timer to 64
[ 147.559840] ehci_hcd 0000:00:1a.0: setting latency timer to 64
[ 147.559880] usb usb1: root hub lost power or was reset
[ 147.559906] ehci_hcd 0000:00:1a.0: reset command 0080002 (park)=0 ithresh=8 period=1024 Reset HALT
[ 147.559930] snd_hda_intel 0000:00:1b.0: irq 45 for MSI/MSI-X
[ 147.560048] ehci_hcd 0000:00:1d.0: setting latency timer to 64
[ 147.560054] ahci 0000:00:1f.2: setting latency timer to 64
[ 147.560071] usb usb2: root hub lost power or was reset
[ 147.560085] ehci_hcd 0000:00:1d.0: reset command 0080002 (park)=0 ithresh=8 period=1024 Reset HALT
[ 147.563800] ehci_hcd 0000:00:1a.0: cache line size of 64 is not supported
[ 147.563820] usb usb1: usb resume
[ 147.563828] ehci_hcd 0000:00:1a.0: resume root hub after power loss
[ 147.564282] ehci_hcd 0000:00:1d.0: cache line size of 64 is not supported
[ 147.564819] usb usb2: usb resume
[ 147.564826] ehci_hcd 0000:00:1d.0: resume root hub after power loss
[ 147.583553] hub 1-0:1.0: hub_reset_resume
[ 147.583559] hub 1-0:1.0: trying to enable port power on non-switchable hub
[ 147.584563] hub 2-0:1.0: hub_reset_resume
[ 147.584572] hub 2-0:1.0: trying to enable port power on non-switchable hub
[ 147.641086] [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off
[ 147.650114] atl1c 0000:03:00.0: irq 46 for MSI/MSI-X
[ 147.684584] ehci_hcd 0000:00:1a.0: GetStatus port:1 status 001803 0 ACK POWER sig=j CSC CONNECT
[ 147.684602] hub 1-0:1.0: port 1: status 0501 change 0001
[ 147.685571] ehci_hcd 0000:00:1d.0: GetStatus port:1 status 001803 0 ACK POWER sig=j CSC CONNECT
[ 147.685583] hub 2-0:1.0: port 1: status 0501 change 0001
[ 147.785577] usb 1-1: finish reset-resume
[ 147.786555] usb 2-1: finish reset-resume
[ 147.836698] ehci_hcd 0000:00:1a.0: port 1 high speed
[ 147.836714] ehci_hcd 0000:00:1a.0: GetStatus port:1 status 001005 0 ACK POWER sig=se0 PE CONNECT
[ 147.875482] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 147.877791] ata3.00: ACPI cmd ef/10:06:00:00:00:a0 (SET FEATURES) succeeded
[ 147.877811] ata3.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered out
[ 147.881892] ata3.00: ACPI cmd ef/10:06:00:00:00:a0 (SET FEATURES) succeeded
[ 147.881912] ata3.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered out
[ 147.883449] ata3.00: configured for UDMA/100
[ 147.887485] usb 1-1: reset high-speed USB device number 2 using ehci_hcd
[ 147.938648] ehci_hcd 0000:00:1a.0: port 1 high speed
[ 147.938664] ehci_hcd 0000:00:1a.0: GetStatus port:1 status 001005 0 ACK POWER sig=se0 PE CONNECT
[ 148.001587] ehci_hcd 0000:00:1a.0: set dev address 2 for port 1
[ 148.001598] ehci_hcd 0000:00:1a.0: LPM: no device attached
[ 148.002062] hub 1-1:1.0: hub_reset_resume
[ 148.002071] hub 1-1:1.0: enabling power on all ports
[ 148.052711] ehci_hcd 0000:00:1d.0: port 1 high speed
[ 148.052727] ehci_hcd 0000:00:1d.0: GetStatus port:1 status 001005 0 ACK POWER sig=se0 PE CONNECT
[ 148.103404] usb 2-1: reset high-speed USB device number 2 using ehci_hcd
[ 148.104514] hub 1-1:1.0: port 1: status 0101 change 0001
[ 148.104888] hub 1-1:1.0: port 2: status 0101 change 0001
[ 148.160530] ehci_hcd 0000:00:1d.0: port 1 high speed
[ 148.160546] ehci_hcd 0000:00:1d.0: GetStatus port:1 status 001005 0 ACK POWER sig=se0 PE CONNECT
[ 148.206372] usb 1-1: link qh256-0001/ffff88013a93ed00 start 3 [1/0 us]
[ 148.206557] usb 1-1.2: finish reset-resume
[ 148.206858] usb 1-1.1: finish reset-resume
[ 148.223468] ehci_hcd 0000:00:1d.0: set dev address 2 for port 1
[ 148.223480] ehci_hcd 0000:00:1d.0: LPM: no device attached
[ 148.224226] hub 2-1:1.0: hub_reset_resume
[ 148.224235] hub 2-1:1.0: enabling power on all ports
[ 148.234465] hub 1-1:1.0: port 2 not reset yet, waiting 10ms
[ 148.296583] usb 1-1.2: reset high-speed USB device number 4 using ehci_hcd
[ 148.325925] hub 2-1:1.0: port 3: status 0101 change 0001
[ 148.388528] hub 1-1:1.0: port 1 not reset yet, waiting 10ms
[ 148.427243] usb 2-1: link qh256-0001/ffff88013a93e400 start 2 [1/0 us]
[ 148.450517] usb 1-1.1: reset full-speed USB device number 3 using ehci_hcd
[ 148.467506] hub 1-1:1.0: port 1 not reset yet, waiting 10ms
[ 149.457684] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 149.465889] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) filtered out
[ 149.472303] ata1.00: ACPI cmd ef/10:06:00:00:00:a0 (SET FEATURES) succeeded
[ 149.472312] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered out
[ 149.482789] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) filtered out
[ 149.489164] ata1.00: ACPI cmd ef/10:06:00:00:00:a0 (SET FEATURES) succeeded
[ 149.489176] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered out
[ 149.496961] ata1.00: configured for UDMA/133
[ 149.502899] sd 0:0:0:0: [sda] Starting disk
[ 149.559598] PM: resume of devices complete after 2000.913 msecs
[ 149.619233] PM: Finishing wakeup.
[ 149.619241] Restarting tasks ...
[ 149.619442] hub 1-0:1.0: state 7 ports 2 chg 0002 evt 0000
[ 149.624455] done.
[ 149.632672] hub 1-0:1.0: port 1, status 0503, change 0000, 480 Mb/s
[ 149.632686] hub 2-0:1.0: state 7 ports 2 chg 0002 evt 0000
[ 149.632699] hub 2-0:1.0: port 1, status 0503, change 0000, 480 Mb/s
[ 149.632707] hub 1-1:1.0: state 7 ports 6 chg 0006 evt 0004
[ 149.632817] hub 1-1:1.0: port 1, status 0103, change 0000, 12 Mb/s
[ 149.632960] hub 1-1:1.0: port 2, status 0503, change 0000, 480 Mb/s
[ 149.632974] hub 2-1:1.0: state 7 ports 6 chg 0008 evt 0000
[ 149.633205] hub 2-1:1.0: port 3, status 0101, change 0000, 12 Mb/s
[ 149.643682] hub 2-1:1.0: port 3 not reset yet, waiting 10ms
[ 149.705688] usb 2-1.3: new high-speed USB device number 3 using ehci_hcd
[ 149.720119] video LNXVIDEO:01: Restoring backlight state
[ 149.790209] usb 2-1.3: default language 0x0409
[ 149.790751] usb 2-1.3: udev 3, busnum 2, minor = 130
[ 149.790761] usb 2-1.3: New USB device found, idVendor=04e8, idProduct=5133
[ 149.790907] usb 2-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=5
[ 149.791051] usb 2-1.3: Product: YP-U6
[ 149.791127] usb 2-1.3: Manufacturer: Samsung Electronics
[ 149.791234] usb 2-1.3: SerialNumber: 38F5000001B1241C0002DCE4D908E41C
[ 149.791902] usb 2-1.3: usb_probe_device
[ 149.791911] usb 2-1.3: configuration #1 chosen from 2 choices
[ 149.792207] usb 2-1.3: adding 2-1.3:1.0 (config #1, interface 0)
[ 149.925318] uas 2-1.3:1.0: usb_probe_interface
[ 149.925328] uas 2-1.3:1.0: usb_probe_interface - got id
[ 149.925422] usbcore: registered new interface driver uas
[ 149.936863] libusual 2-1.3:1.0: usb_probe_interface
[ 149.936877] libusual 2-1.3:1.0: usb_probe_interface - got id
[ 149.936996] usbcore: registered new interface driver libusual
[ 149.958603] Initializing USB Mass Storage driver...
[ 149.958802] usb-storage 2-1.3:1.0: usb_probe_interface
[ 149.958816] usb-storage 2-1.3:1.0: usb_probe_interface - got id
[ 149.958931] scsi6 : usb-storage 2-1.3:1.0
[ 149.959189] usbcore: registered new interface driver usb-storage
[ 149.959309] USB Mass Storage support registered.
[ 150.962927] scsi 6:0:0:0: Direct-Access Samsung YP-U6 0100 PQ: 0 ANSI: 4
[ 150.965186] sd 6:0:0:0: [sdb] 1889152 2048-byte logical blocks: (3.86 GB/3.60 GiB)
[ 150.966136] sd 6:0:0:0: [sdb] Write Protect is off
[ 150.966271] sd 6:0:0:0: [sdb] Mode Sense: 3e 00 00 00
[ 150.966875] sd 6:0:0:0: [sdb] No Caching mode page present
[ 150.967020] sd 6:0:0:0: [sdb] Assuming drive cache: write through
[ 150.968497] sd 6:0:0:0: [sdb] 1889152 2048-byte logical blocks: (3.86 GB/3.60 GiB)
[ 150.969732] sd 6:0:0:0: [sdb] No Caching mode page present
[ 150.969897] sd 6:0:0:0: [sdb] Assuming drive cache: write through
[ 150.972374] sdb: sdb1
[ 150.974025] sd 6:0:0:0: [sdb] 1889152 2048-byte logical blocks: (3.86 GB/3.60 GiB)
[ 150.975232] sd 6:0:0:0: [sdb] No Caching mode page present
[ 150.979258] sd 6:0:0:0: [sdb] Assuming drive cache: write through
[ 150.983262] sd 6:0:0:0: [sdb] Attached SCSI removable disk
[ 150.994014] usb 1-1.1: usb auto-suspend, wakeup 0
[ 150.994027] usb 1-1.2: usb auto-suspend, wakeup 0
[ 153.003869] hub 1-1:1.0: hub_suspend
[ 153.003893] usb 1-1: unlink qh256-0001/ffff88013a93ed00 start 3 [1/0 us]
[ 153.004042] usb 1-1: usb auto-suspend, wakeup 1
[ 155.013849] hub 1-0:1.0: hub_suspend
[ 155.013870] usb usb1: bus auto-suspend, wakeup 1
[ 155.013877] ehci_hcd 0000:00:1a.0: suspend root hub
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
From: Steven Rostedt @ 2012-04-19 18:30 UTC (permalink / raw)
To: Alan Stern
Cc: Andrey Rahmatullin, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list
In-Reply-To: <Pine.LNX.4.44L0.1204191411360.1154-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
On Thu, 2012-04-19 at 14:13 -0400, Alan Stern wrote:
> > Mine applied to pci_finish_runtime_suspend not pci_prepare_to_sleep :-p
> > I'm using 3.2.5.
>
> Whoops! That'll do it. The names say it all: one routine is used for
> runtime PM and the other is used for system sleep. The two functions
> are very similar, so naturally "patch" got confused.
Yep, after making the fix, it suspends fine.
But after setting all the power/wakeup to enabled, mine didn't wake up
when putting in a usb device. I had no lights either (unlike Andrey).
I've just set CONFIG_USB_DEBUG and I'm recompiling.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: ehci_hcd related S3 lockup on ASUS laptops, again
From: Alan Stern @ 2012-04-19 18:13 UTC (permalink / raw)
To: Steven Rostedt; +Cc: jrnieder, Andrey Rahmatullin, linux-pm, USB list
In-Reply-To: <1334858921.28106.66.camel@gandalf.stny.rr.com>
On Thu, 19 Apr 2012, Steven Rostedt wrote:
> Rebuilt with mrproper, and confirming the patch was added.
>
> It still locked up. But, I looked at your patch and mine and realized
> that mine applied with some "FUZZ".
>
> Mine:
>
> @@ -1723,6 +1723,8 @@ int pci_finish_runtime_suspend(struct pci_dev *dev)
> pci_power_t target_state = pci_target_state(dev);
> int error;
>
> + if (1)
> + target_state = PCI_D0;
> if (target_state == PCI_POWER_ERROR)
> return -EIO;
>
> Yours:
>
> @@ -1713,6 +1713,8 @@ int pci_prepare_to_sleep(struct pci_dev
> pci_power_t target_state = pci_target_state(dev);
> int error;
>
> + if (1)
> + target_state = PCI_D0;
> if (target_state == PCI_POWER_ERROR)
> return -EIO;
>
> Mine applied to pci_finish_runtime_suspend not pci_prepare_to_sleep :-p
> I'm using 3.2.5.
Whoops! That'll do it. The names say it all: one routine is used for
runtime PM and the other is used for system sleep. The two functions
are very similar, so naturally "patch" got confused.
Alan Stern
^ permalink raw reply
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
From: Steven Rostedt @ 2012-04-19 18:08 UTC (permalink / raw)
To: Alan Stern
Cc: Andrey Rahmatullin, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list
In-Reply-To: <1334852575.28106.62.camel-f9ZlEuEWxVcI6MkJdU+c8EEOCMrvLtNR@public.gmane.org>
On Thu, 2012-04-19 at 12:22 -0400, Steven Rostedt wrote:
> I removed all previous patches and added this one. But without the
> script, it locks up again in suspend.
>
> I'll rebuild again just to make sure I didn't screw something up.
Rebuilt with mrproper, and confirming the patch was added.
It still locked up. But, I looked at your patch and mine and realized
that mine applied with some "FUZZ".
Mine:
@@ -1723,6 +1723,8 @@ int pci_finish_runtime_suspend(struct pci_dev *dev)
pci_power_t target_state = pci_target_state(dev);
int error;
+ if (1)
+ target_state = PCI_D0;
if (target_state == PCI_POWER_ERROR)
return -EIO;
Yours:
@@ -1713,6 +1713,8 @@ int pci_prepare_to_sleep(struct pci_dev
pci_power_t target_state = pci_target_state(dev);
int error;
+ if (1)
+ target_state = PCI_D0;
if (target_state == PCI_POWER_ERROR)
return -EIO;
Mine applied to pci_finish_runtime_suspend not pci_prepare_to_sleep :-p
I'm using 3.2.5.
/me fixes, recompiles and retests
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
From: Alan Stern @ 2012-04-19 18:07 UTC (permalink / raw)
To: Andrey Rahmatullin
Cc: jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list,
Steven Rostedt
In-Reply-To: <20120419163055.GB11484-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
On Thu, 19 Apr 2012, Andrey Rahmatullin wrote:
> On Thu, Apr 19, 2012 at 09:43:45AM -0400, Alan Stern wrote:
> > Below is a patch that will prevent any PCI device from being put into
> > D3 during suspend. (This is meant to be used without any of the
> > earlier diagnostic patches.) Obviously it's not the final solution;
> > the test in the "if" statement needs to be more discriminating. :-)
> >
> > But before going any farther, I'd like to test if USB wakeup works.
> > So after booting with this patch, make sure that the power/wakeup file
> > says "enabled" in the sysfs path for each controller as well as the
> > usb1, usb2, 1-2, and 2-2 paths under /sys/bus/usb/devices/.
> >
> > Then suspend the computer without using the script, and while it is
> > asleep try plugging in a new USB device. That should cause the
> > computer to wake up, if everything is working properly.
> I've set "enabled" for following files:
>
> /sys/bus/usb/devices/usb1/power/wakeup
> /sys/bus/usb/devices/usb2/power/wakeup
> /sys/bus/usb/devices/1-1/power/wakeup
> /sys/bus/usb/devices/2-1/power/wakeup
> /sys/bus/pci/devices/0000:00:1a.0/power/wakeup
> /sys/bus/pci/devices/0000:00:1d.0/power/wakeup
Good.
> yet it didn't wake up after plugging, though devices light up.
You mean, the devices that you plug in light up?
I'd like to see the dmesg log for the complete suspend/resume cycle
(naturally you'll have to resume the system by hand after plugging in
the USB device). Make sure that CONFIG_USB_DEBUG is enabled.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
From: Andrey Rahmatullin @ 2012-04-19 16:30 UTC (permalink / raw)
To: Alan Stern
Cc: jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list,
Steven Rostedt
In-Reply-To: <Pine.LNX.4.44L0.1204190934500.2070-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1652 bytes --]
On Thu, Apr 19, 2012 at 09:43:45AM -0400, Alan Stern wrote:
> Below is a patch that will prevent any PCI device from being put into
> D3 during suspend. (This is meant to be used without any of the
> earlier diagnostic patches.) Obviously it's not the final solution;
> the test in the "if" statement needs to be more discriminating. :-)
>
> But before going any farther, I'd like to test if USB wakeup works.
> So after booting with this patch, make sure that the power/wakeup file
> says "enabled" in the sysfs path for each controller as well as the
> usb1, usb2, 1-2, and 2-2 paths under /sys/bus/usb/devices/.
>
> Then suspend the computer without using the script, and while it is
> asleep try plugging in a new USB device. That should cause the
> computer to wake up, if everything is working properly.
I've set "enabled" for following files:
/sys/bus/usb/devices/usb1/power/wakeup
/sys/bus/usb/devices/usb2/power/wakeup
/sys/bus/usb/devices/1-1/power/wakeup
/sys/bus/usb/devices/2-1/power/wakeup
/sys/bus/pci/devices/0000:00:1a.0/power/wakeup
/sys/bus/pci/devices/0000:00:1d.0/power/wakeup
yet it didn't wake up after plugging, though devices light up.
> Index: usb-3.4/drivers/pci/pci.c
> ===================================================================
> --- usb-3.4.orig/drivers/pci/pci.c
> +++ usb-3.4/drivers/pci/pci.c
> @@ -1713,6 +1713,8 @@ int pci_prepare_to_sleep(struct pci_dev
> pci_power_t target_state = pci_target_state(dev);
> int error;
>
> + if (1)
> + target_state = PCI_D0;
> if (target_state == PCI_POWER_ERROR)
> return -EIO;
>
>
>
--
WBR, wRAR
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
From: Steven Rostedt @ 2012-04-19 16:22 UTC (permalink / raw)
To: Alan Stern
Cc: Andrey Rahmatullin, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list
In-Reply-To: <Pine.LNX.4.44L0.1204190934500.2070-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
On Thu, 2012-04-19 at 09:43 -0400, Alan Stern wrote:
> On Wed, 18 Apr 2012, Alan Stern wrote:
>
> > Tomorrow we can try to figure out the appropriate workaround.
>
> Below is a patch that will prevent any PCI device from being put into
> D3 during suspend. (This is meant to be used without any of the
> earlier diagnostic patches.) Obviously it's not the final solution;
> the test in the "if" statement needs to be more discriminating. :-)
>
> But before going any farther, I'd like to test if USB wakeup works.
> So after booting with this patch, make sure that the power/wakeup file
> says "enabled" in the sysfs path for each controller as well as the
> usb1, usb2, 1-2, and 2-2 paths under /sys/bus/usb/devices/.
>
> Then suspend the computer without using the script, and while it is
> asleep try plugging in a new USB device. That should cause the
> computer to wake up, if everything is working properly.
>
I removed all previous patches and added this one. But without the
script, it locks up again in suspend.
I'll rebuild again just to make sure I didn't screw something up.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: ehci_hcd related S3 lockup on ASUS laptops, again
From: Alan Stern @ 2012-04-19 16:06 UTC (permalink / raw)
To: Andrey Rahmatullin; +Cc: jrnieder, linux-pm, USB list, Steven Rostedt
In-Reply-To: <20120419155309.GA11484@belkar.wrar.name>
On Thu, 19 Apr 2012, Andrey Rahmatullin wrote:
> On Thu, Apr 19, 2012 at 09:43:45AM -0400, Alan Stern wrote:
> > But before going any farther, I'd like to test if USB wakeup works.
> > So after booting with this patch, make sure that the power/wakeup file
> > says "enabled" in the sysfs path for each controller as well as the
> > usb1, usb2, 1-2, and 2-2 paths under /sys/bus/usb/devices/.
> Also, I don't have [12]-2 there:
>
> 1-0:1.0 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1/1-0:1.0
> 1-1 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1/1-1
> 1-1.1 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1
> 1-1.1:1.0 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.0
> 1-1.1:1.1 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.1
> 1-1.2 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2
> 1-1.2:1.0 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0
> 1-1.2:1.1 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.1
> 1-1:1.0 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1:1.0
> 2-0:1.0 -> ../../../devices/pci0000:00/0000:00:1d.0/usb2/2-0:1.0
> 2-1 -> ../../../devices/pci0000:00/0000:00:1d.0/usb2/2-1
> 2-1:1.0 -> ../../../devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0
> usb1 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1
> usb2 -> ../../../devices/pci0000:00/0000:00:1d.0/usb2
My apologies, I meant 1-1 and 2-1. (The number following the '-' is a
port number, not a device address.)
Alan Stern
^ permalink raw reply
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
From: Alan Stern @ 2012-04-19 16:05 UTC (permalink / raw)
To: Andrey Rahmatullin
Cc: jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list,
Steven Rostedt
In-Reply-To: <20120419154453.GZ11484-hAV9HEAGFNe6YibBOCjzsw@public.gmane.org>
On Thu, 19 Apr 2012, Andrey Rahmatullin wrote:
> On Thu, Apr 19, 2012 at 09:43:45AM -0400, Alan Stern wrote:
> > But before going any farther, I'd like to test if USB wakeup works.
> > So after booting with this patch, make sure that the power/wakeup file
> > says "enabled" in the sysfs path for each controller as well as the
> > usb1, usb2, 1-2, and 2-2 paths under /sys/bus/usb/devices/.
> Should I change them if they say "disabled"?
Yes, write "enabled" to them.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
From: Andrey Rahmatullin @ 2012-04-19 15:53 UTC (permalink / raw)
To: Alan Stern
Cc: jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list,
Steven Rostedt
In-Reply-To: <Pine.LNX.4.44L0.1204190934500.2070-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1346 bytes --]
On Thu, Apr 19, 2012 at 09:43:45AM -0400, Alan Stern wrote:
> But before going any farther, I'd like to test if USB wakeup works.
> So after booting with this patch, make sure that the power/wakeup file
> says "enabled" in the sysfs path for each controller as well as the
> usb1, usb2, 1-2, and 2-2 paths under /sys/bus/usb/devices/.
Also, I don't have [12]-2 there:
1-0:1.0 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1/1-0:1.0
1-1 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1/1-1
1-1.1 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1
1-1.1:1.0 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.0
1-1.1:1.1 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.1
1-1.2 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2
1-1.2:1.0 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0
1-1.2:1.1 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.1
1-1:1.0 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1:1.0
2-0:1.0 -> ../../../devices/pci0000:00/0000:00:1d.0/usb2/2-0:1.0
2-1 -> ../../../devices/pci0000:00/0000:00:1d.0/usb2/2-1
2-1:1.0 -> ../../../devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0
usb1 -> ../../../devices/pci0000:00/0000:00:1a.0/usb1
usb2 -> ../../../devices/pci0000:00/0000:00:1d.0/usb2
--
WBR, wRAR
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
From: Andrey Rahmatullin @ 2012-04-19 15:44 UTC (permalink / raw)
To: Alan Stern
Cc: jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list,
Steven Rostedt
In-Reply-To: <Pine.LNX.4.44L0.1204190934500.2070-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 406 bytes --]
On Thu, Apr 19, 2012 at 09:43:45AM -0400, Alan Stern wrote:
> But before going any farther, I'd like to test if USB wakeup works.
> So after booting with this patch, make sure that the power/wakeup file
> says "enabled" in the sysfs path for each controller as well as the
> usb1, usb2, 1-2, and 2-2 paths under /sys/bus/usb/devices/.
Should I change them if they say "disabled"?
--
WBR, wRAR
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
From: Alan Stern @ 2012-04-19 13:43 UTC (permalink / raw)
To: Andrey Rahmatullin
Cc: jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list,
Steven Rostedt
In-Reply-To: <Pine.LNX.4.44L0.1204181729400.1149-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
On Wed, 18 Apr 2012, Alan Stern wrote:
> Tomorrow we can try to figure out the appropriate workaround.
Below is a patch that will prevent any PCI device from being put into
D3 during suspend. (This is meant to be used without any of the
earlier diagnostic patches.) Obviously it's not the final solution;
the test in the "if" statement needs to be more discriminating. :-)
But before going any farther, I'd like to test if USB wakeup works.
So after booting with this patch, make sure that the power/wakeup file
says "enabled" in the sysfs path for each controller as well as the
usb1, usb2, 1-2, and 2-2 paths under /sys/bus/usb/devices/.
Then suspend the computer without using the script, and while it is
asleep try plugging in a new USB device. That should cause the
computer to wake up, if everything is working properly.
Alan Stern
Index: usb-3.4/drivers/pci/pci.c
===================================================================
--- usb-3.4.orig/drivers/pci/pci.c
+++ usb-3.4/drivers/pci/pci.c
@@ -1713,6 +1713,8 @@ int pci_prepare_to_sleep(struct pci_dev
pci_power_t target_state = pci_target_state(dev);
int error;
+ if (1)
+ target_state = PCI_D0;
if (target_state == PCI_POWER_ERROR)
return -EIO;
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Devfreq Simple On Demand Governor
From: MyungJoo Ham @ 2012-04-19 2:48 UTC (permalink / raw)
To: Satendra...; +Cc: linux-pm
In-Reply-To: <CAChS5kO96UeZEeisRqdX7Ene_cQBjdB2+pduBMtoBWvXr4szTw@mail.gmail.com>
On Tue, Apr 17, 2012 at 7:19 PM, Satendra... <satendra.pratap@gmail.com> wrote:
> Hi Ham,
>
> Thanks for your replies. Below are my thoughts.
>
> On 16 April 2012 19:46, MyungJoo Ham <myungjoo.ham@gmail.com> wrote:
>>
>> On Mon, Apr 16, 2012 at 7:07 PM, Satendra... <satendra.pratap@gmail.com>
>> wrote:
>> > Hi Ham,
>> >
>> > I was looking at the simple on demand governor's code and have got few
>> > queries:
>> > - In the code below to check for overflow, why 24 and 7 has been taken?
>> > /* Prevent overflow */
>> > if (stat.busy_time >= (1 << 24) || stat.total_time >= (1 << 24))
>> > {
>> > stat.busy_time >>= 7;
>> > stat.total_time >>= 7;
>> > }
>>
>> It is because 1<<7 >= 100 and 1<<6 < 100. (To get percentage, we are
>> multiplying 100).
>>
> ok. but what about 24? Is it assumed that no one will be allowed to execute
> more than 2^(24-7) units (nsec, msecs etc)?
> Is 2^(24-7) = 128 * 1024 units (nsecs, msecs etc) the default time slice of
> kernel to any code?
It is because we are using 32 bit values and we want to avoid
overflow. If the numbers are sufficiently big, we can forget about the
least bits, which won't impact the precision significantly.
>
>>
>> >
>> > - Also for maximum frequency UINT_MAX is returned which may not be
>> > suited
>> > for some devices.
>>
>> The frequency given to devfreq driver is "recommended frequency", not
>> the "exact frequency required".
>>
>> Thus, the driver is required to choose
>> 1. frequency that is at least (but closest) or same with the
>> "recommended frequency"
>> and if that's impossible,
>> 2. frequency that is closest to the "recommended frequency".
>>
>> Thus, if it's "UINT_MAX", then it should choose the maximum frequency.
>>
>
> You mean we have to check for UINT_MAX in our code and if its so then set
> device at its maximum frequency.
>
>>
>> >
>> > - One more query, whats the unit (usecs, nsecs etc) used for busy and
>> > load
>> > time. Has it got nothing to do with units
>> > and its mere the percentage of busy time?
>>
>> The unit is up to the device driver. It only needs to provide
>> "reasonable" values in u32 to the infrastructure. It could be usec,
>> nsec, #ops, or anything else.
>> I've mentioned it only because jiffy does not seem to be "reasonable";
>> jiffy is too rough. You may even get 0 jiffies for 100 operations
>> while you may get 1 jiffy for 1 operation in the same system.
>>
>> In the governors, maybe busy / total ratio can be used as in
>> simple_ondemand. And you should give values that can support some fair
>> granularity there, which jiffy cannot.
>>
>> >
>> > - If we want to use simple on demand governor then do we need to modify
>> > yours to suit our needs? I mean you have
>> > just provided a framework?
>>
>> If you want to use THE simple_ondemand for your device, you only need
>> to create a devfreq driver. You don't need to modify the governor or
>> the framework/.
>>
>> >
>> > Thanks,
>> > Satendra
>>
>>
>> Cheers!
>> MyungJoo.
>>
>> --
>> MyungJoo Ham, Ph.D.
>> System S/W Lab, S/W Center, Samsung Electronics
>
>
> Thanks,
> Satendra
--
MyungJoo Ham, Ph.D.
System S/W Lab, S/W Center, Samsung Electronics
^ permalink raw reply
* Re: Regarding Devfreq
From: MyungJoo Ham @ 2012-04-19 2:45 UTC (permalink / raw)
To: Satendra...; +Cc: linux-pm
In-Reply-To: <CAChS5kP5n_UvZmJx2-Xatzr0WkH4qF0vc7XNh3v=CPfU184V8Q@mail.gmail.com>
2012/4/17 Satendra... <satendra.pratap@gmail.com>:
> Hi Ham,
>
> On 16 April 2012 17:40, MyungJoo Ham <myungjoo.ham@gmail.com> wrote:
>>
>> On Mon, Apr 16, 2012 at 7:19 PM, MyungJoo Ham <myungjoo.ham@gmail.com>
>> wrote:
>> > On Mon, Apr 16, 2012 at 4:02 PM, Satendra... <satendra.pratap@gmail.com>
>> > wrote:
>> >> Hi Ham,
>> >>
>> >> I have used jiffies to calculate the busy time and total time for a
>> >> module
>> >> (made of 'n' functions say).
>> >> I have added a bew structure:
>> >
>> > Hi.
>> >
>> > In my ARM SoC systems, one jiffy is 5ms. I don't think other systems
>> > won't vary too much (should be around several hundred us to several
>> > ms). Are you sure that jiffy has enough granularity for your system?
>> > If you are counting the length spent in a function call, shouldn't
>> > nsecs be usec? (ktime?). And for saving such values, the
>> > "private_data" is intended for individual devfreq drivers
>> > communicating with governors specific to the drivers. Devfreq->data is
>> > intended for individual devfreq governors. Thus, yes, platform-data is
>> > the right place for devfreq driver internal.
>> >
>> > Cheers!
>> > MyungJoo.
>> >
>>
>> Ah.. and one missing point:
>>
>> Please consider the concurrency. You may have multiple instance of
>> function calls in your device driver. And please do not block them by
>> simply adding locks there if this performance counting is the only
>> reason to make them mutually exclusive. This is another reason to
>> count nsecs (ktime) locally in the function and add the end-start
>> (local variable) into the aggregation variable (lock here only or use
>> atomic operators).
>>
>> Cheers!
>> MyungJoo.
>>
>
> Yes thats true that we will have multiple instances of function calls but
> every instance of driver
> will have its own copy of counters which can be accessed through platform
> data.
Even if each instance of driver has its own data structure, there
could be concurrent function calls to one driver, which will cause
problems.
I'm not talking about:
Thread 1: do_something_on(dev A)
Thread 2: do_something_on(dev B)
I'm talking about:
Thread 1: do_something_on(dev A)
Thread 2: do_something_on(dev A)
> So AFAICS we need not to worry about concurrency issue because no instance
> will touch the
> counters of another instance. Please correct if i am wrong.
>
> Below is the code using ktime API:
>
> typedef struct devfreq_perf_counters {
> #ifdef DEVFREQ_USE_KTIME
> ktime_t fentry_time; /* jiffies at the enrty of a func */
> ktime_t start_time; /* starting jiffies for every busy/total \
> load cal in the last x seconds*/
> ktime_t prev_count; /* last jiffies count */
> s64 busy_time; /* total execution jiffies count in the last \
> x seconds */
> #else
> unsigned long fentry_time; /* jiffies at the enrty of a func */
> unsigned long start_time; /* starting jiffies for every busy/total \
> load cal in the last x
> seconds*/
> unsigned long prev_count; /* last jiffies count */
> unsigned long busy_time; /* total execution jiffies count in the
> last \
> x seconds */
> #endif
> }devfreq_counters;
>
> #ifdef DEVFREQ_USE_KTIME
> /* using ktime */
> #define devfreq_func_start(dc) do {\
> (dc)->fentry_time = ktime_get();\
> }while(0)
>
> #define devfreq_func_end(dc) do {\
> (dc)->prev_count = ktime_get();\
> (dc)->busy_time += ktime_to_ns(ktime_sub((dc)->prev_count, \
> (dc)->fentry_time));\
> }while(0)
>
> #define module_busy_time(dc) ((dc)->busy_time)
>
> #define module_busy_plus_not_busy_time(dc) \
> ktime_to_ns(ktime_sub(ktime_get(), (dc)->start_time))
>
> #define devfreq_reset_counters(dc) do { \
> (dc)->start_time = ktime_get();\
> }while(0)
> #else
> #define devfreq_func_start(dc) \
> (dc)->fentry_time = jiffies
>
> #define devfreq_fun_end(dc) do { \
> (dc)->prev_count = (jiffies)-((dc)->fentry_time);\
> (dc)->busy_time += (dc)->prev_count;\
> }while(0)
>
> #define module_busy_time(dc) \
> jiffies_to_usecs((dc)->busy_time)
>
> #define module_busy_plus_not_busy_time(dc) \
> jiffies_to_usecs(((jiffies) - (dc)->start_time))
>
> #define devfreq_reset_counters(dc) do { \
> (dc)->fentry_time = 0UL; \
> (dc)->prev_count = 0UL; \
> (dc)->busy_time = 0UL; \
> (dc)->start_time = jiffies;\
> }while(0)
> #endif
>
> Thanks,
> Satendra
>
>>
>> >>
>> >> typedef struct devfreq_perf_counters {
>> >> unsigned long func_entry_jiffies; /* jiffies at the enrty of a
>> >> func
>> >> */
>> >> unsigned long start_jiffies; /* starting jiffies for every
>> >> busy/total \
>> >> load cal in the last x
>> >> seconds*/
>> >> unsigned long local_jiffies; /* last jiffies count */
>> >> unsigned long busy_jiffies; /* total execution jiffies count in
>> >> the
>> >> last \
>> >> x seconds */
>> >> }devfreq_counters;
>> >>
>> >> This structure's instance can be included in the platform_data(or
>> >> private
>> >> data) of the
>> >> driver which has to register itself with devfreq. This way while doing
>> >> set_drv_data, access
>> >> to these counters could be available all the time.
>> >>
>> >> Now there is one initialization function :
>> >>
>> >> void devfreq_counters_init(void *data)
>> >> {
>> >> devfreq_counters **dc = &data->dpc;
>> >>
>> >> *dc = kzalloc(sizeof (devfreq_counters), GFP_KERNEL);
>> >>
>> >> (*dc)->func_entry_jiffies = 0UL;
>> >> (*dc)->local_jiffies = 0UL;
>> >> (*dc)->busy_jiffies = 0UL;
>> >> (*dc)->start_jiffies = jiffies;
>> >>
>> >> return;
>> >> }
>> >>
>> >> This function initializes the counters and is called at the end of
>> >> driver
>> >> initialiation function.
>> >>
>> >> Now there is a list of APIs as shown below:
>> >>
>> >> #define devfreq_jiffies_start(dc) \
>> >> dc->func_entry_jiffies = jiffies
>> >>
>> >> #define devfreq_jiffies_end(dc) do { \
>> >> dc->local_jiffies = (jiffies)-(dc->func_entry_jiffies);\
>> >> dc->busy_jiffies += dc->local_jiffies;\
>> >> }while(0)
>> >>
>> >> #define busy_jiffies_in_usec(dc) \
>> >> jiffies_to_usecs((dc)->busy_jiffies)
>> >>
>> >> #define busy_plus_not_busy_jiffies_in_usec(dc) \
>> >> jiffies_to_usecs(((jiffies) - (dc)->start_jiffies))
>> >>
>> >> #define devfreq_reset_counters(dc) do { \
>> >> dc->func_entry_jiffies = 0UL; \
>> >> dc->local_jiffies = 0UL; \
>> >> dc->busy_jiffies = 0UL; \
>> >> dc->start_jiffies = jiffies;\
>> >> }while(0)
>> >>
>> >> Description:
>> >> - devfreq_jiffies_start(dc): Will be called in the start of the
>> >> function
>> >> (this is one of the functions
>> >> which we want to consider in measuring the busy time of the driver)
>> >> - devfreq_jiffies_end(dc): Will be called at the end of that function
>> >> - busy_jiffies_in_usec(dc): Will return jiffies for which all
>> >> considered
>> >> (for busy time) driver's
>> >> functions were busy
>> >> - busy_plus_not_busy_jiffies_in_usec(dc): Total jiffies i.e. busy time
>> >> + not
>> >> busy time of driver
>> >> - devfreq_reset_counters(dc): obvious
>> >>
>> >> I wanted the simple solution to busy and load and i thought about this.
>> >> This
>> >> solution hasn't been verified
>> >> yet.
>> >>
>> >> Ham, can you please provide your views on it.
>> >>
>> >> Thanks,
>> >> Satendra
>> >>
>> >>
>> >> On 29 March 2012 07:44, MyungJoo Ham <myungjoo.ham@gmail.com> wrote:
>> >>>
>> >>> 2012/3/28 Satendra... <satendra.pratap@gmail.com>
>> >>> >
>> >>> > Hi Ham,
>> >>> >
>> >>> > In the below struct :
>> >>> > struct devfreq_dev_status {
>> >>> > /* both since the last measure */
>> >>> > unsigned long total_time;
>> >>> > unsigned long busy_time;
>> >>> > unsigned long current_frequency;
>> >>> > void *private_data;
>> >>> > };
>> >>> >
>> >>> > How to calculate total_time/busy_time? Does it require hardware
>> >>> > support
>> >>> > (may be some performance counters)?
>> >>> >
>> >>> > Thanks,
>> >>> > Satendra
>> >>>
>> >>> It is decided by each devfreq device driver, which is why
>> >>> get_dev_status() is to be provided by the devfreq device driver.
>> >>>
>> >>> If the device has performance counters, then, it's great, but
>> >>> performance counters are not mandatory.
>> >>>
>> >>> Here goes a list of mechanisms to fetch busy/total time:
>> >>> - Performance counters
>> >>> - Measure the time between "operation start" and "operation end" and
>> >>> accumulate the time (getting busy time. probably by ktime?)
>> >>> - Measure the idle time (CPUIDLE/CPUFREQ does this)
>> >>> - Count the number of operation and calculate the operational time
>> >>> based on the number.
>> >>> - and so on.
>> >>>
>> >>> As you can see in the list, you don't need a hardware support such as
>> >>> performance counters.
>> >>>
>> >>>
>> >>>
>> >>> Cheers!
>> >>> MyungJoo.
>> >>>
>> >>> >
>> >>> >
>> >>> > On 21 March 2012 15:49, 함명주 <myungjoo.ham@samsung.com> wrote:
>> >>> >>
>> >>> >> Hi Stendra,
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >> - Bascially, you can determine the voltage based on frequency;
>> >>> >> thus, we
>> >>> >> do not need to determint voltages at DVFS framework. It is
>> >>> >> corresponding
>> >>> >> device driver's responsibility even when we have AVS features.
>> >>> >> Thus,
>> >>> >> yes,
>> >>> >> the target callback needs to control both frequency and voltage
>> >>> >> (and
>> >>> >> anything else required to change the frequency/voltage)
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >> - I recommend to use regulator framework to control regulators
>> >>> >> unless
>> >>> >> you
>> >>> >> really really need to ignore regulator framework. Don't reinvent
>> >>> >> the
>> >>> >> wheel.
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >> - The three steps you've mentioned are correct.
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >> - The mailing list is opened to all. You are welcomed to use it
>> >>> >> (CC'ed
>> >>> >> linux-pm) and just CC needed people.
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >> Cheers!
>> >>> >>
>> >>> >> MyungJoo.
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >> ------- Original Message -------
>> >>> >>
>> >>> >> Sender : Satendra...<satendra.pratap@gmail.com>
>> >>> >>
>> >>> >> Date : 2012-03-21 19:03 (GMT+09:00)
>> >>> >>
>> >>> >> Title : Re: Re: Regarding Devfreq
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >> Hi Ham,
>> >>> >>
>> >>> >> Thank you very much for your reply. I will try not to disturb you
>> >>> >> much.
>> >>> >> In Devfreq I dont see any API related to voltage scaling. Is it the
>> >>> >> "->target" function's (in struct devfreq_dev_profile)
>> >>> >> responsibility to change the voltage as well with frequency?
>> >>> >> Do we really need to register our regulators using regulator
>> >>> >> framework
>> >>> >> of
>> >>> >> linux for voltage scaling?
>> >>> >>
>> >>> >> For a clear understanding I need to do following to use devfreq (I
>> >>> >> am
>> >>> >> sorry as I may be verifying it again):
>> >>> >> - define an instance of "struct devfreq_dev_profile" and provide
>> >>> >> implementations of target, get_dev_status and exit callbacks
>> >>> >> - Implement our choice of governer or use any one from already
>> >>> >> implemented ones.
>> >>> >> - call "devfreq_add_device" function from our driver's probe
>> >>> >> function.
>> >>> >>
>> >>> >> is that it? or do we need to do something else also?
>> >>> >>
>> >>> >> Thanks,
>> >>> >> Satendra
>> >>> >>
>> >>> >>
>> >>> >> On 21 March 2012 15:14, 함명주 <myungjoo.ham@samsung.com> wrote:
>> >>> >>>
>> >>> >>> Hello Satendra,
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>> - For Devfreq, OPP is optional though recommended for easier
>> >>> >>> implementation. You can still implement all the needed things
>> >>> >>> without
>> >>> >>> OPP.
>> >>> >>> OPP is just a simple data structure to store pairs of voltage and
>> >>> >>> frequency.
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>> - Yes, you need to call devfreq_add_device() and supply the
>> >>> >>> required
>> >>> >>> data. You can implement your own governor or use one of predefined
>> >>> >>> governors. Runtime replacement of governors like CPUfreq is "TODO"
>> >>> >>> for
>> >>> >>> now.
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>> - For example, you can see /drivers/devfreq/exynos4_bus.c. GPU,
>> >>> >>> Display
>> >>> >>> devfreq drivers are under development in other companies (ARM).
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>> Cheers!
>> >>> >>>
>> >>> >>> MyungJoo.
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>> ------- Original Message -------
>> >>> >>>
>> >>> >>> Sender : Satendra...<satendra.pratap@gmail.com>
>> >>> >>>
>> >>> >>> Date : 2012-03-21 17:31 (GMT+09:00)
>> >>> >>>
>> >>> >>> Title : Re: Regarding Devfreq
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>> Hi Ham,
>> >>> >>>
>> >>> >>> I have studied DVFS and what I feel is that we need to use OPP and
>> >>> >>> Voltage regulator interfaces also to
>> >>> >>> maintain Optimum Performance Points and to provide APIs to change
>> >>> >>> the
>> >>> >>> voltage.
>> >>> >>> What I feel is that to use DVFS every driver has to
>> >>> >>> call devfreq_add_device function to register that device to
>> >>> >>> the devfreq framework. And in order to do that we have to
>> >>> >>> implement devfreq_dev_profile and our choice of governer.
>> >>> >>>
>> >>> >>> I appreciate your help.
>> >>> >>>
>> >>> >>> Thanks,
>> >>> >>> Satendra
>> >>> >>>
>> >>> >>> On 20 March 2012 12:16, Satendra... <satendra.pratap@gmail.com>
>> >>> >>> wrote:
>> >>> >>>>
>> >>> >>>> Hi Ham,
>> >>> >>>>
>> >>> >>>> We are working on a new SoC for our new product and would want to
>> >>> >>>> use
>> >>> >>>> your Devfreq
>> >>> >>>> framework for our devices. Would you please let me know any other
>> >>> >>>> implementation which
>> >>> >>>> uses devfreq ? so that we could take that as a reference.
>> >>> >>>> Or we would be the first one to start?
>> >>> >>>>
>> >>> >>>> Thanks,
>> >>> >>>> Satendra
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>> --
>> >>> >>>
>> >>> >>> MyungJoo Ham (함명주), PHD
>> >>> >>>
>> >>> >>> System S/W Lab, S/W Platform Team, Software Center
>> >>> >>> Samsung Electronics
>> >>> >>> Cell: +82-10-6714-2858
>> >>> >>>
>> >>> >>>
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >> --
>> >>> >>
>> >>> >> MyungJoo Ham (함명주), PHD
>> >>> >>
>> >>> >> System S/W Lab, S/W Platform Team, Software Center
>> >>> >> Samsung Electronics
>> >>> >> Cell: +82-10-6714-2858
>> >>> >>
>> >>> >>
>> >>> >
>> >>> >
>> >>> >
>> >>> > _______________________________________________
>> >>> > linux-pm mailing list
>> >>> > linux-pm@lists.linux-foundation.org
>> >>> > https://lists.linuxfoundation.org/mailman/listinfo/linux-pm
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> MyungJoo Ham, Ph.D.
>> >>> System S/W Lab, S/W Center, Samsung Electronics
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > MyungJoo Ham, Ph.D.
>> > System S/W Lab, S/W Center, Samsung Electronics
>>
>>
>>
>> --
>> MyungJoo Ham, Ph.D.
>> System S/W Lab, S/W Center, Samsung Electronics
>
>
--
MyungJoo Ham, Ph.D.
System S/W Lab, S/W Center, Samsung Electronics
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-pm
^ permalink raw reply
* Re: ehci_hcd related S3 lockup on ASUS laptops, again
From: Andrey Rahmatullin @ 2012-04-18 21:47 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: jrnieder, linux-pm, USB list, Steven Rostedt
In-Reply-To: <201204182344.16986.rjw@sisk.pl>
[-- Attachment #1.1: Type: text/plain, Size: 685 bytes --]
On Wed, Apr 18, 2012 at 11:44:16PM +0200, Rafael J. Wysocki wrote:
> > > > Yes, there are ways to work around this. At the moment I'm not sure
> > > > what would be best; we can ask Rafael. One big remaining puzzle: Why
> > > > are the EHCI controllers the only devices that cause a crash when left
> > > > in D3 during suspend? We may never know...
> > >
> > > Are they put into D3 by ACPI or using the native PCI PM?
> >
> > PCI PM, definitely. Maybe ACPI gets into the act as well, but I doubt
> > it. How would we tell?
>
> If ACPI is involved, the dev_printk() in acpi_pci_set_power_state() should
> trigger.
And it apparently doesn't?
--
WBR, wRAR
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
From: Rafael J. Wysocki @ 2012-04-18 21:44 UTC (permalink / raw)
To: Alan Stern
Cc: linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
Steven Rostedt, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
Andrey Rahmatullin, USB list
In-Reply-To: <Pine.LNX.4.44L0.1204181727580.1149-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
On Wednesday, April 18, 2012, Alan Stern wrote:
> On Wed, 18 Apr 2012, Rafael J. Wysocki wrote:
>
> > > Yes, there are ways to work around this. At the moment I'm not sure
> > > what would be best; we can ask Rafael. One big remaining puzzle: Why
> > > are the EHCI controllers the only devices that cause a crash when left
> > > in D3 during suspend? We may never know...
> >
> > Are they put into D3 by ACPI or using the native PCI PM?
>
> PCI PM, definitely. Maybe ACPI gets into the act as well, but I doubt
> it. How would we tell?
If ACPI is involved, the dev_printk() in acpi_pci_set_power_state() should
trigger.
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [linux-pm] ehci_hcd related S3 lockup on ASUS laptops, again
From: Steven Rostedt @ 2012-04-18 21:41 UTC (permalink / raw)
To: Alan Stern
Cc: Andrey Rahmatullin, jrnieder-Re5JQEeQqe8AvxtiuMwx3w,
linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, USB list
In-Reply-To: <Pine.LNX.4.44L0.1204181724570.1149-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
On Wed, 2012-04-18 at 17:27 -0400, Alan Stern wrote:
> > Below is the dmesg output after running with pm_test set to "platform".
>
> The part you included didn't show the suspend itself. It looks like a
> bunch of stuff following the resume. But I guess it doesn't much
> matter, since we now know what needs to be fixed.
Oops sorry. Even though Andrey posted stuff, I'll post this anyway.
Should include everything you need.
-- Steve
[ 42.896778] Intel AES-NI instructions are not detected.
[ 43.470301] PM: Starting manual resume from disk
[ 43.470384] PM: Hibernation image partition 254:2 present
[ 43.470386] PM: Looking for hibernation image.
[ 43.470862] PM: Image not found (code -22)
[ 43.470864] PM: Hibernation image not present or could not be loaded.
[ 43.478348] EXT4-fs (dm-1): INFO: recovery required on readonly filesystem
[ 43.478434] EXT4-fs (dm-1): write access will be enabled during recovery
[ 43.898420] EXT4-fs (dm-1): recovery complete
[ 43.899517] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: (null)
[ 45.842764] udev[396]: starting version 164
[ 46.558691] input: Lid Switch as /devices/LNXSYSTM:00/device:00/PNP0C0D:00/input/input1
[ 46.563721] input: PC Speaker as /devices/platform/pcspkr/input/input2
[ 46.573988] ACPI: Lid Switch [LID]
[ 46.574101] input: Sleep Button as /devices/LNXSYSTM:00/device:00/PNP0C0E:00/input/input3
[ 46.574186] ACPI: Sleep Button [SLPB]
[ 46.574281] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input4
[ 46.574360] ACPI: Power Button [PWRF]
[ 46.580765] wmi: Mapper loaded
[ 46.617519] ACPI: AC Adapter [AC0] (on-line)
[ 46.635591] Monitor-Mwait will be used to enter C-1 state
[ 46.635645] Monitor-Mwait will be used to enter C-2 state
[ 46.635673] ACPI: acpi_idle registered with cpuidle
[ 46.650782] ACPI: Battery Slot [BAT0] (battery present)
[ 46.690831] cfg80211: Calling CRDA to update world regulatory domain
[ 46.766509] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[ 46.772575] i801_smbus 0000:00:1f.3: PCI INT C -> GSI 18 (level, low) -> IRQ 18
[ 46.772658] ACPI: resource 0000:00:1f.3 [io 0xe040-0xe05f] conflicts with ACPI region SMBI [io 0xe040-0xe04f]
[ 46.772740] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[ 46.818531] Linux media interface: v0.10
[ 46.825793] Bluetooth: Core ver 2.16
[ 46.825868] NET: Registered protocol family 31
[ 46.825931] Bluetooth: HCI device and connection manager initialized
[ 46.825996] Bluetooth: HCI socket layer initialized
[ 46.826059] Bluetooth: L2CAP socket layer initialized
[ 46.826125] Bluetooth: SCO socket layer initialized
[ 46.840697] asus_wmi: ASUS WMI generic driver loaded
[ 46.938273] xhci_hcd 0000:03:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
[ 46.938427] xhci_hcd 0000:03:00.0: setting latency timer to 64
[ 46.938432] xhci_hcd 0000:03:00.0: xHCI Host Controller
[ 46.938505] xhci_hcd 0000:03:00.0: new USB bus registered, assigned bus number 3
[ 46.948266] xhci_hcd 0000:03:00.0: irq 19, io mem 0xdde00000
[ 46.948397] xhci_hcd 0000:03:00.0: irq 45 for MSI/MSI-X
[ 46.948400] xhci_hcd 0000:03:00.0: irq 46 for MSI/MSI-X
[ 46.948404] xhci_hcd 0000:03:00.0: irq 47 for MSI/MSI-X
[ 46.948407] xhci_hcd 0000:03:00.0: irq 48 for MSI/MSI-X
[ 46.948410] xhci_hcd 0000:03:00.0: irq 49 for MSI/MSI-X
[ 46.948518] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002
[ 46.948586] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 46.948664] usb usb3: Product: xHCI Host Controller
[ 46.948725] usb usb3: Manufacturer: Linux 3.2.5-custom+ xhci_hcd
[ 46.948790] usb usb3: SerialNumber: 0000:03:00.0
[ 46.948929] xHCI xhci_add_endpoint called for root hub
[ 46.948931] xHCI xhci_check_bandwidth called for root hub
[ 46.948959] hub 3-0:1.0: USB hub found
[ 46.949027] hub 3-0:1.0: 2 ports detected
[ 46.949144] xhci_hcd 0000:03:00.0: xHCI Host Controller
[ 46.949216] xhci_hcd 0000:03:00.0: new USB bus registered, assigned bus number 4
[ 46.949316] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003
[ 46.949384] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 46.949462] usb usb4: Product: xHCI Host Controller
[ 46.949524] usb usb4: Manufacturer: Linux 3.2.5-custom+ xhci_hcd
[ 46.949588] usb usb4: SerialNumber: 0000:03:00.0
[ 46.949706] xHCI xhci_add_endpoint called for root hub
[ 46.949708] xHCI xhci_check_bandwidth called for root hub
[ 46.949731] hub 4-0:1.0: USB hub found
[ 46.949798] hub 4-0:1.0: 2 ports detected
[ 46.979554] asus_wmi: Initialization: 0x1
[ 46.979632] asus_wmi: BIOS WMI version: 7.6
[ 46.979788] asus_wmi: SFUN value: 0xa0877
[ 46.980446] input: Asus WMI hotkeys as /devices/platform/asus-nb-wmi/input/input5
[ 47.042230] asus_wmi: Backlight controlled by ACPI video driver
[ 47.117511] Bluetooth: Generic Bluetooth USB driver ver 0.6
[ 47.117715] usbcore: registered new interface driver btusb
[ 47.139336] Intel(R) Wireless WiFi Link AGN driver for Linux, in-tree:
[ 47.139398] Copyright(c) 2003-2011 Intel Corporation
[ 47.139488] iwlwifi 0000:02:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[ 47.139553] iwlwifi 0000:02:00.0: setting latency timer to 64
[ 47.139575] iwlwifi 0000:02:00.0: pci_resource_len = 0x00002000
[ 47.139633] iwlwifi 0000:02:00.0: pci_resource_base = ffffc90005790000
[ 47.139691] iwlwifi 0000:02:00.0: HW Revision ID = 0x34
[ 47.139821] iwlwifi 0000:02:00.0: irq 50 for MSI/MSI-X
[ 47.139852] iwlwifi 0000:02:00.0: Detected Intel(R) Centrino(R) Wireless-N 1030 BGN, REV=0xB0
[ 47.139983] iwlwifi 0000:02:00.0: L1 Disabled; Enabling L0S
[ 47.155846] iwlwifi 0000:02:00.0: device EEPROM VER=0x716, CALIB=0x6
[ 47.155908] iwlwifi 0000:02:00.0: Device SKU: 0X150
[ 47.155967] iwlwifi 0000:02:00.0: Valid Tx ant: 0X1, Valid Rx ant: 0X3
[ 47.156035] iwlwifi 0000:02:00.0: Tunable channels: 13 802.11bg, 0 802.11a channels
[ 47.199920] snd_hda_intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
[ 47.200042] snd_hda_intel 0000:00:1b.0: irq 51 for MSI/MSI-X
[ 47.200067] snd_hda_intel 0000:00:1b.0: setting latency timer to 64
[ 47.275349] Linux video capture interface: v2.00
[ 47.303064] uvcvideo: Found UVC 1.00 device USB 2.0 UVC VGA WebCam (13d3:5710)
[ 47.309669] input: USB 2.0 UVC VGA WebCam as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/input/input6
[ 47.309818] usbcore: registered new interface driver uvcvideo
[ 47.309881] USB Video Class driver (1.1.1)
[ 47.310221] [drm] Initialized drm 1.1.0 20060810
[ 47.392764] psmouse serio4: synaptics: Touchpad model: 1, fw: 7.5, id: 0x1e0b1, caps: 0xd00073/0x240000/0xa0400
[ 47.426245] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio4/input/input7
[ 47.661923] iwlwifi 0000:02:00.0: loaded firmware version 17.168.5.1 build 33993
[ 47.662161] Registered led device: phy0-led
[ 47.694429] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs'
[ 47.963645] HDMI status: Codec=3 Pin=6 Presence_Detect=0 ELD_Valid=0
[ 47.963854] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1b.0/sound/card0/input8
[ 47.964240] input: HDA Intel PCH Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input9
[ 47.964430] input: HDA Intel PCH Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input10
[ 47.964770] i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 47.964834] i915 0000:00:02.0: setting latency timer to 64
[ 48.048682] i915 0000:00:02.0: irq 52 for MSI/MSI-X
[ 48.048687] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[ 48.048748] [drm] Driver supports precise vblank timestamp query.
[ 48.048838] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[ 48.683726] fbcon: inteldrmfb (fb0) is primary device
[ 48.924618] Console: switching to colour frame buffer device 170x48
[ 48.926877] fb0: inteldrmfb frame buffer device
[ 48.926878] drm: registered panic notifier
[ 48.979505] ACPI Warning: _BQC returned an invalid level (20110623/video-472)
[ 48.979864] acpi device:40: registered as cooling_device4
[ 48.980218] input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input11
[ 48.980302] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no)
[ 48.980411] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
[ 49.417304] EXT4-fs (dm-1): re-mounted. Opts: (null)
[ 49.610562] EXT4-fs (dm-1): re-mounted. Opts: errors=remount-ro
[ 49.833738] loop: module loaded
[ 50.257032] Adding 7811068k swap on /dev/mapper/VG00-Swap. Priority:-1 extents:1 across:7811068k
[ 51.068930] kjournald starting. Commit interval 5 seconds
[ 51.069511] EXT3-fs (sda5): using internal journal
[ 51.069516] EXT3-fs (sda5): mounted filesystem with ordered data mode
[ 51.137232] EXT4-fs (dm-3): mounted filesystem with ordered data mode. Opts: (null)
[ 52.829790] fuse init (API version 7.17)
[ 54.025020] RPC: Registered named UNIX socket transport module.
[ 54.025801] RPC: Registered udp transport module.
[ 54.026556] RPC: Registered tcp transport module.
[ 54.027316] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 54.396007] Installing knfsd (copyright (C) 1996 okir-pn4DOG8n3UYbFoVRYvo4fw@public.gmane.org).
[ 54.759224] input: ACPI Virtual Keyboard Device as /devices/virtual/input/input12
[ 56.352662] svc: failed to register lockdv1 RPC service (errno 97).
[ 56.353371] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
[ 56.366818] NFSD: starting 90-second grace period
[ 58.198428] iwlwifi 0000:02:00.0: L1 Disabled; Enabling L0S
[ 58.206338] iwlwifi 0000:02:00.0: Radio type=0x2-0x2-0x1
[ 58.298416] iwlwifi 0000:02:00.0: L1 Disabled; Enabling L0S
[ 58.307383] iwlwifi 0000:02:00.0: Radio type=0x2-0x2-0x1
[ 58.395490] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 58.404550] atl1c 0000:04:00.0: irq 53 for MSI/MSI-X
[ 58.489997] ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 67.638348] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 67.638352] Bluetooth: BNEP filters: protocol multicast
[ 67.710164] Bridge firewalling registered
[ 67.777648] Bluetooth: RFCOMM TTY layer initialized
[ 67.777664] Bluetooth: RFCOMM socket layer initialized
[ 67.777668] Bluetooth: RFCOMM ver 1.11
[ 70.854657] lp: driver loaded but no devices found
[ 70.871763] ppdev: user-space parallel port driver
[ 74.010024] sshd (2152): /proc/2152/oom_adj is deprecated, please use /proc/2152/oom_score_adj instead.
[ 88.946287] wlan0: authenticate with e0:91:f5:5e:86:d4 (try 1)
[ 88.949046] wlan0: authenticated
[ 88.949130] wlan0: associate with e0:91:f5:5e:86:d4 (try 1)
[ 88.952812] wlan0: RX AssocResp from e0:91:f5:5e:86:d4 (capab=0x411 status=0 aid=6)
[ 88.952815] wlan0: associated
[ 88.959397] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 99.259619] wlan0: no IPv6 routers present
[ 126.278905] iwlwifi 0000:02:00.0: Tx aggregation enabled on ra = e0:91:f5:5e:86:d4 tid = 6
[ 157.542516] ehci_hcd 0000:00:1a.0: remove, state 1
[ 157.544628] usb usb1: USB disconnect, device number 1
[ 157.546782] usb 1-1: USB disconnect, device number 2
[ 157.549045] usb 1-1.1: USB disconnect, device number 3
[ 157.551452] usb 1-1: clear tt 1 (9032) error -19
[ 157.551485] Bluetooth: hci0 urb ffff88022f4d1d80 submission failed
[ 157.802999] usb 1-1.2: USB disconnect, device number 4
[ 157.866578] ehci_hcd 0000:00:1a.0: USB bus 1 deregistered
[ 157.869037] ehci_hcd 0000:00:1a.0: PCI INT A disabled
[ 157.871489] ehci_hcd 0000:00:1d.0: remove, state 4
[ 157.873594] usb usb2: USB disconnect, device number 1
[ 157.875670] usb 2-1: USB disconnect, device number 2
[ 157.882492] ehci_hcd 0000:00:1d.0: USB bus 2 deregistered
[ 157.884674] ehci_hcd 0000:00:1d.0: PCI INT A disabled
[ 158.215336] wlan0: deauthenticating from e0:91:f5:5e:86:d4 by local choice (reason=3)
[ 158.427757] cfg80211: Calling CRDA to update world regulatory domain
[ 158.949659] PM: Syncing filesystems ... done.
[ 158.950715] PM: Preparing system for mem sleep
[ 158.951081] Freezing user space processes ... (elapsed 0.01 seconds) done.
[ 158.966690] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
[ 158.982673] PM: Entering mem sleep
[ 158.982783] Suspending console(s) (use no_console_suspend to debug)
[ 158.983044] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 159.025372] pci 0000:00:1f.3: PCI INT C disabled
[ 159.173746] sd 0:0:0:0: [sda] Stopping disk
[ 159.230634] snd_hda_intel 0000:00:1b.0: PCI INT A disabled
[ 159.585813] PM: suspend of devices complete after 603.884 msecs
[ 159.601635] atl1c 0000:04:00.0: cur 0 target 3 error 0
[ 159.601762] xhci_hcd 0000:03:00.0: PME# enabled
[ 159.601769] pcieport 0000:00:1c.3: wake-up capability enabled by ACPI
[ 159.617624] xhci_hcd 0000:03:00.0: cur 0 target 3 error 0
[ 159.633600] iwlwifi 0000:02:00.0: cur 0 target 3 error 0
[ 159.633654] pci 0000:00:1f.3: cur 0 target 0 error 0
[ 159.633703] pci 0000:00:1f.0: cur 5 target 0 error 0
[ 159.633734] pci 0000:00:1d.0: PME# enabled
[ 159.633739] pci 0000:00:1d.0: wake-up capability enabled by ACPI
[ 159.649551] pci 0000:00:1d.0: cur 0 target 3 error 0
[ 159.649629] pci 0000:00:1a.0: PME# enabled
[ 159.649656] pci 0000:00:1a.0: wake-up capability enabled by ACPI
[ 159.665525] pci 0000:00:1a.0: cur 0 target 3 error 0
[ 159.681497] pci 0000:00:16.0: Refused to change power state, currently in D0
[ 159.681506] pci 0000:00:16.0: cur 5 target 3 error 0
[ 159.681571] PM: late suspend of devices complete after 95.909 msecs
[ 159.682243] ACPI: Preparing to enter system sleep state S3
[ 161.191414] PM: Saving platform NVS memory
[ 161.192356] suspend debug: Waiting for 5 seconds.
[ 166.142910] ACPI: Waking up from system sleep state S3
[ 166.230892] i915 0000:00:02.0: BAR 0: set to [mem 0xdd000000-0xdd3fffff 64bit] (PCI address [0xdd000000-0xdd3fffff])
[ 166.230907] i915 0000:00:02.0: BAR 2: set to [mem 0xc0000000-0xcfffffff 64bit pref] (PCI address [0xc0000000-0xcfffffff])
[ 166.230917] i915 0000:00:02.0: BAR 4: set to [io 0xe000-0xe03f] (PCI address [0xe000-0xe03f])
[ 166.230951] i915 0000:00:02.0: restoring config space at offset 0x1 (was 0x900403, writing 0x900407)
[ 166.246866] pci 0000:00:1a.0: BAR 0: set to [mem 0xdfc08000-0xdfc083ff] (PCI address [0xdfc08000-0xdfc083ff])
[ 166.246900] pci 0000:00:1a.0: restoring config space at offset 0xf (was 0x100, writing 0x10b)
[ 166.246942] pci 0000:00:1a.0: restoring config space at offset 0x1 (was 0x2900000, writing 0x2900002)
[ 166.262844] snd_hda_intel 0000:00:1b.0: BAR 0: set to [mem 0xdfc00000-0xdfc03fff 64bit] (PCI address [0xdfc00000-0xdfc03fff])
[ 166.262883] snd_hda_intel 0000:00:1b.0: restoring config space at offset 0xf (was 0x100, writing 0x105)
[ 166.262920] snd_hda_intel 0000:00:1b.0: restoring config space at offset 0x3 (was 0x0, writing 0x10)
[ 166.262941] snd_hda_intel 0000:00:1b.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100002)
[ 166.278813] pci 0000:00:1d.0: BAR 0: set to [mem 0xdfc07000-0xdfc073ff] (PCI address [0xdfc07000-0xdfc073ff])
[ 166.278848] pci 0000:00:1d.0: restoring config space at offset 0xf (was 0x100, writing 0x105)
[ 166.278889] pci 0000:00:1d.0: restoring config space at offset 0x1 (was 0x2900000, writing 0x2900002)
[ 166.294842] ahci 0000:00:1f.2: restoring config space at offset 0x1 (was 0x2b00403, writing 0x2b00407)
[ 166.310776] iwlwifi 0000:02:00.0: BAR 0: set to [mem 0xde800000-0xde801fff 64bit] (PCI address [0xde800000-0xde801fff])
[ 166.310837] iwlwifi 0000:02:00.0: restoring config space at offset 0xf (was 0x100, writing 0x105)
[ 166.310901] iwlwifi 0000:02:00.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100006)
[ 166.326745] xhci_hcd 0000:03:00.0: BAR 0: set to [mem 0xdde00000-0xdde07fff 64bit] (PCI address [0xdde00000-0xdde07fff])
[ 166.326906] pcieport 0000:00:1c.3: wake-up capability disabled by ACPI
[ 166.326912] xhci_hcd 0000:03:00.0: PME# disabled
[ 166.342863] PM: early resume of devices complete after 127.606 msecs
[ 166.342935] i915 0000:00:02.0: setting latency timer to 64
[ 166.342940] pci 0000:00:1a.0: wake-up capability disabled by ACPI
[ 166.342947] pci 0000:00:1a.0: PME# disabled
[ 166.342950] snd_hda_intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
[ 166.342961] snd_hda_intel 0000:00:1b.0: setting latency timer to 64
[ 166.342970] pci 0000:00:1d.0: wake-up capability disabled by ACPI
[ 166.342976] pci 0000:00:1d.0: PME# disabled
[ 166.342984] pci 0000:00:1f.3: PCI INT C -> GSI 18 (level, low) -> IRQ 18
[ 166.342987] ahci 0000:00:1f.2: setting latency timer to 64
[ 166.343018] xhci_hcd 0000:03:00.0: setting latency timer to 64
[ 166.343039] snd_hda_intel 0000:00:1b.0: irq 51 for MSI/MSI-X
[ 166.343042] usb usb3: root hub lost power or was reset
[ 166.343043] usb usb4: root hub lost power or was reset
[ 166.343140] sd 0:0:0:0: [sda] Starting disk
[ 166.347650] xhci_hcd 0000:03:00.0: irq 45 for MSI/MSI-X
[ 166.347653] xhci_hcd 0000:03:00.0: irq 46 for MSI/MSI-X
[ 166.347657] xhci_hcd 0000:03:00.0: irq 47 for MSI/MSI-X
[ 166.347661] xhci_hcd 0000:03:00.0: irq 48 for MSI/MSI-X
[ 166.347665] xhci_hcd 0000:03:00.0: irq 49 for MSI/MSI-X
[ 166.662204] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 166.670183] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 166.673729] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) filtered out
[ 166.683187] ata1.00: ACPI cmd ef/10:06:00:00:00:a0 (SET FEATURES) succeeded
[ 166.683190] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered out
[ 166.684986] ata3.00: ACPI cmd ef/10:06:00:00:00:a0 (SET FEATURES) succeeded
[ 166.684996] ata3.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered out
[ 166.713928] ata3.00: ACPI cmd ef/10:06:00:00:00:a0 (SET FEATURES) succeeded
[ 166.713938] ata3.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered out
[ 166.726782] ata3.00: configured for UDMA/100
[ 168.627624] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) filtered out
[ 168.627913] ata1.00: ACPI cmd ef/10:06:00:00:00:a0 (SET FEATURES) succeeded
[ 168.627923] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered out
[ 168.628796] ata1.00: configured for UDMA/133
[ 168.660546] PM: resume of devices complete after 2321.391 msecs
[ 168.660712] PM: Finishing wakeup.
[ 168.660713] Restarting tasks ... done.
[ 168.665650] video LNXVIDEO:00: Restoring backlight state
[ 168.701530] iwlwifi 0000:02:00.0: L1 Disabled; Enabling L0S
[ 168.709187] iwlwifi 0000:02:00.0: Radio type=0x2-0x2-0x1
[ 168.801144] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 168.803561] atl1c 0000:04:00.0: irq 53 for MSI/MSI-X
[ 168.888515] ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 168.898150] ehci_hcd 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 168.900556] ehci_hcd 0000:00:1a.0: setting latency timer to 64
[ 168.900566] ehci_hcd 0000:00:1a.0: EHCI Host Controller
[ 168.902803] ehci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 1
[ 168.905033] ehci_hcd 0000:00:1a.0: debug port 2
[ 168.911060] ehci_hcd 0000:00:1a.0: cache line size of 64 is not supported
[ 168.911074] ehci_hcd 0000:00:1a.0: irq 16, io mem 0xdfc08000
[ 168.926501] ehci_hcd 0000:00:1a.0: USB 2.0 started, EHCI 1.00
[ 168.927782] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 168.929028] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 168.930280] usb usb1: Product: EHCI Host Controller
[ 168.931159] usb usb1: Manufacturer: Linux 3.2.5-custom+ ehci_hcd
[ 168.931825] usb usb1: SerialNumber: 0000:00:1a.0
[ 168.932636] hub 1-0:1.0: USB hub found
[ 168.933580] hub 1-0:1.0: 2 ports detected
[ 168.958631] ehci_hcd 0000:00:1d.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23
[ 168.959979] ehci_hcd 0000:00:1d.0: setting latency timer to 64
[ 168.959985] ehci_hcd 0000:00:1d.0: EHCI Host Controller
[ 168.961010] ehci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
[ 168.961888] ehci_hcd 0000:00:1d.0: debug port 2
[ 168.966644] ehci_hcd 0000:00:1d.0: cache line size of 64 is not supported
[ 168.966659] ehci_hcd 0000:00:1d.0: irq 23, io mem 0xdfc07000
[ 168.982442] ehci_hcd 0000:00:1d.0: USB 2.0 started, EHCI 1.00
[ 168.984712] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
[ 168.986937] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 168.989072] usb usb2: Product: EHCI Host Controller
[ 168.991221] usb usb2: Manufacturer: Linux 3.2.5-custom+ ehci_hcd
[ 168.993345] usb usb2: SerialNumber: 0000:00:1d.0
[ 168.995824] hub 2-0:1.0: USB hub found
[ 168.996495] hub 2-0:1.0: 2 ports detected
[ 169.246068] usb 1-1: new high-speed USB device number 2 using ehci_hcd
[ 169.378364] usb 1-1: New USB device found, idVendor=8087, idProduct=0024
[ 169.380124] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 169.382318] hub 1-1:1.0: USB hub found
[ 169.384196] hub 1-1:1.0: 6 ports detected
[ 169.497629] usb 2-1: new high-speed USB device number 2 using ehci_hcd
[ 169.629894] usb 2-1: New USB device found, idVendor=8087, idProduct=0024
[ 169.632100] usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 169.635009] hub 2-1:1.0: USB hub found
[ 169.637506] hub 2-1:1.0: 6 ports detected
[ 169.713401] usb 1-1.1: new full-speed USB device number 3 using ehci_hcd
[ 169.809382] usb 1-1.1: New USB device found, idVendor=8086, idProduct=0189
[ 169.811659] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 169.822285] wlan0: authenticate with e0:91:f5:5e:86:d4 (try 1)
[ 169.825100] wlan0: authenticated
[ 169.825502] wlan0: waiting for beacon from e0:91:f5:5e:86:d4
[ 169.835059] wlan0: beacon received
[ 169.873008] wlan0: associate with e0:91:f5:5e:86:d4 (try 1)
[ 169.876767] wlan0: RX AssocResp from e0:91:f5:5e:86:d4 (capab=0x411 status=0 aid=6)
[ 169.876776] wlan0: associated
[ 169.881390] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 169.889131] usb 1-1.2: new high-speed USB device number 4 using ehci_hcd
[ 170.042023] usb 1-1.2: New USB device found, idVendor=13d3, idProduct=5710
[ 170.044334] usb 1-1.2: New USB device strings: Mfr=3, Product=1, SerialNumber=2
[ 170.046665] usb 1-1.2: Product: USB 2.0 UVC VGA WebCam
[ 170.048996] usb 1-1.2: Manufacturer: Azurewave
[ 170.051261] usb 1-1.2: SerialNumber: 0x0001
[ 170.055819] uvcvideo: Found UVC 1.00 device USB 2.0 UVC VGA WebCam (13d3:5710)
[ 170.066505] input: USB 2.0 UVC VGA WebCam as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/input/input13
[ 179.996624] wlan0: no IPv6 routers present
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox