Bug 3910 - ACPI Screen blanking works, unblanking does not in DrakX (Dell Inspiron E1405)
Summary: ACPI Screen blanking works, unblanking does not in DrakX (Dell Inspiron E1405)
Status: REOPENED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Installer (show other bugs)
Version: Cauldron
Hardware: i586 Linux
: High major
Target Milestone: Mageia 6
Assignee: Mageia tools maintainers
QA Contact:
URL:
Whiteboard:
Keywords: FOR_ERRATA5
Depends on:
Blocks:
 
Reported: 2011-12-29 02:22 CET by David Walser
Modified: 2017-01-17 10:29 CET (History)
8 users (show)

See Also:
Source RPM:
CVE:
Status comment:


Attachments

Description David Walser 2011-12-29 02:22:17 CET
While installing Mageia 1 on a Dell Inspiron E1405 laptop (also known as the Inspiron 640m), I closed the lid which turned the screen off.  Opening it up later, the screen did not turn back on.  I was able to turn it back on manually by executing a command at the console, as follows:
Ctrl-Alt-F2 (switch to console)
vbetool dpms on

From lspcidrake:
unknown         : Intel Corporation|Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller [DISPLAY_OTHER] (rev: 03)
Card:Intel 810 and later: Intel Corporation|Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller [DISPLAY_VGA] (rev: 03)
unknown         : Intel Corporation|Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub [BRIDGE_HOST] (rev: 03)

Note that in the installed system itself, the blanking/unblanking functionality works fine.
Comment 1 Manuel Hiebel 2011-12-29 17:46:07 CET
Hi, thanks for reporting this bug.
Assigned to the package maintainer.

(Please set the status to 'assigned' if you are working on it)
Comment 2 David Walser 2012-03-07 15:19:24 CET
tv, is there any additional info or anything else I can do to help with this?
Comment 3 Marja van Waes 2012-07-06 15:06:10 CEST
Please look at the bottom of this mail to see whether you're the assignee of this  bug, if you don't already know whether you are.


If you're the assignee:

We'd like to know for sure whether this bug was assigned correctly. Please change status to ASSIGNED if it is, or put OK on the whiteboard instead.

If you don't have a clue and don't see a way to find out, then please put NEEDHELP on the whiteboard.

Please assign back to Bug Squad or to the correct person to solve this bug if we were wrong to assign it to you, and explain why.

Thanks :)

**************************** 

@ the reporter and persons in the cc of this bug:

If you have any new information that wasn't given before (like this bug being valid for another version of Mageia, too, or it being solved) please tell us.

@ the reporter of this bug

If you didn't reply yet to a request for more information, please do so within two weeks from now.

Thanks all :-D
Comment 4 David Walser 2012-07-06 16:28:19 CEST
This can't be fixed for Mageia 1 now.  I have yet to test and verify if it's
still an issue with Mageia 2.
Comment 5 Manuel Hiebel 2012-11-05 16:54:04 CET
This message is a reminder that Mageia 1 is nearing its end of life. 
In approximately 25 days from now, Mageia will stop maintaining and issuing 
updates for Mageia 1. At that time this bug will be closed as WONTFIX (EOL) if it 
remains open with a Mageia 'version' of '1'.

Package Maintainer: If you wish for this bug to remain open because you plan to 
fix it in a currently maintained version, simply change the 'version' to a later 
Mageia version prior to Mageia 1's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not 
be able to fix it before Mageia 1 is end of life.  If you would still like to see 
this bug fixed and are able to reproduce it against a later version of Mageia, 
you are encouraged to click on "Version" and change it against that version 
of Mageia.

Although we aim to fix as many bugs as possible during every release's lifetime, 
sometimes those efforts are overtaken by events. Often a more recent Mageia 
release includes newer upstream software that fixes bugs or makes them obsolete.

--
Mageia Bugsquad
Comment 6 Manuel Hiebel 2012-12-02 14:36:28 CET
Mageia 1 changed to end-of-life (EOL) status on ''1st December''. Mageia 1 is no 
longer maintained, which means that it will not receive any further security or 
bug fix updates. As a result we are closing this bug. 

If you can reproduce this bug against a currently maintained version of Mageia 
please feel free to click on "Version" change it against that version of Mageia
and reopen this bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

