On 11/21/2007 01:00 AM, Rafael J. Wysocki wrote:
> On Tuesday, 20 of November 2007, Mark M. Hoffman wrote:
>> commit ce9c7b78c839a6304696d90083eac08baad524ce
>> Author: Mark M. Hoffman <[EMAIL PROTECTED]>
>> Date: Tue Nov 20 07:51:50 2007 -0500
>>
>> hwmon: (coretemp) fix suspend/resume hang
On Wednesday, 21 of November 2007, Alan Stern wrote:
> On Wed, 21 Nov 2007, Rafael J. Wysocki wrote:
>
> > > Is it possible to unregister a driver on CPU_DOWN_PREPARE_FROZEN?
> >
> > No. In that case the suspend core is holding the device's mutex and your
> > attempt to unregister it will deadlo
On Wed, 21 Nov 2007, Rafael J. Wysocki wrote:
> > Is it possible to unregister a driver on CPU_DOWN_PREPARE_FROZEN?
>
> No. In that case the suspend core is holding the device's mutex and your
> attempt to unregister it will deadlock with it.
>
> Do you _have_ _to_ unregister the device at all?
On Tuesday, 20 of November 2007, Mark M. Hoffman wrote:
> Hi all:
>
> * Alan Stern <[EMAIL PROTECTED]> [2007-11-19 15:27:14 -0500]:
> > On Mon, 19 Nov 2007, Rudolf Marek wrote:
> >
> > > Hello all,
> > > >>> gives coretemp_cpu_callback -> coretemp_device_remove ->
> > > >>> platform_device_unregi
Hi all:
* Alan Stern <[EMAIL PROTECTED]> [2007-11-19 15:27:14 -0500]:
> 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.
> > >
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() nee
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 m
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,
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. Dur
Aah, we probably should let coretemp people known.
Whole thread:
http://marc.info/?t=11950720581&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 prin
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 y
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
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 y
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 hangi
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/
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 call
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.p
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo in
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
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
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 wr
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 802
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
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.pa
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; PR
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 state
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
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.
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, an
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.
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-
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/st
On Wed, 14 Nov 2007 21:24:39 +0100 Jiri Slaby <[EMAIL PROTECTED]> 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.
> ec
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 posi
34 matches
Mail list logo
