From: Jaco K. <ja...@cs...> - 2005-12-21 06:44:07
|
Hello all, 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. I've proceeded to make a copy of /proc/acpi/dsdt into ~/dsdt.dat and decompiled that using iasl. Upon recompiling (without making modifications) this rendered 17 errors and 3 warnings. One of the warnings being about _WAK not returning a value - which I've changed to always return a packet containing two zeroes (not a fix but rather a workaround). There were also some access errors where changing AnyAcc to ByteAcc solved 3 of the errors. I unfortunately have no idea how to solve the other errors, most of which are 'Error 1094 - Missing ResourceSource string (required)'. I've read somewhere that these strings are in fact optional. Is this a bug in the iasl compiler? An example of such a block: DWordMemory (ResourceProducer, SubDecode, MinFixed, MaxFixed, NonCacheable, ReadWrite, 0x00000000, // Address Space Granularity 0x000A0000, // Address Range Minimum 0x000BFFFF, // Address Range Maximum 0x00000000, // Address Translation Offset 0x00020000, 0x00,, , AddressRangeMemory, TypeStatic) This is inside a block ' Name (RSRC, ResourceTemplate () { ... many of the above blocks here }) I suspect this is resource specifications, in this particular case, the VGA BIOS video memory used by vesa if I'm not mistaken. The other error that I receive is 'Error 1013 - Method local variable is not initialized (Local1)'. In this case I guess I can just initialize it to 0 and get it over with? There are also two warnings 'Warning 2019 - Not all control paths return a value' for methods SLLB and PBGU. Looking at these methods they indeed look dodgy. The SLLB function looks like: Method (SLLB, 1, NotSerialized) { Store (Arg0, Local0) And (Local0, 0xFF, Local0) If (LLess (Arg0, 0x0100)) { Return (Z00B) } Else { Store (Local0, Z00B) } } This means that when SLLB gets called with an argument less that 0x0100 then a value will be returned, but if not we store the value passed in the argument anded with 0xFF. For optimization - shouldn't this calculation be moved into the Else part, also, should both cases return Z00B, in which case the If can be rewritten to a > 0xFF and both Stores and the And inside that with the Return after the If. The second case is less clear: Method (PBGU, 1, NotSerialized) { If (LEqual (Arg0, 0x00)) { Return (BGU1) } If (LEqual (Arg0, 0x01)) { Return (Z00C) } If (LEqual (Arg0, 0x02)) { Store (0x00, ZOOC) Return (Z00C) } } This case is less clear. If we can assume that values will always be in the range [0-2] then it's possible to simply remove the last If statement and just put it's contents there. Any and all advice appreciated. I could not locate these methods in the ACPI spec so I'm suspecting that they are being used internally and does not form part of the ACPI spec. Thank, -- Jaco Kroon Support Engineer CSS TIRISANO Computer Systems (Pty) Ltd Tel: +27 12 621 3171 Fax: +27 12 661 4984 Cell: +27 84 515 8255 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. |
From: Pavel M. <pa...@uc...> - 2005-12-22 11:02:45
|
Hi > 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? 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. Pavel -- Thanks, Sharp! |
From: Stefan S. <se...@su...> - 2005-12-22 12:04:25
|
On Thu, Dec 22, 2005 at 12:02:19PM +0100, Pavel Machek wrote: > Hi >=20 > > I'm having some trouble with suspend/resume on my Toshiba Satellite P= 10=20 > > and was wondering whether anybody would be able to assist. > >=20 > > The omnibook module makes some functionality (like the multimedia key= s,=20 > > temperature readings, LCD and FAN adjustments) available. It however= =20 > > does not help with suspend/resume at all. > >=20 > > It seems like the notebook only supports standby and suspend to ram. = It=20 > > seems to come out of standby almost immediately and never come out of= =20 > > suspend to ram. Running hibernate-ram -n works fine, but when runnin= g=20 > > it without -n it actually suspends to RAM, hdd spins down, network go= es=20 > > down, CPU fans stop and the power led turns red (instead of the norma= l=20 > > blue - this is in accordance with what I've seen with Windows). > >=20 > > When it's time again to resume however, it just does nothing and I ne= ed=20 > > to power-cycle the machine to get it usable again. >=20 > P10... is it that beast with pentium4 and hyperthreading? Dual cpu > fans? >=20 > 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. --=20 Stefan Seyfried \ "I didn't want to write for pay. I QA / R&D Team Mobile Devices \ wanted to be paid for what I write." SUSE LINUX Products GmbH, N=FCrnberg \ -- Leonard Cohe= n |
From: Jaco K. <ja...@cs...> - 2005-12-22 14:00:03
|
Stefan Seyfried wrote: > On Thu, Dec 22, 2005 at 12:02:19PM +0100, Pavel Machek wrote: >>>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? P4 - not HT though (not afaik anyway - or for a change I was blind - running without HT anyway). >>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? > 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. "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. I do recall that booting with acpi=off caused the notebook to die in a similar fashion on reboot. Not sure what the cause is/was but it's working mostly now. Could be the same thing that causes both hangs. 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. Thanks, -- Jaco Kroon Support Engineer CSS TIRISANO Computer Systems (Pty) Ltd Tel: +27 12 621 3171 Fax: +27 12 661 4984 Cell: +27 84 515 8255 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. |
From: Pavel M. <pa...@su...> - 2005-12-22 14:26:41
|
Hi! > >>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). > > >>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? No idea, I did not play with fglrx (what is it anyway?) Pavel -- Thanks, Sharp! |
From: Stefan S. <se...@su...> - 2005-12-22 16:06:49
|
On Thu, Dec 22, 2005 at 03:59:26PM +0200, Jaco Kroon wrote: =20 > P4 - not HT though (not afaik anyway - or for a change I was blind -=20 > running without HT anyway). it looks like you have a very different P10 than the one we have... > I also assume it's at this time impossible to use fglrx with resume/sus= pend? ...because ours has a NVidia graphics card. > "The beast" specs and what I've done (and gotten working) so far is=20 > available at http://www.kroon.co.za/howto.php?howto=3Dtoshiba_p10. This sounds similar to ours, but we definitely have an NVidia card and a HT capable processor. > With regards to the ACPI code though - I've managed to fix all the=20 > warnings and errors, except the one about the ResourceSource error,=20 > which according to the spec is optional but iasl insists it's required.= =20 > No idea what I'm going to do about that. Also not sure whether fixing= =20 > _WAK to always return a value will actually do something. I do not remember that i would have to fix any DSDT bugs, everything work= ed with the original DSDT. But it is some time ago that i did use this machine, and due to its=20 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 :-)) =20 > Notice: This message and any attachments are confidential and intended=20 > solely for the addressee. If you have received this message in error,=20 > please notify the sender by email or by phone to the listed number. Any= =20 > unauthorised use, alteration or dissemination is prohibited. CSS=20 > Tirisano (Pty) Ltd accepts no liability for any direct, indirect or=20 > consequential loss or damages, arising from the contents of this messag= e. OMG! i hope i'm not going to jail now ;-) --=20 Stefan Seyfried \ "I didn't want to write for pay. I QA / R&D Team Mobile Devices \ wanted to be paid for what I write." SUSE LINUX Products GmbH, N=FCrnberg \ -- Leonard Cohe= n |
From: Jaco K. <ja...@cs...> - 2005-12-23 06:44:59
|
Stefan Seyfried wrote: > On Thu, Dec 22, 2005 at 03:59:26PM +0200, Jaco Kroon wrote: >>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... Similar but different yes. Mine is P10-772 (iirc), the one mentioned in the kernel specs is 5??. >>I also assume it's at this time impossible to use fglrx with resume/suspend? > > ...because ours has a NVidia graphics card. 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. >>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. 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. > 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 :-)) It's not _that_ heavy! But yes, it is rather noisy, but nothing compared to these air-conditioners we have here, or my graphics card in my desktop at home. >>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 ;-) Company policy. It sucks I know. The content of these messages is fortunately intented for any soul who is interrested. Thanks, -- Jaco Kroon Support Engineer CSS TIRISANO Computer Systems (Pty) Ltd Tel: +27 12 621 3171 Fax: +27 12 661 4984 Cell: +27 84 515 8255 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. |
From: Pavel M. <pa...@su...> - 2005-12-23 11:13:04
|
Hi! > >>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. > > 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 ;-). > 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. Pavel -- Thanks, Sharp! |
From: Jaco K. <ja...@kr...> - 2005-12-23 16:52:48
Attachments:
smime.p7s
|
Pavel Machek wrote: > Hi! > > >>>>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. >> >>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 ;-). Will try when I get back from the movies. I've seen one other message that mentioned this same error in iasl, can't remember where though. >>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. That is all I've managed to become wizer today. Really not particularly usefull I know. Sorry for the noise. -- There are only 10 kinds of people in this world, those that understand binary and those that don't. http://www.kroon.co.za/ |
From: Pavel M. <pa...@su...> - 2005-12-23 17:25:29
|
Hi! > >>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. Yep, "Linux" is printed from assembly header. Fortunately your machine gets into C, so you'll not have to debug _that_. You can just debug it using printk(). But try _minimal config_, first. > 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. See Doc*/power/swsusp.txt. suspend to disk should be easier to fix. Pavel -- Thanks, Sharp! |
From: Jaco K. <ja...@kr...> - 2005-12-23 22:56:45
Attachments:
smime.p7s
|
Pavel Machek wrote: > 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). >>And that is where it all stops. > > See Doc*/power/swsusp.txt. suspend to disk should be easier to fix. That didn't really teach me anything new. -- There are only 10 kinds of people in this world, those that understand binary and those that don't. http://www.kroon.co.za/ |
From: Pavel M. <pa...@su...> - 2005-12-23 23:01:57
|
Hi! > > 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.) > 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. Pavel -- Thanks, Sharp! |
From: Jaco K. <ja...@kr...> - 2005-12-24 00:05:37
Attachments:
smime.p7s
|
Pavel Machek wrote: > Hi! > > >>>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.) Oops. Reverted. Still does the same thing though, doing: # echo shutdown > /sys/power/disk # echo disk > /sys/power/state (then on that special VT): Stopping tasks: =========| Freeing memory... done (0 pages freed) swsusp: Need to copy 10553 pages swsusp: critical section/: done (10595 pages copied) ACPI: PCI Interrupt 0000:00:14: ... 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. >>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. Actually, I lie. There are weird lockups. I can typically do "echo foo", or "ls", but I for example can't run make, diff or anything funky (mount without any params works but mount -o rw,remount /boot locks up). This may be due to incompatibilities with the running kernel and the installed glibc but I somehow suspect this is not the case. I can also post my kernel config somewhere if that would help. In both cases issues any further suspend/resume commands locks up the system. As in this could also be that caused the lockup after resuming from ram. Indeed. Retrying the suspend-to-ram and then performing a remount works. However, running make menuconfig in /usr/src/linux after that does not. 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). Guess I should start by enable many more of those kernel debugging options ..., right now I need some sleep however. 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. Jaco -- There are only 10 kinds of people in this world, those that understand binary and those that don't. http://www.kroon.co.za/ |
From: Pavel M. <pa...@su...> - 2005-12-24 00:25:55
|
Hi! > ... 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). Okay, what *other* patches do you have installed? What kernel are you running? 2.6.15-rc6? > 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? > 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? > 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). Pavel -- Thanks, Sharp! |
From: Jaco K. <ja...@kr...> - 2005-12-24 00:34:25
Attachments:
smime.p7s
|
Pavel Machek wrote: > Hi! > > >>... 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). > > 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. >>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? In the morning. >>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. I've also found that I forgot to disable registers. Neither made a difference though. > 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?). >>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). Figured. Thanks for you patience on this. Jaco -- There are only 10 kinds of people in this world, those that understand binary and those that don't. http://www.kroon.co.za/ |
From: Pavel M. <pa...@su...> - 2005-12-24 00:38:32
|
Hi! > > 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. > >>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. > > I've also found that I forgot to disable registers. Neither made a > difference though. CONFIG_REGPARM? > > 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. Pavel -- Thanks, Sharp! |
From: Jaco K. <ja...@kr...> - 2005-12-24 08:44:37
Attachments:
smime.p7s
|
Pavel Machek wrote: > Hi! > > >>>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. Right, I've done this for userspace programs linked with -rdynamic before, but how do I convert those hexadecimal offsets into line numbers for the kernel? Just point me at the docs to RTFM so that I can RTFS. The keyboard auto-repeat still breaks. If it's possible to re-enable this using some command-line tool (which I'm not aware off) then I can just re-enable that manually from a suspend/resume script. >>>>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. >> >>I've also found that I forgot to disable registers. Neither made a >>difference though. > > CONFIG_REGPARM? Argh. It was too early in the morning (late at night?). Yes. >>>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. You should have received the patch. Jaco -- There are only 10 kinds of people in this world, those that understand binary and those that don't. http://www.kroon.co.za/ |
From: Stefan S. <se...@su...> - 2005-12-24 08:54:17
|
On Sat, Dec 24, 2005 at 10:45:58AM +0200, Jaco Kroon wrote: > Pavel Machek wrote: > > rc5 should be good enough. >=20 > Same problem. SysRq+T reveals that the newly spawned process is gettin= g > stuck in: >=20 > 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 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 :-( --=20 Stefan Seyfried \ "I didn't want to write for pay. I QA / R&D Team Mobile Devices \ wanted to be paid for what I write." SUSE LINUX Products GmbH, N=FCrnberg \ -- Leonard Cohe= n |
From: Jaco K. <ja...@kr...> - 2005-12-24 09:12:06
Attachments:
smime.p7s
|
Stefan Seyfried wrote: > On Sat, Dec 24, 2005 at 10:45:58AM +0200, Jaco Kroon wrote: > >>Pavel Machek wrote: >> >>>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 > > > 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. dsdt.dat (orriginal DSDT) dsdt.dsl (my so-far edited version) dsdt.dsl.orig (orriginal decompiled version). Hmm, just noticed that iasl still creates a .hex file even though it gives me 13 errors! Including into kernel ... same issue. Jaco -- There are only 10 kinds of people in this world, those that understand binary and those that don't. http://www.kroon.co.za/ |
From: Jaco K. <ja...@kr...> - 2005-12-24 12:00:42
Attachments:
smime.p7s
|
Jaco Kroon wrote: > Stefan Seyfried wrote: >>>Same problem. SysRq+T reveals that the newly spawned process is getting >>>stuck in: >>> >>>ide_do_request+0x18a/0x3c5 >>>io_schedule+0xe/0x16 [--snip--] >>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. Jaco -- There are only 10 kinds of people in this world, those that understand binary and those that don't. http://www.kroon.co.za/ |
From: Pavel M. <pa...@su...> - 2005-12-24 12:22:46
|
Hi! > 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. 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? Pavel -- Thanks, Sharp! |
From: Jaco K. <ja...@kr...> - 2005-12-24 12:43:55
Attachments:
smime.p7s
|
Pavel Machek wrote: > Hi! > > >>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. > > > 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? Yes. If the first thing I do after boot is "echo mem > /sys/power/state", then how can tools like dmesg, make, gcc, cat and even ls be in the cache? -- There are only 10 kinds of people in this world, those that understand binary and those that don't. http://www.kroon.co.za/ |
From: Manuel L. <ma...@ro...> - 2005-12-24 10:45:03
|
Jaco Kroon wrote: > 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). 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. -- Manuel Lauss |
From: Jaco K. <ja...@kr...> - 2005-12-24 11:20:09
Attachments:
smime.p7s
|
Manuel Lauss wrote: > Jaco Kroon wrote: > > >>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). > > > 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. Jaco -- There are only 10 kinds of people in this world, those that understand binary and those that don't. http://www.kroon.co.za/ |
From: Pavel M. <pa...@su...> - 2005-12-24 11:48:26
|
Hi! > > 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. 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. Pavel -- Thanks, Sharp! |