One good and some bad news

One good and some bad news

[Thomas Bogendoerfer]

Hi,

first the good news: 

Yesterday XF68_FBDev showed the first ugly gray X11 screen on my 
Olivetti M700. Yeah !

But after killing the X server, I've got a dbe in check_tty_count.

This was the first bad news. To get XF68_FBDev to work, I had to
discover, that the logic with MAP_MASK is broken. When you look in
memory.c in function remap_pte_range(), you will find following:


                mapnr = MAP_NR(__va(phys_addr));
                if (mapnr >= max_mapnr || PageReserved(mem_map+mapnr))
                        set_pte(pte, mk_pte_phys(phys_addr, prot));


These works perfect for addresses in the first 512MB of address space
(MAP_MASK is 0x1fffffff), but it fails when you use 0x40000000 (frame
buffer address of the Olli). My first shot to fix that, was to use
0x7fffffff MAP_MASK, but resulted in a not working kernel, no idea why.
To cludge this problem I've changed the code:

                mapnr = MAP_NR(__va(phys_addr));
                if (mapnr >= max_mapnr || PageReserved(mem_map+mapnr))
                        set_pte(pte, mk_pte_phys(phys_addr, prot));
                if (phys_addr > MAP_MASK)
                        set_pte(pte, mk_pte_phys(__va(phys_addr), prot));

This works, but as this is common Linux code, Linus will never accept
it, even with a #ifdef __mips__ around the second if. While writing this
mail, I got an idea. Would it work, when we change MAP_NR to something like:

#define MAP_NR(addr)    (((addr) > MAP_MASK) ? 0xffffffff : \
			((((unsigned long)(addr)) & MAP_MASK) >> PAGE_SHIFT))

I'll try it later.

Another bad news, I've tried to build egcs. egcs itself build fine, but
when linking the shared library libstdc++, ld bombs out with a signal 6.
As I was still using binutils-2.8.1, I've compiled bintuils-2.9.1.0.4.
But the problem remains the same. I hope to get the gdb fixes from Ralf,
to look at this problem.

Binutils 2.9.1.0.4 seem to work ok, but I get following messages, when
linking programs:

ld: Warning: type of symbol `_fini' changed from 1 to 2 in /usr/lib/crti.o
ld: Warning: type of symbol `_gp_disp' changed from 1 to 3 in /lib/libc.so.6

I guess, it will go way, when I rebuild glibc with the new binutils, but
can someone explain to me, what's the reason for these messages.

Thomas.

-- 
See, you not only have to be a good coder to create a system like Linux,
you have to be a sneaky bastard too ;-)
                   [Linus Torvalds in <4rikft$7g5@linux.cs.Helsinki.FI>]

Re: One good and some bad news

[ralf]

On Sun, Jul 12, 1998 at 11:29:49AM +0200, Thomas Bogendoerfer wrote:

> first the good news: 
> 
> Yesterday XF68_FBDev showed the first ugly gray X11 screen on my 
> Olivetti M700. Yeah !

Does this mean the X Server which I've built is running without
changes?

> But after killing the X server, I've got a dbe in check_tty_count.

DBE has a nasty property, it can be delayed until some write access
is written back from cache to memory.  The EPC then often points to
completly useless addresses.

> This was the first bad news. To get XF68_FBDev to work, I had to
> discover, that the logic with MAP_MASK is broken. When you look in
> memory.c in function remap_pte_range(), you will find following:
> 
> 
>                 mapnr = MAP_NR(__va(phys_addr));
>                 if (mapnr >= max_mapnr || PageReserved(mem_map+mapnr))
>                         set_pte(pte, mk_pte_phys(phys_addr, prot));
> 
> 
> These works perfect for addresses in the first 512MB of address space
> (MAP_MASK is 0x1fffffff), but it fails when you use 0x40000000 (frame
> buffer address of the Olli). My first shot to fix that, was to use
> 0x7fffffff MAP_MASK, but resulted in a not working kernel, no idea why.

Some places in the kernel also pass uncached addresses to MAP_NR().  In
order to make that work right I decieded back in '94 to mask out everything
but the bits that might be set in the physical address corrosponding to a
KSEG0 address.

Fix: try to track down the places that pass something else than a KSEG0
address for RAM, convert the addresses to KSEG0.  Eleminate the entire
MAP_MASK thing.  Change __va() such that it can deals properly with
addresses >= 512mb.

The Olli case is somewhat special because the designers had the gorgeuous
idea of placing some peripherals outside the lowest 4gb therefore more
fun with EISA mappings for example ahead ...

