-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ShredOS fails to wake from suspend #70
Comments
'ShredOS fails to wake from suspend' might be a better title – the suspend part appears to be okay. Referring to https://github.com/PartialVolume/shredos.x86_64_2020.05/issues/20#issuecomment-766953990, ACPI support, or lack of, is the most likely culprit. That would also account for the waking without restarting the video hardware (https://github.com/PartialVolume/shredos.x86_64_2020.05/issues/20#issuecomment-766871022). Apologies if you already know this stuff, but this Ubuntu wiki entry gives a useful overview. |
Feedback and links to articles are always useful, thanks. |
@hameau I just tried So the problem would seem to be related to specific hardware. |
Wake from suspend has been a thorn in the side of Linux for ever! I have tried with an MSI Wind (Atom) and it fails to resume – black screen, but the computer is running. The same result using That hardware works correctly under SysRescCD, but not Clonezilla (Debian version). For a standard installed Linux distribution, it's usually a matter of pushing options to the video driver. Interesting that both of my test cases have integrated Intel graphics, which your P4 doesn't. (Of course, integration itself may not be significant – other things will also have changed over time.) There is a kernel-level TRACE_RESUME feature: https://www.kernel.org/doc/Documentation/power/s2ram.txt I'll set up the MSI Wind to test with that in the next few days, if I can. It's something that needs a bit of preparation and some clear bench space. Also, this Ubuntu wiki page: https://wiki.ubuntu.com/DebuggingKernelSuspend (but needs a workaround for |
What's the hardware for this one? CPU & graphics. |
HP Pavilion dm1 notebook. AMD E-450 APU (AMD Radeon HD 6320) |
@hameau I've now got rtcwake working properly on my main laptop, which is an I7 with Nvidia graphics. The laptop now wakes correctly. Not only that but the LCD brightness controls on the keyboard now work too. I've had to expand the disc size from 38Mb to 41Mb to accommodate all the video, backlight, control drivers for Intel, AMD, ATI plus others. There is a couple of issues I need to work on, on the HP notebook the screen is alive in that it says 'ShedOS booting' but nwipe never displays. If you ALT F2 you can power off but the screen never changes from saying ShredOS booting. The other problem is the text resolution on my I7, because it's now using the Nvidia video driver it defaults to the screens highest resolution which is too high for nwipe.. On the plus side the laptop now wakes properly from sleep. |
nomodeset on the kernel command line gets me my original 80 x 25 character resolution back but reintroduces the rtcwake issue. So I definitely need to set a graphics mode, VGA=0x etc is deprecated and set gfxpayload=1024x1024x24 still leaves me with the highest resolution. Onwards and upwards .. |
Yes, I was afraid of some growth. You're still pretty compact at around 7% of SysRescCD, so the wider usefulness is very much worthwhile, imo.
I doubt if
Impressive progress, thanks. |
@hameau thanks for those links, they were very useful. I think I'm going to have to spend a lot more time on making this reliable using video drivers rather than the fb driver, I have one generic I7/Nvidia laptop that works well but I need to work out a method by which the resolution can be easily changed by a user. While on a Sony VAIO the laptop freezes the frame buffer when switching drivers and the same with an HP. This will be something I intend to do (or somebody else if they can can up with a good PR) but for the time being I need to fix a couple of bugs in nwipe and add HDA detection and correction and then I'll come back to this particular issue, therefore I'll leave this issue open. As always any help you can provide on this is appreciated. |
I've been looking at the issue of ShredOS not waking from sleep this evening, and specifically what part of the system doesn't wake. This is a DELL Optiplex 9010. I've found I can telnet into ShredOS and the drives are indeed 'not frozen' and I can do a secure erase via hdparm. What seems to happen is that the display hardware (Intel) doesn't wake from sleep. The keyboard is functional so it seems the consoles ALT-F1-F3 is working. It's just the display that isn't. I've been looking at the various power related features in /sys/devices/ etc and toggled auto to on in control but no luck yet. |
And my Dell optiflex also having integrated Intel graphics. I think I will get on with making the changes to nwipe so it supports ATA secure erase and controls putting the system to sleep then come back to this. |
@hameau @Firminator Looks like I may have solved the suspend to RAM issue. I've added some drm Direct Rendering Manager code to ShredOS along with a selection of Nvidia, AMD and Intel DRM drivers and some configuration of ACPI and now ShredOS on my Nvidia laptop boots ShredOS with the native resolution of the screen. Previously it only ever displayed ShredOS in a low Res display. Most importantly, the command I can now start writing the secure erase code in nwipe and have a working ShredOS that will correctly suspend to RAM that I can use as a test bed. Before I do a release I'll need some testing done on systems with lots of different graphics hardware to make sure ShredOS can always be sent to sleep and restored with fully working graphics. If anybody is interested in testing the beta version of ShredOS with secure erase then let me know and I'll send you a link to download the .img in due course. |
I've got a couple of different combinations of graphic cards and monitor resolutions, newer and older hardware, which I can test if you want. |
The test procedure: Once ShredOS has booted, ALT F2 to bring up the 2nd virtual terminal. ShredOS version: You will need to be testing against the pre-release version v2021.08.2_22_x86-64_0.32.023 or higher. I'm not interested in the results from earlier revisions. Once ShredOS has booted run the following rtcwake & hdparm commands in the 2nd virtual terminal (on a PC ALT F2) (on a Mac Fn ALT F2):
Repeat for each drive on the system. The following information can be obtained from the nwipe log (after a Control C) and from running the command
(*) I've got two drives in this machine: SATA drive is "not frozen", but for the NVME drive hdparm -I /dev/nvme0n1 and hdparm -I /dev/nvme0 returns nothing. [ @gorbiWTF ] See #70 (comment) and #70 (comment) for further info about the nvme-cli command for nvme drives. Add you findings in the comments and I'll add your results to the table. Starting off with a I7 Nvidia laptop and a MacBook Pro that I'm currently testing. |
A note about screen resolution: With the new DRM drivers, the kernel controls the resolution of the display using KMS (kernel mode setting) With all the systems I've tested so far the kernel chooses the native resolution of the monitor. On a high resolution monitor this can result in quite small text. If this isn't to your taste you can have ShredOS boot using the 640x480 (80x30) resolution, nwipe then fills the entire monitor with larger text. To disable KMS and revert to low resolution display and larger text add the following to the kernel command line HOWEVER, if you disable KMS using the following method you will most likely find that rtcwake will no longer work as the kernel can't then control the display hardware to rewake it. So if you want secure erase to work properly DO NOT make the following additions to the linux kernel command line in grub.cfgFor Nvidia hardware, add nomodeset and nouveau.modeset=0
For Intel, add nomodeset and i915.modeset=0
For Nvidia Optimus dual-graphics system, you need to add all the three kernel parameters (i.e. "nomodeset i915.modeset=0 nouveau.modeset=0").
|
With reference to the above comment about screen resolution, the preferred way to increase font size is to not mess with KMS and NOT set
Important! This command then doubles the size of the existing font. I think I may put an option in nwipe that toggles between default and double size font, specifically for high resolution monitors The images below show a monitor operating at it's native resolution of 1920x1200. The first image is the default 8x16 font. The second image is after having run the |
A little more info about manually doubling the font size of the default nwipe that runs in tty1. So type ALT F2 (Fn ALT F2 on a MAC) to bring up the 2nd virtual console. Type the following
So to set the font for the default nwipe in the first virtual console ALT F1 (/dev/tty1), type the following command in the 2nd virtual console (ALT F2)
Always specify the full path to setfont, |
(*) I've got two drives in this machine: SATA drive is "not frozen", but for the NVME drive Even resolutions up to 5120x1440 are working flawlessly for me. However, I got two machines which don't want to boot: "HP Compaq 8100 Elite" (doesn't want to boot at all) and "HP EliteDesk 800 G4" (stuck on "booting 'shredos'"). |
hdparm doesn't support nvme, with nvme drives you would use nvme-cli, however I have read that even nvme-cli doesn't provide security status 'frozen' information. Don't quote me on that though as I've got no nvme hardware to test on. With nvme I think it's a case of sending ShredOS to sleep then issuing the secure erase command via nvme-cli. This is something I'm going to have to take care of in nwipe. When it recognises a nvme drive it switches to using nvme-cli. nvme-cli should be available on ShredOS so you may want to try a wipe using that. Let me know how it works out. I think @Firminator uses nvme-cli and may be able to help here.
-s1 meaning0: No Secure Erase operation requested (generally speaking, this just TRIMs/deallocates all the LBAs) 1: User Data Erase – this physically erases the data on the drive. In a mainstream NAND NVMe SSD, this will trigger the erase of all the blocks as well as changing the cryptographic key. Due to the physics of NAND erases (consuming power and time) this can take some time (for large drives measured in single digit minutes) 2: Crypto Erase, this completes much faster (under 1 second in most cases) by swapping out the cryptographic key so that all data is rendered unreadable. Like all three cases, this will deallocate the LBAs and some drives may support deterministic read zero after TRIM for subsequent reads. ref:Secure Erase: Format, and Sanitize section of open-source-nvme-management-utility-nvme-command-line-interface-nvme-cli |
On those high resolution screens did you get to try the /bin/setfont -d command? Was the text better for reading at a distance? |
Do those two systems have a secondary graphics card installed by any chance? |
@gorbiWTF Come to think of it, I think I had a HP Compaq 8100 Elite at some point and could never get the thing to boot from USB. It worked fine booting from CD though. Think I may have to build the .iso version of this pre-release. |
I see. When I first send the system to sleep, then use
Text size is fine for me out of the box, with the command I think it's too big. The screen only has 109 ppi, but I will try it later with a 164 ppi screen.
Yes, they both do.
Haha, well, I got the same problem when I tried to install Windows 10 from an USB drive, but a BIOS update fixed that for me. |
It would be interesting to see if pulling out the secondary graphics card fixed either of them, at least it would indicate a graphics related issue. I don't know if you have two monitors attached but it would be worth checking the output of both video outputs. I had a similar problem, the bios allowed you to set the default card but that appeared to have no affect. Yet other systems worked nicely with two graphics cards. Funnily enough the systems who's bios allowed you to set the default card didn't work and those bios that had no video setting worked just fine. Still, I guess it's a quick test to pull the secondary card out of the system and see if ShredOS boots properly. |
@gorbiWTF Did you send shredos to sleep with a |
@gorbiWTF Sorry, just reread your comment, looks like you did send the system to sleep before running that command. |
Is the system shutting down so there is no display (or backlight) and all fans are off and if there are any spinning discs they have stopped spinning? One thing to check is whether the bios contains any ACPI settings, I found one of my systems was not powering down sufficiently because there was a setting that was set as S1 when it needed to be S3. Could be something like that. Maybe there is something specific in the bios for M2 or nmve power managment? |
Yes, the system is shutting down like all other system, the SATA drive correctly changes from "frozen" to "not frozen" but I can't use There are no BIOS options regarding the NVME drive, and changing the only power option ("Enhanced Power Saving Mode") isn't helping. |
I removed the graphics card from the HP EliteDesk 800 G4 and then ShredOS worked as expected. I can't remove the graphics card from the other system because the iGPU isn't working anymore. I also tried it on my notebook with an external screen: "booting 'shredos'" is showing up on the integrated screen (and always stays there), while the UI is on the external screen. |
I also got a HP Compaq dc7900 Convertible MT which can't boot (it just flashes an underscore cursor). |
Does this boot with the previous version: If it boots with the .iso then at least we know it's likely to be the HP USB boot issue rather than a graphics issue. |
Adding to the list a HPE ProLiant Microserver Gen8
for d in sd{a,b,c,d}; do hdparm -I /dev/$d | grep frozen; done
frozen
frozen
frozen
frozen What does however work is hot-plugging the drives. That should work on every platform. So far the best results I've achieved was by reconnecting the power cable, while the data cable stayed in place. |
Closing, as we now have switched to Linux DRM and include all the necessary firmware for most graphics cards, |
rtcwake -m mem -s 5 does indeed put the device to sleep but upon waking reboots ShredOS rather than the expected behaviour of restoring the running ShredOS from RAM.
The text was updated successfully, but these errors were encountered: