Toshiba Satellite P10

I'm having some trouble with suspend/resume on my Toshiba Satellite P10 and was wondering whether anybody would be able to assist.

The omnibook module makes some functionality (like the multimedia keys, temperature readings, LCD and FAN adjustments) available. It however does not help with suspend/resume at all.

It seems like the notebook only supports standby and suspend to ram. It seems to come out of standby almost immediately and never come out of suspend to ram. Running hibernate-ram -n works fine, but when running it without -n it actually suspends to RAM, hdd spins down, network goes down, CPU fans stop and the power led turns red (instead of the normal blue - this is in accordance with what I've seen with Windows).

When it's time again to resume however, it just does nothing and I need to power-cycle the machine to get it usable again.

Hi

Quoted 14 lines

I'm having some trouble with suspend/resume on my Toshiba Satellite P10 and was wondering whether anybody would be able to assist.

The omnibook module makes some functionality (like the multimedia keys, temperature readings, LCD and FAN adjustments) available. It however does not help with suspend/resume at all.

It seems like the notebook only supports standby and suspend to ram. It seems to come out of standby almost immediately and never come out of suspend to ram. Running hibernate-ram -n works fine, but when running it without -n it actually suspends to RAM, hdd spins down, network goes down, CPU fans stop and the power led turns red (instead of the normal blue - this is in accordance with what I've seen with Windows).

Quoted 2 lines

When it's time again to resume however, it just does nothing and I need to power-cycle the machine to get it usable again.

P10... is it that beast with pentium4 and hyperthreading? Dual cpu fans?

That worked for me. See Doc*/power/video.txt. Yep, that one works with right config. Get swsusp working, first. Then you can debug s2ram.

Quoted 10 lines · Pavel Machek

Quoted 7 lines

I'm having some trouble with suspend/resume on my Toshiba Satellite P10 and was wondering whether anybody would be able to assist.

The omnibook module makes some functionality (like the multimedia keys, temperature readings, LCD and FAN adjustments) available. It however does not help with suspend/resume at all.

It seems like the notebook only supports standby and suspend to ram. It seems to come out of standby almost immediately and never come out of suspend to ram. Running hibernate-ram -n works fine, but when running it without -n it actually suspends to RAM, hdd spins down, network goes down, CPU fans stop and the power led turns red (instead of the normal blue - this is in accordance with what I've seen with Windows).

When it's time again to resume however, it just does nothing and I need to power-cycle the machine to get it usable again.

P10... is it that beast with pentium4 and hyperthreading? Dual cpu fans?

Quoted 2 lines

That worked for me. See Doc*/power/video.txt. Yep, that one works with right config. Get swsusp working, first. Then you can debug s2ram.

Holger, do you have any hints on recent kernels on the P10? I have not touched this beast (the right noun for this brick :-) for a long time.

Quoted 2 lines

Quoted 2 lines

P10... is it that beast with pentium4 and hyperthreading? Dual cpu fans?

P4 - not HT though (not afaik anyway - or for a change I was blind - running without HT anyway).

Quoted 2 lines

Quoted 2 lines

That worked for me. See Doc*/power/video.txt. Yep, that one works with right config. Get swsusp working, first. Then you can debug s2ram.

Ah. I missed those options. Those might well solve a few things. Can't reboot atm (At the work and processor is working overtime at the moment). Also, they mention fesafb - will switch that off for the while being just to first get the basic stuff working, then try to re-add that. Don't know whether that will be possible.

I also assume it's at this time impossible to use fglrx with resume/suspend?

P4 - not HT though (not afaik anyway - or for a change I was blind - running without HT anyway).

I also assume it's at this time impossible to use fglrx with resume/suspend?

"The beast" specs and what I've done (and gotten working) so far is available at http://www.kroon.co.za/howto.php?howto=toshiba_p10.

With regards to the ACPI code though - I've managed to fix all the warnings and errors, except the one about the ResourceSource error, which according to the spec is optional but iasl insists it's required.
No idea what I'm going to do about that. Also not sure whether fixing
_WAK to always return a value will actually do something.

Notice: This message and any attachments are confidential and intended solely for the addressee. If you have received this message in error, please notify the sender by email or by phone to the listed number. Any unauthorised use, alteration or dissemination is prohibited. CSS Tirisano (Pty) Ltd accepts no liability for any direct, indirect or consequential loss or damages, arising from the contents of this message.

Quoted 1 line · Jaco Kroon

P4 - not HT though (not afaik anyway - or for a change I was blind - running without HT anyway).

it looks like you have a very different P10 than the one we have...

Quoted 1 line

I also assume it's at this time impossible to use fglrx with resume/suspend?

...because ours has a NVidia graphics card.

Quoted 1 line

With regards to the ACPI code though - I've managed to fix all the warnings and errors, except the one about the ResourceSource error, which according to the spec is optional but iasl insists it's required. No idea what I'm going to do about that. Also not sure whether fixing _WAK to always return a value will actually do something.

I do not remember that i would have to fix any DSDT bugs, everything worked with the original DSDT.

But it is some time ago that i did use this machine, and due to its tremendously huge footprint and very heavy weight, i just used it as a Workstation, so not very frequent. Also the dual turbines did their
share that it was turned off most of the time :-))

Quoted 1 line

Notice: This message and any attachments are confidential and intended solely for the addressee. If you have received this message in error, please notify the sender by email or by phone to the listed number. Any unauthorised use, alteration or dissemination is prohibited. CSS Tirisano (Pty) Ltd accepts no liability for any direct, indirect or consequential loss or damages, arising from the contents of this message.

OMG! i hope i'm not going to jail now ;-)

Quoted 6 lines

Quoted 5 lines

With regards to the ACPI code though - I've managed to fix all the warnings and errors, except the one about the ResourceSource error, which according to the spec is optional but iasl insists it's required. No idea what I'm going to do about that. Also not sure whether fixing _WAK to always return a value will actually do something.

Quoted 2 lines

I do not remember that i would have to fix any DSDT bugs, everything worked with the original DSDT.

There is only really one error that bothers me, and I read somewhere that the kernel doesn't look at it's value, and that is the _WAK call that doesn't return a value. Unless that of course changed recently. And I can't recompile the DSDT due to those ResourceSource required errors, which seems to be a bug in iasl.

I still haven't managed to finish of the resume process. The screen comes back up and console switching works but that is just about where it ends. I don't see any kernel panic messages either. Will RTFM and fool around some more.

Hi!

Quoted 9 lines

Quoted 8 lines

Quoted 5 lines

With regards to the ACPI code though - I've managed to fix all the warnings and errors, except the one about the ResourceSource error, which according to the spec is optional but iasl insists it's required. No idea what I'm going to do about that. Also not sure whether fixing _WAK to always return a value will actually do something.

I do not remember that i would have to fix any DSDT bugs, everything worked with the original DSDT.

Quoted 5 lines

There is only really one error that bothers me, and I read somewhere that the kernel doesn't look at it's value, and that is the _WAK call that doesn't return a value. Unless that of course changed recently. And I can't recompile the DSDT due to those ResourceSource required errors, which seems to be a bug in iasl.

Fix iasl, then ;-).

