Hi all,
swsusp is not working for me with 2.6.12rc1. I compiled the kernel
preempt, I am compiling now without preempt to test it. -mm3 has a
similar behaviour.
All the configuration, dmesg, lsmod etc is here:
http://www.dea.icai.upco.es/romano/linux/config-2.6.12-rc1/laptop-config.html
Perfectly working (swsup included) similar data is in:
http://www.dea.icai.upco.es/romano/linux/config-2.6.11-rg/laptop-config.html
When suspending, it stops dead with thi two lines (hand copied)
ACPI: PCI interrupt 0000:00:07.5 [C] -> GSI 5 (level, low) -> IRQ5
ACPI: PCI interrupt 0000:00:0e.0 [A] -> GSI 9 (level, low) -> IRQ9
...and nothing more.
Romano
--
Romano Giannetti - Univ. Pontificia Comillas (Madrid, Spain)
Electronic Engineer - phone +34 915 422 800 ext 2416 fax +34 915 596 569
On Tue, Mar 29, 2005 at 01:03:09PM +0200, Romano Giannetti wrote:
> Hi all,
>
> swsusp is not working for me with 2.6.12rc1. I compiled the kernel
> preempt, I am compiling now without preempt to test it. -mm3 has a
> similar behaviour.
Tested with no-preempt -rc1-mm3. No joy; the suspend stops exactly at the
same point.
If you need more info, just tell me.
Romano
--
Romano Giannetti - Univ. Pontificia Comillas (Madrid, Spain)
Electronic Engineer - phone +34 915 422 800 ext 2416 fax +34 915 596 569
On Tue, Mar 29, 2005 at 03:20:22PM +0200, Romano Giannetti wrote:
> > swsusp is not working for me with 2.6.12rc1. I compiled the kernel
> > preempt, I am compiling now without preempt to test it. -mm3 has a
> > similar behaviour.
>
> Tested with no-preempt -rc1-mm3. No joy; the suspend stops exactly at the
> same point.
Double auto-answer. I have a serial console now; if anybody can help me to
explain why (after booting with console=ttyS0,115200 console=tty0) if I do a
sysrq-t on the serial console appears just the "[4295210.188000] SysRq :
Show State" and not the dump which appears only to the virtual console...
then I can capture all the logs you like.
Romano
--
Romano Giannetti - Univ. Pontificia Comillas (Madrid, Spain)
Electronic Engineer - phone +34 915 422 800 ext 2416 fax +34 915 596 569
Hi!
> > > swsusp is not working for me with 2.6.12rc1. I compiled the kernel
> > > preempt, I am compiling now without preempt to test it. -mm3 has a
> > > similar behaviour.
> >
> > Tested with no-preempt -rc1-mm3. No joy; the suspend stops exactly at the
> > same point.
>
> Double auto-answer. I have a serial console now; if anybody can help me to
> explain why (after booting with console=ttyS0,115200 console=tty0) if I do a
> sysrq-t on the serial console appears just the "[4295210.188000] SysRq :
> Show State" and not the dump which appears only to the virtual console...
I'd start with non-preempt 2.6.12-rc1, then remove all the
unneccessary drivers, boot init=/bin/bash, and see what happens.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
On Tue, Mar 29, 2005 at 08:15:51PM +0200, Pavel Machek wrote:
> I'd start with non-preempt 2.6.12-rc1, then remove all the
> unneccessary drivers, boot init=/bin/bash, and see what happens.
Tried it. Well, the good news is that now I can use correctly the serial
console. I discovered that if I use
console=ttyS0,115200n8
all the message goes through the cable... but if I add (as per documentation)
console=tty0 too, something goes to the serial console and something no...
but well, I can live with it.
The bad news is that with 2.6.12-rc1 (no preempt) swsusp fails to go. The
all thing that can capture the serial console is:
Mar 31 16:14:52 rukbat kernel: [4294819.325000] usbcore: deregistering
driver usbhid
Mar 31 16:14:52 rukbat kernel: [4294819.537000] uhci_hcd 0000:00:07.2:
remove, state 1
Mar 31 16:14:52 rukbat kernel: [4294819.537000] usb usb1: USB disconnect,
address 1
Mar 31 16:14:52 rukbat kernel: [4294819.537000] usb 1-2: USB disconnect,
address 2
Mar 31 16:14:52 rukbat kernel: [4294819.714000] uhci_hcd 0000:00:07.2: USB
bus 1 deregistered
Mar 31 16:14:52 rukbat kernel: [4294819.729000] uhci_hcd 0000:00:07.3:
remove, state 1
Mar 31 16:14:52 rukbat kernel: [4294819.729000] usb usb2: USB disconnect,
address 1
Mar 31 16:14:52 rukbat kernel: [4294819.819000] uhci_hcd 0000:00:07.3: USB
bus 2 deregistered
Mar 31 16:14:52 rukbat kernel: [4294819.861000] usbcore: deregistering
driver usbmouse
[4294821.492000] Stopping tasks:
===============================================================================|
[4294821.505000] Freeing memory... done (44548 pages freed)
And then stops dead. One thing I noticed: the "rotating bar" is now much
more slow than before (although the total time before "done" is not changed
a lot, it seems). Could be a hint?
the full log (42k) is here
http://www.dea.icai.upco.es/romano/linux/swsusp/2612-rc1.log
I tried with init=/bin/bash, same thing, here:
http://www.dea.icai.upco.es/romano/linux/swsusp/2612-rc1-2nd.log
To compare, this is a full log of boot, suspend and successful resume
with 2.6.11:
http://www.dea.icai.upco.es/romano/linux/swsusp/2611-rg.log
it's not vanilla, it has the following patch applied, but I tested with and
without it and nothing change (that is, all is OK in this kernel)
http://www.dea.icai.upco.es/romano/linux/config-2.6.11-rg/patch-no3851.id4516
Well... what can I do now (apart doing some real work)? I can try to debug
why 2.6.11 with preempt fail, or continue on 2.6.12? I am willing to help!
Thank you for your help,
Romano
--
Romano Giannetti - Univ. Pontificia Comillas (Madrid, Spain)
Electronic Engineer - phone +34 915 422 800 ext 2416 fax +34 915 596 569
On Thu, 31 Mar 2005 16:47:29 +0200, Romano Giannetti <[email protected]> wrote:
>
> The bad news is that with 2.6.12-rc1 (no preempt) swsusp fails to go.
Ok, I see you have an ALPS touchpad. I think this patch will help you
with swsusp:
http://marc.theaimsgroup.com/?l=linux-kernel&m=111212532524998&q=raw
Also, could you please try sticking psmouse_reset(psmouse) call at the
beginning of drivers/input/mouse/alps.c::alps_reconnect() and see if
it can suspend _without_ the patch above.
Thanks!
--
Dmitry
On Thu, Mar 31, 2005 at 10:15:26AM -0500, Dmitry Torokhov wrote:
> On Thu, 31 Mar 2005 16:47:29 +0200, Romano Giannetti <[email protected]> wrote:
> >
> > The bad news is that with 2.6.12-rc1 (no preempt) swsusp fails to go.
>
> Ok, I see you have an ALPS touchpad. I think this patch will help you
> with swsusp:
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=111212532524998&q=raw
>
> Also, could you please try sticking psmouse_reset(psmouse) call at the
> beginning of drivers/input/mouse/alps.c::alps_reconnect() and see if
> it can suspend _without_ the patch above.
I will try in a moment. But... probably I am not understanding but... the
patch is at "resume()" and my problem happens during suspend...
...mumbling...
...is because we suspend, then restart to write image, then suspend again?
Maybe. Will try. By the way, thanks for the ALPS integration, it works very
well for me in 2.6.11.
Romano
--
Romano Giannetti - Univ. Pontificia Comillas (Madrid, Spain)
Electronic Engineer - phone +34 915 422 800 ext 2416 fax +34 915 596 569
On Thu, Mar 31, 2005 at 10:15:26AM -0500, Dmitry Torokhov wrote:
> On Thu, 31 Mar 2005 16:47:29 +0200, Romano Giannetti <[email protected]> wrote:
> >
> > The bad news is that with 2.6.12-rc1 (no preempt) swsusp fails to go.
>
> Ok, I see you have an ALPS touchpad. I think this patch will help you
> with swsusp:
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=111212532524998&q=raw
Yes! With this it works ok.
> Also, could you please try sticking psmouse_reset(psmouse) call at the
> beginning of drivers/input/mouse/alps.c::alps_reconnect() and see if
> it can suspend _without_ the patch above.
It works, too. Which one is the best one?
I will try now with preempt, although I suspect that this was an unrelated
problem.
Thanks a lot,
Romano
--
Romano Giannetti - Univ. Pontificia Comillas (Madrid, Spain)
Electronic Engineer - phone +34 915 422 800 ext 2416 fax +34 915 596 569
On Thu, 31 Mar 2005 18:50:07 +0200, Romano Giannetti <[email protected]> wrote:
> On Thu, Mar 31, 2005 at 10:15:26AM -0500, Dmitry Torokhov wrote:
> > On Thu, 31 Mar 2005 16:47:29 +0200, Romano Giannetti <[email protected]> wrote:
> > >
> > > The bad news is that with 2.6.12-rc1 (no preempt) swsusp fails to go.
> >
> > Ok, I see you have an ALPS touchpad. I think this patch will help you
> > with swsusp:
> >
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=111212532524998&q=raw
>
> Yes! With this it works ok.
>
> > Also, could you please try sticking psmouse_reset(psmouse) call at the
> > beginning of drivers/input/mouse/alps.c::alps_reconnect() and see if
> > it can suspend _without_ the patch above.
>
Both patches are working for me (Dell D600). before i was unable to
suspend to disk on this laptop (it was stuck in alps code).
By the way, i have an unrelated problem:
if the kernel was booted with the "noresume" option, it cannot be
suspended, it fails with:
swsusp: FATAL: cannot find swap device, try swapon -a!
Thanks,
Benoit
On Thursday 31 March 2005 11:50, Romano Giannetti wrote:
> On Thu, Mar 31, 2005 at 10:15:26AM -0500, Dmitry Torokhov wrote:
> > On Thu, 31 Mar 2005 16:47:29 +0200, Romano Giannetti <[email protected]> wrote:
> > >
> > > The bad news is that with 2.6.12-rc1 (no preempt) swsusp fails to go.
> >
> > Ok, I see you have an ALPS touchpad. I think this patch will help you
> > with swsusp:
> >
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=111212532524998&q=raw
>
> Yes! With this it works ok.
>
> > Also, could you please try sticking psmouse_reset(psmouse) call at the
> > beginning of drivers/input/mouse/alps.c::alps_reconnect() and see if
> > it can suspend _without_ the patch above.
>
> It works, too. Which one is the best one?
>
Both of them are needed as they address two different problems.
--
Dmitry
Hi!
> > Yes! With this it works ok.
> >
> > > Also, could you please try sticking psmouse_reset(psmouse) call at the
> > > beginning of drivers/input/mouse/alps.c::alps_reconnect() and see if
> > > it can suspend _without_ the patch above.
> >
>
> Both patches are working for me (Dell D600). before i was unable to
> suspend to disk on this laptop (it was stuck in alps code).
>
> By the way, i have an unrelated problem:
> if the kernel was booted with the "noresume" option, it cannot be
> suspended, it fails with:
>
> swsusp: FATAL: cannot find swap device, try swapon -a!
Uh, okay, logic error, probably introduced by resume-from-initrd
patch. Does this fix it?
OTOH, perhaps refusing suspend is right thing to do. If user is
running in "safe mode" (with noresume), we don't want him to be able
to suspend...
Pavel
--- clean/kernel/power/swsusp.c 2005-03-19 00:32:32.000000000 +0100
+++ linux/kernel/power/swsusp.c 2005-04-01 00:23:15.000000000 +0200
@@ -1376,16 +1371,6 @@
{
int error;
- if (!swsusp_resume_device) {
- if (!strlen(resume_file))
- return -ENOENT;
- swsusp_resume_device = name_to_dev_t(resume_file);
- pr_debug("swsusp: Resume From Partition %s\n", resume_file);
- } else {
- pr_debug("swsusp: Resume From Partition %d:%d\n",
- MAJOR(swsusp_resume_device), MINOR(swsusp_resume_device));
- }
-
resume_bdev = open_by_devnum(swsusp_resume_device, FMODE_READ);
if (!IS_ERR(resume_bdev)) {
set_blocksize(resume_bdev, PAGE_SIZE);
--- clean/kernel/power/disk.c 2005-03-19 00:32:32.000000000 +0100
+++ linux/kernel/power/disk.c 2005-04-01 00:23:09.000000000 +0200
@@ -233,6 +237,16 @@
{
int error;
+ if (!swsusp_resume_device) {
+ if (!strlen(resume_file))
+ return -ENOENT;
+ swsusp_resume_device = name_to_dev_t(resume_file);
+ pr_debug("swsusp: Resume From Partition %s\n", resume_file);
+ } else {
+ pr_debug("swsusp: Resume From Partition %d:%d\n",
+ MAJOR(swsusp_resume_device), MINOR(swsusp_resume_device));
+ }
+
if (noresume) {
/**
* FIXME: If noresume is specified, we need to find the partition
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
Hi.
On Fri, 2005-04-01 at 08:25, Pavel Machek wrote:
> Hi!
>
> > > Yes! With this it works ok.
> > >
> > > > Also, could you please try sticking psmouse_reset(psmouse) call at the
> > > > beginning of drivers/input/mouse/alps.c::alps_reconnect() and see if
> > > > it can suspend _without_ the patch above.
> > >
> >
> > Both patches are working for me (Dell D600). before i was unable to
> > suspend to disk on this laptop (it was stuck in alps code).
> >
> > By the way, i have an unrelated problem:
> > if the kernel was booted with the "noresume" option, it cannot be
> > suspended, it fails with:
> >
> > swsusp: FATAL: cannot find swap device, try swapon -a!
>
> Uh, okay, logic error, probably introduced by resume-from-initrd
> patch. Does this fix it?
>
> OTOH, perhaps refusing suspend is right thing to do. If user is
> running in "safe mode" (with noresume), we don't want him to be able
> to suspend...
What? If you suspend, then decide not to resume, you can suspend again
until after your next reboot?!
Nigel
--
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028; Mob: +61 (417) 100 574
Maintainer of Suspend2 Kernel Patches http://suspend2.net
Hi again.
On Fri, 2005-04-01 at 10:50, Nigel Cunningham wrote:
> > OTOH, perhaps refusing suspend is right thing to do. If user is
> > running in "safe mode" (with noresume), we don't want him to be able
> > to suspend...
>
> What? If you suspend, then decide not to resume, you can suspend again
> until after your next reboot?!
err... "...can't suspend again..."
> Nigel
--
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028; Mob: +61 (417) 100 574
Maintainer of Suspend2 Kernel Patches http://suspend2.net
Hi!
> > > > Yes! With this it works ok.
> > > >
> > > > > Also, could you please try sticking psmouse_reset(psmouse) call at the
> > > > > beginning of drivers/input/mouse/alps.c::alps_reconnect() and see if
> > > > > it can suspend _without_ the patch above.
> > > >
> > >
> > > Both patches are working for me (Dell D600). before i was unable to
> > > suspend to disk on this laptop (it was stuck in alps code).
> > >
> > > By the way, i have an unrelated problem:
> > > if the kernel was booted with the "noresume" option, it cannot be
> > > suspended, it fails with:
> > >
> > > swsusp: FATAL: cannot find swap device, try swapon -a!
> >
> > Uh, okay, logic error, probably introduced by resume-from-initrd
> > patch. Does this fix it?
> >
> > OTOH, perhaps refusing suspend is right thing to do. If user is
> > running in "safe mode" (with noresume), we don't want him to be able
> > to suspend...
>
> What? If you suspend, then decide not to resume, you can suspend again
> until after your next reboot?!
Yes, in current code. It was a bug. OTOH that means that you can not
suspend from safe mode, and that's good: if you *do* suspend from safe
mode, there's basically no way for you to resume [user *could* select
safe mode next time, and kill noresume, but I don't think many users
will figure that out.]
So I can fix the bug (patch was attached), but that means that it
would be nice to prevent suspend from safe mode in next SuSE... And
probably other distros, too.
(Safe mode is grub setting with noapic noresume....)
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
On Mar 31, 2005 8:09 PM, Dmitry Torokhov <[email protected]> wrote:
> > It works, too. Which one is the best one?
> >
>
> Both of them are needed as they address two different problems.
>
I tried to boot with the 2 patches applied (and the patch which solves
noresume) and now touchpad/touchpoint no longer works (with this
kernel or with an older kernel).
Were the 2 patches safe or is it unrelated ?
Is there an easy way to get the touchpad back ?
regards,
Benoit
On Apr 1, 2005 11:14 AM, Benoit Boissinot <[email protected]> wrote:
> On Mar 31, 2005 8:09 PM, Dmitry Torokhov <[email protected]> wrote:
> > > It works, too. Which one is the best one?
> > >
> >
> > Both of them are needed as they address two different problems.
> >
> I tried to boot with the 2 patches applied (and the patch which solves
> noresume) and now touchpad/touchpoint no longer works (with this
> kernel or with an older kernel).
>
Could you be more explicit - it is not recognized at all or it is
recognized but mouse pointer does not move or something else? dmesg
also might be interesting.
Also, the 2nd "patch" was never published, could you post what exactly
you have applied?
Thanks!
--
Dmitry
On Fri, Apr 01, 2005 at 11:28:05AM -0500, Dmitry Torokhov wrote:
> On Apr 1, 2005 11:14 AM, Benoit Boissinot <[email protected]> wrote:
> > On Mar 31, 2005 8:09 PM, Dmitry Torokhov <[email protected]> wrote:
> > > > It works, too. Which one is the best one?
> > > >
> > >
> > > Both of them are needed as they address two different problems.
> > >
> > I tried to boot with the 2 patches applied (and the patch which solves
> > noresume) and now touchpad/touchpoint no longer works (with this
> > kernel or with an older kernel).
> >
>
> Could you be more explicit - it is not recognized at all or it is
> recognized but mouse pointer does not move or something else? dmesg
> also might be interesting.
>
It is recognized in dmesg (same message as before), but the mouse
pointer does not move (a `cat /dev/input/mice` doesn't do anything).
By the way, it is a dell D600.
> Also, the 2nd "patch" was never published, could you post what exactly
> you have applied?
>
attached
> Thanks!
>
> --
> Dmitry
--
powered by bash/screen/(urxvt/fvwm|linux-console)/gentoo/gnu/linux OS
On Apr 1, 2005 11:43 AM, Benoit Boissinot <[email protected]> wrote:
> On Fri, Apr 01, 2005 at 11:28:05AM -0500, Dmitry Torokhov wrote:
> > On Apr 1, 2005 11:14 AM, Benoit Boissinot <[email protected]> wrote:
> > > On Mar 31, 2005 8:09 PM, Dmitry Torokhov <[email protected]> wrote:
> > > > > It works, too. Which one is the best one?
> > > > >
> > > >
> > > > Both of them are needed as they address two different problems.
> > > >
> > > I tried to boot with the 2 patches applied (and the patch which solves
> > > noresume) and now touchpad/touchpoint no longer works (with this
> > > kernel or with an older kernel).
> > >
> >
> > Could you be more explicit - it is not recognized at all or it is
> > recognized but mouse pointer does not move or something else? dmesg
> > also might be interesting.
> >
> It is recognized in dmesg (same message as before), but the mouse
> pointer does not move (a `cat /dev/input/mice` doesn't do anything).
>
Should work... The patches come into play only when
suspending/resuming. So you are saying even with an old, unpatched
kernel ALS stopped working, right?
Hmm, that USB mouse - was it there before? I wonder if "usb-handoff"
on the kernel comman line will help.
--
Dmitry
On Fri, Apr 01, 2005 at 12:00:42PM -0500, Dmitry Torokhov wrote:
> On Apr 1, 2005 11:43 AM, Benoit Boissinot <[email protected]> wrote:
> > On Fri, Apr 01, 2005 at 11:28:05AM -0500, Dmitry Torokhov wrote:
> > > On Apr 1, 2005 11:14 AM, Benoit Boissinot <[email protected]> wrote:
> > > > On Mar 31, 2005 8:09 PM, Dmitry Torokhov <[email protected]> wrote:
> > > > > > It works, too. Which one is the best one?
> > > > > >
> > > > >
> > > > > Both of them are needed as they address two different problems.
> > > > >
> > > > I tried to boot with the 2 patches applied (and the patch which solves
> > > > noresume) and now touchpad/touchpoint no longer works (with this
> > > > kernel or with an older kernel).
> > > >
> > >
> > > Could you be more explicit - it is not recognized at all or it is
> > > recognized but mouse pointer does not move or something else? dmesg
> > > also might be interesting.
> > >
> > It is recognized in dmesg (same message as before), but the mouse
> > pointer does not move (a `cat /dev/input/mice` doesn't do anything).
> >
>
> Should work... The patches come into play only when
> suspending/resuming. So you are saying even with an old, unpatched
> kernel ALS stopped working, right?
>
I did a suspend/resume with the patches applied. And yes it doesn't work
with an old unpatched kernel.
Detected in dmesg, but no movement.
> Hmm, that USB mouse - was it there before? I wonder if "usb-handoff"
> on the kernel comman line will help.
>
I plugged it after i saw the touchpad didn't worked anymore (and i test
if the touchpad works without the mouse plugged in).
> --
> Dmitry
--
powered by bash/screen/(urxvt/fvwm|linux-console)/gentoo/gnu/linux OS
On Fri, Apr 01, 2005 at 07:29:15PM +0200, Benoit Boissinot wrote:
> On Fri, Apr 01, 2005 at 12:00:42PM -0500, Dmitry Torokhov wrote:
> > On Apr 1, 2005 11:43 AM, Benoit Boissinot <[email protected]> wrote:
> > > On Fri, Apr 01, 2005 at 11:28:05AM -0500, Dmitry Torokhov wrote:
> > > > On Apr 1, 2005 11:14 AM, Benoit Boissinot <[email protected]> wrote:
> > > > > On Mar 31, 2005 8:09 PM, Dmitry Torokhov <[email protected]> wrote:
> > > > > > > It works, too. Which one is the best one?
> > > > > > >
> > > > > I tried to boot with the 2 patches applied (and the patch which solves
> > > > > noresume) and now touchpad/touchpoint no longer works (with this
> > > > > kernel or with an older kernel).
> > > > >
> > > >
> >
> > Should work... The patches come into play only when
> > suspending/resuming. So you are saying even with an old, unpatched
> > kernel ALS stopped working, right?
> >
> I did a suspend/resume with the patches applied. And yes it doesn't work
> with an old unpatched kernel.
> Detected in dmesg, but no movement.
>
When i booted the laptop today, the touchpad did work. I suppose it
was an hardware problem or something like that.
Sorry for bothering you.
Thanks
Benoit
--
powered by bash/screen/(urxvt/fvwm|linux-console)/gentoo/gnu/linux OS