Re: [Bugme-new] [Bug 10580] New: uvesafb is broken

Re: [Bugme-new] [Bug 10580] New: uvesafb is broken

[Andrew Morton]

(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

On Wed, 30 Apr 2008 16:25:13 -0700 (PDT)
bugme-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=10580
> 
>            Summary: uvesafb is broken
>            Product: Drivers
>            Version: 2.5
>      KernelVersion: 2.6.25-git
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: Console/Framebuffers
>         AssignedTo: jsimmons@infradead.org
>         ReportedBy: francois.valenduc@tvcablenet.be
> 
> 
> Latest working kernel version: 2.6.25-git7
> Earliest failing kernel version: 2.6.25-git8
> Distribution: Gentoo
> Hardware Environment: Packard Bell MB86, Intel Core 2 Duo
> Software Environment:
> Problem Description:
> 
> uvesafb doesn't work anymore with the current git version. v86d failed with the
> following error:
> 
> Program v86d tried to access /dev/mem between a0000->110000.
> v86d[255]: segfault at 7f1025c22000 ip 400da6 sp 7fff2dc3e1d0 error 6 in
> v86d[400000+17000]
> uvesafb: Getting VBE info block failed (eax=0x4f00, err=-3)
> uvesafb: vbe_init() failed with -22
> uvesafb: probe of uvesafb.0 failed with error -22
> 
> After having tried git-bisect, it seems that the first bad commit which might
> cause the problem is the following:
> 
> commit e2beb3eae627211b67e456c53f946cede2ac10d7
> Author: Venki Pallipadi <venkatesh.pallipadi@intel.com>
> Date:   Thu Mar 6 23:01:47 2008 -0800
> 
>     devmem: add range_is_allowed() check to mmap of /dev/mem
>
> I have tried to revert it on the current git (git16) but it's not possible to
> do so.
> 
> Steps to reproduce:

Thanks for the report - it really helps.

Was you setting of CONFIG_NONPROMISC_DEVMEM the same in both -git7 and in
-git8?

RE: [Bugme-new] [Bug 10580] New: uvesafb is broken

[Pallipadi, Venkatesh]

 

>-----Original Message-----
>From: Andrew Morton [mailto:akpm@linux-foundation.org] 
>Sent: Wednesday, April 30, 2008 4:37 PM
>To: francois.valenduc@tvcablenet.be
>Cc: bugme-daemon@bugzilla.kernel.org; Ingo Molnar; Pallipadi, 
>Venkatesh; linux-kernel@vger.kernel.org
>Subject: Re: [Bugme-new] [Bug 10580] New: uvesafb is broken
>
>> 
>> uvesafb doesn't work anymore with the current git version. 
>v86d failed with the
>> following error:
>> 
>> Program v86d tried to access /dev/mem between a0000->110000.
>> v86d[255]: segfault at 7f1025c22000 ip 400da6 sp 
>7fff2dc3e1d0 error 6 in
>> v86d[400000+17000]
>> uvesafb: Getting VBE info block failed (eax=0x4f00, err=-3)
>> uvesafb: vbe_init() failed with -22
>> uvesafb: probe of uvesafb.0 failed with error -22
>> 
>> After having tried git-bisect, it seems that the first bad 
>commit which might
>> cause the problem is the following:
>> 
>> commit e2beb3eae627211b67e456c53f946cede2ac10d7
>> Author: Venki Pallipadi <venkatesh.pallipadi@intel.com>
>> Date:   Thu Mar 6 23:01:47 2008 -0800
>> 
>>     devmem: add range_is_allowed() check to mmap of /dev/mem
>>
>> I have tried to revert it on the current git (git16) but 
>it's not possible to
>> do so.
>> 
>> Steps to reproduce:
>
>Thanks for the report - it really helps.
>
>Was you setting of CONFIG_NONPROMISC_DEVMEM the same in both 
>-git7 and in
>-git8?
>
>
------- Comment #4 From Venkatesh Pallipadi 2008-04-30 16:45:54 [reply]
------- 
>We have the range_is_allowed check with and without
CONFIG_NONPROMISC_DEVMEM
>now!
>
>It is needed to prevent PAT aliasing. Looks like, the driver or user
app is
>trying to map the range a0000->110000, and atleast part of that range
is
>usable memory.
> BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 00000000bf6d0000 (usable)
>
>Thats the reason why mmap is failing.
>
>Now, we need to find who is mapping that memory and why. Looking at
uvesafb.c
>....

Looked at this a bit more..
v86d emulator seems to be hardcoding
mem_bios as 0x0a0000 - 0x10ffef

And mmaping the whole address and may be doing read write in that range
during the emulation.
But, as per e820 0x100000 onwards is usable memory and may be getting
used by kernel. So, surely there is some conflict here.

I am not sure whether it is the BIOS that is giving wrong E820 info or
is it the v86d emulator making assumption about this address wrongly.
One workaround is to make upto 0x10ffef as reserved and make kernel not
use it. But, we should really know why this problem is happening in the
first place, before going the workaround route.

Thanks,
Venki