swsusp: kill crash when too much memory is free

swsusp: kill crash when too much memory is free

[Pavel Machek]

Hi!

If too much memory is free, swsusp dies in quite a ugly way. Even when
it is not neccessary to relocate pagedir, it is proably still
neccessary to relocate individual pages. Thanks to Kurt Garloff and
Stefan Seyfried...
								Pavel
PS: And could I have one brown paper bag, please?

--- clean-mm/kernel/power/swsusp.c	2004-09-07 21:12:33.000000000 +0200
+++ linux-mm/kernel/power/swsusp.c	2004-09-09 08:56:20.000000000 +0200
@@ -950,9 +934,9 @@
 
 	printk("Relocating pagedir ");
 
-	if(!does_collide_order(old_pagedir, (unsigned long)old_pagedir, pagedir_order)) {
+	if (!does_collide_order(old_pagedir, (unsigned long)old_pagedir, pagedir_order)) {
 		printk("not necessary\n");
-		return 0;
+		return check_pagedir();
 	}
 
 	while ((m = (void *) __get_free_pages(GFP_ATOMIC, pagedir_order)) != NULL) {

Re: swsusp: kill crash when too much memory is free

[Rafael J. Wysocki]

 On Thursday 09 of September 2004 17:42, Pavel Machek wrote:
> Hi!
> 
> If too much memory is free, swsusp dies in quite a ugly way. Even when
> it is not neccessary to relocate pagedir, it is proably still
> neccessary to relocate individual pages. Thanks to Kurt Garloff and
> Stefan Seyfried...
> 								Pavel
> PS: And could I have one brown paper bag, please?

I applied this and it didn't fix my problems with resuming, unfortunately, but 
it changed the symptoms.  Namely, if USB modules are not unloaded before 
suspending, I get:

Relocating pagedir .....:::::|
Reading image data (11315 
pages): ...................................................................................
Stopping tasks: ==|
Freeing memory: |
PM: Restoring saved image.
<7>PM: Image restored successfully.
Losing some ticks... checking if CPU frequency changed.
warning: many lost ticks.
Your time source seems to be instable or some driver is hogging interupts
rip free_hot_cold_page+0x31/0x130
Warning: CPU frequency out of sync: cpufreq and timing core thinks of 800000, 
is 1800000 kHz.
PCI: Setting latency timer of device 0000:00:02.0 to 64
ohci_hcd 0000:00:02.0: HC died; cleaning up
usb 1-2: USB disconnect, address 3
Badness in hcd_endpoint_disable at drivers/usb/core/hcd.c:1310

Call Trace:<ffffffffa0045b80>{:usbcore:hcd_endpoint_disable+0}
       <ffffffffa0045beb>{:usbcore:hcd_endpoint_disable+107}
       <ffffffffa0046bb9>{:usbcore:usb_disable_endpoint+41}
       <ffffffffa0046d3a>{:usbcore:usb_disable_device+26}
       <ffffffffa0042b7c>{:usbcore:usb_disconnect+188} 
<ffffffffa0042ac2>{:usbcore:usb_disconnect+2}
       <ffffffffa0044890>{:usbcore:hcd_panic+0} 
<ffffffffa00448da>{:usbcore:hcd_panic+74}
       <ffffffff80152742>{worker_thread+674} 
<ffffffff80136930>{default_wake_function+0}
       <ffffffff80134e23>{__wake_up_common+67} 
<ffffffff80136930>{default_wake_function+0}
       <ffffffff801524a0>{worker_thread+0} <ffffffff8015945d>{kthread+205}
       <ffffffff80111673>{child_rip+8} <ffffffff80159390>{kthread+0}
       <ffffffff8011166b>{child_rip+0}
Badness in hcd_endpoint_disable at drivers/usb/core/hcd.c:1310

If they _are_ unloaded (ie "rmmod ehci_hcd ohci_hcd usbserial usbhid") before 
suspending, I get:

Relocating pagedir not necessary
Reading image data (11335 
pages): ...................................................................................
Stopping tasks: ==|
Freeing memory: |
PM: Restoring saved image.
<7>PM: Image restored successfully.
Losing some ticks... checking if CPU frequency changed.
warning: many lost ticks.
Your time source seems to be instable or some driver is hogging interupts
rip swsusp_free+0xfe/0x1a0
ACPI: PCI interrupt 0000:00:02.0[A] -> GSI 11 (level, low) -> IRQ 11
PCI: Setting latency timer of device 0000:00:02.0 to 64
ACPI: PCI interrupt 0000:00:02.1[B] -> GSI 5 (level, low) -> IRQ 5
PCI: Setting latency timer of device 0000:00:02.1 to 64
ACPI: PCI interrupt 0000:00:02.2[C] -> GSI 10 (level, low) -> IRQ 10
PCI: Setting latency timer of device 0000:00:02.2 to 64
ACPI: PCI interrupt 0000:00:06.0[A] -> GSI 5 (level, low) -> IRQ 5
PCI: Setting latency timer of device 0000:00:06.0 to 64
Warning: CPU frequency out of sync: cpufreq and timing core thinks of 800000, 
is 1800000 kHz.
ACPI: PCI interrupt 0000:02:00.0[A] -> GSI 11 (level, low) -> IRQ 11
ACPI: PCI interrupt 0000:02:01.2[C] -> GSI 11 (level, low) -> IRQ 11

And then silence (the box hangs solid and there's no more output on the serial 
console).

Well, this would indicate that there's a problem related to CPU scaling, so I 
compiled it out.  Then, I got:

Relocating pagedir .....:::::|
Reading image data (11667 
pages): ...................................................................................
Stopping tasks: ==|
Freeing memory: |
PM: Restoring saved image.
<0>double fault: 0000 [1]
CPU 0
Modules linked in: parport_pc lp parport joydev sg st sd_mod sr_mod scsi_mod 
snd_seq_oss snd_seq_midi_event snd_seq d
Pid: 12161, comm: bash Not tainted 2.6.9-rc1-mm4
RIP: 0010:[<ffffffff801245d7>] <ffffffff801245d7>{do_page_fault+55}
RSP: 0000:000001001fdfff48  EFLAGS: 00010016
RAX: ffffffff801245a0 RBX: 0000000000000001 RCX: 000ffffffffff000
RDX: 000000001fce3000 RSI: 0000000000000000 RDI: 000001001fe00068
RBP: 0000000080111203 R08: 0000000000000000 R09: 000001001fe27e64
R10: 0000000000000000 R11: 0000000000000064 R12: 0000000000000000
R13: 000001001b746618 R14: 000001000e0a3430 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffffffff805b7340(0000) knlGS:0000000000000000
CS:  0010 DS: 0018 ES: 0018 CR0: 0000000080050033
CR2: 000001001fdfff38 CR3: 0000000000101000 CR4: 00000000000006e0
Process bash (pid: 12161, threadinfo 00000100102b6000, task 000001000e0a3430)
Stack:

and nothing more.  Next time I unloaded dm_mod additionally before suspending 
and I got:

Relocating pagedir .....:::::|
Reading image data (11498 
pages): ...................................................................................
Stopping tasks: ==|
Freeing memory: |
PM: Restoring saved image.
<7>PM: Image restored successfully.
ACPI: PCI interrupt 0000:00:02.0[A] -> GSI 11 (level, low) -> IRQ 11
PCI: Setting latency timer of device 0000:00:02.0 to 64
ACPI: PCI interrupt 0000:00:02.1[B] -> GSI 5 (level, low) -> IRQ 5
PCI: Setting latency timer of device 0000:00:02.1 to 64
ACPI: PCI interrupt 0000:00:02.2[C] -> GSI 10 (level, low) -> IRQ 10
PCI: Setting latency timer of device 0000:00:02.2 to 64
ACPI: PCI interrupt 0000:00:06.0[A] -> GSI 5 (level, low) -> IRQ 5
PCI: Setting latency timer of device 0000:00:06.0 to 64
ACPI: PCI interrupt 0000:02:00.0[A] -> GSI 11 (level, low) -> IRQ 11
ACPI: PCI interrupt 0000:02:01.2[C] -> GSI 11 (level, low) -> IRQ 11

And then silence ...

This is 100% reproducible (ie unload USB modules and dm_mod, suspend the 
machine, try to wake it up, hangs solid).

Can you tell me, please, if there's anything I can compile out/in to debug it 
a bit more?  Or can I put some printk()s somewhere in the code to get some 
more info?  Any suggestions welcome.

Greets,
RJW

-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

Re: swsusp: kill crash when too much memory is free

[Pavel Machek]

Hi!

> > If too much memory is free, swsusp dies in quite a ugly way. Even when
> > it is not neccessary to relocate pagedir, it is proably still
> > neccessary to relocate individual pages. Thanks to Kurt Garloff and
> > Stefan Seyfried...
> > 								Pavel
> > PS: And could I have one brown paper bag, please?
> 
> I applied this and it didn't fix my problems with resuming, unfortunately, but 
> it changed the symptoms.  Namely, if USB modules are not unloaded before 
> suspending, I get:

> This is 100% reproducible (ie unload USB modules and dm_mod, suspend the 
> machine, try to wake it up, hangs solid).
> 
> Can you tell me, please, if there's anything I can compile out/in to debug it 
> a bit more?  Or can I put some printk()s somewhere in the code to get some 
> more info?  Any suggestions welcome.

Can you try my "bigdiff"? Also, does it work okay in 32-bit mode?

									Pavel

Re: swsusp: kill crash when too much memory is free

[Rafael J. Wysocki]

On Friday 10 of September 2004 11:40, Pavel Machek wrote:
> Hi!
> 
> > > If too much memory is free, swsusp dies in quite a ugly way. Even when
> > > it is not neccessary to relocate pagedir, it is proably still
> > > neccessary to relocate individual pages. Thanks to Kurt Garloff and
> > > Stefan Seyfried...
> > > 								Pavel
> > > PS: And could I have one brown paper bag, please?
> > 
> > I applied this and it didn't fix my problems with resuming, unfortunately, 
but 
> > it changed the symptoms.  Namely, if USB modules are not unloaded before 
> > suspending, I get:
> 
> > This is 100% reproducible (ie unload USB modules and dm_mod, suspend the 
> > machine, try to wake it up, hangs solid).
> > 
> > Can you tell me, please, if there's anything I can compile out/in to debug 
it 
> > a bit more?  Or can I put some printk()s somewhere in the code to get some 
> > more info?  Any suggestions welcome.
> 
> Can you try my "bigdiff"?

It's compiling.  I can't get output from the serial console right now, so I'll 
send you a summary later on.

> Also, does it work okay in 32-bit mode? 

Well, I have a 64-bit distro installed, so I would have to reinstall to check 
this ...  It's not impossible, though.  If the big diff does not help, I'll 
try to do something about it.

Greets,
RJW

-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

Re: swsusp: kill crash when too much memory is free

[Rafael J. Wysocki]

On Friday 10 of September 2004 11:40, Pavel Machek wrote:
> Hi!
> 
> > > If too much memory is free, swsusp dies in quite a ugly way. Even when
> > > it is not neccessary to relocate pagedir, it is proably still
> > > neccessary to relocate individual pages. Thanks to Kurt Garloff and
> > > Stefan Seyfried...
> > > 								Pavel
> > > PS: And could I have one brown paper bag, please?
> > 
> > I applied this and it didn't fix my problems with resuming, unfortunately, 
but 
> > it changed the symptoms.  Namely, if USB modules are not unloaded before 
> > suspending, I get:
> 
> > This is 100% reproducible (ie unload USB modules and dm_mod, suspend the 
> > machine, try to wake it up, hangs solid).
> > 
> > Can you tell me, please, if there's anything I can compile out/in to debug 
it 
> > a bit more?  Or can I put some printk()s somewhere in the code to get some 
> > more info?  Any suggestions welcome.
> 
> Can you try my "bigdiff"? Also, does it work okay in 32-bit mode?

Well, the good news is that it sort of works.  Still, there are some bad news, 
as usual. ;-)

First, to make the box wake up, I have to unload ohci_hcd and everything that 
sits on IRQ11 before suspending (on my system that is sk98lin, yenta_socked, 
and ohci1394).  If you want me to show what happens if I don't unload these 
modules, I'll be able to grab some traces in a couple of hours. ;-)  Also, I 
have to compile out the frequency scaling, because otherwise it hangs solid 
at some time after wake-up.

Second, after it's woken up, it seems to be very, _very_ slow, and the reason 
is indicated by this:

albercik:~ # cat /proc/interrupts && cat /proc/interrupts
           CPU0
  0:     273334          XT-PIC  timer
  1:       1803          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  5:    6656316          XT-PIC  NVidia nForce3
  8:          0          XT-PIC  rtc
  9:        121          XT-PIC  acpi
 10:          2          XT-PIC  ehci_hcd
 12:       5447          XT-PIC  i8042
 14:         16          XT-PIC  ide0
 15:       5044          XT-PIC  ide1
NMI:          0
LOC:     272507
ERR:          0
MIS:          0
           CPU0
  0:     273460          XT-PIC  timer
  1:       1803          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  5:    6680145          XT-PIC  NVidia nForce3
  8:          0          XT-PIC  rtc
  9:        121          XT-PIC  acpi
 10:          2          XT-PIC  ehci_hcd
 12:       5447          XT-PIC  i8042
 14:         16          XT-PIC  ide0
 15:       5046          XT-PIC  ide1
NMI:          0
LOC:     272632
ERR:          0
MIS:          0

Normally (eg before suspending), I get something like that:

           CPU0
  0:     196903          XT-PIC  timer
  1:       1437          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  5:         40          XT-PIC  NVidia nForce3
  8:          0          XT-PIC  rtc
  9:         99          XT-PIC  acpi
 10:          2          XT-PIC  ehci_hcd
 12:       3302          XT-PIC  i8042
 14:         16          XT-PIC  ide0
 15:       4667          XT-PIC  ide1
NMI:          0
LOC:     196751
ERR:          0
MIS:          0
           CPU0
  0:     196905          XT-PIC  timer
  1:       1437          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  5:         40          XT-PIC  NVidia nForce3
  8:          0          XT-PIC  rtc
  9:         99          XT-PIC  acpi
 10:          2          XT-PIC  ehci_hcd
 12:       3302          XT-PIC  i8042
 14:         16          XT-PIC  ide0
 15:       4667          XT-PIC  ide1
NMI:          0
LOC:     196753
ERR:          0
MIS:          0

In the 32-bit mode it behaves similarly (eg I have to unload the same modules 
etc. to make the box wake up), although the rate of growth of the number of 
IRQ5s seems to be smaller.

If you need any more info or if I can do anything more to debug it further, 
please let me know.

Greets,
RJW

-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

Re: swsusp: kill crash when too much memory is free

[Pavel Machek]

Hi!

> > Can you try my "bigdiff"? Also, does it work okay in 32-bit mode?
> 
> Well, the good news is that it sort of works.  Still, there are some bad news, 
> as usual. ;-)

