Bug 10580

Created attachment 15990 [details]
kernel configuration file

Created attachment 15992 [details]
output of dmesg

Reply-To: akpm@linux-foundation.org

(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?

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 ....

 

>-----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 

<hpa> OK, this is *probably* a bug in the user space code
<hpa> It probably wants to map the legacy region, 0xa0000-0x100000, but it maps the wrong range
<hpa> There is no sane reason it should map 0xa0000..0x110000 that's preposterous
<hpa> An strace should verify that

Either that, or our in-kernel range check is broken.  Again, getting the strace would be highly useful.

It's a problem with the userspace helper (v86d).  I will release a fixed version in a few minutes.

Note: there is no legitimate reason for uvesafb to map memory used by the kernel.  The only legitimate areas for it to map are:

- The low BIOS page (0-4K)
- The EBDA (find the EBDA pointer in the low BIOS page and map from it up to 640K)
- The legacy I/O region (640-1024K)

Memory in between the low BIOS page and the EBDA, and above 1024K, are used by the kernel, and attempted access are potentially disastrous.  If necessary, the userspace code can map in anonymous readonly memory to those regions.

The problem is indeed solved with the new version of v86d (0.1.5). 
Thanks for your help.