> To cludge this problem I've changed the code:
> 
>                 mapnr = MAP_NR(__va(phys_addr));
>                 if (mapnr >= max_mapnr || PageReserved(mem_map+mapnr))
>                         set_pte(pte, mk_pte_phys(phys_addr, prot));
>                 if (phys_addr > MAP_MASK)
>                         set_pte(pte, mk_pte_phys(__va(phys_addr), prot));
> 
> This works, but as this is common Linux code, Linus will never accept
> it, even with a #ifdef __mips__ around the second if. While writing this
> mail, I got an idea. Would it work, when we change MAP_NR to something like:
> 
> #define MAP_NR(addr)    (((addr) > MAP_MASK) ? 0xffffffff : \
> 			((((unsigned long)(addr)) & MAP_MASK) >> PAGE_SHIFT))
> 
> I'll try it later.

Which is basically my suggestion from above.  I'd just prefer to see the
fix in __va.

> Another bad news, I've tried to build egcs. egcs itself build fine, but
> when linking the shared library libstdc++, ld bombs out with a signal 6.
> As I was still using binutils-2.8.1, I've compiled bintuils-2.9.1.0.4.
> But the problem remains the same. I hope to get the gdb fixes from Ralf,
> to look at this problem.
> 
> Binutils 2.9.1.0.4 seem to work ok, but I get following messages, when
> linking programs:
> 
> ld: Warning: type of symbol `_fini' changed from 1 to 2 in /usr/lib/crti.o

That's data object -> code object.

> ld: Warning: type of symbol `_gp_disp' changed from 1 to 3 in /lib/libc.so.6

And this is a data object -> section symbol.

These type of warning messae often indicate serious trouble.

> I guess, it will go way, when I rebuild glibc with the new binutils, but
> can someone explain to me, what's the reason for these messages.

In ELF every symbol has a type and a size.  If linker encounters conflicting
definitions, it will issue warnings.

Note that the symbol _gp_disp is absolute black magic used for MIPS PIC code.
References against it are automatically generated by the assembler and
resolved by the linker.  It's never defined or referenced in normal source
code.  I'm therefore somewhat worried.

  Ralf

Re: One good and some bad news

[Thomas Bogendoerfer]

On Sun, Jul 12, 1998 at 11:29:49AM +0200, Thomas Bogendoerfer wrote:
> This was the first bad news. To get XF68_FBDev to work, I had to
> discover, that the logic with MAP_MASK is broken. When you look in

ok, I've found a solution for this problem by just using what the other
ports are using for MAP_NR(). I also fixed the mk_pte_phys(), which was
broken, too. Below is the patch I'm currently using. The problem with
the dbe after quiting the X server, didn't happen again. 

Thomas.

Index: include/asm/page.h
===================================================================
RCS file: /var/mips/linus/cvs/linux/include/asm-mips/page.h,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 page.h
--- page.h	1997/06/01 03:17:11	1.1.1.1
+++ page.h	1998/07/12 18:50:11
@@ -76,8 +76,7 @@
 #define PAGE_OFFSET	0x80000000UL
 #define __pa(x)		((unsigned long) (x) - PAGE_OFFSET)
 #define __va(x)		((void *)((unsigned long) (x) + PAGE_OFFSET))
-#define MAP_MASK        0x1fffffffUL
-#define MAP_NR(addr)	((((unsigned long)(addr)) & MAP_MASK) >> PAGE_SHIFT)
+#define MAP_NR(addr)	(__pa(addr) >> PAGE_SHIFT)
 
 #endif /* defined (__KERNEL__) */
 
Index: include/asm/pgtable.h
===================================================================
RCS file: /var/mips/linus/cvs/linux/include/asm-mips/pgtable.h,v
retrieving revision 1.11
diff -u -r1.11 pgtable.h
--- pgtable.h	1998/03/17 22:16:15	1.11
+++ pgtable.h	1998/07/12 17:57:22
@@ -346,7 +346,7 @@
 
 extern inline pte_t mk_pte_phys(unsigned long physpage, pgprot_t pgprot)
 {
-	return __pte((physpage - PAGE_OFFSET) | pgprot_val(pgprot));
+	return __pte(physpage | pgprot_val(pgprot));
 }
 
 extern inline pte_t pte_modify(pte_t pte, pgprot_t newprot)


-- 
See, you not only have to be a good coder to create a system like Linux,
you have to be a sneaky bastard too ;-)
                   [Linus Torvalds in <4rikft$7g5@linux.cs.Helsinki.FI>]

Re: One good and some bad news

[Thomas Bogendoerfer]