So it sort-of-works, 32-bit and 64-bit mode? Good.

> First, to make the box wake up, I have to unload ohci_hcd and everything that 
> sits on IRQ11 before suspending (on my system that is sk98lin, yenta_socked, 
> and ohci1394).  If you want me to show what happens if I don't unload these 
> modules, I'll be able to grab some traces in a couple of hours. ;-)  Also, I 
> have to compile out the frequency scaling, because otherwise it hangs solid 
> at some time after wake-up.
> 
> Second, after it's woken up, it seems to be very, _very_ slow, and the reason 
> is indicated by this:

Hmm, I do not know what nForce3 is (it should use better name at the
minimum), but that driver probably needs some work.


>   5:    6656316          XT-PIC  NVidia nForce3
....
>   5:    6680145          XT-PIC  NVidia nForce3

								Pavel

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: swsusp: kill crash when too much memory is free

[Rafael J. Wysocki]

On Saturday 11 of September 2004 00:29, Pavel Machek wrote:
> Hi!
> 
> > > Can you try my "bigdiff"? Also, does it work okay in 32-bit mode?
> > 
> > Well, the good news is that it sort of works.  Still, there are some bad 
news, 
> > as usual. ;-)
> 
> So it sort-of-works, 32-bit and 64-bit mode? Good.
> 
> > First, to make the box wake up, I have to unload ohci_hcd and everything 
that 
> > sits on IRQ11 before suspending (on my system that is sk98lin, 
yenta_socked, 
> > and ohci1394).  If you want me to show what happens if I don't unload 
these 
> > modules, I'll be able to grab some traces in a couple of hours. ;-)  Also, 
I 
> > have to compile out the frequency scaling, because otherwise it hangs 
solid 
> > at some time after wake-up.
> > 
> > Second, after it's woken up, it seems to be very, _very_ slow, and the 
reason 
> > is indicated by this:
> 
> Hmm, I do not know what nForce3 is (it should use better name at the
> minimum), but that driver probably needs some work.