Quoted 4 lines

I still haven't managed to finish of the resume process. The screen comes back up and console switching works but that is just about where it ends. I don't see any kernel panic messages either. Will RTFM and fool around some more.

RTFM will not help you here, I'm afraid. Try it with minimal kernel config.

Quoted 7 lines

Quoted 4 lines

I still haven't managed to finish of the resume process. The screen comes back up and console switching works but that is just about where it ends. I don't see any kernel panic messages either. Will RTFM and fool around some more.

RTFM will not help you here, I'm afraid. Try it with minimal kernel config.

Ok, that sucks. This is what I get, one some VT that is not reachable with Alt+Fx, I get this:

inu
Back to C!
ACPI: PCI Interrupt 0000:00:14.1[A] -> GSI 16 (level, low) -> IRQ 177

The inu is in yellow and I presume forms part of the word "Linux". I get this screen when it comes back, from here I can switch to all twelfe VTs with Alt+Fx, and back to this screen with Alt+right from tty1.

On tty1 I can type, but that is the only VT. This is also the VT I run hibernate-ram from. Auto-repeat however does not function. The same applies when running "echo mem > /sys/power/state"

When running hibernate it doesn't power down! This seems odd since powerdown works when going "init 0". Anyhow, the last messages I see is this:

Freezing processes
Preparing Image.
Starting to save the image..
Writing caches...
Doing atormic copy.
Writing kernel & process data...

And that is where it all stops.

But try _minimal config_, first.

Quoted 1 line

And that is where it all stops.

See Doc*/power/swsusp.txt. suspend to disk should be easier to fix.

Quoted 1 line

But try _minimal config_, first.

Doesn't include CONFIG_NET imho, but kernel/power/ui.h (part of suspend2?) doesn't compile without it. I can probably write a patch, the problem seems to be that ui_helper_data only gets declared if CONFIG_NET is set, but it gets used elsewhere even if CONFIG_NET is not set.

Setting CONFIG_NET works around this problem.

With almost nothing in the kernel though (only what is essential to make it boot) suspend-to-ram works. Still suspend-to-disk though.

Guess it's time to go find the module that causes the problem and fix it (if I can figure it out).

Hi!

Quoted 7 lines

Quoted 1 line

But try _minimal config_, first.

