lkml.org 
[lkml]   [2008]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRE: [Bugme-new] [Bug 10580] New: uvesafb is broken
Date
From


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


\
 
 \ /
  Last update: 2008-05-01 03:23    [W:0.048 / U:0.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site