* Re: broken suspend [Was: 2.6.24-rc2-mm1] [not found] <Pine.LNX.4.44L0.0711181203220.5712-100000@netrider.rowland.org> @ 2007-11-18 19:09 ` Jiri Slaby [not found] ` <200711182328.00570.rjw@sisk.pl> ` (2 more replies) 0 siblings, 3 replies; 26+ messages in thread From: Jiri Slaby @ 2007-11-18 19:09 UTC (permalink / raw) To: Alan Stern; +Cc: Andrew Morton, Kernel development list, Linux-pm mailing list On 11/18/2007 06:07 PM, Alan Stern wrote: > You'll get more useful results if you redo your changes to > notifier_call_chain(). Have it print out the address of the routine > _before_ making the call, and don't limit it to 20. That way you'll > know exactly which notifier routine ends up hanging. The problem is, that notifier_call_chain is called again and again zillion times by somebody else... Anyway you led me to another idea: * _cpu_down printk("%s: u\n", __func__); BUBAK=1; /* CPU is completely dead: tell everyone. Too late to complain. */ if (raw_notifier_call_chain(&cpu_chain, CPU_DEAD | 0x88000 | mod, hcpu) == NOTIFY_BAD) BUG(); BUBAK=0; ----- * notifier_call_chain unsigned int a = val & 0x88000; unsigned int yes = a == 0x88000; nb = rcu_dereference(*nl); if (a && a != 0x88000) printk("Somebody calls with val: %lx\n", val); else val &= ~0x88000; while (nb && nr_to_call) { next_nb = rcu_dereference(nb->next); if (unlikely(BUBAK && yes)) printk("%s: %p\n", __func__, nb->notifier_call); ret = nb->notifier_call(nb, val, v); ----- gives coretemp_cpu_callback -> coretemp_device_remove -> platform_device_unregister, so coretemp seems to be what I have and you don't. ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <200711182328.00570.rjw@sisk.pl>]
* Re: broken suspend [Was: 2.6.24-rc2-mm1] [not found] ` <200711182328.00570.rjw@sisk.pl> @ 2007-11-18 22:12 ` Jiri Slaby [not found] ` <4740B8E9.4030903@gmail.com> 1 sibling, 0 replies; 26+ messages in thread From: Jiri Slaby @ 2007-11-18 22:12 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Andrew Morton, Kernel development list, Linux-pm mailing list On 11/18/2007 11:27 PM, Rafael J. Wysocki wrote: > You can use a global variable to switch the logging only before the CPU > hotunplug done by the suspend code. You just need to hack > disable_nonboot_cpus() for that. If I understand you correctly, that's what BUBAK variable is there for. But it is still called again and again while the suspend code runs... regards, -- Jiri Slaby (jirislaby@gmail.com) Faculty of Informatics, Masaryk University ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <4740B8E9.4030903@gmail.com>]
* Re: broken suspend [Was: 2.6.24-rc2-mm1] [not found] ` <4740B8E9.4030903@gmail.com> @ 2007-11-18 22:42 ` Rafael J. Wysocki 0 siblings, 0 replies; 26+ messages in thread From: Rafael J. Wysocki @ 2007-11-18 22:42 UTC (permalink / raw) To: Jiri Slaby; +Cc: Andrew Morton, Kernel development list, Linux-pm mailing list On Sunday, 18 of November 2007, Jiri Slaby wrote: > On 11/18/2007 11:27 PM, Rafael J. Wysocki wrote: > > You can use a global variable to switch the logging only before the CPU > > hotunplug done by the suspend code. You just need to hack > > disable_nonboot_cpus() for that. > > If I understand you correctly, that's what BUBAK variable is there for. Ah, yes. -ETOOTIRED > But it is still called again and again while the suspend code runs... You can count the number of calls and then make it print the information for the last, say, 20 of them. Greetings, Rafael ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: broken suspend [Was: 2.6.24-rc2-mm1] 2007-11-18 19:09 ` broken suspend [Was: 2.6.24-rc2-mm1] Jiri Slaby [not found] ` <200711182328.00570.rjw@sisk.pl> @ 2007-11-18 22:27 ` Jiri Slaby 2007-11-19 3:04 ` Alan Stern 2007-11-18 22:27 ` Rafael J. Wysocki 2 siblings, 1 reply; 26+ messages in thread From: Jiri Slaby @ 2007-11-18 22:27 UTC (permalink / raw) To: Alan Stern Cc: r.marek, Kernel development list, lm-sensors, Andrew Morton, Linux-pm mailing list Aah, we probably should let coretemp people known. Whole thread: http://marc.info/?t=119507205800001&r=1&w=2 On 11/18/2007 08:09 PM, Jiri Slaby wrote: > On 11/18/2007 06:07 PM, Alan Stern wrote: >> You'll get more useful results if you redo your changes to >> notifier_call_chain(). Have it print out the address of the routine >> _before_ making the call, and don't limit it to 20. That way you'll >> know exactly which notifier routine ends up hanging. > > The problem is, that notifier_call_chain is called again and again zillion times > by somebody else... > > Anyway you led me to another idea: > * _cpu_down > printk("%s: u\n", __func__); > BUBAK=1; > /* CPU is completely dead: tell everyone. Too late to complain. */ > if (raw_notifier_call_chain(&cpu_chain, CPU_DEAD | 0x88000 | mod, > hcpu) == NOTIFY_BAD) > BUG(); > BUBAK=0; > ----- > * notifier_call_chain > unsigned int a = val & 0x88000; > unsigned int yes = a == 0x88000; > > nb = rcu_dereference(*nl); > > if (a && a != 0x88000) > printk("Somebody calls with val: %lx\n", val); > else > val &= ~0x88000; > > while (nb && nr_to_call) { > next_nb = rcu_dereference(nb->next); > if (unlikely(BUBAK && yes)) > printk("%s: %p\n", __func__, nb->notifier_call); > ret = nb->notifier_call(nb, val, v); > ----- > gives coretemp_cpu_callback -> coretemp_device_remove -> > platform_device_unregister, so coretemp seems to be what I have and you don't. Just in case you are curious: http://www.fi.muni.cz/~xslaby/sklad/susp_hang3.diff produces: http://www.fi.muni.cz/~xslaby/sklad/susp_hang3.png ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: broken suspend [Was: 2.6.24-rc2-mm1] 2007-11-18 22:27 ` Jiri Slaby @ 2007-11-19 3:04 ` Alan Stern 0 siblings, 0 replies; 26+ messages in thread From: Alan Stern @ 2007-11-19 3:04 UTC (permalink / raw) To: Jiri Slaby Cc: r.marek, Kernel development list, lm-sensors, Andrew Morton, Linux-pm mailing list On Sun, 18 Nov 2007, Jiri Slaby wrote: > > gives coretemp_cpu_callback -> coretemp_device_remove -> > > platform_device_unregister, so coretemp seems to be what I have and you don't. Yes. For the coretemp developers: coretemp_cpu_callback() needs to be more careful about what it does. During a system sleep transition (suspend, hibernate, resume) it isn't possible to register or unregister a device. Attempts to register will fail and attempts to unregister will block until the system sleep is over -- and for this callback that means hanging. It's not clear what the best way is to fix this. Perhaps the CPU notification should be sent along with a special flag indicating that the CPU transition is part of a system sleep (although this seems racy). Perhaps the driver should notice when a system sleep begins, and defer all CPU-change handling until after the sleep is over. Alan Stern ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: broken suspend [Was: 2.6.24-rc2-mm1] 2007-11-18 19:09 ` broken suspend [Was: 2.6.24-rc2-mm1] Jiri Slaby [not found] ` <200711182328.00570.rjw@sisk.pl> 2007-11-18 22:27 ` Jiri Slaby @ 2007-11-18 22:27 ` Rafael J. Wysocki 2 siblings, 0 replies; 26+ messages in thread From: Rafael J. Wysocki @ 2007-11-18 22:27 UTC (permalink / raw) To: Jiri Slaby; +Cc: Andrew Morton, Kernel development list, Linux-pm mailing list On Sunday, 18 of November 2007, Jiri Slaby wrote: > On 11/18/2007 06:07 PM, Alan Stern wrote: > > You'll get more useful results if you redo your changes to > > notifier_call_chain(). Have it print out the address of the routine > > _before_ making the call, and don't limit it to 20. That way you'll > > know exactly which notifier routine ends up hanging. > > The problem is, that notifier_call_chain is called again and again zillion times > by somebody else... You can use a global variable to switch the logging only before the CPU hotunplug done by the suspend code. You just need to hack disable_nonboot_cpus() for that. ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <Pine.LNX.4.44L0.0711182156330.22727-100000@netrider.rowland.org>]
* Re: broken suspend [Was: 2.6.24-rc2-mm1] [not found] <Pine.LNX.4.44L0.0711182156330.22727-100000@netrider.rowland.org> @ 2007-11-19 20:01 ` Rudolf Marek [not found] ` <4741EB91.9080000@assembler.cz> 1 sibling, 0 replies; 26+ messages in thread From: Rudolf Marek @ 2007-11-19 20:01 UTC (permalink / raw) To: Alan Stern Cc: Jiri Slaby, Kernel development list, lm-sensors, Andrew Morton, Linux-pm mailing list Hello all, >>> gives coretemp_cpu_callback -> coretemp_device_remove -> >>> platform_device_unregister, so coretemp seems to be what I have and you don't. > > Yes. > > For the coretemp developers: coretemp_cpu_callback() needs to be more > careful about what it does. During a system sleep transition (suspend, > hibernate, resume) it isn't possible to register or unregister a > device. Attempts to register will fail and attempts to unregister will > block until the system sleep is over -- and for this callback that > means hanging. Well I wrote the driver. Thanks for the clarification. If I recall correctly I looked how this part should be done from others drivers. Now while checking what happened to the file, seems Rafael added something related. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8bb7844286fb8c9fce6f65d8288aeb09d03a5e0d > It's not clear what the best way is to fix this. Perhaps the CPU > notification should be sent along with a special flag indicating that > the CPU transition is part of a system sleep (although this seems > racy). Perhaps the driver should notice when a system sleep begins, > and defer all CPU-change handling until after the sleep is over. maybe it does exist? CPU_DOWN_PREPARE ? http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/cpu-hotplug.txt;hb=HEAD Unfortunately I'm not very familiar with this, calling the coretemp_device_remove from CPU_DOWN_PREPARE would help? Looking at microcode driver, seems it just hide sysfs interface from user. Thanks, Rudolf ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <4741EB91.9080000@assembler.cz>]
* Re: broken suspend [Was: 2.6.24-rc2-mm1] [not found] ` <4741EB91.9080000@assembler.cz> @ 2007-11-19 20:27 ` Alan Stern 2007-11-19 21:53 ` Rafael J. Wysocki 1 sibling, 0 replies; 26+ messages in thread From: Alan Stern @ 2007-11-19 20:27 UTC (permalink / raw) To: Rudolf Marek Cc: Jiri Slaby, Kernel development list, lm-sensors, Andrew Morton, Linux-pm mailing list On Mon, 19 Nov 2007, Rudolf Marek wrote: > Hello all, > >>> gives coretemp_cpu_callback -> coretemp_device_remove -> > >>> platform_device_unregister, so coretemp seems to be what I have and you don't. > > > > Yes. > > > > For the coretemp developers: coretemp_cpu_callback() needs to be more > > careful about what it does. During a system sleep transition (suspend, > > hibernate, resume) it isn't possible to register or unregister a > > device. Attempts to register will fail and attempts to unregister will > > block until the system sleep is over -- and for this callback that > > means hanging. > > Well I wrote the driver. Thanks for the clarification. If I recall correctly I > looked how this part should be done from others drivers. Now while checking > what happened to the file, seems Rafael added something related. > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8bb7844286fb8c9fce6f65d8288aeb09d03a5e0d That does look like it was meant for exactly this sort of situation. > > It's not clear what the best way is to fix this. Perhaps the CPU > > notification should be sent along with a special flag indicating that > > the CPU transition is part of a system sleep (although this seems > > racy). Perhaps the driver should notice when a system sleep begins, > > and defer all CPU-change handling until after the sleep is over. > > maybe it does exist? CPU_DOWN_PREPARE ? > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/cpu-hotplug.txt;hb=HEAD > > Unfortunately I'm not very familiar with this, calling the > coretemp_device_remove from CPU_DOWN_PREPARE would help? Looking at microcode > driver, seems it just hide sysfs interface from user. I'm not sure exactly what you want to do here. But it seems like a waste to unregister the coretemp devices at the start of a system sleep and then register them back at the end. Could you simply leave the devices registered throughout the entire sleep? Of course, at the end you would have to check that all the CPUs really did come back up, and unregister the devices for the CPUs that are still offline. Alan Stern ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: broken suspend [Was: 2.6.24-rc2-mm1] [not found] ` <4741EB91.9080000@assembler.cz> 2007-11-19 20:27 ` Alan Stern @ 2007-11-19 21:53 ` Rafael J. Wysocki 1 sibling, 0 replies; 26+ messages in thread From: Rafael J. Wysocki @ 2007-11-19 21:53 UTC (permalink / raw) To: Rudolf Marek Cc: Jiri Slaby, Kernel development list, lm-sensors, Andrew Morton, Linux-pm mailing list On Monday, 19 of November 2007, Rudolf Marek wrote: > Hello all, > >>> gives coretemp_cpu_callback -> coretemp_device_remove -> > >>> platform_device_unregister, so coretemp seems to be what I have and you don't. > > > > Yes. > > > > For the coretemp developers: coretemp_cpu_callback() needs to be more > > careful about what it does. During a system sleep transition (suspend, > > hibernate, resume) it isn't possible to register or unregister a > > device. Attempts to register will fail and attempts to unregister will > > block until the system sleep is over -- and for this callback that > > means hanging. > > Well I wrote the driver. Thanks for the clarification. If I recall correctly I > looked how this part should be done from others drivers. Now while checking > what happened to the file, seems Rafael added something related. > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8bb7844286fb8c9fce6f65d8288aeb09d03a5e0d Well, in principle you can use the observation that the _FROZEN versions are used during suspend/hibernation. Thus, if you only unregister the device for CPU_DEAD, but you won't do that for CPU_DEAD_FROZEN, it will work as long as the freezer is there. > > It's not clear what the best way is to fix this. Perhaps the CPU > > notification should be sent along with a special flag indicating that > > the CPU transition is part of a system sleep (although this seems > > racy). In fact, it's already done that way and I don't think it's racy (see above). Greetings, Rafael ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <4740570A.5030101@gmail.com>]
* Re: broken suspend [Was: 2.6.24-rc2-mm1] [not found] <4740570A.5030101@gmail.com> @ 2007-11-18 17:07 ` Alan Stern 0 siblings, 0 replies; 26+ messages in thread From: Alan Stern @ 2007-11-18 17:07 UTC (permalink / raw) To: Jiri Slaby; +Cc: Andrew Morton, Kernel development list, Linux-pm mailing list On Sun, 18 Nov 2007, Jiri Slaby wrote: > On 11/18/2007 04:23 PM, RafaÅ J. Wysocki wrote: > > On Sunday, 18 of November 2007, Jiri Slaby wrote: > >> On 11/18/2007 04:03 PM, Rafael J. Wysocki wrote: > >>> Can you also make the new System-map available, please? > >> Sure: > >> http://www.fi.muni.cz/~xslaby/sklad/System.map1 > > > > The last notifier called in http://www.fi.muni.cz/~xslaby/sklad/susp_hang2.png > > Last... Note, that it's only first 20 invokations of notifiers, there are > bazillion of them when I remove the condition '< 20'. > > > is apparently cpu_swap_callback() which is not called in > > http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png . > > > > Can you verify that cpu_swap_callback() gets called if the patch is not > > applied? > > Does this still apply? You'll get more useful results if you redo your changes to notifier_call_chain(). Have it print out the address of the routine _before_ making the call, and don't limit it to 20. That way you'll know exactly which notifier routine ends up hanging. Alan Stern ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <Pine.LNX.4.44L0.0711171649100.7748-100000@netrider.rowland.org>]
* Re: broken suspend [Was: 2.6.24-rc2-mm1] [not found] <Pine.LNX.4.44L0.0711171649100.7748-100000@netrider.rowland.org> @ 2007-11-18 12:42 ` Jiri Slaby [not found] ` <4740332A.80002@gmail.com> 1 sibling, 0 replies; 26+ messages in thread From: Jiri Slaby @ 2007-11-18 12:42 UTC (permalink / raw) To: Alan Stern; +Cc: Andrew Morton, Kernel development list, Linux-pm mailing list Alan Stern napsal(a): > On Sat, 17 Nov 2007, Rafael J. Wysocki wrote: >> On Saturday, 17 of November 2007, Jiri Slaby wrote: >>> On 11/16/2007 05:10 PM, Alan Stern wrote: >>>> The thing to do is figure out which driver is causing the problem. >>>> Jiri, try enabling CONFIG_DEBUG_DRIVER. >>> Sadly no output. Nice update scripts wiped kern.* from syslog config file out, hence no output before. > Back to the main topic... My system hibernates and resumes with no > apparent problem. Jiri, it looks like you'll have to do some debug > tracing of the routines in drivers/base/power/main.c. Beside this two nothing strange: dpm_suspend: b 00:06 WARNING: at /home/l/latest/bughunt/kernel/resource.c:185 __release_resource() Call Trace: [<ffffffff8023f7b5>] release_resource+0xb5/0xf0 [<ffffffff8036cda0>] pnp_release_resources+0x70/0x130 [<ffffffff8036db85>] pnp_stop_dev+0x45/0x90 [<ffffffff8036c942>] pnp_bus_suspend+0x92/0xb0 [<ffffffff803b9f73>] suspend_device+0x113/0x180 [<ffffffff803ba330>] device_suspend+0x200/0x320 [<ffffffff80266905>] suspend_devices_and_enter+0xa5/0x170 [<ffffffff80266bd9>] enter_state+0x209/0x270 [<ffffffff80266cef>] state_store+0xaf/0xf0 [<ffffffff8032ca67>] kobj_attr_store+0x17/0x20 [<ffffffff802e459e>] sysfs_write_file+0xce/0x140 [<ffffffff80299cc7>] vfs_write+0xc7/0x170 [<ffffffff8029a360>] sys_write+0x50/0x90 [<ffffffff8020bcde>] system_call+0x7e/0x83 WARNING: at /home/l/latest/bughunt/kernel/resource.c:189 __release_resource() Call Trace: [<ffffffff8023f7e0>] release_resource+0xe0/0xf0 [<ffffffff8036cda0>] pnp_release_resources+0x70/0x130 [<ffffffff8036db85>] pnp_stop_dev+0x45/0x90 [<ffffffff8036c942>] pnp_bus_suspend+0x92/0xb0 [<ffffffff803b9f73>] suspend_device+0x113/0x180 [<ffffffff803ba330>] device_suspend+0x200/0x320 [<ffffffff80266905>] suspend_devices_and_enter+0xa5/0x170 [<ffffffff80266bd9>] enter_state+0x209/0x270 [<ffffffff80266cef>] state_store+0xaf/0xf0 [<ffffffff8032ca67>] kobj_attr_store+0x17/0x20 [<ffffffff802e459e>] sysfs_write_file+0xce/0x140 [<ffffffff80299cc7>] vfs_write+0xc7/0x170 [<ffffffff8029a360>] sys_write+0x50/0x90 [<ffffffff8020bcde>] system_call+0x7e/0x83 ... dpm_suspend: b 0000:00:1f.5 ACPI Error (psargs-0355): [FZHD] Namespace lookup failure, AE_NOT_FOUND ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.SAT1.CHN0._GTM] (Node FFFF81007D000220), AE_NOT_FOUND ACPI Error (psargs-0355): [FZHD] Namespace lookup failure, AE_NOT_FOUND ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.SAT1.CHN1._GTM] (Node FFFF81007D000360), AE_NOT_FOUND It's stuck at _cpu_down (enter_state -> suspend_devices_and_enter -> disable_nonboot_cpus -> _cpu_down) after calling raw_notifier_call_chain printk("%s: s\n", __func__); /* Wait for it to sleep (leaving idle task). */ while (!idle_cpu(cpu)) yield(); printk("%s: t\n", __func__); /* This actually kills the CPU. */ __cpu_die(cpu); printk("%s: u\n", __func__); BUBAK=1; /* CPU is completely dead: tell everyone. Too late to complain. */ if (raw_notifier_call_chain(&cpu_chain, CPU_DEAD | mod, hcpu) == NOTIFY_BAD) BUG(); BUBAK=0; printk("%s: v\n", __func__); See shot of prints here: http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png notifier_call_chain looks like: while (nb && nr_to_call) { next_nb = rcu_dereference(nb->next); ret = nb->notifier_call(nb, val, v); if (unlikely(BUBAK && cnt < 20 && (ret != lastr || lastp != nb->notifier_call))) { printk("%s: c %p %d\n", __func__, nb->notifier_call, ret); lastr = ret; lastp = nb->notifier_call; cnt++; } if (nr_calls) (*nr_calls)++; if ((ret & NOTIFY_STOP_MASK) == NOTIFY_STOP_MASK) break; nb = next_nb; nr_to_call--; } System.map is here if you are curoius what are the pointers from the snapshot: http://www.fi.muni.cz/~xslaby/sklad/System.map regards, -- http://www.fi.muni.cz/~xslaby/ Jiri Slaby faculty of informatics, masaryk university, brno, cz ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <4740332A.80002@gmail.com>]
* Re: broken suspend [Was: 2.6.24-rc2-mm1] [not found] ` <4740332A.80002@gmail.com> @ 2007-11-18 13:06 ` Jiri Slaby [not found] ` <474038C9.3040002@gmail.com> 1 sibling, 0 replies; 26+ messages in thread From: Jiri Slaby @ 2007-11-18 13:06 UTC (permalink / raw) To: Alan Stern; +Cc: Andrew Morton, Kernel development list, Linux-pm mailing list On 11/18/2007 01:42 PM, Jiri Slaby wrote: > See shot of prints here: > http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png BTW output from that tree minus the patch: _cpu_down: s _cpu_down: t CPU 1 is now offline SMP alternatives: switching to UP code _cpu_down: u notifier_call_chain: c FFFFFFFF80232370 1 notifier_call_chain: c FFFFFFFF8026EF10 1 notifier_call_chain: c FFFFFFFF8024B8F0 1 notifier_call_chain: c FFFFFFFF802419E0 1 notifier_call_chain: c FFFFFFFF80255B50 1 notifier_call_chain: c FFFFFFFF80250C40 1 notifier_call_chain: c FFFFFFFF8028E8F0 1 notifier_call_chain: c FFFFFFFF802B59C0 1 notifier_call_chain: c FFFFFFFF80323460 1 notifier_call_chain: c FFFFFFFF80270990 0 notifier_call_chain: c FFFFFFFF8023D5D0 1 notifier_call_chain: c FFFFFFFF80266090 1 notifier_call_chain: c FFFFFFFF802320A0 1 notifier_call_chain: c FFFFFFFF80249DA0 1 notifier_call_chain: c FFFFFFFF80318440 1 notifier_call_chain: c FFFFFFFF8047BE80 1 notifier_call_chain: c FFFFFFFF80212F40 0 notifier_call_chain: c FFFFFFFF80216350 1 notifier_call_chain: c FFFFFFFF80217220 1 notifier_call_chain: c FFFFFFFF80218120 1 _cpu_down: v _cpu_down: w _cpu_down: x _cpu_down: y _cpu_down: z disable_nonboot_cpus: 3 0 regards, -- Jiri Slaby (jirislaby@gmail.com) Faculty of Informatics, Masaryk University ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <474038C9.3040002@gmail.com>]
* Re: broken suspend [Was: 2.6.24-rc2-mm1] [not found] ` <474038C9.3040002@gmail.com> @ 2007-11-18 13:42 ` Rafael J. Wysocki [not found] ` <200711181442.09917.rjw@sisk.pl> 1 sibling, 0 replies; 26+ messages in thread From: Rafael J. Wysocki @ 2007-11-18 13:42 UTC (permalink / raw) To: Jiri Slaby; +Cc: Andrew Morton, Kernel development list, Linux-pm mailing list On Sunday, 18 of November 2007, Jiri Slaby wrote: > On 11/18/2007 01:42 PM, Jiri Slaby wrote: > > See shot of prints here: > > http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png > > BTW output from that tree minus the patch: Hm, it looks like one of the CPU hotplug notifiers is doing something wrong. Can you try to see what happens (with the patch applied) if thermal_throttle_cpu_callback() is not registered? > _cpu_down: s > _cpu_down: t > CPU 1 is now offline > SMP alternatives: switching to UP code > _cpu_down: u > notifier_call_chain: c FFFFFFFF80232370 1 > notifier_call_chain: c FFFFFFFF8026EF10 1 > notifier_call_chain: c FFFFFFFF8024B8F0 1 > notifier_call_chain: c FFFFFFFF802419E0 1 > notifier_call_chain: c FFFFFFFF80255B50 1 > notifier_call_chain: c FFFFFFFF80250C40 1 > notifier_call_chain: c FFFFFFFF8028E8F0 1 > notifier_call_chain: c FFFFFFFF802B59C0 1 > notifier_call_chain: c FFFFFFFF80323460 1 > notifier_call_chain: c FFFFFFFF80270990 0 > notifier_call_chain: c FFFFFFFF8023D5D0 1 > notifier_call_chain: c FFFFFFFF80266090 1 > notifier_call_chain: c FFFFFFFF802320A0 1 > notifier_call_chain: c FFFFFFFF80249DA0 1 > notifier_call_chain: c FFFFFFFF80318440 1 > notifier_call_chain: c FFFFFFFF8047BE80 1 > notifier_call_chain: c FFFFFFFF80212F40 0 > notifier_call_chain: c FFFFFFFF80216350 1 > notifier_call_chain: c FFFFFFFF80217220 1 > notifier_call_chain: c FFFFFFFF80218120 1 > _cpu_down: v > _cpu_down: w > _cpu_down: x > _cpu_down: y > _cpu_down: z > disable_nonboot_cpus: 3 0 ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <200711181442.09917.rjw@sisk.pl>]
* Re: broken suspend [Was: 2.6.24-rc2-mm1] [not found] ` <200711181442.09917.rjw@sisk.pl> @ 2007-11-18 13:53 ` Jiri Slaby [not found] ` <474043EC.4000700@gmail.com> 1 sibling, 0 replies; 26+ messages in thread From: Jiri Slaby @ 2007-11-18 13:53 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Andrew Morton, Kernel development list, Linux-pm mailing list On 11/18/2007 02:42 PM, Rafael J. Wysocki wrote: > On Sunday, 18 of November 2007, Jiri Slaby wrote: >> On 11/18/2007 01:42 PM, Jiri Slaby wrote: >>> See shot of prints here: >>> http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png >> BTW output from that tree minus the patch: > > Hm, it looks like one of the CPU hotplug notifiers is doing something wrong. > > Can you try to see what happens (with the patch applied) if > thermal_throttle_cpu_callback() is not registered? After commenting out //device_initcall(thermal_throttle_init_device); it looks like this: http://www.fi.muni.cz/~xslaby/sklad/susp_hang2.png regards, -- Jiri Slaby (jirislaby@gmail.com) Faculty of Informatics, Masaryk University ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <474043EC.4000700@gmail.com>]
[parent not found: <200711181603.26522.rjw@sisk.pl>]
* Re: broken suspend [Was: 2.6.24-rc2-mm1] [not found] ` <200711181603.26522.rjw@sisk.pl> @ 2007-11-18 14:49 ` Jiri Slaby [not found] ` <474050EC.5080507@gmail.com> 1 sibling, 0 replies; 26+ messages in thread From: Jiri Slaby @ 2007-11-18 14:49 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Andrew Morton, Kernel development list, Linux-pm mailing list On 11/18/2007 04:03 PM, Rafael J. Wysocki wrote: > Can you also make the new System-map available, please? Sure: http://www.fi.muni.cz/~xslaby/sklad/System.map1 ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <474050EC.5080507@gmail.com>]
[parent not found: <200711181623.20029.rjwysocki@sisk.pl>]
* Re: broken suspend [Was: 2.6.24-rc2-mm1] [not found] ` <200711181623.20029.rjwysocki@sisk.pl> @ 2007-11-18 15:15 ` Jiri Slaby 0 siblings, 0 replies; 26+ messages in thread From: Jiri Slaby @ 2007-11-18 15:15 UTC (permalink / raw) To: "Rafał J. Wysocki" Cc: Andrew Morton, Kernel development list, Linux-pm mailing list On 11/18/2007 04:23 PM, Rafał J. Wysocki wrote: > On Sunday, 18 of November 2007, Jiri Slaby wrote: >> On 11/18/2007 04:03 PM, Rafael J. Wysocki wrote: >>> Can you also make the new System-map available, please? >> Sure: >> http://www.fi.muni.cz/~xslaby/sklad/System.map1 > > The last notifier called in http://www.fi.muni.cz/~xslaby/sklad/susp_hang2.png Last... Note, that it's only first 20 invokations of notifiers, there are bazillion of them when I remove the condition '< 20'. > is apparently cpu_swap_callback() which is not called in > http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png . > > Can you verify that cpu_swap_callback() gets called if the patch is not > applied? Does this still apply? ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: broken suspend [Was: 2.6.24-rc2-mm1] [not found] ` <474050EC.5080507@gmail.com> [not found] ` <200711181623.20029.rjwysocki@sisk.pl> @ 2007-11-18 15:23 ` Rafał J. Wysocki 1 sibling, 0 replies; 26+ messages in thread From: Rafał J. Wysocki @ 2007-11-18 15:23 UTC (permalink / raw) To: Jiri Slaby; +Cc: Andrew Morton, Kernel development list, Linux-pm mailing list On Sunday, 18 of November 2007, Jiri Slaby wrote: > On 11/18/2007 04:03 PM, Rafael J. Wysocki wrote: > > Can you also make the new System-map available, please? > > Sure: > http://www.fi.muni.cz/~xslaby/sklad/System.map1 The last notifier called in http://www.fi.muni.cz/~xslaby/sklad/susp_hang2.png is apparently cpu_swap_callback() which is not called in http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png . Can you verify that cpu_swap_callback() gets called if the patch is not applied? ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: broken suspend [Was: 2.6.24-rc2-mm1] [not found] ` <474043EC.4000700@gmail.com> [not found] ` <200711181603.26522.rjw@sisk.pl> @ 2007-11-18 15:03 ` Rafael J. Wysocki 1 sibling, 0 replies; 26+ messages in thread From: Rafael J. Wysocki @ 2007-11-18 15:03 UTC (permalink / raw) To: Jiri Slaby; +Cc: Andrew Morton, Kernel development list, Linux-pm mailing list On Sunday, 18 of November 2007, Jiri Slaby wrote: > On 11/18/2007 02:42 PM, Rafael J. Wysocki wrote: > > On Sunday, 18 of November 2007, Jiri Slaby wrote: > >> On 11/18/2007 01:42 PM, Jiri Slaby wrote: > >>> See shot of prints here: > >>> http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png > >> BTW output from that tree minus the patch: > > > > Hm, it looks like one of the CPU hotplug notifiers is doing something wrong. > > > > Can you try to see what happens (with the patch applied) if > > thermal_throttle_cpu_callback() is not registered? > > After commenting out > //device_initcall(thermal_throttle_init_device); > it looks like this: > http://www.fi.muni.cz/~xslaby/sklad/susp_hang2.png Can you also make the new System-map available, please? ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <200711172137.18784.rjw@sisk.pl>]
* Re: broken suspend [Was: 2.6.24-rc2-mm1] [not found] <200711172137.18784.rjw@sisk.pl> @ 2007-11-17 21:58 ` Alan Stern 0 siblings, 0 replies; 26+ messages in thread From: Alan Stern @ 2007-11-17 21:58 UTC (permalink / raw) To: Jiri Slaby, Andrew Morton; +Cc: Linux-pm mailing list, Kernel development list On Sat, 17 Nov 2007, Rafael J. Wysocki wrote: > On Saturday, 17 of November 2007, Jiri Slaby wrote: > > On 11/16/2007 05:10 PM, Alan Stern wrote: > > > On Thu, 15 Nov 2007, Greg KH wrote: > > > > > >>> The offending -mm patch is > > >>> gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch > > >>> > > >>> 2.6.24-rc2-mm1 minus it works just fine; PROVE_LOCKING shows nothing new when > > >>> the patch is applied. > > >> Thanks for tracking this down. Alan, any thoughts? > > > > > > It's a driver problem somewhere. Probably not one of the most common > > > drivers because I don't see the same problem here (but then I'm not > > > testing -mm). > > > > > > The thing to do is figure out which driver is causing the problem. > > > Jiri, try enabling CONFIG_DEBUG_DRIVER. > > > > Sadly no output. > > > > > If there's also a config > > > option to prevent the console from being suspended, set it as well. > > > > no_suspend_console kernel parameter has no effect (why?). > > I'm not sure. > > Please try to set CONFIG_PM_VERBOSE. I finally got 2.6.24-rc2-mm1 working. Andrew, how come those two recent patches from Greg and Kay (the ones changing alloc_disk_node() and system_bus_init()) aren't in your hot-fixes directory? There's still a problem. During bootup I get this: floppy0: Floppy io-port 0x03f2 in use That's not supposed to happen; the floppy disk should be working perfectly. Is this a known problem? Back to the main topic... My system hibernates and resumes with no apparent problem. Jiri, it looks like you'll have to do some debug tracing of the routines in drivers/base/power/main.c. Alan Stern ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <Pine.LNX.4.44L0.0711161058170.2738-100000@iolanthe.rowland.org>]
* Re: broken suspend [Was: 2.6.24-rc2-mm1] [not found] <Pine.LNX.4.44L0.0711161058170.2738-100000@iolanthe.rowland.org> @ 2007-11-17 15:08 ` Jiri Slaby [not found] ` <473F03DF.4020306@gmail.com> 1 sibling, 0 replies; 26+ messages in thread From: Jiri Slaby @ 2007-11-17 15:08 UTC (permalink / raw) To: Alan Stern; +Cc: Jiri Slaby, linux-kernel, Andrew Morton, Linux-pm mailing list On 11/16/2007 05:10 PM, Alan Stern wrote: > On Thu, 15 Nov 2007, Greg KH wrote: > >>> The offending -mm patch is >>> gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch >>> >>> 2.6.24-rc2-mm1 minus it works just fine; PROVE_LOCKING shows nothing new when >>> the patch is applied. >> Thanks for tracking this down. Alan, any thoughts? > > It's a driver problem somewhere. Probably not one of the most common > drivers because I don't see the same problem here (but then I'm not > testing -mm). > > The thing to do is figure out which driver is causing the problem. > Jiri, try enabling CONFIG_DEBUG_DRIVER. Sadly no output. > If there's also a config > option to prevent the console from being suspended, set it as well. no_suspend_console kernel parameter has no effect (why?). > Then you should be able to tell which driver is making trouble. I think no unusual hardware inside: 00:00.0 Host bridge: Intel Corporation 82G33/G31/P35 Express DRAM Controller (rev 02) Subsystem: Intel Corporation 82G33/G31/P35 Express DRAM Controller Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- Latency: 0 Capabilities: [e0] Vendor Specific Information 00: 86 80 c0 29 06 00 90 20 02 00 00 06 00 00 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 c0 29 30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00 00:02.0 VGA compatible controller: Intel Corporation 82G33/G31 Express Integrated Graphics Controller (rev 02) (prog-if 00 [VGA]) Subsystem: Intel Corporation 82G33/G31 Express Integrated Graphics Controller Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin A routed to IRQ 16 Region 0: Memory at ffa80000 (32-bit, non-prefetchable) [size=512K] Region 1: I/O ports at ec00 [size=8] Region 2: Memory at d0000000 (32-bit, prefetchable) [size=256M] Region 3: Memory at ff900000 (32-bit, non-prefetchable) [size=1M] Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Address: 00000000 Data: 0000 Capabilities: [d0] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00: 86 80 c2 29 07 00 90 00 02 00 00 03 00 00 00 00 10: 00 00 a8 ff 01 ec 00 00 08 00 00 d0 00 00 90 ff 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 c2 29 30: 00 00 00 00 90 00 00 00 00 00 00 00 0a 01 00 00 00:03.0 Communication controller: Intel Corporation 82G33/G31/P35 Express MEI Controller (rev 02) Subsystem: Intel Corporation 82G33/G31/P35 Express MEI Controller Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin A routed to IRQ 10 Region 0: Memory at ffa7bc00 (64-bit, non-prefetchable) [size=16] Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [8c] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 00: 86 80 c4 29 06 00 10 00 02 00 80 07 00 00 80 00 10: 04 bc a7 ff 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 c4 29 30: 00 00 00 00 50 00 00 00 00 00 00 00 0a 01 00 00 00:03.2 IDE interface: Intel Corporation 82G33/G31/P35 Express PT IDER Controller (rev 02) (prog-if 85 [Master SecO PriO]) Subsystem: Intel Corporation 82G33/G31/P35 Express PT IDER Controller Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin C routed to IRQ 12 Region 0: I/O ports at e880 [size=8] Region 1: I/O ports at e800 [size=4] Region 2: I/O ports at e480 [size=8] Region 3: I/O ports at e400 [size=4] Region 4: I/O ports at e080 [size=16] Capabilities: [c8] Power Management version 3 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 00: 86 80 c6 29 05 00 b0 00 02 85 01 01 00 00 00 00 10: 81 e8 00 00 01 e8 00 00 81 e4 00 00 01 e4 00 00 20: 81 e0 00 00 00 00 00 00 00 00 00 00 86 80 c6 29 30: 00 00 00 00 c8 00 00 00 00 00 00 00 0c 03 00 00 00:03.3 Serial controller: Intel Corporation 82G33/G31/P35 Express Serial KT Controller (rev 02) (prog-if 02 [16550]) Subsystem: Intel Corporation 82G33/G31/P35 Express Serial KT Controller Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin B routed to IRQ 17 Region 0: I/O ports at e000 [size=8] Region 1: Memory at ffa7a000 (32-bit, non-prefetchable) [size=4K] Capabilities: [c8] Power Management version 3 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 00: 86 80 c7 29 07 00 b0 00 02 02 00 07 00 00 00 00 10: 01 e0 00 00 00 a0 a7 ff 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 c7 29 30: 00 00 00 00 c8 00 00 00 00 00 00 00 05 02 00 00 00:19.0 Ethernet controller: Intel Corporation 82566DM-2 Gigabit Network Connection (rev 02) Subsystem: Intel Corporation Unknown device 0000 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin A routed to IRQ 318 Region 0: Memory at ffa40000 (32-bit, non-prefetchable) [size=128K] Region 1: Memory at ffa79000 (32-bit, non-prefetchable) [size=4K] Region 2: I/O ports at dc00 [size=32] Capabilities: [c8] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=1 PME- Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+ Address: 00000000fee0300c Data: 4191 Capabilities: [e0] Vendor Specific Information 00: 86 80 bd 10 07 04 10 00 02 00 00 02 00 00 00 00 10: 00 00 a4 ff 00 90 a7 ff 01 dc 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 00 00 30: 00 00 00 00 c8 00 00 00 00 00 00 00 0f 01 00 00 00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 02) (prog-if 00 [UHCI]) Subsystem: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin A routed to IRQ 16 Region 4: I/O ports at d880 [size=32] Capabilities: [50] Vendor Specific Information 00: 86 80 37 29 05 00 90 02 02 00 03 0c 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 81 d8 00 00 00 00 00 00 00 00 00 00 86 80 37 29 30: 00 00 00 00 50 00 00 00 00 00 00 00 0a 01 00 00 00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 02) (prog-if 00 [UHCI]) Subsystem: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin B routed to IRQ 21 Region 4: I/O ports at d800 [size=32] Capabilities: [50] Vendor Specific Information 00: 86 80 38 29 05 00 90 02 02 00 03 0c 00 00 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 d8 00 00 00 00 00 00 00 00 00 00 86 80 38 29 30: 00 00 00 00 50 00 00 00 00 00 00 00 0e 02 00 00 00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 02) (prog-if 00 [UHCI]) Subsystem: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin C routed to IRQ 18 Region 4: I/O ports at d480 [size=32] Capabilities: [50] Vendor Specific Information 00: 86 80 39 29 05 00 90 02 02 00 03 0c 00 00 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 81 d4 00 00 00 00 00 00 00 00 00 00 86 80 39 29 30: 00 00 00 00 50 00 00 00 00 00 00 00 0c 03 00 00 00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 02) (prog-if 20 [EHCI]) Subsystem: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin D routed to IRQ 19 Region 0: Memory at ffa7b400 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Debug port Capabilities: [98] Vendor Specific Information 00: 86 80 3c 29 06 00 90 02 02 20 03 0c 00 00 00 00 10: 00 b4 a7 ff 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 3c 29 30: 00 00 00 00 50 00 00 00 00 00 00 00 03 04 00 00 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 02) Subsystem: Intel Corporation 82801I (ICH9 Family) HD Audio Controller Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 22 Region 0: Memory at ffa70000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [70] Express Unknown type IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s <64ns, L1 <1us Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed unknown, Width x0, ASPM unknown, Port 0 Link: Latency L0s <64ns, L1 <1us Link: ASPM Disabled CommClk- ExtSynch- Link: Speed unknown, Width x0 Capabilities: [100] Virtual Channel Capabilities: [130] Unknown (5) 00: 86 80 3e 29 06 00 10 00 02 00 03 04 08 00 00 00 10: 04 00 a7 ff 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 3e 29 30: 00 00 00 00 50 00 00 00 00 00 00 00 07 01 00 00 00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 02) (prog-if 00 [UHCI]) Subsystem: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin A routed to IRQ 23 Region 4: I/O ports at d400 [size=32] Capabilities: [50] Vendor Specific Information 00: 86 80 34 29 05 00 90 02 02 00 03 0c 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 d4 00 00 00 00 00 00 00 00 00 00 86 80 34 29 30: 00 00 00 00 50 00 00 00 00 00 00 00 0a 01 00 00 00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 02) (prog-if 00 [UHCI]) Subsystem: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin B routed to IRQ 19 Region 4: I/O ports at d080 [size=32] Capabilities: [50] Vendor Specific Information 00: 86 80 35 29 05 00 90 02 02 00 03 0c 00 00 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 81 d0 00 00 00 00 00 00 00 00 00 00 86 80 35 29 30: 00 00 00 00 50 00 00 00 00 00 00 00 03 02 00 00 00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 02) (prog-if 00 [UHCI]) Subsystem: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin D routed to IRQ 16 Region 4: I/O ports at d000 [size=32] Capabilities: [50] Vendor Specific Information 00: 86 80 36 29 05 00 90 02 02 00 03 0c 00 00 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 d0 00 00 00 00 00 00 00 00 00 00 86 80 36 29 30: 00 00 00 00 50 00 00 00 00 00 00 00 0a 04 00 00 00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 02) (prog-if 20 [EHCI]) Subsystem: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin A routed to IRQ 23 Region 0: Memory at ffa7b000 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Debug port Capabilities: [98] Vendor Specific Information 00: 86 80 3a 29 06 00 90 02 02 20 03 0c 00 00 00 00 10: 00 b0 a7 ff 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 3a 29 30: 00 00 00 00 50 00 00 00 00 00 00 00 0a 01 00 00 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 92) (prog-if 01 [Subtractive decode]) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=32 Memory behind bridge: ff600000-ff6fffff Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR- BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B- Capabilities: [50] Subsystem: Intel Corporation 82801 PCI Bridge 00: 86 80 4e 24 06 01 10 00 92 01 04 06 00 00 01 00 10: 00 00 00 00 00 00 00 00 00 01 01 20 f0 00 80 22 20: 60 ff 60 ff f1 ff 01 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 50 00 00 00 00 00 00 00 ff 00 02 00 00:1f.0 ISA bridge: Intel Corporation Unknown device 2910 (rev 02) Subsystem: Intel Corporation Unknown device 2910 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Capabilities: [e0] Vendor Specific Information 00: 86 80 10 29 07 00 10 02 02 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 10 29 30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00 00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA AHCI Controller (rev 02) (prog-if 01 [AHCI 1.0]) Subsystem: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA AHCI Controller Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin B routed to IRQ 319 Region 0: I/O ports at cc00 [size=8] Region 1: I/O ports at c880 [size=4] Region 2: I/O ports at c800 [size=8] Region 3: I/O ports at c480 [size=4] Region 4: I/O ports at c400 [size=32] Region 5: Memory at ffa78800 (32-bit, non-prefetchable) [size=2K] Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/4 Enable+ Address: fee0300c Data: 4169 Capabilities: [70] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [a8] #12 [0010] Capabilities: [b0] Vendor Specific Information 00: 86 80 22 29 07 04 b0 02 02 01 06 01 00 00 00 00 10: 01 cc 00 00 81 c8 00 00 01 c8 00 00 81 c4 00 00 20: 01 c4 00 00 00 88 a7 ff 00 00 00 00 86 80 22 29 30: 00 00 00 00 80 00 00 00 00 00 00 00 03 02 00 00 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 02) Subsystem: Intel Corporation 82801I (ICH9 Family) SMBus Controller Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Interrupt: pin C routed to IRQ 18 Region 0: Memory at ffa7b800 (64-bit, non-prefetchable) [size=256] Region 4: I/O ports at 0400 [size=32] 00: 86 80 30 29 03 00 80 02 02 00 05 0c 00 00 00 00 10: 04 b8 a7 ff 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 04 00 00 00 00 00 00 00 00 00 00 86 80 30 29 30: 00 00 00 00 00 00 00 00 00 00 00 00 03 03 00 00 00:1f.5 IDE interface: Intel Corporation 82801I (ICH9 Family) 2 port SATA IDE Controller (rev 02) (prog-if 85 [Master SecO PriO]) Subsystem: Intel Corporation 82801I (ICH9 Family) 2 port SATA IDE Controller Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin B routed to IRQ 19 Region 0: I/O ports at c000 [size=8] Region 1: I/O ports at bc00 [size=4] Region 2: I/O ports at b880 [size=8] Region 3: I/O ports at b800 [size=4] Region 4: I/O ports at b480 [size=16] Region 5: I/O ports at b400 [size=16] Capabilities: [70] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [b0] Vendor Specific Information 00: 86 80 26 29 07 00 b0 02 02 85 01 01 00 00 00 00 10: 01 c0 00 00 01 bc 00 00 81 b8 00 00 01 b8 00 00 20: 81 b4 00 00 01 b4 00 00 00 00 00 00 86 80 26 29 30: 00 00 00 00 70 00 00 00 00 00 00 00 03 02 00 00 00:1f.6 Signal processing controller: Intel Corporation 82801I (ICH9 Family) Thermal Subsystem (rev 02) Subsystem: Intel Corporation 82801I (ICH9 Family) Thermal Subsystem Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Interrupt: pin C routed to IRQ 12 Region 0: Memory at ffa6f000 (64-bit, non-prefetchable) [size=4K] Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00: 86 80 32 29 02 00 10 00 02 00 80 11 00 00 00 00 10: 04 f0 a6 ff 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 32 29 30: 00 00 00 00 50 00 00 00 00 00 00 00 0c 03 00 00 01:00.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01) Subsystem: Wistron NeWeb Corp. CM9 Wireless a/b/g MiniPCI Adapter Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 168 (2500ns min, 7000ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 21 Region 0: Memory at ff6f0000 (32-bit, non-prefetchable) [size=64K] Capabilities: [44] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=2 PME- 00: 8c 16 13 00 16 00 90 02 01 00 00 02 08 a8 00 00 10: 00 00 6f ff 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 01 50 00 00 5f 18 12 10 30: 00 00 00 00 44 00 00 00 00 00 00 00 0e 01 0a 1c Plugged usb devices: Bus 004 Device 007: ID 045e:00f0 Microsoft Corp. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x045e Microsoft Corp. idProduct 0x00f0 bcdDevice 1.01 iManufacturer 1 Microsoft Corporation iProduct 2 Microsoft � Laser Mouse 6000 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 34 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Devices bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 2 Mouse iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.11 bCountryCode 33 US bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 59 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 10 Bus 004 Device 006: ID 0458:004c KYE Systems Corp. (Mouse Systems) Slimstar Pro Keyboard Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0458 KYE Systems Corp. (Mouse Systems) idProduct 0x004c Slimstar Pro Keyboard bcdDevice 1.01 iManufacturer 1 ABBHOME iProduct 2 USB Keyboard iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 59 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 50mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Devices bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 1 Keyboard iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.10 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 65 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 10 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Devices bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 2 Mouse iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.10 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 104 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 10 Bus 004 Device 005: ID 04b4:2050 Cypress Semiconductor Corp. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 Full speed (or root) hub bMaxPacketSize0 8 idVendor 0x04b4 Cypress Semiconductor Corp. idProduct 0x2050 bcdDevice 0.01 iManufacturer 1 Bella Corporation iProduct 2 GBella Corporation DV Keyboard iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0001 1x 1 bytes bInterval 255 Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 3 wHubCharacteristic 0x000d Per-port power switching Compound device Per-port overcurrent protection bPwrOn2PwrGood 50 * 2 milli seconds bHubContrCurrent 25 milli Ampere DeviceRemovable 0x00 PortPwrCtrlMask 0x60 Hub Port Status: Port 1: 0000.0103 power enable connect Port 2: 0000.0303 lowspeed power enable connect Port 3: 0000.0100 power regards, -- Jiri Slaby (jirislaby@gmail.com) Faculty of Informatics, Masaryk University ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <473F03DF.4020306@gmail.com>]
* Re: broken suspend [Was: 2.6.24-rc2-mm1] [not found] ` <473F03DF.4020306@gmail.com> @ 2007-11-17 15:12 ` Jiri Slaby 2007-11-17 16:13 ` Alan Stern 2007-11-17 20:37 ` Rafael J. Wysocki 2 siblings, 0 replies; 26+ messages in thread From: Jiri Slaby @ 2007-11-17 15:12 UTC (permalink / raw) To: Alan Stern; +Cc: Andrew Morton, linux-kernel, Linux-pm mailing list On 11/17/2007 04:08 PM, Jiri Slaby wrote: > On 11/16/2007 05:10 PM, Alan Stern wrote: >> If there's also a config >> option to prevent the console from being suspended, set it as well. > > no_suspend_console kernel parameter has no effect (why?). Eh, no, this (/proc/cmdline): ro root=/dev/md1 reboo1 vga=1 2 no_console_suspend regards, -- Jiri Slaby (jirislaby@gmail.com) Faculty of Informatics, Masaryk University ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: broken suspend [Was: 2.6.24-rc2-mm1] [not found] ` <473F03DF.4020306@gmail.com> 2007-11-17 15:12 ` Jiri Slaby @ 2007-11-17 16:13 ` Alan Stern 2007-11-17 20:37 ` Rafael J. Wysocki 2 siblings, 0 replies; 26+ messages in thread From: Alan Stern @ 2007-11-17 16:13 UTC (permalink / raw) To: Jiri Slaby; +Cc: Andrew Morton, linux-kernel, Linux-pm mailing list On Sat, 17 Nov 2007, Jiri Slaby wrote: > > The thing to do is figure out which driver is causing the problem. > > Jiri, try enabling CONFIG_DEBUG_DRIVER. > > Sadly no output. Guess I'll have to try running 2.6.24-rc2-mm1 on my own system. In the meantime, you can try adding some printk statements to drivers/base/power/main.c. In particular, see whether lock_all_devices() gets called from device_suspend(), whether it returns, and how far dpm_suspend() manages to get. Alan Stern ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: broken suspend [Was: 2.6.24-rc2-mm1] [not found] ` <473F03DF.4020306@gmail.com> 2007-11-17 15:12 ` Jiri Slaby 2007-11-17 16:13 ` Alan Stern @ 2007-11-17 20:37 ` Rafael J. Wysocki 2 siblings, 0 replies; 26+ messages in thread From: Rafael J. Wysocki @ 2007-11-17 20:37 UTC (permalink / raw) To: Jiri Slaby; +Cc: Andrew Morton, linux-kernel, Linux-pm mailing list On Saturday, 17 of November 2007, Jiri Slaby wrote: > On 11/16/2007 05:10 PM, Alan Stern wrote: > > On Thu, 15 Nov 2007, Greg KH wrote: > > > >>> The offending -mm patch is > >>> gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch > >>> > >>> 2.6.24-rc2-mm1 minus it works just fine; PROVE_LOCKING shows nothing new when > >>> the patch is applied. > >> Thanks for tracking this down. Alan, any thoughts? > > > > It's a driver problem somewhere. Probably not one of the most common > > drivers because I don't see the same problem here (but then I'm not > > testing -mm). > > > > The thing to do is figure out which driver is causing the problem. > > Jiri, try enabling CONFIG_DEBUG_DRIVER. > > Sadly no output. > > > If there's also a config > > option to prevent the console from being suspended, set it as well. > > no_suspend_console kernel parameter has no effect (why?). I'm not sure. Please try to set CONFIG_PM_VERBOSE. ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <20071116003836.GA24490@kroah.com>]
* Re: broken suspend [Was: 2.6.24-rc2-mm1] [not found] <20071116003836.GA24490@kroah.com> @ 2007-11-16 16:10 ` Alan Stern 0 siblings, 0 replies; 26+ messages in thread From: Alan Stern @ 2007-11-16 16:10 UTC (permalink / raw) To: Greg KH; +Cc: Andrew Morton, Linux-pm mailing list, Jiri Slaby, linux-kernel On Thu, 15 Nov 2007, Greg KH wrote: > > The offending -mm patch is > > gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch > > > > 2.6.24-rc2-mm1 minus it works just fine; PROVE_LOCKING shows nothing new when > > the patch is applied. > > Thanks for tracking this down. Alan, any thoughts? It's a driver problem somewhere. Probably not one of the most common drivers because I don't see the same problem here (but then I'm not testing -mm). The thing to do is figure out which driver is causing the problem. Jiri, try enabling CONFIG_DEBUG_DRIVER. If there's also a config option to prevent the console from being suspended, set it as well. Then you should be able to tell which driver is making trouble. Alan Stern ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <20071113175906.497a1a6a.akpm@linux-foundation.org>]
[parent not found: <473B5987.60904@gmail.com>]
[parent not found: <200711142248.59547.rjw@sisk.pl>]
* Re: broken suspend [Was: 2.6.24-rc2-mm1] [not found] ` <200711142248.59547.rjw@sisk.pl> @ 2007-11-15 23:59 ` Jiri Slaby [not found] ` <473CDD6D.8080008@gmail.com> 1 sibling, 0 replies; 26+ messages in thread From: Jiri Slaby @ 2007-11-15 23:59 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Andrew Morton, linux-kernel, Linux-pm mailing list On 11/14/2007 10:48 PM, Rafael J. Wysocki wrote: > On Wednesday, 14 of November 2007, Jiri Slaby wrote: >> On 11/14/2007 02:59 AM, Andrew Morton wrote: >>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc2/2.6.24-rc2-mm1/ >> Doesn't suspend for me (neither broken-out-2007-11-13-04-14 did) on x86_64. >> echo mem >/sys/power/state >> causes shut down of disk(s) and blinking cursor on 1,1 position. >> The last working was 2.6.23-rc8-mm2. I haven't tested >> 2.6.23-mm1, since it didn't work for me. > > Does the current mainline work? Yes. The offending -mm patch is gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch 2.6.24-rc2-mm1 minus it works just fine; PROVE_LOCKING shows nothing new when the patch is applied. regards, -- Jiri Slaby (jirislaby@gmail.com) Faculty of Informatics, Masaryk University ^ permalink raw reply [flat|nested] 26+ messages in thread
[parent not found: <473CDD6D.8080008@gmail.com>]
* Re: broken suspend [Was: 2.6.24-rc2-mm1] [not found] ` <473CDD6D.8080008@gmail.com> @ 2007-11-16 0:38 ` Greg KH 0 siblings, 0 replies; 26+ messages in thread From: Greg KH @ 2007-11-16 0:38 UTC (permalink / raw) To: Jiri Slaby; +Cc: Andrew Morton, linux-kernel, Linux-pm mailing list On Fri, Nov 16, 2007 at 12:59:41AM +0100, Jiri Slaby wrote: > On 11/14/2007 10:48 PM, Rafael J. Wysocki wrote: > > On Wednesday, 14 of November 2007, Jiri Slaby wrote: > >> On 11/14/2007 02:59 AM, Andrew Morton wrote: > >>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc2/2.6.24-rc2-mm1/ > >> Doesn't suspend for me (neither broken-out-2007-11-13-04-14 did) on x86_64. > >> echo mem >/sys/power/state > >> causes shut down of disk(s) and blinking cursor on 1,1 position. > >> The last working was 2.6.23-rc8-mm2. I haven't tested > >> 2.6.23-mm1, since it didn't work for me. > > > > Does the current mainline work? > > Yes. > > The offending -mm patch is > gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch > > 2.6.24-rc2-mm1 minus it works just fine; PROVE_LOCKING shows nothing new when > the patch is applied. Thanks for tracking this down. Alan, any thoughts? thanks, greg k-h ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2007-11-19 21:53 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <Pine.LNX.4.44L0.0711181203220.5712-100000@netrider.rowland.org>
2007-11-18 19:09 ` broken suspend [Was: 2.6.24-rc2-mm1] Jiri Slaby
[not found] ` <200711182328.00570.rjw@sisk.pl>
2007-11-18 22:12 ` Jiri Slaby
[not found] ` <4740B8E9.4030903@gmail.com>
2007-11-18 22:42 ` Rafael J. Wysocki
2007-11-18 22:27 ` Jiri Slaby
2007-11-19 3:04 ` Alan Stern
2007-11-18 22:27 ` Rafael J. Wysocki
[not found] <Pine.LNX.4.44L0.0711182156330.22727-100000@netrider.rowland.org>
2007-11-19 20:01 ` Rudolf Marek
[not found] ` <4741EB91.9080000@assembler.cz>
2007-11-19 20:27 ` Alan Stern
2007-11-19 21:53 ` Rafael J. Wysocki
[not found] <4740570A.5030101@gmail.com>
2007-11-18 17:07 ` Alan Stern
[not found] <Pine.LNX.4.44L0.0711171649100.7748-100000@netrider.rowland.org>
2007-11-18 12:42 ` Jiri Slaby
[not found] ` <4740332A.80002@gmail.com>
2007-11-18 13:06 ` Jiri Slaby
[not found] ` <474038C9.3040002@gmail.com>
2007-11-18 13:42 ` Rafael J. Wysocki
[not found] ` <200711181442.09917.rjw@sisk.pl>
2007-11-18 13:53 ` Jiri Slaby
[not found] ` <474043EC.4000700@gmail.com>
[not found] ` <200711181603.26522.rjw@sisk.pl>
2007-11-18 14:49 ` Jiri Slaby
[not found] ` <474050EC.5080507@gmail.com>
[not found] ` <200711181623.20029.rjwysocki@sisk.pl>
2007-11-18 15:15 ` Jiri Slaby
2007-11-18 15:23 ` Rafał J. Wysocki
2007-11-18 15:03 ` Rafael J. Wysocki
[not found] <200711172137.18784.rjw@sisk.pl>
2007-11-17 21:58 ` Alan Stern
[not found] <Pine.LNX.4.44L0.0711161058170.2738-100000@iolanthe.rowland.org>
2007-11-17 15:08 ` Jiri Slaby
[not found] ` <473F03DF.4020306@gmail.com>
2007-11-17 15:12 ` Jiri Slaby
2007-11-17 16:13 ` Alan Stern
2007-11-17 20:37 ` Rafael J. Wysocki
[not found] <20071116003836.GA24490@kroah.com>
2007-11-16 16:10 ` Alan Stern
[not found] <20071113175906.497a1a6a.akpm@linux-foundation.org>
[not found] ` <473B5987.60904@gmail.com>
[not found] ` <200711142248.59547.rjw@sisk.pl>
2007-11-15 23:59 ` Jiri Slaby
[not found] ` <473CDD6D.8080008@gmail.com>
2007-11-16 0:38 ` Greg KH
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox