Subject: One good and some bad news

From: Thomas Bogendoerfer <[email-masked]>
Date: Sun, 12 Jul 1998 11:29:49 +0200

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 <[email-masked]>]

---

From: [email-masked]
Date: Sun, 12 Jul 1998 19:01:35 +0200

> Yesterday XF68_FBDev showed the first ugly gray X11 screen on my 

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.

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

> 			((((unsigned long)(addr)) & MAP_MASK) >> PAGE_SHIFT))

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

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

> 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

---

From: Thomas Bogendoerfer <[email-masked]>
Date: Sun, 12 Jul 1998 20:55:23 +0200

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

---

From: Thomas Bogendoerfer <[email-masked]>
Date: Sun, 12 Jul 1998 23:53:19 +0200

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

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.

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

> but the bits that might be set in the physical address corrosponding to a

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

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

---

From: [email-masked]
Date: Mon, 13 Jul 1998 02:36:06 +0200

> the X screen down. Looks like my "hardware" scrolling has some problems

Cool.

> give us some chances to find the real culprit. But it still hasn't happen

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.

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

> hmm, the produced binaries are working without problem.

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

  Ralf

---

From: Thomas Bogendoerfer <[email-masked]>
Date: Tue, 14 Jul 1998 00:08:25 +0200

> 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