--
Mageia Bugsquad
Comment 7 David Walser 2013-01-01 19:21:00 CET
Still valid on Mageia 2.
Comment 8 Samuel Verschelde 2013-08-27 13:30:13 CEST
This can't be fixed for Mageia 2 nor Mageia 3. Is it still valid in latest alpha?
Comment 9 David Walser 2013-08-27 14:56:02 CEST
It most likely is.  I don't know that anything's been done to address it.  I'll test it again when I get a chance.
Comment 10 David Walser 2013-09-07 04:28:23 CEST
Confirmed still an issue on Mageia 3.  I'll test Cauldron when I can.
Comment 11 Dick Gevers 2014-11-15 05:43:44 CET
Needinfo as per commebt #10
Comment 12 David Walser 2015-01-24 18:33:12 CET
It's worse now in Cauldron.  Not only is it not fixed (not that there was any reason to believe that it might have been), vbetool doesn't work in the installer anymore.  It gives a message (assuming you run it before the screen is blanked so that you can see it) failed to initialize Linux Real Mode Interface.  So now if the screen gets blanked, there's no way to recover from it.
Comment 13 Thierry Vignaud 2015-02-03 14:42:17 CET
My first guess would have been maybe do we lack a kernel module?

But, from reading the code, the "Failed to initialise LRMI (Linux Real-Mode Interface)" error messages cames when it fails to open or process /dev/mem

Is there any other messages before/after?
All errors pathes are using perror() to report issues...

The following bug reports points to permission issues due to dracut
https://bugzilla.redhat.com/show_bug.cgi?id=710711

Colin, WDYT about lessening perms for installer?

If that doesn't fix it, another hint the libx86 patch that stops some mmap() of page zero is causing havoc?
https://bugzilla.redhat.com/show_bug.cgi?id=518351

But I'm guessing for noexec mounting of /dev/
Comment 14 David Walser 2015-02-08 01:15:00 CET
The error message is coming in the console you run the vbetool command in:
Failed to initialize LRMI (Linux Real-Mode Interface).

I don't see any errors printed in the other consoles relevant to this.
Comment 15 Colin Guthrie 2015-02-24 09:03:59 CET
(In reply to Thierry Vignaud from comment #13)
> My first guess would have been maybe do we lack a kernel module?
> 
> But, from reading the code, the "Failed to initialise LRMI (Linux Real-Mode
> Interface)" error messages cames when it fails to open or process /dev/mem
> 
> Is there any other messages before/after?
> All errors pathes are using perror() to report issues...
> 
> The following bug reports points to permission issues due to dracut
> https://bugzilla.redhat.com/show_bug.cgi?id=710711
> 
> Colin, WDYT about lessening perms for installer?

This is a really old bug and references a really old dracut commit that we've not carried for some time.

