From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
To: linux-mips@fnet.fr, linux@cthulhu.engr.sgi.com
Subject: One good and some bad news
Date: Sun, 12 Jul 1998 11:29:49 +0200 [thread overview]
Message-ID: <19980712112949.25350@alpha.franken.de> (raw)
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>]
next reply other threads:[~1998-07-12 10:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-07-12 9:29 Thomas Bogendoerfer [this message]
1998-07-12 17:01 ` One good and some bad news ralf
1998-07-12 21:53 ` Thomas Bogendoerfer
1998-07-13 0:36 ` ralf
1998-07-13 22:08 ` Thomas Bogendoerfer
1998-07-12 18:55 ` Thomas Bogendoerfer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=19980712112949.25350@alpha.franken.de \
--to=tsbogend@alpha.franken.de \
--cc=linux-mips@fnet.fr \
--cc=linux@cthulhu.engr.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox