linux-mips-fnet
[Top] [All Lists]

Re: mmap() frame buffer causes bus error on MIPS ...

To: linux-fbdev@vuser.vu.union.edu, linux-mips@oss.sgi.com, linux-mips@fnet.fr
Subject: Re: mmap() frame buffer causes bus error on MIPS ...
From: Jun Sun <jsun@mvista.com>
Date: Tue, 05 Sep 2000 22:48:43 -0700
References: <39B5BD14.A8D2F467@mvista.com>
Sender: jsun@hermes.mvista.com
Jun Sun wrote:
> 
> With the help from Attila, I got the latest tdfx framebuffer driver
> working on my NEC DDB5476 board.   I have console working based on this
> driver.
> 
> However, when I try to mmap frame buffer into user land, the mapping is
> succesful, but trying to read the buffer causes a bus error.
> 
> I tried to trace the kernel using gdb.  fb_mmap() seems to do the right
> thing :
> 
> 1) it calls fb->fb_get_fix() to get the buffer address, size, etc.  The
> values all look fine.  The address is physical address, pointing a
> mapped PCI memory block.  I verified that I can access that address in
> gdb.
> 
> 2) for MIPS, fb_mmap() turns off CACHE bit for the page.
> 
> I would imagine when the app tries to read the buffer, a TLB miss is
> generated.  TLB refill routine probably sets up the right TLB entry, and
> the app will try to read again, and get the content.  I really can't
> think of where the Bus error might occur.
> 
> Does anybody have a clue here?  Thanks a lot.
> 
> Jun

Did more probing on this.  It appears the TLB entry that gets filled is
not right, even though the original page entry is generated correctly. 
See below TLB dump.

The original page table still has the same value (not corrupted), and
the only explanation is that tlb_refill actually gets the entry from a
wrong place.  I then tried to decode tlb_refill code but really got lost
there.  (Is there an explanation about the page table setup?)

How could this be? Maybe the pte's are put in the wrong place to begin
with?  Ralf, please help ...

Jun

P.S., even though tlb entry is wrong, it does not explain the bus error,
because the wrong tlb entry does point to a physical memory area.  Hmm,
more questions ...

----------------

dump tlb for 0x2ac3d000 :
Entry 37 maps address 0x2ac3d000
Index: 37 pgmask=00000000 va=2ac3c000 asid=0000007b  [pa=000000 c=0 d=0
v=0 g=0]  [pa=2300000 c=2 d=0 v=1 g=0]
dump all tlb :
Index:  4 pgmask=00000000 va=2abbc000 asid=0000007b  [pa=0ff000 c=3 d=0
v=1 g=0]  [pa=000000 c=0 d=0 v=0 g=0]
Index: 10 pgmask=00000000 va=7fffe000 asid=0000007b  [pa=000000 c=0 d=0
v=0 g=0]  [pa=0f2000 c=3 d=1 v=1 g=0]
Index: 11 pgmask=00000000 va=10052000 asid=0000007b  [pa=000000 c=0 d=0
v=0 g=0]  [pa=0f0000 c=3 d=1 v=1 g=0]
Index: 30 pgmask=00000000 va=00424000 asid=0000007b  [pa=0f0000 c=3 d=0
v=1 g=0]  [pa=0f0000 c=3 d=0 v=1 g=0]

------------------

Where the pte's are :

(gdb) x/32 0x83ca30f0
0x83ca30f0:     0x00000000      0x8c00048f      0x8c001407     
0x8c002407
0x83ca3100:     0x8c003407      0x8c004407      0x8c005407     
0x8c006407
0x83ca3110:     0x8c007407      0x8c008407      0x8c009407     
0x8c00a407
0x83ca3120:     0x8c00b407      0x8c00c407      0x8c00d407     
0x8c00e407
0x83ca3130:     0x8c00f407      0x8c010407      0x8c011407     
0x8c012407
0x83ca3140:     0x8c013407      0x8c014407      0x8c015407     
0x8c016407
0x83ca3150:     0x8c017407      0x8c018407      0x8c019407     
0x8c01a407
0x83ca3160:     0x8c01b407      0x8c01c407      0x8c01d407     
0x8c01e407

<Prev in Thread] Current Thread [Next in Thread>