It is the sound chip (ie snd-intel8x0).  If I unload it after resume, 
everything's fine and dandy.  Moreover, if I unload it before suspend, the 
box wakes up with no problems (of course, I have to unload the other modules 
too, as I said before).

However, I think the problem is with the hardware, not with the driver: if the 
sound driver is unloaded before suspend and loaded again after resume, the 
box behaves as though it were loaded all the time (ie IRQ #5 goes mad).  Are 
there any boot options that may help get around this?

Greets,
RJW

-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

Re: swsusp: kill crash when too much memory is free

[Rafael J. Wysocki]

On Saturday 11 of September 2004 11:50, Rafael J. Wysocki wrote:
> On Saturday 11 of September 2004 00:29, Pavel Machek wrote:
[- snip -]
> 
> However, I think the problem is with the hardware, not with the driver: if 
the 
> sound driver is unloaded before suspend and loaded again after resume, the 
> box behaves as though it were loaded all the time (ie IRQ #5 goes mad).  Are 
> there any boot options that may help get around this?

Some good news here. :-)

If the kernel is booted with pci=routeirq and nmi_watchdog=0, almost all of 
the problems that I had with swsusp "magically" disappear.

One issue that remains is a USB-related crash (trace available at: 
http://www.sisk.pl/kernel/040911/swsusp-usb-trace.log), which does not 
prevent the box from waking up (as you can see in the trace), but requires 
the ohci_hcd module to be reloaded.  I have got rid of it by compiling the 
USB drivers into the kernel.

The second remaining "thing" is that the network interface on eth0 (sk98lin) 
does not come up properly after resume and I have to restart networking to 
make it work, but this is a non-issue.

Thanks a lot for your help, and if I can do something for you (like testing 
new code etc.), please let me know.

Greets,
RJW

-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

Re: swsusp: kill crash when too much memory is free

[Rafael J. Wysocki]

On Saturday 11 of September 2004 21:22, Rafael J. Wysocki wrote:
> On Saturday 11 of September 2004 11:50, Rafael J. Wysocki wrote:
> > On Saturday 11 of September 2004 00:29, Pavel Machek wrote:
> [- snip -]
> > 
> > However, I think the problem is with the hardware, not with the driver: if 
> the 
> > sound driver is unloaded before suspend and loaded again after resume, the 
> > box behaves as though it were loaded all the time (ie IRQ #5 goes mad).  
Are 
> > there any boot options that may help get around this?
> 
> Some good news here. :-)
> 

I said this too early. :-(

After issuing "echo 4 > /proc/acpi/sleep" I get things similar to this:

Stopping tasks: 
===========================================================================|
Freeing memory... done (82503 pages freed)
Losing some ticks... checking if CPU frequency changed.
PM: Attempting to suspend to disk.
PM: snapshotting memory.
swsusp: critical section:
[nosave pfn 0x5ef]swsusp: Need to copy 45470 pages
suspend: (pages needed: 45470 + 512 free: 85409)
[nosave pfn 0x5ef]swsusp: critical section/: done (45982 pages copied)
invalid operand: 0000 [1]
CPU 0
Modules linked in: usbserial parport_pc lp parport joydev sg sd_mod sr_mod 
scsi_mod yenta_socket pcmcia_core ohci1394 ieee1394 cpufreq_used
Pid: 17809, comm: bash Not tainted 2.6.9-rc1-mm4
RIP: 0010:[<ffffffff805cd476>] <ffffffff805cd476>{cpu_init+54}
RSP: 0018:0000010000eb3e40  EFLAGS: 00010002
RAX: 0000000000000089 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000010000eb3e68 RDI: ffffffff804741d4
RBP: ffffffff80487140 R08: 0000000000000000 R09: 0000000000000004
R10: 00000000ffffffff R11: 0000000000000000 R12: 0000000000000003
R13: 0000000000000002 R14: 0000002a955a5000 R15: 0000000000000000
FS:  0000002a95d330a0(0000) GS:ffffffff805c16c0(0000) knlGS:0000000055a62e80
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000002a95653000 CR3: 0000000000101000 CR4: 00000000000006e0
Process bash (pid: 17809, threadinfo 0000010000eb2000, task 000001001c3620f0)
Stack: ffffffff801211d9 0000000000000002 ffffffff80487140 8000895b7e402080
       00000000ffffffff ffffffff8053de00 ffffffff80121448 0000000000000000
       ffffffff80161033 0000000000000002
Call Trace:<ffffffff801211d9>{fix_processor_context+137} 
<ffffffff80121448>{__restore_processor_state+120}
       <ffffffff80161033>{swsusp_suspend+19} 
<ffffffff80161ee4>{pm_suspend_disk+100}
       <ffffffff8015fa26>{enter_state+70} 
<ffffffff803032c4>{acpi_system_write_sleep+107}
       <ffffffff8018ff14>{vfs_write+228} <ffffffff80190053>{sys_write+83}
       <ffffffff80110be2>{system_call+126}

Code: 61 67 6e 69 74 75 64 65 73 00 6e 70 31 2e 30 00 5a 45 52 4f
RIP <ffffffff805cd476>{cpu_init+54} RSP <0000010000eb3e40>

It happens if memory is almost entirely used by applications.

Greets,
RJW

-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

swsusp (2.6.9-rc1-mm4 + bigdiff): Unable to handle kernel paging request

[Rafael J. Wysocki]

On Saturday 11 of September 2004 23:59, Rafael J. Wysocki wrote:
> On Saturday 11 of September 2004 21:22, Rafael J. Wysocki wrote:
> > On Saturday 11 of September 2004 11:50, Rafael J. Wysocki wrote:
[- snip -]
> After issuing "echo 4 > /proc/acpi/sleep" I get things similar to this:

Here goes a similar trace of that sort:

Stopping tasks: 
====================================================================|
Freeing memory... done (97366 pages freed)
PM: Attempting to suspend to disk.
PM: snapshotting memory.
swsusp: critical section:
[nosave pfn 0x5ef]swsusp: Need to copy 26830 pages
suspend: (pages needed: 26830 + 512 free: 104049)
[nosave pfn 0x5ef]swsusp: critical section/: done (27086 pages copied)
Unable to handle kernel paging request at ffffffff93d9fdff RIP:
<ffffffff805cd401>{syscall_init+1}
PML4 103027 PGD 105027 PMD 0
Oops: 0002 [1]
CPU 0
Modules linked in: usbserial parport_pc lp parport joydev sg sd_mod sr_mod 
scsi_mod ohci1394 yenta_socket ieee1394 pcmcia_core cpufreq_ud
Pid: 17970, comm: bash Not tainted 2.6.9-rc1-mm4
RIP: 0010:[<ffffffff805cd401>] <ffffffff805cd401>{syscall_init+1}
RSP: 0000:000001000a089e40  EFLAGS: 00010402
RAX: 0000000000000089 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 000001000a089e68 RDI: ffffffff804741d0
RBP: ffffffff80487140 R08: 0000000000000000 R09: 0000000000000004
R10: 00000000ffffffff R11: 0000000000000000 R12: 0000000000000003
R13: 0000000000000002 R14: 0000002a955a5000 R15: 0000000000000000
FS:  0000002a95d330a0(0000) GS:ffffffff805c16c0(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffff93d9fdff CR3: 0000000000101000 CR4: 00000000000006e0
Process bash (pid: 17970, threadinfo 000001000a088000, task 0000010016f7aa10)
Stack: ffffffff801211d9 0000000000000002 ffffffff80487140 8000895b7e402080
       00000000ffffffff ffffffff8053de00 ffffffff80121448 0000000000000000
       ffffffff80161033 0000000000000002
Call Trace:<ffffffff801211d9>{fix_processor_context+137} 
<ffffffff80121448>{__restore_processor_state+120}
       <ffffffff80161033>{swsusp_suspend+19} 
<ffffffff80161ee4>{pm_suspend_disk+100}
       <ffffffff8015fa26>{enter_state+70} 
<ffffffff803032c4>{acpi_system_write_sleep+107}
       <ffffffff8018ff14>{vfs_write+228} <ffffffff80190053>{sys_write+83}
       <ffffffff80110be2>{system_call+126}

Code: d9 93 ff fd d9 93 ff fe da 93 ff fd da 91 ff fc d9 90 ff fd
RIP <ffffffff805cd401>{syscall_init+1} RSP <000001000a089e40>
CR2: ffffffff93d9fdff

It is easily reproducible.  It suffices to run X with KDE and some apps with 
it and try "echo 4 > /proc/acpi/sleep" to get one of those (100% of the time 
or so).

Greets,
RJW

-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

Re: swsusp: kill crash when too much memory is free

[Pavel Machek]

Hi!

> > Hmm, I do not know what nForce3 is (it should use better name at the
> > minimum), but that driver probably needs some work.
> 
> It is the sound chip (ie snd-intel8x0).  If I unload it after resume, 
> everything's fine and dandy.  Moreover, if I unload it before suspend, the 
> box wakes up with no problems (of course, I have to unload the other modules 
> too, as I said before).
> 
> However, I think the problem is with the hardware, not with the driver: if the 
> sound driver is unloaded before suspend and loaded again after resume, the 
> box behaves as though it were loaded all the time (ie IRQ #5 goes mad).  Are 
> there any boot options that may help get around this?

Hmm, I do not think it is hardware problem. Does snd-intel8x0 have any
suspend/resume support?

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: swsusp: kill crash when too much memory is free

[Rafael J. Wysocki]

On Sunday 12 of September 2004 22:42, Pavel Machek wrote:
> Hi!
> 
> > > Hmm, I do not know what nForce3 is (it should use better name at the
> > > minimum), but that driver probably needs some work.
> > 
> > It is the sound chip (ie snd-intel8x0).  If I unload it after resume, 
> > everything's fine and dandy.  Moreover, if I unload it before suspend, the 
> > box wakes up with no problems (of course, I have to unload the other 
modules 
> > too, as I said before).
> > 
> > However, I think the problem is with the hardware, not with the driver: if 
the 
> > sound driver is unloaded before suspend and loaded again after resume, the 
> > box behaves as though it were loaded all the time (ie IRQ #5 goes mad).  
Are 
> > there any boot options that may help get around this?
> 
> Hmm, I do not think it is hardware problem.

You're right, it isn't.  If the kernel is booted with pci=routeirq, the 
problem goes away, as I've said already.

> Does snd-intel8x0 have any suspend/resume support?

It seems it doesn't, but frankly I haven't looked at the code.

Greets,
RJW

-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

Re: swsusp: kill crash when too much memory is free

[Stefan Seyfried]

Rafael J. Wysocki wrote:
> On Sunday 12 of September 2004 22:42, Pavel Machek wrote:

>>Does snd-intel8x0 have any suspend/resume support?
> 
> It seems it doesn't, but frankly I haven't looked at the code.

It has intel8x0_suspend() and intel8x0_resume() and works on a lot of
i386 machines fine, i can play sound while suspending and it will
continue after resuming on e.g. a Dell D600 or a hp nx5000.

    Stefan

Re: swsusp: kill crash when too much memory is free

[Rafael J. Wysocki]

On Sunday 12 of September 2004 23:40, Stefan Seyfried wrote:
> Rafael J. Wysocki wrote:
> > On Sunday 12 of September 2004 22:42, Pavel Machek wrote:
> 
> >>Does snd-intel8x0 have any suspend/resume support?
> > 
> > It seems it doesn't, but frankly I haven't looked at the code.
> 
> It has intel8x0_suspend() and intel8x0_resume() and works on a lot of
> i386 machines fine, i can play sound while suspending and it will
> continue after resuming on e.g. a Dell D600 or a hp nx5000.

Well, here I have problems with it in both the 32-bit and 64-bit modes (in 
short, pci=routeirq is necessary to make it work).  I think they're 
NForce3-specific and that's why I said "hardware" before.  Now, what you are 
saying kind of confirms this.

Greets,
RJW

-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"