Is anybody else seeing https://bugs.meego.com/show_bug.cgi?id=17233 ("Netbook display often broken after suspend, especially after starting legacy X programs") It appears to be a longstanding (since 1.1) bug for some platforms, e.g. "[Toshiba NB 305 / Lenovo Ideapad S10-3t] fails to resume from suspend" https://bugs.meego.com/show_bug.cgi?id=10351
Based on a suggestion in the above, I disabled hpet at boot and now my 1.2 "trunk" netbook recovers from suspend even after running a terminal or emacs. Without it, you'd see a guaranteed dead display on resume if you used any of these programs. So what's the downside to booting with "nohpet" ? For example, even w/ nohpet, I still get high precision timers in the main place I want, ALSA, so nothing but benefit here: ................................................................. meegolem-50-~> cat /proc/asound/timers G0: system timer : 1000.000us (10000000 ticks) G3: HR timer : 0.001us (1000000000 ticks) P0-0-0: PCM playback 0-0-0 : SLAVE P0-0-1: PCM capture 0-0-1 : SLAVE ................................................................. And also the ALSA midi seq interface on this '.38 pinetrail adaptation kernel has HR timers for snd_seq_midi despite seemingly-missing snd_hrtimer ( http://lists.meego.com/pipermail/meego-kernel/2011-March/002282.html ) (nice!): ................................................................. meegolem-52-~> qtractor & ## http://qtractor.sourceforge.net [...] meegolem-53-~> cat /proc/asound/seq/timer Timer for queue 0 : HR timer Period time : 0.000000000 Skew : 65536 / 65536 ................................................................. However, even booting with "nohpet" , one can trigger the "display is dead until reboot" bug by suspending while running programs like qtractor that enable hrtimer usage in the alsa midi seq interface, as indicated by the presenence of HPET timer i/proc/asound/seq/timer . And once "cat /proc/asound/seq/timer" outputs something at all, then https://bugs.meego.com/show_bug.cgi?id=17233 is seen consistently. (Therefore with or without the "nohpet" fix, one shouldn't suspend after running qtractor, just power-down). Perhaps too many uses/users of a limited http://www.kernel.org/doc/Documentation/timers/hpet.txt resource is happening, and/or some mutex locking mechanism on the limited timers resource is failing? .................... Bug 17233 - Netbook display often broken after suspend, especially after starting legacy X programs BUILD IMAGE: "1.2" == 2.6.38.2-8.6-adaptation-pinetrail + http://download.meego.com/snapshots/latest-testing-1.2/repos/oss/ia32/packages + http://download.meego.com/live/devel:/connectivity:/latest/Trunk HARDWARE MODEL: Lenovo S10-3t BUG DETAILED DESCRIPTIONS =========================================================== If you boot up MeeGo 1.2 and just play around with various netbook-UX panels but don't launch any programs, then suspend, the display will often work after suspend. However, if you launch any gnome programs that haven't specifically been customized for the netbook display (like evolution), such as, gnome-terminal(1), emacs(1), etc... then if you suspend, you might as well shut down, because that's the only way you'll be able to use the display again. The X display is running, and hitting the powerbutton probably pops up the 30 second dialog (because it shuts down 30 seconds later)... it's just that you can't see anything on the display, and no amount of turning on/off display switching display ports or anything gets it back again, other than a reboot. To work-around, I added the following boot entry and now boot into a system with HPET disabled # Fix suspend bug? https://bugs.meego.com/show_bug.cgi?id=10351 label 2.6.38.2-8.6-adaptation-pinetrail menu label no-HPET 1.2 (2.6.38.2-7.1-adaptation-pinetrail) menu default kernel vmlinuz-2.6.38.2-8.6-adaptation-pinetrail append ro root=/dev/sda5 quiet vga=current nohpet With HPET disabled on this 2.6.38.2-8.6 kernel, the display can be seen after suspend and it doesn't matter if legacy-X apps like emacs(1) or gnome-terminal(1) have been run. EXACT STEPS LEADING TO PROBLEM: =========================================================== 1. boot Meego 1.2 2. bring up gnome-terminal 3. close lid of netbook until lights indicate it has suspended 4. reopen netbook 5. display is dark, all work lost, and there's no way to recover w/o power-cycle. EXPECTED OUTCOME: =================== Netbook suspends and resumes with display and applications working and no hangs. ACTUAL OUTCOME: =================== Netbook must be rebooted. Display won't work. Work not automatically saved by shutting down apps is lost. USER IMPACT: =================== Netbook cannot be used as one would expect to use a netbook, in a mobile situation, with lots of suspend/resumes and not needing to pay attention to what apps bork up the display and force you to reboot each suspend. REPRODUCIBILITY: ===================================== Always. EXTRA SOFTWARE INSTALLED: ============================ http://wiki.meego.com/MeeGo-Lem OTHER COMMENTS: =================== This is a critical issue and thus my "critical" severity rating. However it is hardware dependent and not necessarily seen on all platforms, as this unresolved "duplicate" of this bug for 1.1 indicates: "[Toshiba NB 305 / Lenovo Ideapad S10-3t] fails to resume from suspend" https://bugs.meego.com/show_bug.cgi?id=10351 It appears some MeeGo netbooks cannot be successfully resumed after suspend and this can cause loss of data, especially if user shuts down the machine "hard" rather than waiting 30 seconds for a clean shutdown after hitting power button (or hitting power once, waiting a few seconds, and then hitting it again). Since the display is "dead" there is no way of knowing the machine hasn't crashed or that it can be shutdown cleanly. ) ............................................................ (of course, if you have an external means of sshing in, if you accidentally suspended the netbook with the wrong programs running, then you can always issue "init 3; init 5" command as root and you get your display back, minus whatever apps that were running at the time...) -- Niels http://nielsmayer.com _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