Do we mount /dev in the installer ourselves these days? (I don't see it with a git grep).

Not 100% sure what you're asking me to do with regards to permissions...


> If that doesn't fix it, another hint the libx86 patch that stops some mmap()
> of page zero is causing havoc?
> https://bugzilla.redhat.com/show_bug.cgi?id=518351
> 
> But I'm guessing for noexec mounting of /dev/

I don't see where /dev/ gets mounted noexec... Dracut code doesn't seem to do it (just grep for devtmpfs, and a systemd system without initramfs doesn't do it. Can you point to some background as to why you think the affected systems have a noexec mounted /dev?
Comment 16 Thierry Vignaud 2015-02-24 10:59:50 CET
/dev is mounted by dracut those days (since http://gitweb.mageia.org/software/drakx/commit/mdk-stage1/?id=63d2a6)
Thus by http://git.kernel.org/cgit/boot/dracut/dracut.git/tree/modules.d/99base/init.sh

So in Cauldron, we don't use noexec for mounting /dev in installer (can you confirm David)?

One difference with FC is that they always build with BACKEND=x86emu whereas we only do so on !x86.
David, can you try rebuilding libx86 that way and test if vbetool works better?
Comment 17 Thierry Vignaud 2015-02-24 11:04:48 CET
Debian always define it too:
See latest debian/rules and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=492470
Comment 18 David Walser 2015-02-24 15:43:34 CET
If there's a new boot.iso that I can try once I get my local Cauldron mirror resynced again, I can test it.
Comment 19 Thierry Vignaud 2015-02-24 15:51:14 CET
You don't need to test it in installer.

Just test it in your favorite desktop:
1) check vbetool fails in your terminal
2) rebuild libx86 as told
3) update libx86
4) check if vbetool now works
Comment 20 David Walser 2015-02-24 15:58:05 CET
In that case I can only test it in Mageia 4, as that's what's installed on the machine.  vbetool works fine from root.  If I try to run it from a regular user account, it says open /dev/mem: Permission denied, and gives the LRMI error too.
Comment 21 Colin Guthrie 2015-02-24 16:13:07 CET
(In reply to David Walser from comment #20)
> In that case I can only test it in Mageia 4, as that's what's installed on
> the machine.  vbetool works fine from root.  If I try to run it from a
> regular user account, it says open /dev/mem: Permission denied, and gives
> the LRMI error too.

I don't know the tool, but I would expect it to fail as non-root if it's accessing /dev/mem and it's not setuid or anything special.

Is this tool integrated anywhere in such a way that it's called as a regular user? If so, that's likely a bug. If this is just a local thing that is done locally for a specific h/w hack, then I'd just setup a sudo or policykit rule accordingly and run it via sudo/pkexec or similar.

It's probably possible to use an MGA5 live media (and still recompile it after urpmi the build reqs!) if it needs testing on this h/w on newer builds - assuming you have enough memory to play with :)
Comment 22 David Walser 2015-02-24 16:26:21 CET
No, it's fine that it doesn't work as regular user.  Where it's tied in is to ACPI events, so that it is used to blank and turn on the screen when the lid is closed and opened.  In an installed Mageia 4 system, this works fine.  The original issue for this bug is that in the installer, it only blanks the screen when you close the lid, and fails to turn it back on when you open it.  Before mga5 Cauldron, you could at least manually Ctrl-Alt-F2 and then run vbetool to turn it back on, but this problem was made worse when that stopped working too.  Both of these issues really need to be fixed.

As far as testing, the best I can do is try running vbetool on a Cauldron machine at work, but that's not a laptop.
Comment 23 Thierry Vignaud 2015-02-24 17:38:31 CET
hum what happens is that LRMI_common_init() is run entirely, we don't go in any error path that returns NULL.
However, offset is NULL and so the final return is NULL, so the caller think its broken...
Comment 24 Thierry Vignaud 2015-02-24 20:43:30 CET
Actually in mga3, it was returning 1.
The difference is due to libx86-mmap-offset.patch which was introduced to fix segfault (mga#13676)
Comment 25 Thierry Vignaud 2015-02-24 20:50:05 CET
Disabling the patch fixes it for me.
Comment 26 Thierry Vignaud 2015-02-26 06:03:34 CET
Can you try latest cauldron?
Comment 27 David Walser 2015-02-28 19:00:13 CET
vbetool is completely broken now.  No matter what arguments you give it, it just says:
Illegal instruction

It still blanks the screen when closing the lid and doesn't unblank it when opening it.
Comment 28 Anne Nicolas 2015-04-05 23:13:53 CEST
ping ?
Comment 29 David Walser 2015-04-09 20:46:59 CEST
vbetool/libx86 issue fixed, original bug still remains.
Comment 30 Marja van Waes 2016-07-12 16:54:25 CEST
(In reply to David Walser from comment #29)
> vbetool/libx86 issue fixed, original bug still remains.

And what is it like now, in current cauldron?
Comment 31 David Walser 2016-07-17 19:03:06 CEST
Let me first be clear, this is the kind of bug that isn't going to just disappear on its own.  It won't be fixed until something is actively done to fix it.

Either there's something in the installer that's triggering the screen to blank without a matching thing to unblank it, or there's something intrinsic in this hardware causing it to blank, and the installer is missing something to disable that or to unblank the screen when the lid is opened.

Just to humor you, I have confirmed that the bug is still present in current Cauldron.
Comment 32 Rémi Verschelde 2016-07-28 10:45:36 CEST
Thierry, any idea what could be done to solve this issue? I'm pretty confident David will be able to do all the testing necessary to help solve it.

Note You need to log in before you can comment on or make changes to this bug.