Even though hibernate works fine, suspend to disk is severly broken on the IBM R31. On wakeup, the CD starts spinning, the fan starts, though the machine hangs otherwise, black console, unreachable over the network, completely unresponsive. The ACPI DSDT shows that the _WAK entry misses a proper return (buggy bios), it is attached.
Created attachment 144311 [details] DSDT of the IBM R31
Isn't suspend to disk called hibernation? Or do you mean suspend to mem is broken?
Yes, suspend to disk is called hibernation. Sorry for the confusion - suspend to ram is broken. I checked various other releases, it seems to be consistently broken over all of them. The problem is not related to any kernel drivers - I unloaded as many as possible but still get a hang. Suspend to RAM is also broken on Windows98SE, but works on Windows XP. The R31 does not have an APM bios, hence this option is unfortunately not available. I also tried the "resume" kernel debugging tricks that store the last known location of the kernel in the RTC, but unfortunately did not get anything. It seems to be stuck somewhere before it actually reaches the parts that store information into the RTC. In the meantime, I made the DSDT compile with iasl, fixed the wrongly declared memory regions and added the missing returns for \_WAK, but without success. iasl compiles the fixed ACPI table correctly, the kernel loads them, but no avail. Probably the RAM looses its contents? Is there known information for the i830 chipset what one has to do to keep the RAM powered up?
Please refer to Documentation/power/pm_basic_debug.txt, and try different pm_test levels and check if they work for you?
That's all already done. All the pm-tests work fine, i.e. the machine comes up in the test cases. It does not, however, if I test for real. I also tried the S3_beep option from the kernel to check whether the real mode entry hook of the kernel is ever entered. It is not. The machine is just unresponsive. Thus, the \_WAK hook of the DSDT is actually never used. The "prepare to sleep" hook is, but apparently, it does not configure the machine correctly for the sleep as it never wakes up again. The "standby" mode works, though, but only that.
(In reply to Thomas Richter from comment #5) > That's all already done. All the pm-tests work fine, i.e. the machine comes > up in the test cases. It does not, however, if I test for real. I also tried > the S3_beep option from the kernel to check whether the real mode entry hook > of the kernel is ever entered. It is not. The machine is just unresponsive. > Thus, the \_WAK hook of the DSDT is actually never used. why? how do you verify this? > The "prepare to > sleep" hook is, do you mean suspend_ops->prepare()? (In reply to Thomas Richter from comment #3) > Yes, suspend to disk is called hibernation. Sorry for the confusion - > suspend to ram is broken. I checked various other releases, it seems to be > consistently broken over all of them. The problem is not related to any > kernel drivers - I unloaded as many as possible but still get a hang. > Suspend to RAM is also broken on Windows98SE, but works on Windows XP. please reboot with boot option acpi_os_name="Windows 2001"
Verified by acpi_sleep=S3_beep. The entry hook of the kernel is never called, the notebook does not beep at all. I suspect it's the kernel that works along the DTST? One of the debug methods place a magic word in the RTC - or actually should. When restarting, nothing is found by the kernel. That's consistent with the first finding, i.e. the kernel is never re-entered from the suspend. Pretty consistent for many kernel versions. The older APM-based versions send the machine only to standby (not suspend to ram), thus the fan keeps rotating. Suspend to RAM works under Windows XP, not under Windows 98. "Prepare to sleep" is the \_PTS function of the DSDT. I suspect that should prepare the hardware registers to initiate a sleep. Looks like something is missing there? As far as acpi_os_name is concerned, the DSDT checks for Windows 98, Windows NT and Windows ME (see attachement above). I tried already all combinations. None of them work. The only difference is that for one of the combinations the display remains dark after a suspend to disk. (Actually, not dark, but the background light is not re-enabled, the display itself works and shows the contents if checked closely). But again,suspend to RAM never works - the machine sleeps, but does not wake up.
(In reply to Thomas Richter from comment #7) > Verified by acpi_sleep=S3_beep. The entry hook of the kernel is never > called, the notebook does not beep at all. TBH, I suspect the system is broken in BIOS, i.e. Linux kernel never get chance to do anything during resume. Aaron, can you please attach your debug patch to check if it hangs in BIOS or kernel? > I suspect it's the kernel that > works along the DTST? One of the debug methods place a magic word in the RTC > - or actually should. When restarting, nothing is found by the kernel. > That's consistent with the first finding, i.e. the kernel is never > re-entered from the suspend. Pretty consistent for many kernel versions. The > older APM-based versions send the machine only to standby (not suspend to > ram), thus the fan keeps rotating. Suspend to RAM works under Windows XP, > not under Windows 98. > > "Prepare to sleep" is the \_PTS function of the DSDT. I suspect that should > prepare the hardware registers to initiate a sleep. Looks like something is > missing there? > I don't think so. _PTS is invoked during suspending. > As far as acpi_os_name is concerned, the DSDT checks for Windows 98, Windows > NT and Windows ME (see attachement above). I tried already all combinations. Right, and Windows XP os name is none of these, thus leads to a different code path, that's why I want you to check acpi_os_name="Windows 2001", actually, you can even try any string as long as it does not match any of the above three strings. > None of them work. you mean none of the above three? or none of the above three and "Windows 2001"? > The only difference is that for one of the combinations > the display remains dark after a suspend to disk. (Actually, not dark, but > the background light is not re-enabled, the display itself works and shows > the contents if checked closely). > > But again,suspend to RAM never works - the machine sleeps, but does not wake > up. As I suspect this is an BIOS issue, can you please check if there is any newer BIOS available and upgrade your BIOS if possible?
You are right that Linux does not get a chance on resume because the kernel is never entered again. However, if the resume phase is unfixable, but $OtherOs can resume from S3, then apparently $OtherOs must do something different during the suspend phase. That's exactly why I'd say that there's probably something in _PTS that should be done, but that is missing from the DSDT. Yes, I know that "Windows XP" is not the name used in the DSDT. Here is the relevant code segment: If (OSCP (\_OS, "Microsoft Windows")) { Store (0x00, OSTP) } Else { If (OSCP (\_OS, "Microsoft Windows NT")) { Store (0x01, OSTP) } Else { If (OSCP (\_OS, "Microsoft WindowsME: Millennium Edition")) As already stated, I tried all three of them. Makes no freaking difference, the machine freezes at suspend. S1 ("standby") works, but $OtherOs does not standby. It enteres something that is, at least from the outside, very much like S3 (fan is off, for example, but it remains on in S1). The machine has already the latest Bios I could find, there's no newer release that could potentially fix this, sorry.
(In reply to Zhang Rui from comment #8) > (In reply to Thomas Richter from comment #7) > > Verified by acpi_sleep=S3_beep. The entry hook of the kernel is never > > called, the notebook does not beep at all. > > TBH, I suspect the system is broken in BIOS, i.e. Linux kernel never get > chance to do anything during resume. > Aaron, > can you please attach your debug patch to check if it hangs in BIOS or > kernel? If the laptop can make beep and acpi_sleep=S3_beep doesn't make the beep, that means Linux doesn't get control from BIOS on resume and there is nothing we can do to solve this problem(is there a BIOS update available?). BTW, it seems pretty hard to use my patch as the symptom here is that on resume, the system is broken instead of directely booting as if it is not suspended. Anyway, I'll attach it soon.
Created attachment 154071 [details] Patch to hang Linux the moment it gets control from BIOS We normally used this patch for systems that directly boot on resume so it is effective to tell if Linux gets the control from BIOS on resume. The patch will also dump some values to port 0x80, which is normally only available on test machines, so...
In the meantime, I worked around this issue by supplying a custom DSDT which has the S3 information completely removed. As a result, linux uses the S1 state instead of the S3 state for standby (not suspend to ram), and that works fine.
OK, I don't see there is anything more we can do, so close it as WILL_NOT_FIX for the S3 issue.