GNU bug report logs - #40538
installer: Support uvesafb to install on machines without KMS.

Previous Next

Package: guix;

Reported by: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>

Date: Fri, 10 Apr 2020 12:56:01 UTC

Severity: normal

Done: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>

Bug is archived. No further changes may be made.

Full log


Message #56 received at 40538 <at> debbugs.gnu.org (full text, mbox):

From: Bengt Richter <bokr <at> bokr.com>
To: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
Cc: Mathieu Othacehe <m.othacehe <at> gmail.com>, 40538 <at> debbugs.gnu.org
Subject: Re: bug#40538: installer: Support uvesafb to install on machines
 without KMS.
Date: Sun, 12 Apr 2020 19:48:19 +0200
Hi Florian,

On +2020-04-12 17:30:52 +0200, pelzflorian (Florian Pelz) wrote:
> On Sun, Apr 12, 2020 at 04:48:36PM +0200, Mathieu Othacehe wrote:
> > Thanks for your patch. I tried briefly 1.1.0-rc2 on some hardware of
> > mine. On three somehow recent laptops, everything still works fine but
> > v86d segfaults without giving much information.
> > 
> > The 'dmesg' output looks like:
> > 
> > --8<---------------cut here---------------start------------->8---
> > v86d[371]: segfault at xxxxx.
> > uvesafb: Getting VBE info block failed (eax=0x4f00, err=1)
> > uvesafb: vbe_init() failed with -22
> > uvesafb: probe of uvesafb.0 failed with error -22
> > --8<---------------cut here---------------end--------------->8---
> >
> 
> Even though I do not remember a segfault, I believe these errors come
> when another driver has already reserved the memory that uvesafb
> wants.  If the other driver already works fine and that is the only
> error, maybe we can just ignore the uvesafb error.
> 
>

Could it be segfaulting trying to access a missing v86d ?
(if so maybe you could detect its absence before it segfaults and issue a hint?)

Looking at
    https://www.kernel.org/doc/html/latest/fb/uvesafb.html
I see (hand-wrapped, and boxing what I thought might be extra interesting):
--8<---------------cut here---------------start------------->8---
Unlike other drivers, uvesafb makes use of a userspace helper called v86d.
v86d is used to run the x86 Video BIOS code in a simulated and controlled environment.
This allows uvesafb to function on arches other than x86.
Check the v86d documentation for a list of currently supported arches.

v86d source code can be downloaded from the following website:

    https://github.com/mjanusz/v86d

Please refer to the v86d documentation for detailed configuration and installation instructions.

┌───────────────────────────────────────────────────────────────┐
│ Note that the v86d userspace helper has to be available       │
│ at all times in order for uvesafb to work properly.           │
│ If you want to use uvesafb during early boot,                 │
│ you will have to include v86d into an initramfs image,        │
│ and either compile it into the kernel or use it as an initrd. │
└───────────────────────────────────────────────────────────────┘
--8<---------------cut here---------------end--------------->8---
Also there are various options for compiling in vs modprobe vs kernel params etc
mentioned in https://www.kernel.org/doc/html/latest/fb/uvesafb.html so I imagine
v86d could be missing for various reasons in a particular run-time context?

> 
> > On a really old Intel machine, I have a complete black screen on all TTY
> > but that was maybe the case on older Guix System revisions and I would
> > need to do more investigations.
> > 
> > Mathieu
> 
> Please try adding nomodeset to the kernel parameters.  I hope this
> makes the Intel machine work fine.
> 
> Thank you for your feedback and all your work!
> 
> Regards,
> Florian
> 
-- 
Regards,
Bengt Richter




This bug report was last modified 5 years and 41 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.