Doesn't include CONFIG_NET imho, but kernel/power/ui.h (part of suspend2?) doesn't compile without it. I can probably write a patch, the problem seems to be that ui_helper_data only gets declared if CONFIG_NET is set, but it gets used elsewhere even if CONFIG_NET is not set.

You did not tell me your kernel contains suspend2. Revert those patches. In-kernel code tends to have less bells/whistles, but seems more reliable to me. (And it is the only one I can help you with.)

Quoted 7 lines

Setting CONFIG_NET works around this problem.

With almost nothing in the kernel though (only what is essential to make it boot) suspend-to-ram works. Still suspend-to-disk though.

Guess it's time to go find the module that causes the problem and fix it (if I can figure it out).

Yep ;-). Keep us updated with name of offending module.

... and I didn't get the rest cause as soon as I accidentally pressed a key it powered down ...

It halted directly after "Shutting down hda" (can't remember the exact message). Powering up resuming worked just fine. Including issues I had with suspend-to-ram (described below).

This happened at least twice. Having to hit some key to make it go away is probably not the biggest issue I've had in my life, I guess if need be I can live with that.

This feels like a post-wakeup racecondition to me... Disabling the big kernel lock preemption think again... yes, seems to be working better now. Suspending to ram and then to disk still fails. (resume from mem works, can do make menuconfig - a few times - and then it starts suspend-to-disk process and then just hangs).

If I posted my DSDT, could you possibly take a look? It seems that the compiler error message doesn't mean what it says. Under certain conditions it will complain if a certain string is set but some index is not. And I don't know enough with regards to DSL to be able to spot the errors.

Hi!

Quoted 3 lines

... and I didn't get the rest cause as soon as I accidentally pressed a key it powered down ...

Quoted 3 lines

It halted directly after "Shutting down hda" (can't remember the exact message). Powering up resuming worked just fine. Including issues I had with suspend-to-ram (described below).

Okay, what *other* patches do you have installed? What kernel are you running? 2.6.15-rc6?

Quoted 3 lines

This happened at least twice. Having to hit some key to make it go away is probably not the biggest issue I've had in my life, I guess if need be I can live with that.

I have seen that before with acpi vgapost or something like that... Strange. Can you insert printks to find out what is going on?

Quoted 5 lines

This feels like a post-wakeup racecondition to me... Disabling the big kernel lock preemption think again... yes, seems to be working better now. Suspending to ram and then to disk still fails. (resume from mem works, can do make menuconfig - a few times - and then it starts suspend-to-disk process and then just hangs).

So... there's no module to blame? I do have CONFIG_PREEMPT=y and CONFIG_PREEMPT_BKL=y set here, but there were some problems with those before, so keeping it disabled may be wise.

Ouch and now that suspend-to-ram more or less works for you, can you submit update to Doc*/power/video.txt?

Quoted 5 lines

If I posted my DSDT, could you possibly take a look? It seems that the compiler error message doesn't mean what it says. Under certain conditions it will complain if a certain string is set but some index is not. And I don't know enough with regards to DSL to be able to spot the errors.

I'm not DSDT expert, sorry. (And problem is probably not in DSDT anyway).

Quoted 2 lines

Okay, what *other* patches do you have installed? What kernel are you running? 2.6.15-rc6?

I'm trying with 2.6.14.3, but I've got 2.6.15rc5 available here (can always get the VI patch to rc6). Was intending to run the acpi_include patch, but since that is a standard option in 2.6.14.x I never actually pulled in that patch, so no other patches and I've backed out suspend2 now. Will also give 15rc6 a go in the morning.

Quoted 6 lines

Quoted 5 lines

This feels like a post-wakeup racecondition to me... Disabling the big kernel lock preemption think again... yes, seems to be working better now. Suspending to ram and then to disk still fails. (resume from mem works, can do make menuconfig - a few times - and then it starts suspend-to-disk process and then just hangs).

Quoted 3 lines

So... there's no module to blame? I do have CONFIG_PREEMPT=y and CONFIG_PREEMPT_BKL=y set here, but there were some problems with those before, so keeping it disabled may be wise.

I've also found that I forgot to disable registers. Neither made a difference though.

Quoted 2 lines

Ouch and now that suspend-to-ram more or less works for you, can you submit update to Doc*/power/video.txt?

Will do if I get it working. more-or-less is simply not good enough (or should I just make a note there?).

Hi!

Quoted 3 lines

Quoted 2 lines

Okay, what *other* patches do you have installed? What kernel are you running? 2.6.15-rc6?

Quoted 5 lines

I'm trying with 2.6.14.3, but I've got 2.6.15rc5 available here (can always get the VI patch to rc6). Was intending to run the acpi_include patch, but since that is a standard option in 2.6.14.x I never actually pulled in that patch, so no other patches and I've backed out suspend2 now. Will also give 15rc6 a go in the morning.

rc5 should be good enough.

Quoted 6 lines

Quoted 6 lines

Quoted 5 lines

This feels like a post-wakeup racecondition to me... Disabling the big kernel lock preemption think again... yes, seems to be working better now. Suspending to ram and then to disk still fails. (resume from mem works, can do make menuconfig - a few times - and then it starts suspend-to-disk process and then just hangs).

Quoted 6 lines

Quoted 3 lines

So... there's no module to blame? I do have CONFIG_PREEMPT=y and CONFIG_PREEMPT_BKL=y set here, but there were some problems with those before, so keeping it disabled may be wise.

I've also found that I forgot to disable registers. Neither made a difference though.

CONFIG_REGPARM?

Quoted 5 lines

Quoted 2 lines

Ouch and now that suspend-to-ram more or less works for you, can you submit update to Doc*/power/video.txt?

Will do if I get it working. more-or-less is simply not good enough (or should I just make a note there?).

It is good enough for video.txt. It describes how to get _video_ working, and video works just ok for you.

Quoted 1 line · Pavel Machek

rc5 should be good enough.

Same problem. SysRq+T reveals that the newly spawned process is getting stuck in:

ide_do_request+0x18a/0x3c5
io_schedule+0xe/0x16
sync_page+0x3e/0x4b
__wait_on_bit_lock+0x41/0x61
sync_page+0x0/0x4b
__lock_page+0x9d/0xb1
wake_bit_function+0x0/0x55
wake_bit_function+0x0/0x55
do_generic_mapping_read+0x335/0x7fd
__generic_file_aio_read+0x19d/0x203
file_read_actor+0x0/0xfa

generic_file_read+0xba/0xd8
autoremove_wake_function+0x0/0x57
vfs_read+0x1a5/0x1aa
kernel_read+0x50/0x5f
prepare_binprm+0xd8/0x103
do_execve+0xfe/0x203
sys_execve+0x3c/0x6f
sysenter_past_esp+0x54/0x75

Quoted 18 lines · Jaco Kroon

Quoted 1 line · Pavel Machek

rc5 should be good enough.

Same problem. SysRq+T reveals that the newly spawned process is getting stuck in:

ide_do_request+0x18a/0x3c5
io_schedule+0xe/0x16
sync_page+0x3e/0x4b
__wait_on_bit_lock+0x41/0x61
sync_page+0x0/0x4b
__lock_page+0x9d/0xb1
wake_bit_function+0x0/0x55
wake_bit_function+0x0/0x55
do_generic_mapping_read+0x335/0x7fd
__generic_file_aio_read+0x19d/0x203
file_read_actor+0x0/0xfa

Quoted 8 lines

generic_file_read+0xba/0xd8
autoremove_wake_function+0x0/0x57
vfs_read+0x1a5/0x1aa
kernel_read+0x50/0x5f
prepare_binprm+0xd8/0x103
do_execve+0xfe/0x203
sys_execve+0x3c/0x6f
sysenter_past_esp+0x54/0x75

To my untrained eye this looks like an IDE suspend / resume problem. Maybe another machine that needs those ACPI methods for the IDE drives badly :-(

Quoted 5 lines · Stefan Seyfried

Quoted 5 lines

Same problem. SysRq+T reveals that the newly spawned process is getting stuck in:

ide_do_request+0x18a/0x3c5
io_schedule+0xe/0x16

Quoted 3 lines

To my untrained eye this looks like an IDE suspend / resume problem. Maybe another machine that needs those ACPI methods for the IDE drives badly :-(

To mine as well. _WAK? Some other methods? I'm posting my DSDT at
http://www.kroon.co.za/downloads/toshiba_p10-792/ now. If somebody else can take a look it just might reveal something I'm missing.

Damn. I just thought I solved it. I disabled the APIC and tried again.
This time round I managed to re-enable APIC in the kernel source
(without IO-APIC) and _recompile_ it entirely. Only upon issueing "make install modules_install" did it pop.

Sequence was something like:

echo mem > /sys/power/state
cd /usr/src/linux
make menuconfig
make menuconfig
echo mem > /sys/power/state
make menuconfig
--> re-enable APIC but not IO-APIC
make
make install modules_install
->> pop. When copying the image from the source directory to /boot.

This is beginning to sound more and more like some obscure race-condition if you ask me.

Hi!

Quoted 18 lines

Damn. I just thought I solved it. I disabled the APIC and tried again. This time round I managed to re-enable APIC in the kernel source (without IO-APIC) and _recompile_ it entirely. Only upon issueing "make install modules_install" did it pop.

Sequence was something like:

echo mem > /sys/power/state
cd /usr/src/linux
make menuconfig
make menuconfig
echo mem > /sys/power/state
make menuconfig
--> re-enable APIC but not IO-APIC
make
make install modules_install
->> pop. When copying the image from the source directory to /boot.

Quoted 2 lines

This is beginning to sound more and more like some obscure race-condition if you ask me.

I would be surprised if that was the case. Are you sure it is not just "disk does not work after resume", and depending of stuff in cache, it fails at random places?

ide_do_request+0x18a/0x3c5
io_schedule+0xe/0x16
sync_page+0x3e/0x4b
__wait_on_bit_lock+0x41/0x61
sync_page+0x0/0x4b
__lock_page+0x9d/0xb1
wake_bit_function+0x0/0x55
wake_bit_function+0x0/0x55
do_generic_mapping_read+0x335/0x7fd
__generic_file_aio_read+0x19d/0x203
file_read_actor+0x0/0xfa
generic_file_read+0xba/0xd8
autoremove_wake_function+0x0/0x57
vfs_read+0x1a5/0x1aa
kernel_read+0x50/0x5f
prepare_binprm+0xd8/0x103
do_execve+0xfe/0x203
sys_execve+0x3c/0x6f
sysenter_past_esp+0x54/0x75

Second run round the first command I issued worked fine, as did cd to /usr/src/linux, but running make menuconfig failed. This time the stack trace was considerably longer (I'm not going to type that over). The top two calls are the same, but it comes in from sync_buffer, __wait_on_bit, sync_buffer, sync_buffer, out_of_line_wait_on_bit, wake_bit_function, wakebit_function, and so forth. A quick scan of the VI between rc5 and rc6 doesn't reveal any changes that could possibly affect this (I'm going to patch to rc6 in any case).

Quoted 20 lines · Jaco Kroon

ide_do_request+0x18a/0x3c5
io_schedule+0xe/0x16
sync_page+0x3e/0x4b
__wait_on_bit_lock+0x41/0x61
sync_page+0x0/0x4b
__lock_page+0x9d/0xb1
wake_bit_function+0x0/0x55
wake_bit_function+0x0/0x55
do_generic_mapping_read+0x335/0x7fd
__generic_file_aio_read+0x19d/0x203
file_read_actor+0x0/0xfa
generic_file_read+0xba/0xd8
autoremove_wake_function+0x0/0x57
vfs_read+0x1a5/0x1aa
kernel_read+0x50/0x5f
prepare_binprm+0xd8/0x103
do_execve+0xfe/0x203
sys_execve+0x3c/0x6f
sysenter_past_esp+0x54/0x75

Quoted 8 lines

Second run round the first command I issued worked fine, as did cd to /usr/src/linux, but running make menuconfig failed. This time the stack trace was considerably longer (I'm not going to type that over). The top two calls are the same, but it comes in from sync_buffer, __wait_on_bit, sync_buffer, sync_buffer, out_of_line_wait_on_bit, wake_bit_function, wakebit_function, and so forth. A quick scan of the VI between rc5 and rc6 doesn't reveal any changes that could possibly affect this (I'm going to patch to rc6 in any case).

I have a Vaio which has the same ide problem (at least I think so):
after resume, all processes wishing to access the disk hang, dmesg shows lots of "hda: lost interrupt" messages. However, doing a "hdparm -w /dev/hda" after resume makes everything work again.

From the man page:

Quoted 8 lines

I have a Vaio which has the same ide problem (at least I think so):
after resume, all processes wishing to access the disk hang, dmesg shows lots of "hda: lost interrupt" messages. However, doing a "hdparm -w /dev/hda" after resume makes everything work again.

From the man page:

-w Perform a device reset (DANGEROUS). Do NOT use this
option. It
exists for unlikely situations where a reboot might
otherwise be
required to get a confused drive back into a useable state.

Ok. I don't have really important data on the notebook atm (all backed up for obvious reasons). So I gave this a try. It causes the kernel to crash entirely. No more SysRq. No OOPS. Nothing. It outputs a single string namely "/dev/hda:" and then dies.

Hi!

Quoted 15 lines

Quoted 8 lines

I have a Vaio which has the same ide problem (at least I think so):
after resume, all processes wishing to access the disk hang, dmesg shows lots of "hda: lost interrupt" messages. However, doing a "hdparm -w /dev/hda" after resume makes everything work again.

From the man page:

-w Perform a device reset (DANGEROUS). Do NOT use this
option. It
exists for unlikely situations where a reboot might
otherwise be
required to get a confused drive back into a useable state.

Quoted 4 lines

Ok. I don't have really important data on the notebook atm (all backed up for obvious reasons). So I gave this a try. It causes the kernel to crash entirely. No more SysRq. No OOPS. Nothing. It outputs a single string namely "/dev/hda:" and then dies.

Try verifying that your interrupts work after resume. (I assume we are still talking suspend-to-RAM here, and that you got suspend-to-disk to more or less work?) Do cat /proc/interrupts; sleep 10; cat /proc/interrupts both before and after suspend.

I presume you're looking for ide0 and ide1 interrupts, yes, after suspending to ram twice the command showed that interrupt 14 (ide0) increased from 994 to 1011 and for 15 (ide1) it stayed at 24. My hdd is on hda so that'll be on ide0, dvd-rw is on hdc or ide1.

The interrupt counts for cascade (irq 2), rtc (irq 8) and acpi (irq 9) stayed constant though, at 0, 2 and 4 respectively.

No NMI or ERR conditions were ever signaled.

Now, with APIC, but no IO-APIC there is a bug notice during resume. Going to type it over (from dmesg):

Back to C!
Debug: sleeping function called from invalid context at mm/slab.c:2472 in_atomic():0, irqs_disabled():1

 __might_sleep+0x9e/0xa6
 acpi_os_allocate+0x15/0x26
 kmem_cache_alloc+0x95/0xad
 acpi_ut_callocate+0x37/0x79

ACPI: PCI Interrupt 0000:00:14.1[A] -> Link [LNK0] -> GSI 11 (level, low) -> IRQ 11
ACPI: PCI Interrupt 0000:02:04.0[A] -> Link [LNK0] -> GSI 11 (level, low) -> IRQ 11
Restarting tasks... done

Both cases looks identical. /proc/interrupts doesn't list 11 as an interrupt ?!?

Also, this time round the auto-repeat on the keys is working again after resume. In fact, everything seems to be working. Just that debug stacktrace that bothers me. Oh, and my console blanking time also seems to get lost but I can fix that with the help of echo and /dev/tty*.

Anyhow, suspended twice to ram now in succession, make cleaned and rebuilt the kernel, installed it, and the only thing that even suggests there is a glitch is that trace.

Looks like I need APIC on and IO-APIC off. Any explanations very
welcome: and don't tell me the IO-APIC is buggy - I've been running with both those options on for as long as I've had this notebook now.

Quoted 10 lines

Now, with APIC, but no IO-APIC there is a bug notice during resume. Going to type it over (from dmesg):

Back to C!
Debug: sleeping function called from invalid context at mm/slab.c:2472 in_atomic():0, irqs_disabled():1

__might_sleep+0x9e/0xa6
acpi_os_allocate+0x15/0x26
kmem_cache_alloc+0x95/0xad
acpi_ut_callocate+0x37/0x79

I know, it is scary, but it is also known and harmless. You can ignore this one.

Quoted 8 lines

ACPI: PCI Interrupt 0000:00:14.1[A] -> Link [LNK0] -> GSI 11 (level, low) -> IRQ 11
ACPI: PCI Interrupt 0000:02:04.0[A] -> Link [LNK0] -> GSI 11 (level, low) -> IRQ 11
Restarting tasks... done

Both cases looks identical. /proc/interrupts doesn't list 11 as an interrupt ?!?

Talk to acpi people about that.

Quoted 7 lines

Anyhow, suspended twice to ram now in succession, make cleaned and rebuilt the kernel, installed it, and the only thing that even suggests there is a glitch is that trace.

Looks like I need APIC on and IO-APIC off. Any explanations very
welcome: and don't tell me the IO-APIC is buggy - I've been running with both those options on for as long as I've had this notebook now.

I do not know enough explanations, feel free to investigate.

Anyway so both suspend-to-ram and suspend-to-disk now works for you, right? No need to press keys to make it write image on disk?

Oh and thanks for video.txt diff, applied.

Quoted 11 lines · Pavel Machek

Quoted 10 lines

Now, with APIC, but no IO-APIC there is a bug notice during resume. Going to type it over (from dmesg):

Back to C!
Debug: sleeping function called from invalid context at mm/slab.c:2472 in_atomic():0, irqs_disabled():1

__might_sleep+0x9e/0xa6
acpi_os_allocate+0x15/0x26
kmem_cache_alloc+0x95/0xad
acpi_ut_callocate+0x37/0x79

Quoted 2 lines

I know, it is scary, but it is also known and harmless. You can ignore this one.

Now _that_ made me raise an eyebrow. Even more than the fact that my DSDT insists on checking for the version of Microsoft Windows I'm running!

Not right now. The festive season awaits (yay ...). So in that spirit, Merry Christmas and a Happy New Year!

Quoted 1 line

Oh and thanks for video.txt diff, applied.

Shees. That is my second accepted patch in a week. Also my first two accepted patches. LOL. Hopefully there will be more to come. Now I

Quoted 15 lines · Jaco Kroon

Quoted 13 lines · Pavel Machek

Quoted 10 lines

Now, with APIC, but no IO-APIC there is a bug notice during resume. Going to type it over (from dmesg):

Back to C!
Debug: sleeping function called from invalid context at mm/slab.c:2472 in_atomic():0, irqs_disabled():1

__might_sleep+0x9e/0xa6
acpi_os_allocate+0x15/0x26
kmem_cache_alloc+0x95/0xad
acpi_ut_callocate+0x37/0x79

I know, it is scary, but it is also known and harmless. You can ignore this one.

Quoted 3 lines

Now _that_ made me raise an eyebrow. Even more than the fact that my DSDT insists on checking for the version of Microsoft Windows I'm running!

See archives. Len even had a fix at some point, but it was too ugly IIRC.

New weird error. This may also be harmless though. Just first a few notes, I'm back onto 2.6.14.3 kernel (fglrx doesn't work with 2.6.15-rc?
- it just crashes the whole system), and I really need that.

With fglrx I can suspend to disk and resume. However, I can't suspend-to-ram. Well, suspend works and it comes back up fine but as soon as I switch back to X it hard-crashes the machine. Now, I'm currently between resume and switching to X, and the last few lines from dmesg looks as follows:

Restarting tasks... done
ACPI-0284: *** Error: Region EmbeddedController(3) has no handler
ACPI-0508: *** Error: Method execution failed [\_SB_.EPWR.PCLK]
(Node c14d3200), AE_NOT_EXIST
ACPI-0508: *** Error: Method execution failed
[\_SB_.CPI0.LPC0.EC0_._Q1E] (Node c14ceee0), AE_NOT_EXIST

Now I have a very weird feeling down in my gut that I did not see this before and it's probably due to the fglrx module in my kernel. And interrupt 11, btw, is for the screen (it gets shown now in /proc/interrupts after I restored most of my kernel).

Now, initially when I switch back to X I get the correct image on the bottom third of the screen with the top two thirds seemingly corrupted.
This is pretty normal and is identical to what I normally see when
switching between consoles and X. This lasts for about half a second before it freezes up and causes a hard-lock. Normally the screen just resets itself at the time it now locks up.

Hi!

I'm sorry, there's no way we can help you with fglrx. I'm glad at least s-t-disk works.
Pavel

Quoted 6 lines

Now, initially when I switch back to X I get the correct image on the bottom third of the screen with the top two thirds seemingly corrupted. This is pretty normal and is identical to what I normally see when switching between consoles and X. This lasts for about half a second before it freezes up and causes a hard-lock. Normally the screen just resets itself at the time it now locks up.

I'm sorry, there's no way we can help you with fglrx. I'm glad at least s-t-disk works.

Quoted 10 lines

Quoted 8 lines

Quoted 2 lines

Okay, what *other* patches do you have installed? What kernel are you running? 2.6.15-rc6?

I'm trying with 2.6.14.3, but I've got 2.6.15rc5 available here (can always get the VI patch to rc6). Was intending to run the acpi_include patch, but since that is a standard option in 2.6.14.x I never actually pulled in that patch, so no other patches and I've backed out suspend2 now. Will also give 15rc6 a go in the morning.

rc5 should be good enough.

Same problem. SysRq+T reveals that the newly spawned process is getting stuck in:

ide_do_request+0x18a/0x3c5
io_schedule+0xe/0x16
sync_page+0x3e/0x4b
__wait_on_bit_lock+0x41/0x61
sync_page+0x0/0x4b
__lock_page+0x9d/0xb1
wake_bit_function+0x0/0x55
wake_bit_function+0x0/0x55
do_generic_mapping_read+0x335/0x7fd
__generic_file_aio_read+0x19d/0x203
file_read_actor+0x0/0xfa
generic_file_read+0xba/0xd8
autoremove_wake_function+0x0/0x57
vfs_read+0x1a5/0x1aa
kernel_read+0x50/0x5f
prepare_binprm+0xd8/0x103
do_execve+0xfe/0x203
sys_execve+0x3c/0x6f
sysenter_past_esp+0x54/0x75

Second run round the first command I issued worked fine, as did cd to /usr/src/linux, but running make menuconfig failed. This time the stack trace was considerably longer (I'm not going to type that over). The top two calls are the same, but it comes in from sync_buffer, __wait_on_bit, sync_buffer, sync_buffer, out_of_line_wait_on_bit, wake_bit_function, wakebit_function, and so forth. A quick scan of the VI between rc5 and rc6 doesn't reveal any changes that could possibly affect this (I'm going to patch to rc6 in any case).

Could it be a bug in reiserfs? I have run a fsck but no errors were found, so I presume the fs is still in tact.

Quoted 5 lines

Quoted 2 lines

Will do if I get it working. more-or-less is simply not good enough (or should I just make a note there?).

It is good enough for video.txt. It describes how to get _video_ working, and video works just ok for you.

You should have received the patch.

Hi!

Quoted 43 lines

Quoted 10 lines

Quoted 8 lines

Quoted 2 lines

Okay, what *other* patches do you have installed? What kernel are you running? 2.6.15-rc6?

I'm trying with 2.6.14.3, but I've got 2.6.15rc5 available here (can always get the VI patch to rc6). Was intending to run the acpi_include patch, but since that is a standard option in 2.6.14.x I never actually pulled in that patch, so no other patches and I've backed out suspend2 now. Will also give 15rc6 a go in the morning.

rc5 should be good enough.

Same problem. SysRq+T reveals that the newly spawned process is getting stuck in:

ide_do_request+0x18a/0x3c5
io_schedule+0xe/0x16
sync_page+0x3e/0x4b
__wait_on_bit_lock+0x41/0x61
sync_page+0x0/0x4b
__lock_page+0x9d/0xb1
wake_bit_function+0x0/0x55
wake_bit_function+0x0/0x55
do_generic_mapping_read+0x335/0x7fd
__generic_file_aio_read+0x19d/0x203
file_read_actor+0x0/0xfa
generic_file_read+0xba/0xd8
autoremove_wake_function+0x0/0x57
vfs_read+0x1a5/0x1aa
kernel_read+0x50/0x5f
prepare_binprm+0xd8/0x103
do_execve+0xfe/0x203
sys_execve+0x3c/0x6f
sysenter_past_esp+0x54/0x75

Second run round the first command I issued worked fine, as did cd to /usr/src/linux, but running make menuconfig failed. This time the stack trace was considerably longer (I'm not going to type that over). The top two calls are the same, but it comes in from sync_buffer, __wait_on_bit, sync_buffer, sync_buffer, out_of_line_wait_on_bit, wake_bit_function, wakebit_function, and so forth. A quick scan of the VI between rc5 and rc6 doesn't reveal any changes that could possibly affect this (I'm going to patch to rc6 in any case).

Quoted 2 lines

Could it be a bug in reiserfs? I have run a fsck but no errors were found, so I presume the fs is still in tact.

Seife is right, this looks like an ide problem. And the fact that autorepeat does not work for you may mean something bad with interrupts. Can you try "noapic"?

Quoted 7 lines

Quoted 5 lines

Quoted 2 lines

Will do if I get it working. more-or-less is simply not good enough (or should I just make a note there?).

It is good enough for video.txt. It describes how to get _video_ working, and video works just ok for you.

You should have received the patch.

I don't see it here. Can you just attach it to this discussion? It should be small enough...

Quoted 1 line · Stefan Seyfried

On Thu, Dec 22, 2005 at 03:59:26PM +0200, Jaco Kroon wrote:

LOL! I wish. fglrx is the ati binary drivers (as asked in the response from Pavel). According to another friend of mine the answer to this one is no. He can suspend/resume his notebook as long as he's using the opensource radeon driver and not fglrx. He's not using a P10 though.

LOL! I wish. fglrx is the ati binary drivers (as asked in the response from Pavel). According to another friend of mine the answer to this one is no. He can suspend/resume his notebook as long as he's using the opensource radeon driver and not fglrx. He's not using a P10 though.

Quoted 4 lines · Jaco Kroon

LOL! I wish. fglrx is the ati binary drivers (as asked in the response from Pavel). According to another friend of mine the answer to this one is no. He can suspend/resume his notebook as long as he's using the opensource radeon driver and not fglrx. He's not using a P10 though.

The latest fglrx should support suspend/resume. I don't think any distributions include it yet, so you'll have to get it from ati.com.

Quoted 19 lines · Pavel Machek

Hi

Quoted 16 lines

I'm having some trouble with suspend/resume on my Toshiba Satellite P10 and was wondering whether anybody would be able to assist.

The omnibook module makes some functionality (like the multimedia keys, temperature readings, LCD and FAN adjustments) available. It however does not help with suspend/resume at all.

It seems like the notebook only supports standby and suspend to ram. It seems to come out of standby almost immediately and never come out of suspend to ram. Running hibernate-ram -n works fine, but when running it without -n it actually suspends to RAM, hdd spins down, network goes down, CPU fans stop and the power led turns red (instead of the normal blue - this is in accordance with what I've seen with Windows).

When it's time again to resume however, it just does nothing and I need to power-cycle the machine to get it usable again.

Quoted 5 lines

P10... is it that beast with pentium4 and hyperthreading? Dual cpu fans?

That worked for me. See Doc*/power/video.txt. Yep, that one works with right config. Get swsusp working, first. Then you can debug s2ram.

Holger, do you have any hints on recent kernels on the P10? I have not touched this beast (the right noun for this brick :-) for a long time.

Tested with 2.6.14 kernels without hyperthreading and both suspend to disk and suspend to ram are working when using acpi_sleep=s3_bios,s3_mode at the boot prompt. Though, with smp kernels and hyperthreading enabled, both are not working (video.txt already contains this information).

Regards,
Holger