Rafael J. Wysocki wrote:
> Hi,
>> On Fri, 2005-04-01 at 08:18, Pavel Machek wrote:
>> > I believe we should freeze hotplug before processes.
>
> I agree. IMO user space should not be considered as available once we have
> started freezing processes, so hotplug should be disabled before. By the
Hi,
On Friday, 1 of April 2005 00:28, Nigel Cunningham wrote:
> Hi.
>
> On Fri, 2005-04-01 at 08:18, Pavel Machek wrote:
> > Hi!
> >
> > > > > Ok, what do you think about this one?
> > > > >
> > > > > ===
> > > > >
> > > > >
Hi,
On Friday, 1 of April 2005 00:28, Nigel Cunningham wrote:
Hi.
On Fri, 2005-04-01 at 08:18, Pavel Machek wrote:
Hi!
Ok, what do you think about this one?
===
swsusp: disable usermodehelper after
Rafael J. Wysocki wrote:
Hi,
On Fri, 2005-04-01 at 08:18, Pavel Machek wrote:
I believe we should freeze hotplug before processes.
I agree. IMO user space should not be considered as available once we have
started freezing processes, so hotplug should be disabled before. By the same
Hi.
On Fri, 2005-04-01 at 08:18, Pavel Machek wrote:
> Hi!
>
> > > > Ok, what do you think about this one?
> > > >
> > > > ===
> > > >
> > > > swsusp: disable usermodehelper after generating memory snapshot and
> > > >
Hi!
> > > Ok, what do you think about this one?
> > >
> > > ===
> > >
> > > swsusp: disable usermodehelper after generating memory snapshot and
> > > before resuming devices, so when device fails to resume we
> > >
Hi.
On Fri, 2005-04-01 at 02:32, Dmitry Torokhov wrote:
> On Thu, 31 Mar 2005 08:02:44 -0800 (PST), Patrick Mochel
> <[EMAIL PROTECTED]> wrote:
> >
> > On Thu, 31 Mar 2005, Dmitry Torokhov wrote:
> >
> > > Ok, what do you think about this one?
> > >
> > >
On Thu, 31 Mar 2005 08:02:44 -0800 (PST), Patrick Mochel
<[EMAIL PROTECTED]> wrote:
>
> On Thu, 31 Mar 2005, Dmitry Torokhov wrote:
>
> > Ok, what do you think about this one?
> >
> > ===
> >
> > swsusp: disable usermodehelper after
On Thu, 31 Mar 2005, Dmitry Torokhov wrote:
> Ok, what do you think about this one?
>
> ===
>
> swsusp: disable usermodehelper after generating memory snapshot and
> before resuming devices, so when device fails to resume we
On Thu, 31 Mar 2005 10:39:10 +0200, Pavel Machek <[EMAIL PROTECTED]> wrote:
> > int swsusp_write(void)
> > {
> > int error;
> > - device_resume();
> > lock_swapdevices();
> > error = write_suspend_image();
> > /* This will unlock ignored swap devices since writing is
Hi!
> > > > We currently freeze processes for suspend-to-ram, too. I guess that
> > > > disable_usermodehelper is probably better and that in_suspend() should
> > > > only be used for sanity checks... go with disable_usermodehelper and
> > > > sorry for the noise.
> > >
> > > Here's another
Hi!
We currently freeze processes for suspend-to-ram, too. I guess that
disable_usermodehelper is probably better and that in_suspend() should
only be used for sanity checks... go with disable_usermodehelper and
sorry for the noise.
Here's another possibility: Freeze the
On Thu, 31 Mar 2005 10:39:10 +0200, Pavel Machek [EMAIL PROTECTED] wrote:
int swsusp_write(void)
{
int error;
- device_resume();
lock_swapdevices();
error = write_suspend_image();
/* This will unlock ignored swap devices since writing is
Looks good,
On Thu, 31 Mar 2005, Dmitry Torokhov wrote:
Ok, what do you think about this one?
===
swsusp: disable usermodehelper after generating memory snapshot and
before resuming devices, so when device fails to resume we
On Thu, 31 Mar 2005 08:02:44 -0800 (PST), Patrick Mochel
[EMAIL PROTECTED] wrote:
On Thu, 31 Mar 2005, Dmitry Torokhov wrote:
Ok, what do you think about this one?
===
swsusp: disable usermodehelper after generating
Hi.
On Fri, 2005-04-01 at 02:32, Dmitry Torokhov wrote:
On Thu, 31 Mar 2005 08:02:44 -0800 (PST), Patrick Mochel
[EMAIL PROTECTED] wrote:
On Thu, 31 Mar 2005, Dmitry Torokhov wrote:
Ok, what do you think about this one?
Hi!
Ok, what do you think about this one?
===
swsusp: disable usermodehelper after generating memory snapshot and
before resuming devices, so when device fails to resume we
won't try to call
Hi.
On Fri, 2005-04-01 at 08:18, Pavel Machek wrote:
Hi!
Ok, what do you think about this one?
===
swsusp: disable usermodehelper after generating memory snapshot and
before resuming devices, so
On Tuesday 29 March 2005 17:35, Pavel Machek wrote:
> Hi!
>
> > > We currently freeze processes for suspend-to-ram, too. I guess that
> > > disable_usermodehelper is probably better and that in_suspend() should
> > > only be used for sanity checks... go with disable_usermodehelper and
> > > sorry
On Tue, Mar 29, 2005 at 01:23:35PM -0800, Patrick Mochel wrote:
>
> On Tue, 29 Mar 2005, Pavel Machek wrote:
>
> > I don't really want us to try execve during resume... Could we simply
> > artifically fail that execve with something if (in_suspend()) return
> > -EINVAL; [except that in_suspend()
On Tue, Mar 29, 2005 at 01:23:35PM -0800, Patrick Mochel wrote:
On Tue, 29 Mar 2005, Pavel Machek wrote:
I don't really want us to try execve during resume... Could we simply
artifically fail that execve with something if (in_suspend()) return
-EINVAL; [except that in_suspend() just is
On Tuesday 29 March 2005 17:35, Pavel Machek wrote:
Hi!
We currently freeze processes for suspend-to-ram, too. I guess that
disable_usermodehelper is probably better and that in_suspend() should
only be used for sanity checks... go with disable_usermodehelper and
sorry for the
On Fri, Mar 25, 2005 at 09:58:40AM -0500, Dmitry Torokhov wrote:
> I wonder why ALPS reconnect failed. You don't have a serial console
> set up, do you? If not then maybe you could make a huge framebuffer to
> capture as much info as you can... I hope you have a digital camera ;)
No serial ports
On Tue, Mar 29, 2005 at 01:42:26PM -0500, Dmitry Torokhov wrote:
> Could you please try the patch below - it should fix the issues you are
[snip]
> --- dtor.orig/drivers/input/serio/serio.c
> +++ dtor/drivers/input/serio/serio.c
> if (!serio->drv || !serio->drv->reconnect ||
>
Hi.
On Wed, 2005-03-30 at 08:35, Pavel Machek wrote:
> Hi!
>
> > > We currently freeze processes for suspend-to-ram, too. I guess that
> > > disable_usermodehelper is probably better and that in_suspend() should
> > > only be used for sanity checks... go with disable_usermodehelper and
> > >
Hi,
On Friday, 25 of March 2005 17:04, Dmitry Torokhov wrote:
> On Fri, 25 Mar 2005 16:42:37 +0100, Pavel Machek <[EMAIL PROTECTED]> wrote:
> > Hi!
> >
> > > > > This is more of a general swsusp problem I believe - the second phase
> > > > > when it blindly resumes entire system. Resume of a
Hi,
On Friday, 25 of March 2005 15:52, Dmitry Torokhov wrote:
> On Fri, 25 Mar 2005 15:24:15 +0100, Pavel Machek <[EMAIL PROTECTED]> wrote:
> > Hi!
> >
> > > > > > OK, anything else I should try?
> > > > >
> > > > > not really, i just wait for Vojtech and Pavel :-)
> > > >
> > > > Try commenting
Hi,
On Tuesday, 29 of March 2005 23:12, Pavel Machek wrote:
> Hi!
>
> > > I don't really want us to try execve during resume... Could we simply
> > > artifically fail that execve with something if (in_suspend()) return
> > > -EINVAL; [except that in_suspend() just is not there, but there were
>
Hi!
> > We currently freeze processes for suspend-to-ram, too. I guess that
> > disable_usermodehelper is probably better and that in_suspend() should
> > only be used for sanity checks... go with disable_usermodehelper and
> > sorry for the noise.
>
> Here's another possibility: Freeze the
Hi.
On Wed, 2005-03-30 at 07:44, Pavel Machek wrote:
> We currently freeze processes for suspend-to-ram, too. I guess that
> disable_usermodehelper is probably better and that in_suspend() should
> only be used for sanity checks... go with disable_usermodehelper and
> sorry for the noise.
Here's
On Út 29-03-05 16:33:04, Dmitry Torokhov wrote:
> On Tue, 29 Mar 2005 23:12:39 +0200, Pavel Machek <[EMAIL PROTECTED]> wrote:
> > >
> > > I am leaning towards calling disable_usermodehelper (not writtent yet)
> > > after swsusp completes snapshotting memory. We really don't care about
> > >
On Tue, 29 Mar 2005 13:23:35 -0800 (PST), Patrick Mochel
<[EMAIL PROTECTED]> wrote:
>
> On Tue, 29 Mar 2005, Pavel Machek wrote:
>
> > I don't really want us to try execve during resume... Could we simply
> > artifically fail that execve with something if (in_suspend()) return
> > -EINVAL;
On Tue, 29 Mar 2005 23:12:39 +0200, Pavel Machek <[EMAIL PROTECTED]> wrote:
> >
> > I am leaning towards calling disable_usermodehelper (not writtent yet)
> > after swsusp completes snapshotting memory. We really don't care about
> > hotplug events in this case and this will allow keeping "normal"
On Tue, 29 Mar 2005, Pavel Machek wrote:
> I don't really want us to try execve during resume... Could we simply
> artifically fail that execve with something if (in_suspend()) return
> -EINVAL; [except that in_suspend() just is not there, but there were
> some proposals to add it].
>
> Or just
Hi!
> > I don't really want us to try execve during resume... Could we simply
> > artifically fail that execve with something if (in_suspend()) return
> > -EINVAL; [except that in_suspend() just is not there, but there were
> > some proposals to add it].
> >
> > Or just avoid calling hotplug at
On Tue, 29 Mar 2005 22:52:25 +0200, Pavel Machek <[EMAIL PROTECTED]> wrote:
> I don't really want us to try execve during resume... Could we simply
> artifically fail that execve with something if (in_suspend()) return
> -EINVAL; [except that in_suspend() just is not there, but there were
> some
Hi!
> > > Well, there lies a problem - some devices have to do execve because
> > > they need firmware to operate. Also, again, some buses with
> > > hot-pluggable devices will attempt to clean up unsuccessful resume and
> > > this will cause hotplug events. The point is you either resume system
On Tue, 29 Mar 2005 21:23:39 +0200, Pavel Machek <[EMAIL PROTECTED]> wrote:
> Hi!
>
> > > > If you look at Andy's second trace you will see that we are waiting
> > > > for the disk I/O to get /sbin/hotplug from the disk. Pavel, do you
> > > > know why IO does not complete? khelper is a kernel
On Thursday 24 March 2005 15:38, Stefan Seyfried wrote:
> Andy Isaacson wrote:
> > So I added i8042.noaux to my kernel command line, rebooted, insmodded
> > intel_agp, started X, and verified no touchpad action. Then I
> > suspended, and it worked fine. After restart, I suspended again - also
>
Hi!
> > > If you look at Andy's second trace you will see that we are waiting
> > > for the disk I/O to get /sbin/hotplug from the disk. Pavel, do you
> > > know why IO does not complete? khelper is a kernel thread so it is
> > > marked with
> > > PF_NOFREEZE. Could it be that we managed to
On Tue, 29 Mar 2005 20:18:31 +0200, Pavel Machek <[EMAIL PROTECTED]> wrote:
> Hi!
>
> > If you look at Andy's second trace you will see that we are waiting
> > for the disk I/O to get /sbin/hotplug from the disk. Pavel, do you
> > know why IO does not complete? khelper is a kernel thread so it is
Hi!
> > > In the SysRq-T trace I see one interesting process: most things are
> > > in D state in refrigerator(), but sh shows the following traceback:
> > >
> > > wait_for_completion
> > > call_usermodehelper
> > > kobject_hotplug
> > > kobject_del
> > > class_device_del
> > >
On Fri, 25 Mar 2005 10:22:28 +0100, Stefan Seyfried <[EMAIL PROTECTED]> wrote:
> Andy Isaacson wrote:
>
> > In the SysRq-T trace I see one interesting process: most things are
> > in D state in refrigerator(), but sh shows the following traceback:
> >
> > wait_for_completion
> >
On Fri, 25 Mar 2005 10:22:28 +0100, Stefan Seyfried [EMAIL PROTECTED] wrote:
Andy Isaacson wrote:
In the SysRq-T trace I see one interesting process: most things are
in D state in refrigerator(), but sh shows the following traceback:
wait_for_completion
call_usermodehelper
Hi!
In the SysRq-T trace I see one interesting process: most things are
in D state in refrigerator(), but sh shows the following traceback:
wait_for_completion
call_usermodehelper
kobject_hotplug
kobject_del
class_device_del
class_device_unregister
On Tue, 29 Mar 2005 20:18:31 +0200, Pavel Machek [EMAIL PROTECTED] wrote:
Hi!
If you look at Andy's second trace you will see that we are waiting
for the disk I/O to get /sbin/hotplug from the disk. Pavel, do you
know why IO does not complete? khelper is a kernel thread so it is
marked
Hi!
If you look at Andy's second trace you will see that we are waiting
for the disk I/O to get /sbin/hotplug from the disk. Pavel, do you
know why IO does not complete? khelper is a kernel thread so it is
marked with
PF_NOFREEZE. Could it be that we managed to freeze kblockd?
On Thursday 24 March 2005 15:38, Stefan Seyfried wrote:
Andy Isaacson wrote:
So I added i8042.noaux to my kernel command line, rebooted, insmodded
intel_agp, started X, and verified no touchpad action. Then I
suspended, and it worked fine. After restart, I suspended again - also
fine.
On Tue, 29 Mar 2005 21:23:39 +0200, Pavel Machek [EMAIL PROTECTED] wrote:
Hi!
If you look at Andy's second trace you will see that we are waiting
for the disk I/O to get /sbin/hotplug from the disk. Pavel, do you
know why IO does not complete? khelper is a kernel thread so it is
Hi!
Well, there lies a problem - some devices have to do execve because
they need firmware to operate. Also, again, some buses with
hot-pluggable devices will attempt to clean up unsuccessful resume and
this will cause hotplug events. The point is you either resume system
or you
On Tue, 29 Mar 2005 22:52:25 +0200, Pavel Machek [EMAIL PROTECTED] wrote:
I don't really want us to try execve during resume... Could we simply
artifically fail that execve with something if (in_suspend()) return
-EINVAL; [except that in_suspend() just is not there, but there were
some
Hi!
I don't really want us to try execve during resume... Could we simply
artifically fail that execve with something if (in_suspend()) return
-EINVAL; [except that in_suspend() just is not there, but there were
some proposals to add it].
Or just avoid calling hotplug at all in
On Tue, 29 Mar 2005, Pavel Machek wrote:
I don't really want us to try execve during resume... Could we simply
artifically fail that execve with something if (in_suspend()) return
-EINVAL; [except that in_suspend() just is not there, but there were
some proposals to add it].
Or just avoid
On Tue, 29 Mar 2005 23:12:39 +0200, Pavel Machek [EMAIL PROTECTED] wrote:
I am leaning towards calling disable_usermodehelper (not writtent yet)
after swsusp completes snapshotting memory. We really don't care about
hotplug events in this case and this will allow keeping normal
resume in
On Tue, 29 Mar 2005 13:23:35 -0800 (PST), Patrick Mochel
[EMAIL PROTECTED] wrote:
On Tue, 29 Mar 2005, Pavel Machek wrote:
I don't really want us to try execve during resume... Could we simply
artifically fail that execve with something if (in_suspend()) return
-EINVAL; [except that
On Út 29-03-05 16:33:04, Dmitry Torokhov wrote:
On Tue, 29 Mar 2005 23:12:39 +0200, Pavel Machek [EMAIL PROTECTED] wrote:
I am leaning towards calling disable_usermodehelper (not writtent yet)
after swsusp completes snapshotting memory. We really don't care about
hotplug events in
Hi.
On Wed, 2005-03-30 at 07:44, Pavel Machek wrote:
We currently freeze processes for suspend-to-ram, too. I guess that
disable_usermodehelper is probably better and that in_suspend() should
only be used for sanity checks... go with disable_usermodehelper and
sorry for the noise.
Here's
Hi!
We currently freeze processes for suspend-to-ram, too. I guess that
disable_usermodehelper is probably better and that in_suspend() should
only be used for sanity checks... go with disable_usermodehelper and
sorry for the noise.
Here's another possibility: Freeze the workqueue that
Hi,
On Tuesday, 29 of March 2005 23:12, Pavel Machek wrote:
Hi!
I don't really want us to try execve during resume... Could we simply
artifically fail that execve with something if (in_suspend()) return
-EINVAL; [except that in_suspend() just is not there, but there were
some
Hi,
On Friday, 25 of March 2005 15:52, Dmitry Torokhov wrote:
On Fri, 25 Mar 2005 15:24:15 +0100, Pavel Machek [EMAIL PROTECTED] wrote:
Hi!
OK, anything else I should try?
not really, i just wait for Vojtech and Pavel :-)
Try commenting out call_usermodehelper. If
Hi,
On Friday, 25 of March 2005 17:04, Dmitry Torokhov wrote:
On Fri, 25 Mar 2005 16:42:37 +0100, Pavel Machek [EMAIL PROTECTED] wrote:
Hi!
This is more of a general swsusp problem I believe - the second phase
when it blindly resumes entire system. Resume of a device can fail
Hi.
On Wed, 2005-03-30 at 08:35, Pavel Machek wrote:
Hi!
We currently freeze processes for suspend-to-ram, too. I guess that
disable_usermodehelper is probably better and that in_suspend() should
only be used for sanity checks... go with disable_usermodehelper and
sorry for the
On Tue, Mar 29, 2005 at 01:42:26PM -0500, Dmitry Torokhov wrote:
Could you please try the patch below - it should fix the issues you are
[snip]
--- dtor.orig/drivers/input/serio/serio.c
+++ dtor/drivers/input/serio/serio.c
if (!serio-drv || !serio-drv-reconnect ||
On Fri, Mar 25, 2005 at 09:58:40AM -0500, Dmitry Torokhov wrote:
I wonder why ALPS reconnect failed. You don't have a serial console
set up, do you? If not then maybe you could make a huge framebuffer to
capture as much info as you can... I hope you have a digital camera ;)
No serial ports
Hi!
> > > Btw, I dont think that doing selective resume (as opposed to selective
> > > suspend and Nigel's partial device trees) would be so much
> > > complicated. You'd always resume sysdevs and then, when iterating over
> > > "normal" devices, just skip ones not in resume path. It can all be
>
Hi!
Btw, I dont think that doing selective resume (as opposed to selective
suspend and Nigel's partial device trees) would be so much
complicated. You'd always resume sysdevs and then, when iterating over
normal devices, just skip ones not in resume path. It can all be
contained in
On Fri, Mar 25, 2005 at 11:13:44AM +0100, Pavel Machek wrote:
> Hi!
>
> > > OK, anything else I should try?
> >
> > not really, i just wait for Vojtech and Pavel :-)
>
> Try commenting out "call_usermodehelper". If that helps, Stefan's
> theory is confirmed, and this waits for Vojtech to fix
On Fri, 25 Mar 2005 16:42:37 +0100, Pavel Machek <[EMAIL PROTECTED]> wrote:
> Hi!
>
> > > > This is more of a general swsusp problem I believe - the second phase
> > > > when it blindly resumes entire system. Resume of a device can fail
> > > > (any reason whatsoever) and it will attempt to clean
Hi!
> > > This is more of a general swsusp problem I believe - the second phase
> > > when it blindly resumes entire system. Resume of a device can fail
> > > (any reason whatsoever) and it will attempt to clean up after itself,
> > > but userspace is dead and hotplug never completes. While I am
On Thu, 24 Mar 2005 15:54:39 -0800, Andy Isaacson <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 24, 2005 at 04:10:39PM -0500, Dmitry Torokhov wrote:
> > If you do "ls /sys/bus/serio/devices" and see more than 3 ports you
> > have MUX mode active.
>
> Just serio0 and serio1.
>
> On Thu, Mar 24, 2005
On Fri, 25 Mar 2005 15:24:15 +0100, Pavel Machek <[EMAIL PROTECTED]> wrote:
> Hi!
>
> > > > > OK, anything else I should try?
> > > >
> > > > not really, i just wait for Vojtech and Pavel :-)
> > >
> > > Try commenting out "call_usermodehelper". If that helps, Stefan's
> > > theory is confirmed,
Hi!
> > > > OK, anything else I should try?
> > >
> > > not really, i just wait for Vojtech and Pavel :-)
> >
> > Try commenting out "call_usermodehelper". If that helps, Stefan's
> > theory is confirmed, and this waits for Vojtech to fix it.
> >
>
> This is more of a general swsusp problem I
Hi,
On Fri, 25 Mar 2005 11:13:44 +0100, Pavel Machek <[EMAIL PROTECTED]> wrote:
> Hi!
>
> > > OK, anything else I should try?
> >
> > not really, i just wait for Vojtech and Pavel :-)
>
> Try commenting out "call_usermodehelper". If that helps, Stefan's
> theory is confirmed, and this waits for
Hi!
> > OK, anything else I should try?
>
> not really, i just wait for Vojtech and Pavel :-)
Try commenting out "call_usermodehelper". If that helps, Stefan's
theory is confirmed, and this waits for Vojtech to fix it.
> > In the SysRq-T trace I see one interesting process: most things are
>
Andy Isaacson wrote:
> OK, anything else I should try?
not really, i just wait for Vojtech and Pavel :-)
> Why does it only fail when I have *both* intel_agp and i8042 aux?
later...
> In the SysRq-T trace I see one interesting process: most things are
> in D state in refrigerator(), but sh
Andy Isaacson wrote:
OK, anything else I should try?
not really, i just wait for Vojtech and Pavel :-)
Why does it only fail when I have *both* intel_agp and i8042 aux?
later...
In the SysRq-T trace I see one interesting process: most things are
in D state in refrigerator(), but sh shows
Hi!
OK, anything else I should try?
not really, i just wait for Vojtech and Pavel :-)
Try commenting out call_usermodehelper. If that helps, Stefan's
theory is confirmed, and this waits for Vojtech to fix it.
In the SysRq-T trace I see one interesting process: most things are
in D
Hi,
On Fri, 25 Mar 2005 11:13:44 +0100, Pavel Machek [EMAIL PROTECTED] wrote:
Hi!
OK, anything else I should try?
not really, i just wait for Vojtech and Pavel :-)
Try commenting out call_usermodehelper. If that helps, Stefan's
theory is confirmed, and this waits for Vojtech to fix
Hi!
OK, anything else I should try?
not really, i just wait for Vojtech and Pavel :-)
Try commenting out call_usermodehelper. If that helps, Stefan's
theory is confirmed, and this waits for Vojtech to fix it.
This is more of a general swsusp problem I believe - the second
On Fri, 25 Mar 2005 15:24:15 +0100, Pavel Machek [EMAIL PROTECTED] wrote:
Hi!
OK, anything else I should try?
not really, i just wait for Vojtech and Pavel :-)
Try commenting out call_usermodehelper. If that helps, Stefan's
theory is confirmed, and this waits for Vojtech
On Thu, 24 Mar 2005 15:54:39 -0800, Andy Isaacson [EMAIL PROTECTED] wrote:
On Thu, Mar 24, 2005 at 04:10:39PM -0500, Dmitry Torokhov wrote:
If you do ls /sys/bus/serio/devices and see more than 3 ports you
have MUX mode active.
Just serio0 and serio1.
On Thu, Mar 24, 2005 at 04:14:52PM
Hi!
This is more of a general swsusp problem I believe - the second phase
when it blindly resumes entire system. Resume of a device can fail
(any reason whatsoever) and it will attempt to clean up after itself,
but userspace is dead and hotplug never completes. While I am
On Fri, 25 Mar 2005 16:42:37 +0100, Pavel Machek [EMAIL PROTECTED] wrote:
Hi!
This is more of a general swsusp problem I believe - the second phase
when it blindly resumes entire system. Resume of a device can fail
(any reason whatsoever) and it will attempt to clean up after
On Fri, Mar 25, 2005 at 11:13:44AM +0100, Pavel Machek wrote:
Hi!
OK, anything else I should try?
not really, i just wait for Vojtech and Pavel :-)
Try commenting out call_usermodehelper. If that helps, Stefan's
theory is confirmed, and this waits for Vojtech to fix it.
On Thu, Mar 24, 2005 at 04:10:39PM -0500, Dmitry Torokhov wrote:
> If you do "ls /sys/bus/serio/devices" and see more than 3 ports you
> have MUX mode active.
Just serio0 and serio1.
On Thu, Mar 24, 2005 at 04:14:52PM -0500, Dmitry Torokhov wrote:
> On Thu, 24 Mar 2005 12:20:40 -0800, Andy
On Thu, 24 Mar 2005 12:20:40 -0800, Andy Isaacson <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 24, 2005 at 02:18:40PM -0500, Dmitry Torokhov wrote:
> > On Thu, 24 Mar 2005 10:10:59 -0800, Andy Isaacson <[EMAIL PROTECTED]> wrote:
> > > So I added i8042.noaux to my kernel command line, rebooted,
On Thu, 24 Mar 2005 12:20:40 -0800, Andy Isaacson <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 24, 2005 at 02:18:40PM -0500, Dmitry Torokhov wrote:
> > On Thu, 24 Mar 2005 10:10:59 -0800, Andy Isaacson <[EMAIL PROTECTED]> wrote:
> > > So I added i8042.noaux to my kernel command line, rebooted,
Andy Isaacson wrote:
> On Thu, Mar 24, 2005 at 03:27:15PM +0100, Stefan Seyfried wrote:
> Sysrq still prints stuff, so IRQs aren't locked. But most of the sysrq
> commands don't work... S and U don't seem to do anything (not too
> suprising I suppose) but B does reboot.
sysrq-t will probably
On Thu, Mar 24, 2005 at 02:18:40PM -0500, Dmitry Torokhov wrote:
> On Thu, 24 Mar 2005 10:10:59 -0800, Andy Isaacson <[EMAIL PROTECTED]> wrote:
> > So I added i8042.noaux to my kernel command line, rebooted, insmodded
> > intel_agp, started X, and verified no touchpad action. Then I
> >
On Thu, 24 Mar 2005 10:10:59 -0800, Andy Isaacson <[EMAIL PROTECTED]> wrote:
>
> So I added i8042.noaux to my kernel command line, rebooted, insmodded
> intel_agp, started X, and verified no touchpad action. Then I
> suspended, and it worked fine. After restart, I suspended again - also
> fine.
On Thu, Mar 24, 2005 at 03:27:15PM +0100, Stefan Seyfried wrote:
> Andy Isaacson wrote:
> > Dmesg is attached; hardware is a Vaio r505te.
> >
> > Unfortunately, the deadlock (?) is nondeterministic; it *sometimes*
> > suspends successfully, maybe one time out of 10. And thinking back, I
> >
Andy Isaacson wrote:
> Dmesg is attached; hardware is a Vaio r505te.
>
> Unfortunately, the deadlock (?) is nondeterministic; it *sometimes*
> suspends successfully, maybe one time out of 10. And thinking back, I
> *sometimes* saw failures to suspend with 2.6.11-rc3, maybe one failure
> out of
Andy Isaacson wrote:
Dmesg is attached; hardware is a Vaio r505te.
Unfortunately, the deadlock (?) is nondeterministic; it *sometimes*
suspends successfully, maybe one time out of 10. And thinking back, I
*sometimes* saw failures to suspend with 2.6.11-rc3, maybe one failure
out of 20
On Thu, Mar 24, 2005 at 03:27:15PM +0100, Stefan Seyfried wrote:
Andy Isaacson wrote:
Dmesg is attached; hardware is a Vaio r505te.
Unfortunately, the deadlock (?) is nondeterministic; it *sometimes*
suspends successfully, maybe one time out of 10. And thinking back, I
*sometimes* saw
On Thu, 24 Mar 2005 10:10:59 -0800, Andy Isaacson [EMAIL PROTECTED] wrote:
So I added i8042.noaux to my kernel command line, rebooted, insmodded
intel_agp, started X, and verified no touchpad action. Then I
suspended, and it worked fine. After restart, I suspended again - also
fine.
So
On Thu, Mar 24, 2005 at 02:18:40PM -0500, Dmitry Torokhov wrote:
On Thu, 24 Mar 2005 10:10:59 -0800, Andy Isaacson [EMAIL PROTECTED] wrote:
So I added i8042.noaux to my kernel command line, rebooted, insmodded
intel_agp, started X, and verified no touchpad action. Then I
suspended, and it
Andy Isaacson wrote:
On Thu, Mar 24, 2005 at 03:27:15PM +0100, Stefan Seyfried wrote:
Sysrq still prints stuff, so IRQs aren't locked. But most of the sysrq
commands don't work... S and U don't seem to do anything (not too
suprising I suppose) but B does reboot.
sysrq-t will probably show a
On Thu, 24 Mar 2005 12:20:40 -0800, Andy Isaacson [EMAIL PROTECTED] wrote:
On Thu, Mar 24, 2005 at 02:18:40PM -0500, Dmitry Torokhov wrote:
On Thu, 24 Mar 2005 10:10:59 -0800, Andy Isaacson [EMAIL PROTECTED] wrote:
So I added i8042.noaux to my kernel command line, rebooted, insmodded
On Thu, 24 Mar 2005 12:20:40 -0800, Andy Isaacson [EMAIL PROTECTED] wrote:
On Thu, Mar 24, 2005 at 02:18:40PM -0500, Dmitry Torokhov wrote:
On Thu, 24 Mar 2005 10:10:59 -0800, Andy Isaacson [EMAIL PROTECTED] wrote:
So I added i8042.noaux to my kernel command line, rebooted, insmodded
On Thu, Mar 24, 2005 at 04:10:39PM -0500, Dmitry Torokhov wrote:
If you do ls /sys/bus/serio/devices and see more than 3 ports you
have MUX mode active.
Just serio0 and serio1.
On Thu, Mar 24, 2005 at 04:14:52PM -0500, Dmitry Torokhov wrote:
On Thu, 24 Mar 2005 12:20:40 -0800, Andy Isaacson
1 - 100 of 102 matches
Mail list logo