On Sun, Jul 12, 1998 at 07:01:35PM +0200, ralf@uni-koblenz.de wrote:
> On Sun, Jul 12, 1998 at 11:29:49AM +0200, Thomas Bogendoerfer wrote:
> 
> > first the good news: 
> > 
> > Yesterday XF68_FBDev showed the first ugly gray X11 screen on my 
> > Olivetti M700. Yeah !
> 
> Does this mean the X Server which I've built is running without
> changes?

no, that's the one I've built:-) But it's made with your XFree patch
and an updated .spec file for the latest RH5.1 package (XFree86-3.3.2-13).
A couple of hours ago, I had X with window manager and application running
(PS/2 mouse works, too). There is only one small problem left, when scrolling
the X screen down. Looks like my "hardware" scrolling has some problems
with graphics.

> DBE has a nasty property, it can be delayed until some write access
> is written back from cache to memory.  The EPC then often points to
> completly useless addresses.

good to know, as the address was really bogus. Is there a chance to
print out the faulting physical address for a bus error ? This would
give us some chances to find the real culprit. But it still hasn't happen
again.

> Some places in the kernel also pass uncached addresses to MAP_NR().  In
> order to make that work right I decieded back in '94 to mask out everything
> but the bits that might be set in the physical address corrosponding to a
> KSEG0 address.

hmm, I've checked the MAP_NR() in the kernel, and couldn't find such
cases. In fact my changed kernel works perfect.

> The Olli case is somewhat special because the designers had the gorgeuous
> idea of placing some peripherals outside the lowest 4gb therefore more
> fun with EISA mappings for example ahead ...

I know. 

> These type of warning messae often indicate serious trouble.

hmm, the produced binaries are working without problem.

Thomas.

-- 
See, you not only have to be a good coder to create a system like Linux,
you have to be a sneaky bastard too ;-)
                   [Linus Torvalds in <4rikft$7g5@linux.cs.Helsinki.FI>]

Re: One good and some bad news

[ralf]

On Sun, Jul 12, 1998 at 11:53:19PM +0200, Thomas Bogendoerfer wrote:

> no, that's the one I've built:-) But it's made with your XFree patch
> and an updated .spec file for the latest RH5.1 package (XFree86-3.3.2-13).
> A couple of hours ago, I had X with window manager and application running
> (PS/2 mouse works, too). There is only one small problem left, when scrolling
> the X screen down. Looks like my "hardware" scrolling has some problems
> with graphics.

Cool.

> > DBE has a nasty property, it can be delayed until some write access
> > is written back from cache to memory.  The EPC then often points to
> > completly useless addresses.
> 
> good to know, as the address was really bogus. Is there a chance to
> print out the faulting physical address for a bus error ? This would
> give us some chances to find the real culprit. But it still hasn't happen
> again.

Basically what to do would be to modify the kernel such that it will work
with caches disabled.  Then you get (almost) precise exceptions again.
Alternative and with less impact on the performance you could try to
writeback the caches in strategic positions for debugging.  That makes a
kind of a barrier for DBE exceptions.

> hmm, I've checked the MAP_NR() in the kernel, and couldn't find such
> cases. In fact my changed kernel works perfect.

Good.  Long time ago we had such cases in the kernel; it's why MAP_NR
does things the way it does.  But I admit, when I wrote my last posting
I could recall what I needed that stuff for.

You patch looks good, could you commit it?  Thanks.

> > These type of warning messae often indicate serious trouble.
> 
> hmm, the produced binaries are working without problem.

Hmmm ...  Modify write(2) to not print these messages ;-)

  Ralf

Re: One good and some bad news

[Thomas Bogendoerfer]

On Mon, Jul 13, 1998 at 02:36:06AM +0200, ralf@uni-koblenz.de wrote:
> On Sun, Jul 12, 1998 at 11:53:19PM +0200, Thomas Bogendoerfer wrote:
> > good to know, as the address was really bogus. Is there a chance to
> > print out the faulting physical address for a bus error ? This would
> > give us some chances to find the real culprit. But it still hasn't happen
> > again.
> 
> Basically what to do would be to modify the kernel such that it will work
> with caches disabled.  Then you get (almost) precise exceptions again.
> Alternative and with less impact on the performance you could try to
> writeback the caches in strategic positions for debugging.  That makes a
> kind of a barrier for DBE exceptions.

ugly. I hope, that I won't need it.

> You patch looks good, could you commit it?  Thanks.

I do, when I've merged my stuff with the latest CVS commits. 

Thomas

-- 
See, you not only have to be a good coder to create a system like Linux,
you have to be a sneaky bastard too ;-)
                   [Linus Torvalds in <4rikft$7g5@linux.cs.Helsinki.FI>]