* Kernel 2.6 for R4600 Indy
@ 2004-09-23 13:54 Stuart Longland
2004-09-23 14:51 ` Ladislav Michl
` (2 more replies)
0 siblings, 3 replies; 23+ messages in thread
From: Stuart Longland @ 2004-09-23 13:54 UTC (permalink / raw)
To: linux-mips
[-- Attachment #1: Type: text/plain, Size: 6033 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi All,
I've been trying to get Linux 2.6 going on my Indy for some time now.
However, I've had little success. The machine works just fine under
Linux 2.4.26.
The kernel config is attached. Basically I've tried both booting a
MIPS32 kernel as well as a MIPS64 kernel. In all cases, I've used the
same kernel parameters. (root=/dev/hda3, and sometimes I put
init=/bin/sh or single there too.)
Using a MIPS32 config, the kernel boots, mounts the / filesystem, but
then dies claiming it can't find /sbin/init.
Using a MIPS64 config (built using gas-abi=o32 as suggested by Kumba),
it doesn't even get that far:
- From arcboot/SGI PROM:
(Arcboot version 0.3.8.2)
- -------------------------------8<--------------------------------------
Loading program segment 2 at 0x88002000, offset=0x0, size= 0x0 328085
Zeroing memory at 0x0032a085, size = 0x1bba3
Exception: <vector=Normal>
Status register: 0x30004803<CU1,CU0,IM7,IM4,IPL=???,MODE=KERNEL,EXL,IE>
Cause register: 0x8010<CE=0,IP8,EXC=RADE>
Exception PC: 0x830f018, Exception RA: 0x88804514
Read address error exception, bad address: 0x830f018
Local I/O interrupt register 1: 0x80 <VR/GIO2>
Saved user regs in hex (&gpda 0xa8740e48, &_regs 0xa8741048):
arg: a8740000 88002000 88001fe0 18
tmp: a8740000 3 8880e0b4 830f018 8880e0b0 887fe8ec 887fe5e4 4
sve: a8740000 3 400000 800000 16 3f80 0 10000000
t8 a8740000 t9 ffffffff at ffffffff v0 ffffffff v1 ffffffff k1 830f018
gp a8740000 f0 ffffffff sp ffffffff ra ffffffff
PANIC: Unexpected exception
[Press reset or ENTER to restart.]
- ------------------------------->8--------------------------------------
Now, according to the Linux-MIPS website:
- -------------------------------8<--------------------------------------
*Self-compiled kernels crash when booting.*
When I build my own kernel, it crashes. On an Indy the crash message
looks like the following (the same problem hits other machines as well
but may look completely different):
Exception: <vector=UTLB Miss>
Status register: 0x300004803<CU1,CU0,IM4,IPL=???,MODE=KERNEL,EXL,IE>
Cause register: 0x8008<CE=0,IP8,EXC=RMISS>
Exception PC: 0x881385cc, Exception RA: 0x88002614
exception, bad address: 0x47c4
Local I/O interrupt register 1: 0x80 <VR/GIO2>
Saved user regs in hex (&gpda 0xa8740e48, &_regs 0xa8741048):
arg: 7 8bfff938 8bfffc4d 880025dc
tmp: 8818c14c 8818c14c 10 881510c4 14 8bfad9e0 0 48
sve: 8bfdf3e8 8bfffc40 8bfb2720 8bfff938 a8747420 9fc56394 0 9fc56394
t8 48 t9 8bfffee66 at 1 v0 0 v1 8bfff890 k1 bad11bad
gp 881dfd90 fp 9fc4be88 sp 8bfff8b8 ra 88002614
PANIC: Unexpected exception
This problem is caused by a still unfixed bug in Binutils newer than
version 2.7. As a workaround, change the following line in
arch/mips/Makefile from:
LINKFLAGS = -static -N
to:
LINKFLAGS = -static
- ------------------------------->8--------------------------------------
This looks scaringly similar to what I've already struck. Certainly
the Status Register is almost identical. I've also had it come up UTLB
Miss as well.
It seems though, the fix is more illusive. Looking at
arch/mips/Makefile, there's no LINKFLAGS line. The closest thing I see
is LDFLAGS_vmlinux:
LDFLAGS_vmlinux += -G 0 -static -n
The binutils/gcc versions I'm using are cross compillers generated using
crossdev:
MIPS32 binutils:
GNU assembler 2.14.90.0.8 20040114
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License. This program has absolutely no warranty.
This assembler was configured for a target of `mips-unknown-linux-gnu'.
MIPS64 binutils:
GNU assembler 2.14.90.0.8 20040114
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License. This program has absolutely no warranty.
This assembler was configured for a target of `mips64-unknown-linux-gnu'.
MIPS32 gcc:
mips-unknown-linux-gnu-gcc (GCC) 3.3.3 20040217 (Gentoo Linux 3.3.3,
propolice-3.3-7)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
MIPS64 gcc:
mips64-unknown-linux-gnu-gcc (GCC) 3.3.3 20040217 (Gentoo Linux 3.3.3,
propolice-3.3-7)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Has this bug actually been fixed? It seems the documentation here is a
little lacking as to what to change.
The machine's specs:
CPU: R4600 SC 133MHz [1]
RAM: 256MB 72pin EDO
HDD: 9.1GB IBM
OS: Gentoo Linux/MIPS 1.4
Apologies if this has been answered before... but I'm a bit of a newbie
when it comes to Linux/MIPS.[2] Is there anything I missed when setting
this all up?
Reguards,
- --
+-------------------------------------------------------------+
| Stuart Longland -oOo- http://stuartl.longlandclan.hopto.org |
| Atomic Linux Project -oOo- http://atomicl.berlios.de |
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - |
| I haven't lost my mind - it's backed up on a tape somewhere |
+-------------------------------------------------------------+
Footnotes:
1. A brief look at the MIPS Technologies website had me thinking that
only R5k and above are 64-bit, the R4k were 32-bit. But it seems that
these too are 64-bit capable.
2. I'll admit though... I've learned more about the innards of a
computer playing with the Indy and Qube I own then I have from the last
two years of university study.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBUtWLuarJ1mMmSrkRAvIZAJ0QuwKzWGg3rRk9nzEU17bLfc38MgCfarfQ
+XK9eCVUaC88I5KtBh8fXjE=
=SIHi
-----END PGP SIGNATURE-----
[-- Attachment #2: config.gz --]
[-- Type: application/x-gzip, Size: 4313 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: Kernel 2.6 for R4600 Indy 2004-09-23 13:54 Kernel 2.6 for R4600 Indy Stuart Longland @ 2004-09-23 14:51 ` Ladislav Michl 2004-09-23 15:00 ` Stephen P. Becker 2004-09-23 15:48 ` Florian Lohoff 2 siblings, 0 replies; 23+ messages in thread From: Ladislav Michl @ 2004-09-23 14:51 UTC (permalink / raw) To: Stuart Longland; +Cc: linux-mips On Thu, Sep 23, 2004 at 11:54:19PM +1000, Stuart Longland wrote: > Hi All, > I've been trying to get Linux 2.6 going on my Indy for some time now. > However, I've had little success. The machine works just fine under > Linux 2.4.26. > > The kernel config is attached. Basically I've tried both booting a > MIPS32 kernel as well as a MIPS64 kernel. In all cases, I've used the > same kernel parameters. (root=/dev/hda3, and sometimes I put > init=/bin/sh or single there too.) > > Using a MIPS32 config, the kernel boots, mounts the / filesystem, but > then dies claiming it can't find /sbin/init. > > Using a MIPS64 config (built using gas-abi=o32 as suggested by Kumba), > it doesn't even get that far: > > - From arcboot/SGI PROM: > (Arcboot version 0.3.8.2) > - -------------------------------8<-------------------------------------- > Loading program segment 2 at 0x88002000, offset=0x0, size= 0x0 328085 > Zeroing memory at 0x0032a085, size = 0x1bba3 > > Exception: <vector=Normal> > Status register: 0x30004803<CU1,CU0,IM7,IM4,IPL=???,MODE=KERNEL,EXL,IE> > Cause register: 0x8010<CE=0,IP8,EXC=RADE> > Exception PC: 0x830f018, Exception RA: 0x88804514 > Read address error exception, bad address: 0x830f018 > Local I/O interrupt register 1: 0x80 <VR/GIO2> > Saved user regs in hex (&gpda 0xa8740e48, &_regs 0xa8741048): > arg: a8740000 88002000 88001fe0 18 > tmp: a8740000 3 8880e0b4 830f018 8880e0b0 887fe8ec 887fe5e4 4 > sve: a8740000 3 400000 800000 16 3f80 0 10000000 > t8 a8740000 t9 ffffffff at ffffffff v0 ffffffff v1 ffffffff k1 830f018 > gp a8740000 f0 ffffffff sp ffffffff ra ffffffff > > PANIC: Unexpected exception If that's more than two hours old CVS kernel then it's my fault, already fixed. [snip] > Apologies if this has been answered before... but I'm a bit of a newbie > when it comes to Linux/MIPS.[2] Is there anything I missed when setting > this all up? We have both Indy and O2 running there, but you'll have to wait a bit until patches appear in CVS. Regards, ladis ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Kernel 2.6 for R4600 Indy 2004-09-23 13:54 Kernel 2.6 for R4600 Indy Stuart Longland 2004-09-23 14:51 ` Ladislav Michl @ 2004-09-23 15:00 ` Stephen P. Becker 2004-09-24 0:16 ` Stuart Longland 2004-09-23 15:48 ` Florian Lohoff 2 siblings, 1 reply; 23+ messages in thread From: Stephen P. Becker @ 2004-09-23 15:00 UTC (permalink / raw) To: Stuart Longland; +Cc: linux-mips > Using a MIPS64 config (built using gas-abi=o32 as suggested by Kumba), > it doesn't even get that far: This is certainly wrong. What you really want is gas-abi=o64. Take a look at the O2 minimum patchset at http://www.total-knowledge.com, as the arch/mips/Makefile changes are what you need. Using a 64-bit kernel on your indy is pointless unless you want to run n32 userland anyhow. As of this moment (may change in the future), 2.4 kernels are much better for ip22 anyhow. Serial console, indycam, and sound all work properly in 2.4. In 2.6, serial console is broken, there is no indycam support, and I'm running into some issues with sound where the cpu usage runs way up. Steve ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Kernel 2.6 for R4600 Indy 2004-09-23 15:00 ` Stephen P. Becker @ 2004-09-24 0:16 ` Stuart Longland 2004-09-24 9:07 ` Florian Lohoff 2004-09-24 13:05 ` Stephen P. Becker 0 siblings, 2 replies; 23+ messages in thread From: Stuart Longland @ 2004-09-24 0:16 UTC (permalink / raw) To: Stephen P. Becker; +Cc: linux-mips -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen P. Becker wrote: >> Using a MIPS64 config (built using gas-abi=o32 as suggested by >> Kumba), >> it doesn't even get that far: > > This is certainly wrong. What you really want is gas-abi=o64. Take a > look at the O2 minimum patchset at http://www.total-knowledge.com, as > the arch/mips/Makefile changes are what you need. Using a 64-bit kernel > on your indy is pointless unless you want to run n32 userland anyhow. Ahh yes... sorry, it was after midnight (GMT+10) and my mind must've been elsewhere -- I meant o64. I was planning on moving to either n32 or n64 userland eventually, but I won't do that unless I can get a 64-bit kernel going. > As of this moment (may change in the future), 2.4 kernels are much > better for ip22 anyhow. Serial console, indycam, and sound all work > properly in 2.4. In 2.6, serial console is broken, there is no indycam > support, and I'm running into some issues with sound where the cpu usage > runs way up. Right. Luckily I've got a framebuffer that Linux can talk to and I haven't got an indycam. But the sound issue may be a problem, I was thinking at one point to use this box as a jukebox, but at the moment I'm experimenting with mips64 to see what it can do. I'll have a look at those patches & the O2 documentation, that should give me some leads into sorting out the issue. It would be nice to see if I can squeeze better performance out of the aging beast. - -- +-------------------------------------------------------------+ | Stuart Longland -oOo- http://stuartl.longlandclan.hopto.org | | Atomic Linux Project -oOo- http://atomicl.berlios.de | | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | | I haven't lost my mind - it's backed up on a tape somewhere | +-------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD4DBQFBU2dluarJ1mMmSrkRAvLAAJiGRTLJlg3stJyjA3bRYmM2a/aLAJ0TmcsJ mpAfZVjU/2YHo1OoZp8D7Q== =mUN8 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Kernel 2.6 for R4600 Indy 2004-09-24 0:16 ` Stuart Longland @ 2004-09-24 9:07 ` Florian Lohoff 2004-09-24 15:42 ` Stuart Longland 2004-09-24 13:05 ` Stephen P. Becker 1 sibling, 1 reply; 23+ messages in thread From: Florian Lohoff @ 2004-09-24 9:07 UTC (permalink / raw) To: Stuart Longland; +Cc: Stephen P. Becker, linux-mips [-- Attachment #1: Type: text/plain, Size: 788 bytes --] On Fri, Sep 24, 2004 at 10:16:37AM +1000, Stuart Longland wrote: > Ahh yes... sorry, it was after midnight (GMT+10) and my mind must've > been elsewhere -- I meant o64. I was planning on moving to either n32 > or n64 userland eventually, but I won't do that unless I can get a > 64-bit kernel going. The 64 bit kernel should work so far - With the ip22zilog.c fixes tsbogend just committed the console begins to work again. Includeing the patch i sent earlier my R5k Indy boots fine a 64bit current cvs head and goes into userspace. Using the "soo to be" rtc and statfs64 fixes everything seems to be fine for o32 userspace. Flo -- Florian Lohoff flo@rfc822.org +49-171-2280134 Heisenberg may have been here. [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Kernel 2.6 for R4600 Indy 2004-09-24 9:07 ` Florian Lohoff @ 2004-09-24 15:42 ` Stuart Longland 2004-09-24 16:44 ` Florian Lohoff 0 siblings, 1 reply; 23+ messages in thread From: Stuart Longland @ 2004-09-24 15:42 UTC (permalink / raw) To: Florian Lohoff; +Cc: Stephen P. Becker, linux-mips -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Florian Lohoff wrote: > On Fri, Sep 24, 2004 at 10:16:37AM +1000, Stuart Longland wrote: > >>Ahh yes... sorry, it was after midnight (GMT+10) and my mind must've >>been elsewhere -- I meant o64. I was planning on moving to either n32 >>or n64 userland eventually, but I won't do that unless I can get a >>64-bit kernel going. > > The 64 bit kernel should work so far - With the ip22zilog.c fixes > tsbogend just committed the console begins to work again. > > Includeing the patch i sent earlier my R5k Indy boots fine a 64bit > current cvs head and goes into userspace. > > Using the "soo to be" rtc and statfs64 fixes everything seems to be > fine for o32 userspace. Tried the patch, for some reason 'patch' couldn't find some of the files, and was expecting me to enter the paths in by hand... but once I did that, it applied cleanly[1]. I still get much the same message from the PROM though: - -------------------------------8<-------------------------------------- arcsboot: ARCS Linux ext2fs loader 0.3.8.2 Loading new from scsi(0)disk(1)rdisk(0)partition(0) Allocated 0xe0 bytes for segments Loading 64-bit executable Loading program segment 2 at 0x88004000, offset=0x0 4000, size = 0x0 35b140 Loading program segment 3 at 0x88360020, offset=0x0 360020, size= 0x0 1c065 Zeroing memory at 0x8837c085 size = 0x21feb Exception: <vector=Normal> Status register: 0x30004803<CU1,CU0,IM7,IM4,IPL=???,MODE=KERNEL,EXL,IE> Cause register: 0x8010<CE=0,IP8,EXC=RADE> Exception PC: 0x830f018, Exception RA: 0x88804514 Read address error exception, bad address: 0x830f018 Local I/O interrupt register 1: 0x80 <VR/GIO2> Saved user regs in hex (&gpda 0xa8740e48, &_regs 0xa8741048): arg: a8740000 88002000 88001fe0 18 tmp: a8740000 2 8880e0b4 8360020 8880e0b0 887fe53c 887fe234 9fc55064 sve: a8740000 3 400000 8000000 16 3f80 0 10000000 t8 a8740000 t9 ffffffff at ffffffff v0 ffffffff v1 ffffffff k1 8360020 gp a8740000 f0 ffffffff sp ffffffff ra ffffffff PANIC: Unexpected exception [Press reset or ENTER to restart.] - ------------------------------->8-------------------------------------- Bypassing arcboot, I get: - -------------------------------8<-------------------------------------- >> boot -f newlinux root=/dev/sda3 Exception: <vector=UTLB Miss> Status register: 0x30004803<CU1,CU0,IM7,IM4,IPL=???,MODE=KERNEL,EXL,IE> Cause register: 0x8008<CE=0,IP8,EXC=RMISS> Exception PC: 0x9fc31644, Exception RA: 0x9fc3161c exception, bad address: 0x8 Local I/O interrupt register 1: 0x80 <VR/GIO2> Saved user regs in hex (&gpda 0xa8740e48, &_regs 0xa8741048): arg: a8740000 0 0 887fe878 tmp: a8740000 0 887fec2c 2d 887fe8d8 887fec20 a8746d10 9fc55064 sve: a8740000 3 400000 8000000 16 3f80 0 10000000 t8 a8740000 t9 ffffffff at ffffffff v0 ffffffff v1 ffffffff k1 0 gp a8740000 f0 ffffffff sp ffffffff ra ffffffff PANIC: Unexpected exception [Press reset or ENTER to restart.] - ------------------------------->8-------------------------------------- The latter one is very much like the one mentioned on the website I quoted earlier... but as I mentioned then, the fix doesn't seem to apply to the latest code. I can't rule out it being something with my config though. Has someone got a working config for mips64 on this class of machine? (even a binary) Seeing as it works on R5k, could we be dealing with an R4x00 bug here? - -- +-------------------------------------------------------------+ | Stuart Longland -oOo- http://stuartl.longlandclan.hopto.org | | Atomic Linux Project -oOo- http://atomicl.berlios.de | | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | | I haven't lost my mind - it's backed up on a tape somewhere | +-------------------------------------------------------------+ 1. except the Makefile and spaces.h files... it for some reason tried patching linux/{Makefile,spaces.h} not linux/arch/... etc... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBVEB6uarJ1mMmSrkRAh6DAKCBBbry3yjtMkfZ9lFgGyfguSsPnwCeKRAz UQOls5vmXNIkDNICUj77e80= =+PVx -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Kernel 2.6 for R4600 Indy 2004-09-24 15:42 ` Stuart Longland @ 2004-09-24 16:44 ` Florian Lohoff 0 siblings, 0 replies; 23+ messages in thread From: Florian Lohoff @ 2004-09-24 16:44 UTC (permalink / raw) To: Stuart Longland; +Cc: Stephen P. Becker, linux-mips [-- Attachment #1: Type: text/plain, Size: 1896 bytes --] On Sat, Sep 25, 2004 at 01:42:50AM +1000, Stuart Longland wrote: > > > > The 64 bit kernel should work so far - With the ip22zilog.c fixes > > tsbogend just committed the console begins to work again. > > > > Includeing the patch i sent earlier my R5k Indy boots fine a 64bit > > current cvs head and goes into userspace. > > > > Using the "soo to be" rtc and statfs64 fixes everything seems to be > > fine for o32 userspace. > > Tried the patch, for some reason 'patch' couldn't find some of the > files, and was expecting me to enter the paths in by hand... but once I > did that, it applied cleanly[1]. The last file has a bogus path (Hand crafted patch) and needs the first path element removed IIRC. > Exception: <vector=Normal> > Status register: 0x30004803<CU1,CU0,IM7,IM4,IPL=???,MODE=KERNEL,EXL,IE> > Cause register: 0x8010<CE=0,IP8,EXC=RADE> > Exception PC: 0x830f018, Exception RA: 0x88804514 > Read address error exception, bad address: 0x830f018 >Local I/O interrupt register 1: 0x80 <VR/GIO2> > Saved user regs in hex (&gpda 0xa8740e48, &_regs 0xa8741048): > arg: a8740000 88002000 88001fe0 18 > tmp: a8740000 2 8880e0b4 8360020 8880e0b0 887fe53c 887fe234 9fc55064 > sve: a8740000 3 400000 8000000 16 3f80 0 10000000 > t8 a8740000 t9 ffffffff at ffffffff v0 ffffffff v1 ffffffff k1 8360020 > gp a8740000 f0 ffffffff sp ffffffff ra ffffffff > > PANIC: Unexpected exception This should be a crash in free_bootmem_core because of the non correct spaces.h > I can't rule out it being something with my config though. Has someone > got a working config for mips64 on this class of machine? (even a > binary) Seeing as it works on R5k, could we be dealing with an R4x00 > bug here? Flo -- Florian Lohoff flo@rfc822.org +49-171-2280134 Heisenberg may have been here. [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Kernel 2.6 for R4600 Indy 2004-09-24 0:16 ` Stuart Longland 2004-09-24 9:07 ` Florian Lohoff @ 2004-09-24 13:05 ` Stephen P. Becker 2004-09-24 13:17 ` Robin Humble 1 sibling, 1 reply; 23+ messages in thread From: Stephen P. Becker @ 2004-09-24 13:05 UTC (permalink / raw) To: Stuart Longland; +Cc: linux-mips > Ahh yes... sorry, it was after midnight (GMT+10) and my mind must've > been elsewhere -- I meant o64. I was planning on moving to either n32 > or n64 userland eventually, but I won't do that unless I can get a > 64-bit kernel going. > Heh...I hope you are prepared for a significant slowdown if you end up trying to run n64 userland on such a machine. Steve ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Kernel 2.6 for R4600 Indy 2004-09-24 13:05 ` Stephen P. Becker @ 2004-09-24 13:17 ` Robin Humble 2004-09-24 13:27 ` Stephen P. Becker 0 siblings, 1 reply; 23+ messages in thread From: Robin Humble @ 2004-09-24 13:17 UTC (permalink / raw) To: linux-mips On Fri, Sep 24, 2004 at 09:05:17AM -0400, Stephen P. Becker wrote: >Heh...I hope you are prepared for a significant slowdown if you end up >trying to run n64 userland on such a machine. why's that? cheers, robin ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Kernel 2.6 for R4600 Indy 2004-09-24 13:17 ` Robin Humble @ 2004-09-24 13:27 ` Stephen P. Becker 2004-09-24 13:43 ` Robin Humble 0 siblings, 1 reply; 23+ messages in thread From: Stephen P. Becker @ 2004-09-24 13:27 UTC (permalink / raw) To: Robin Humble; +Cc: linux-mips Robin Humble wrote: > On Fri, Sep 24, 2004 at 09:05:17AM -0400, Stephen P. Becker wrote: > >>Heh...I hope you are prepared for a significant slowdown if you end up >>trying to run n64 userland on such a machine. > > > why's that? > Mostly, 64-bit binaries are much larger than 32-bit. Consider that the scsi controller in an Indy gets about 2mb/sec throughput MAX (on a good day). Also, Indys don't support a large enough memory configuration that 64-bit would be worth it anyhow. What you would *really* want on such a machine would be n32 userland. You get full 64-bit instructions, but the binaries aren't huge. Steve ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Kernel 2.6 for R4600 Indy 2004-09-24 13:27 ` Stephen P. Becker @ 2004-09-24 13:43 ` Robin Humble 2004-09-24 15:13 ` Stephen P. Becker 0 siblings, 1 reply; 23+ messages in thread From: Robin Humble @ 2004-09-24 13:43 UTC (permalink / raw) To: linux-mips On Fri, Sep 24, 2004 at 09:27:44AM -0400, Stephen P. Becker wrote: >Mostly, 64-bit binaries are much larger than 32-bit. Consider that the >scsi controller in an Indy gets about 2mb/sec throughput MAX (on a good /usr/bin/e* on i386 vs x86_64 is 17432 vs 12440 kB => about 40% bigger. so indeed that's a fair bit larger :-) I didn't think it was quite as bad as 2MB/s though, maybe 4. I'll dig my Indys out of storage and give them a whirl. >day). Also, Indys don't support a large enough memory configuration >that 64-bit would be worth it anyhow. indeed they don't. do you get access to more registers or more efficient instruction sets like you do on x86_64? >What you would *really* want on such a machine would be n32 userland. >You get full 64-bit instructions, but the binaries aren't huge. fair enough. cheers, robin ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Kernel 2.6 for R4600 Indy 2004-09-24 13:43 ` Robin Humble @ 2004-09-24 15:13 ` Stephen P. Becker 0 siblings, 0 replies; 23+ messages in thread From: Stephen P. Becker @ 2004-09-24 15:13 UTC (permalink / raw) To: Robin Humble; +Cc: linux-mips >>day). Also, Indys don't support a large enough memory configuration >>that 64-bit would be worth it anyhow. > > > indeed they don't. > do you get access to more registers or more efficient instruction sets > like you do on x86_64? > > >>What you would *really* want on such a machine would be n32 userland. >>You get full 64-bit instructions, but the binaries aren't huge. > Yeah, that is what n32 is for. You get more registers, but pointers are still 32-bit. You still need a mips64 CHOST to build n32 binaries, however. Steve ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Kernel 2.6 for R4600 Indy 2004-09-23 13:54 Kernel 2.6 for R4600 Indy Stuart Longland 2004-09-23 14:51 ` Ladislav Michl 2004-09-23 15:00 ` Stephen P. Becker @ 2004-09-23 15:48 ` Florian Lohoff 2004-10-02 18:50 ` Thiemo Seufer 2 siblings, 1 reply; 23+ messages in thread From: Florian Lohoff @ 2004-09-23 15:48 UTC (permalink / raw) To: Stuart Longland; +Cc: linux-mips [-- Attachment #1.1: Type: text/plain, Size: 681 bytes --] On Thu, Sep 23, 2004 at 11:54:19PM +1000, Stuart Longland wrote: > Using a MIPS64 config (built using gas-abi=o32 as suggested by Kumba), > it doesn't even get that far: There is still a lot left broken - The attached patch fixes some obvious stuff with address space and mibs abi. Missing is a fix for ip22zilog.c which seems to be broken. With this fix the machines goes userspace (reverse engineered by sound of hard disk) but seems to die somewhere. Probably the same bug as seen on other archs - die on first fork. Flo -- Florian Lohoff flo@rfc822.org +49-171-2280134 Heisenberg may have been here. [-- Attachment #1.2: cvs-20040923-ip22-64-2.6.diff --] [-- Type: text/plain, Size: 10816 bytes --] Index: arch/mips/Makefile =================================================================== RCS file: /home/flo/linux-mips-cvs/linux/arch/mips/Makefile,v retrieving revision 1.176 diff -u -r1.176 Makefile --- arch/mips/Makefile 19 Sep 2004 00:15:05 -0000 1.176 +++ arch/mips/Makefile 22 Sep 2004 23:54:24 -0000 @@ -35,7 +35,7 @@ endif ifdef CONFIG_MIPS64 gcc-abi = 64 -gas-abi = 32 +gas-abi = o64 tool-prefix = $(64bit-tool-prefix) UTS_MACHINE := mips64 endif @@ -107,7 +107,7 @@ break; \ done; \ if test "$(gcc-abi)" != "$(gas-abi)"; then \ - gas_abi="-Wa,-$(gas-abi) -Wa,-mgp$(gcc-abi)"; \ + gas_abi="-Wa,-mabi=$(gas-abi) -Wa,-mgp$(gcc-abi)"; \ fi; \ if test "$$gcc_opt" = -march= && test -n "$$gcc_abi"; then \ $(CC) $$gcc_abi $$gcc_opt$$gcc_cpu -S -o /dev/null \ Index: arch/mips/lib-64/dump_tlb.c =================================================================== RCS file: /home/flo/linux-mips-cvs/linux/arch/mips/lib-64/dump_tlb.c,v retrieving revision 1.2 diff -u -r1.2 dump_tlb.c --- arch/mips/lib-64/dump_tlb.c 11 Feb 2004 15:05:44 -0000 1.2 +++ arch/mips/lib-64/dump_tlb.c 23 Sep 2004 01:19:10 -0000 @@ -190,7 +190,7 @@ pgd = pgd_offset(current->mm, addr); pmd = pmd_offset(pgd, addr); pte = pte_offset(pmd, addr); - paddr = (KSEG1 | (unsigned int) pte_val(*pte)) & PAGE_MASK; + paddr = (CKSEG1 | (unsigned int) pte_val(*pte)) & PAGE_MASK; paddr |= (addr & ~PAGE_MASK); return paddr; Index: arch/mips/mm/c-r4k.c =================================================================== RCS file: /home/flo/linux-mips-cvs/linux/arch/mips/mm/c-r4k.c,v retrieving revision 1.89 diff -u -r1.89 c-r4k.c --- arch/mips/mm/c-r4k.c 24 Aug 2004 16:02:25 -0000 1.89 +++ arch/mips/mm/c-r4k.c 23 Sep 2004 01:11:27 -0000 @@ -49,7 +49,7 @@ #define R4600_HIT_CACHEOP_WAR_IMPL \ do { \ if (R4600_V2_HIT_CACHEOP_WAR && cpu_is_r4600_v2_x()) \ - *(volatile unsigned long *)KSEG1; \ + *(volatile unsigned long *)CKSEG1; \ if (R4600_V1_HIT_CACHEOP_WAR) \ __asm__ __volatile__("nop;nop;nop;nop"); \ } while (0) @@ -983,7 +983,7 @@ case CPU_R4000MC: case CPU_R4400SC: case CPU_R4400MC: - probe_scache_kseg1 = (probe_func_t) (KSEG1ADDR(&probe_scache)); + probe_scache_kseg1 = (probe_func_t) (CKSEG1ADDR(&probe_scache)); sc_present = probe_scache_kseg1(config); if (sc_present) c->options |= MIPS_CPU_CACHE_CDEX_S; Index: arch/mips/sgi-ip22/ip22-setup.c =================================================================== RCS file: /home/flo/linux-mips-cvs/linux/arch/mips/sgi-ip22/ip22-setup.c,v retrieving revision 1.39 diff -u -r1.39 ip22-setup.c --- arch/mips/sgi-ip22/ip22-setup.c 20 Aug 2004 10:03:22 -0000 1.39 +++ arch/mips/sgi-ip22/ip22-setup.c 23 Sep 2004 00:56:44 -0000 @@ -76,7 +76,7 @@ #endif /* Set EISA IO port base for Indigo2 */ - set_io_port_base(KSEG1ADDR(0x00080000)); + set_io_port_base(CKSEG1ADDR(0x00080000)); /* ARCS console environment variable is set to "g?" for * graphics console, it is set to "d" for the first serial Index: drivers/net/sgiseeq.c =================================================================== RCS file: /home/flo/linux-mips-cvs/linux/drivers/net/sgiseeq.c,v retrieving revision 1.61 diff -u -r1.61 sgiseeq.c --- drivers/net/sgiseeq.c 31 Jul 2004 01:47:50 -0000 1.61 +++ drivers/net/sgiseeq.c 23 Sep 2004 01:02:06 -0000 @@ -169,7 +169,7 @@ buffer = (unsigned long) kmalloc(PKT_BUF_SZ, GFP_KERNEL); if (!buffer) return -ENOMEM; - sp->tx_desc[i].buf_vaddr = KSEG1ADDR(buffer); + sp->tx_desc[i].buf_vaddr = CKSEG1ADDR(buffer); sp->tx_desc[i].tdma.pbuf = CPHYSADDR(buffer); } sp->tx_desc[i].tdma.cntinfo = TCNTINFO_INIT; @@ -183,7 +183,7 @@ buffer = (unsigned long) kmalloc(PKT_BUF_SZ, GFP_KERNEL); if (!buffer) return -ENOMEM; - sp->rx_desc[i].buf_vaddr = KSEG1ADDR(buffer); + sp->rx_desc[i].buf_vaddr = CKSEG1ADDR(buffer); sp->rx_desc[i].rdma.pbuf = CPHYSADDR(buffer); } sp->rx_desc[i].rdma.cntinfo = RCNTINFO_INIT; @@ -374,7 +374,7 @@ */ while ((td->tdma.cntinfo & (HPCDMA_XIU | HPCDMA_ETXD)) == (HPCDMA_XIU | HPCDMA_ETXD)) - td = (struct sgiseeq_tx_desc *)(long) KSEG1ADDR(td->tdma.pnext); + td = (struct sgiseeq_tx_desc *)(long) CKSEG1ADDR(td->tdma.pnext); if (td->tdma.cntinfo & HPCDMA_XIU) { hregs->tx_ndptr = CPHYSADDR(td); hregs->tx_ctrl = HPC3_ETXCTRL_ACTIVE; @@ -671,11 +671,11 @@ sp->mode = SEEQ_RCMD_RBCAST; sp->rx_desc = (struct sgiseeq_rx_desc *) - KSEG1ADDR(ALIGNED(&sp->srings->rxvector[0])); + CKSEG1ADDR(ALIGNED(&sp->srings->rxvector[0])); dma_cache_wback_inv((unsigned long)&sp->srings->rxvector, sizeof(sp->srings->rxvector)); sp->tx_desc = (struct sgiseeq_tx_desc *) - KSEG1ADDR(ALIGNED(&sp->srings->txvector[0])); + CKSEG1ADDR(ALIGNED(&sp->srings->txvector[0])); dma_cache_wback_inv((unsigned long)&sp->srings->txvector, sizeof(sp->srings->txvector)); Index: drivers/video/console/newport_con.c =================================================================== RCS file: /home/flo/linux-mips-cvs/linux/drivers/video/console/newport_con.c,v retrieving revision 1.9 diff -u -r1.9 newport_con.c --- drivers/video/console/newport_con.c 6 Aug 2004 00:33:29 -0000 1.9 +++ drivers/video/console/newport_con.c 23 Sep 2004 01:21:54 -0000 @@ -290,7 +290,7 @@ if (!sgi_gfxaddr) return NULL; - npregs = (struct newport_regs *) (KSEG1 + sgi_gfxaddr); + npregs = (struct newport_regs *) (CKSEG1ADDR(sgi_gfxaddr)); npregs->cset.config = NPORT_CFG_GD0; if (newport_wait()) { Index: include/asm-mips/addrspace.h =================================================================== RCS file: /home/flo/linux-mips-cvs/linux/include/asm-mips/addrspace.h,v retrieving revision 1.13 diff -u -r1.13 addrspace.h --- include/asm-mips/addrspace.h 30 Nov 2003 01:52:25 -0000 1.13 +++ include/asm-mips/addrspace.h 23 Sep 2004 01:08:48 -0000 @@ -38,16 +38,6 @@ #endif /* - * Memory segments (32bit kernel mode addresses) - * These are the traditional names used in the 32-bit universe. - */ -#define KUSEG 0x00000000 -#define KSEG0 0x80000000 -#define KSEG1 0xa0000000 -#define KSEG2 0xc0000000 -#define KSEG3 0xe0000000 - -/* * Returns the kernel segment base of a given address */ #define KSEGX(a) ((_ACAST32_ (a)) & 0xe0000000) @@ -58,18 +48,7 @@ #define CPHYSADDR(a) ((_ACAST32_ (a)) & 0x1fffffff) #define XPHYSADDR(a) ((_ACAST64_ (a)) & 0x000000ffffffffff) -/* - * Map an address to a certain kernel segment - */ -#define KSEG0ADDR(a) (CPHYSADDR(a) | KSEG0) -#define KSEG1ADDR(a) (CPHYSADDR(a) | KSEG1) -#define KSEG2ADDR(a) (CPHYSADDR(a) | KSEG2) -#define KSEG3ADDR(a) (CPHYSADDR(a) | KSEG3) - -#define CKSEG0ADDR(a) (CPHYSADDR(a) | CKSEG0) -#define CKSEG1ADDR(a) (CPHYSADDR(a) | CKSEG1) -#define CKSEG2ADDR(a) (CPHYSADDR(a) | CKSEG2) -#define CKSEG3ADDR(a) (CPHYSADDR(a) | CKSEG3) +#ifdef CONFIG_MIPS64 /* * Memory segments (64bit kernel mode addresses) @@ -85,6 +64,44 @@ #define CKSSEG 0xffffffffc0000000 #define CKSEG3 0xffffffffe0000000 +#define CKSEG0ADDR(a) (CPHYSADDR(a) | CKSEG0) +#define CKSEG1ADDR(a) (CPHYSADDR(a) | CKSEG1) +#define CKSEG2ADDR(a) (CPHYSADDR(a) | CKSEG2) +#define CKSEG3ADDR(a) (CPHYSADDR(a) | CKSEG3) + +#else + +#define CKSEG0ADDR(a) (CPHYSADDR(a) | KSEG0) +#define CKSEG1ADDR(a) (CPHYSADDR(a) | KSEG1) +#define CKSEG2ADDR(a) (CPHYSADDR(a) | KSEG2) +#define CKSEG3ADDR(a) (CPHYSADDR(a) | KSEG3) + +/* + * Map an address to a certain kernel segment + */ +#define KSEG0ADDR(a) (CPHYSADDR(a) | KSEG0) +#define KSEG1ADDR(a) (CPHYSADDR(a) | KSEG1) +#define KSEG2ADDR(a) (CPHYSADDR(a) | KSEG2) +#define KSEG3ADDR(a) (CPHYSADDR(a) | KSEG3) + +/* + * Memory segments (32bit kernel mode addresses) + * These are the traditional names used in the 32-bit universe. + */ +#define KUSEG 0x00000000 +#define KSEG0 0x80000000 +#define KSEG1 0xa0000000 +#define KSEG2 0xc0000000 +#define KSEG3 0xe0000000 + +#define CKUSEG 0x00000000 +#define CKSEG0 0x80000000 +#define CKSEG1 0xa0000000 +#define CKSEG2 0xc0000000 +#define CKSEG3 0xe0000000 + +#endif + /* * Cache modes for XKPHYS address conversion macros */ Index: include/asm-mips/r4kcache.h =================================================================== RCS file: /home/flo/linux-mips-cvs/linux/include/asm-mips/r4kcache.h,v retrieving revision 1.22 diff -u -r1.22 r4kcache.h --- include/asm-mips/r4kcache.h 5 Jan 2004 01:56:01 -0000 1.22 +++ include/asm-mips/r4kcache.h 23 Sep 2004 01:09:47 -0000 @@ -26,7 +26,7 @@ * - We need a properly sign extended address for 64-bit code. To get away * without ifdefs we let the compiler do it by a type cast. */ -#define INDEX_BASE ((int) KSEG0) +#define INDEX_BASE CKSEG0 #define cache_op(op,addr) \ __asm__ __volatile__( \ --- include/asm-mips/mach-ip22/spaces.h 2004-09-21 12:59:52.000000000 +0200 +++ include/asm-mips/mach-ip22/spaces.h 2004-09-23 01:52:01.000000000 +0200 @@ -0,0 +1,55 @@ +/* + * This file is subject to the terms and conditions of the GNU General Public + * License. See the file "COPYING" in the main directory of this archive + * for more details. + * + * Copyright (C) 1994 - 1999, 2000, 03, 04 Ralf Baechle + * Copyright (C) 2000, 2002 Maciej W. Rozycki + * Copyright (C) 1990, 1999, 2000 Silicon Graphics, Inc. + */ +#ifndef _ASM_MACH_SPACES_H +#define _ASM_MACH_SPACES_H + +#include <linux/config.h> + +#ifdef CONFIG_MIPS32 + +#define CAC_BASE 0x80000000 +#define IO_BASE 0xa0000000 +#define UNCAC_BASE 0xa0000000 +#define MAP_BASE 0xc0000000 + +/* + * This handles the memory map. + * We handle pages at KSEG0 for kernels with 32 bit address space. + */ +#define PAGE_OFFSET 0x80000000UL + +/* + * Memory above this physical address will be considered highmem. + */ +#ifndef HIGHMEM_START +#define HIGHMEM_START 0x20000000UL +#endif + +#endif /* CONFIG_MIPS32 */ + +#ifdef CONFIG_MIPS64 +#define PAGE_OFFSET 0xffffffff80000000UL + +#ifndef HIGHMEM_START +#define HIGHMEM_START (1UL << 59UL) +#endif + +#define CAC_BASE 0xffffffff80000000 +#define IO_BASE 0xffffffffa0000000 +#define UNCAC_BASE 0xffffffffa0000000 +#define MAP_BASE 0xffffffffc0000000 + +#define TO_PHYS(x) ( ((x) & TO_PHYS_MASK)) +#define TO_CAC(x) (CAC_BASE | ((x) & TO_PHYS_MASK)) +#define TO_UNCAC(x) (UNCAC_BASE | ((x) & TO_PHYS_MASK)) + +#endif /* CONFIG_MIPS64 */ + +#endif /* __ASM_MACH_GENERIC_SPACES_H */ [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Kernel 2.6 for R4600 Indy 2004-09-23 15:48 ` Florian Lohoff @ 2004-10-02 18:50 ` Thiemo Seufer 2004-10-02 20:40 ` Thiemo Seufer 0 siblings, 1 reply; 23+ messages in thread From: Thiemo Seufer @ 2004-10-02 18:50 UTC (permalink / raw) To: linux-mips [-- Attachment #1: Type: text/plain, Size: 991 bytes --] Florian Lohoff wrote: > On Thu, Sep 23, 2004 at 11:54:19PM +1000, Stuart Longland wrote: > > Using a MIPS64 config (built using gas-abi=o32 as suggested by Kumba), > > it doesn't even get that far: > > There is still a lot left broken - The attached patch fixes some obvious > stuff with address space and mibs abi. > > Missing is a fix for ip22zilog.c which seems to be broken. > > With this fix the machines goes userspace (reverse engineered by sound > of hard disk) but seems to die somewhere. Probably the same bug as seen > on other archs - die on first fork. The last problem happens only on r4000 and r4400, and occasionally also shows up as "illegal instruction" or "unaligned access". It turned out to be a broken TLB handler. I temporarily switched (for 32bit kernels) from except_vec0_r4000 to except_vec0_r45k_bvahwbug. This may cause an avoidable performance loss, but at least it allows my R4400SC-200 (V6.0) Indy to run current 2.6 CVS. Thiemo [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 240 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Kernel 2.6 for R4600 Indy 2004-10-02 18:50 ` Thiemo Seufer @ 2004-10-02 20:40 ` Thiemo Seufer 2004-10-02 23:47 ` Thiemo Seufer ` (2 more replies) 0 siblings, 3 replies; 23+ messages in thread From: Thiemo Seufer @ 2004-10-02 20:40 UTC (permalink / raw) To: linux-mips; +Cc: ralf [-- Attachment #1: Type: text/plain, Size: 1405 bytes --] Thiemo Seufer wrote: [snip] > > With this fix the machines goes userspace (reverse engineered by sound > > of hard disk) but seems to die somewhere. Probably the same bug as seen > > on other archs - die on first fork. > > The last problem happens only on r4000 and r4400, and occasionally > also shows up as "illegal instruction" or "unaligned access". It > turned out to be a broken TLB handler. I temporarily switched (for > 32bit kernels) from except_vec0_r4000 to except_vec0_r45k_bvahwbug. > This may cause an avoidable performance loss, but at least it allows > my R4400SC-200 (V6.0) Indy to run current 2.6 CVS. One more nop is enough to make it work. This should probably go in a hazard definition. Thiemo Index: arch/mips/mm/tlbex32-r4k.S =================================================================== RCS file: /home/cvs/linux/arch/mips/mm/tlbex32-r4k.S,v retrieving revision 1.1 diff -u -p -r1.1 tlbex32-r4k.S --- arch/mips/mm/tlbex32-r4k.S 20 Jun 2004 23:52:17 -0000 1.1 +++ arch/mips/mm/tlbex32-r4k.S 2 Oct 2004 20:36:29 -0000 @@ -179,6 +179,7 @@ P_MTC0 k1, CP0_ENTRYLO1 # load it mtc0_tlbw_hazard tlbwr # write random tlb entry + nop tlbw_eret_hazard eret # return from trap END(except_vec0_r4000) [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 240 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Kernel 2.6 for R4600 Indy 2004-10-02 20:40 ` Thiemo Seufer @ 2004-10-02 23:47 ` Thiemo Seufer 2004-10-03 0:58 ` Maciej W. Rozycki 2004-10-03 11:40 ` Thomas Bogendoerfer 2 siblings, 0 replies; 23+ messages in thread From: Thiemo Seufer @ 2004-10-02 23:47 UTC (permalink / raw) To: linux-mips; +Cc: ralf [-- Attachment #1: Type: text/plain, Size: 827 bytes --] Thiemo Seufer wrote: [snip] > One more nop is enough to make it work. This should probably go in > a hazard definition. Same for 64bit kernels. Thiemo Index: arch/mips/mm/tlbex64-r4k.S =================================================================== RCS file: /home/cvs/linux/arch/mips/mm/tlbex64-r4k.S,v retrieving revision 1.6 diff -u -p -r1.6 tlbex64-r4k.S --- arch/mips/mm/tlbex64-r4k.S 15 Aug 2004 09:40:01 -0000 1.6 +++ arch/mips/mm/tlbex64-r4k.S 2 Oct 2004 23:45:14 -0000 @@ -116,6 +118,7 @@ LEAF(handle_vec1_r4k) PTE_RELOAD k0 k1 mtc0_tlbw_hazard tlbwr + nop tlbw_eret_hazard eret @@ -128,7 +131,8 @@ LEAF(handle_vec1_r4k) ld k1, 8(k1) # get odd pte PTE_RELOAD k0 k1 mtc0_tlbw_hazard - tlbwr + tlbwr + nop tlbw_eret_hazard eret END(handle_vec1_r4k) [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 240 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Kernel 2.6 for R4600 Indy 2004-10-02 20:40 ` Thiemo Seufer 2004-10-02 23:47 ` Thiemo Seufer @ 2004-10-03 0:58 ` Maciej W. Rozycki 2004-10-04 14:52 ` Ralf Baechle 2004-10-03 11:40 ` Thomas Bogendoerfer 2 siblings, 1 reply; 23+ messages in thread From: Maciej W. Rozycki @ 2004-10-03 0:58 UTC (permalink / raw) To: Thiemo Seufer; +Cc: linux-mips, ralf On Sat, 2 Oct 2004, Thiemo Seufer wrote: > > The last problem happens only on r4000 and r4400, and occasionally > > also shows up as "illegal instruction" or "unaligned access". It > > turned out to be a broken TLB handler. I temporarily switched (for > > 32bit kernels) from except_vec0_r4000 to except_vec0_r45k_bvahwbug. > > This may cause an avoidable performance loss, but at least it allows > > my R4400SC-200 (V6.0) Indy to run current 2.6 CVS. > > One more nop is enough to make it work. This should probably go in > a hazard definition. [...] > --- arch/mips/mm/tlbex32-r4k.S 20 Jun 2004 23:52:17 -0000 1.1 > +++ arch/mips/mm/tlbex32-r4k.S 2 Oct 2004 20:36:29 -0000 > @@ -179,6 +179,7 @@ > P_MTC0 k1, CP0_ENTRYLO1 # load it > mtc0_tlbw_hazard > tlbwr # write random tlb entry > + nop > tlbw_eret_hazard > eret # return from trap > END(except_vec0_r4000) I'd be inclined to add this nop to the tlbw_eret_hazard definition, but it should really be processor-dependent. According to the R4000/R4400 cp0 hazard dependency table, there is a three-instruction delay between tlbwi/tlbwr and eret with respect to TLB use and two-instruction one between tlbwi/tlbwr and the instruction following eret for the R4600/R4700. Therefore, there should actually be three nops there for the R4000/R4400 and one for the R4600/R4700. AFAIK mtc0_tlbw_hazard acts as a way to simulate two nops for the R4000/R4400. Still, tlbw_eret_hazard expands to nothing for non-RM9000 processors. I think we should either handcode all handlers explicitly or build a single one dynamically, like we do for copy_page()/clear_page(). For now, I'll just add the missing nop directly to the handlers. Thanks for working on it. Maciej ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Kernel 2.6 for R4600 Indy 2004-10-03 0:58 ` Maciej W. Rozycki @ 2004-10-04 14:52 ` Ralf Baechle 2004-10-04 23:48 ` Maciej W. Rozycki 0 siblings, 1 reply; 23+ messages in thread From: Ralf Baechle @ 2004-10-04 14:52 UTC (permalink / raw) To: Maciej W. Rozycki; +Cc: Thiemo Seufer, linux-mips On Sun, Oct 03, 2004 at 01:58:27AM +0100, Maciej W. Rozycki wrote: > Still, tlbw_eret_hazard expands to nothing for non-RM9000 processors. > > I think we should either handcode all handlers explicitly or build a > single one dynamically, like we do for copy_page()/clear_page(). That was the plan. > For now, > I'll just add the missing nop directly to the handlers. Thanks for > working on it. Those nops are now cluttering the handler for all those processors that don't need it. Great. Ralf ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Kernel 2.6 for R4600 Indy 2004-10-04 14:52 ` Ralf Baechle @ 2004-10-04 23:48 ` Maciej W. Rozycki 2004-10-05 19:04 ` Ralf Baechle 0 siblings, 1 reply; 23+ messages in thread From: Maciej W. Rozycki @ 2004-10-04 23:48 UTC (permalink / raw) To: Ralf Baechle; +Cc: Thiemo Seufer, linux-mips On Mon, 4 Oct 2004, Ralf Baechle wrote: > > I think we should either handcode all handlers explicitly or build a > > single one dynamically, like we do for copy_page()/clear_page(). > > That was the plan. > > > For now, > > I'll just add the missing nop directly to the handlers. Thanks for > > working on it. > > Those nops are now cluttering the handler for all those processors > that don't need it. Great. Except that: 1. The handler is expected to be for R4000/R4400 only. If it's used for anything else, that it's the anything else's maintainer fault. 2. The except_vec0_sb1 handler is one with the nop omitted, so it can be used for these processors. 3. Correct operation first, only then optimization. 4. Anyone please feel free to do a better fix. 5. Given the "gran plan" as referred to above, points 1 - 4 above are probably irrelevant anyway. ;-) Maciej ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Kernel 2.6 for R4600 Indy 2004-10-04 23:48 ` Maciej W. Rozycki @ 2004-10-05 19:04 ` Ralf Baechle 2004-10-05 19:35 ` Maciej W. Rozycki 0 siblings, 1 reply; 23+ messages in thread From: Ralf Baechle @ 2004-10-05 19:04 UTC (permalink / raw) To: Maciej W. Rozycki; +Cc: Thiemo Seufer, linux-mips On Tue, Oct 05, 2004 at 12:48:37AM +0100, Maciej W. Rozycki wrote: > 1. The handler is expected to be for R4000/R4400 only. If it's used for You're alone in that believe. Despite it's name it's being used for anything that doesn't need it's own special handler. > 2. The except_vec0_sb1 handler is one with the nop omitted, so it can be > used for these processors. Adding more obscurity? > 3. Correct operation first, only then optimization. On of the free software lessons is a bad solution is worse than no solution. > 5. Given the "gran plan" as referred to above, points 1 - 4 above are > probably irrelevant anyway. ;-) Only once implemented. Ralf ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Kernel 2.6 for R4600 Indy 2004-10-05 19:04 ` Ralf Baechle @ 2004-10-05 19:35 ` Maciej W. Rozycki 2004-10-07 12:28 ` Ralf Baechle 0 siblings, 1 reply; 23+ messages in thread From: Maciej W. Rozycki @ 2004-10-05 19:35 UTC (permalink / raw) To: Ralf Baechle; +Cc: Thiemo Seufer, linux-mips On Tue, 5 Oct 2004, Ralf Baechle wrote: > > 1. The handler is expected to be for R4000/R4400 only. If it's used for > > You're alone in that believe. Despite it's name it's being used for > anything that doesn't need it's own special handler. Well, the nearby comment agrees with me. Is the handler misused or has someone forgotten to fix the comment (yes, I do know of the R4700 and R4640/R4650, with the former being almost identical to the R4600 and the latters being unsupported due to lacking a TLB MMU)? > > 2. The except_vec0_sb1 handler is one with the nop omitted, so it can be > > used for these processors. > > Adding more obscurity? Just moving it elsewhere. ;-) > > 3. Correct operation first, only then optimization. > > On of the free software lessons is a bad solution is worse than no solution. And another one is anyone is free to provide a better fix. I suppose another alternative with the current implementation is to make a "generic" handler separate from the R4000/R4400 one. This might even be not so troublesome maintenance-wise if done properly, but given the "grand plan" is it worth the hassle? Or is the "plan" scheduled for around 2.8 or so? Maciej ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Kernel 2.6 for R4600 Indy 2004-10-05 19:35 ` Maciej W. Rozycki @ 2004-10-07 12:28 ` Ralf Baechle 0 siblings, 0 replies; 23+ messages in thread From: Ralf Baechle @ 2004-10-07 12:28 UTC (permalink / raw) To: Maciej W. Rozycki; +Cc: Thiemo Seufer, linux-mips On Tue, Oct 05, 2004 at 08:35:52PM +0100, Maciej W. Rozycki wrote: > Well, the nearby comment agrees with me. Is the handler misused or has > someone forgotten to fix the comment (yes, I do know of the R4700 and > R4640/R4650, with the former being almost identical to the R4600 and the > latters being unsupported due to lacking a TLB MMU)? The names R4000 and R4k are at times used to mean any R4000-ish processor. What that means in a particular context isn't always well defined. Even an oddball processor like the R8000 may be covered ... R5000 being the faster twin of the R4600 also uses it. Nevada only got it's own handler due some processor bug; upto it's workaround this class of processors also used the R4000 handler. With hazards.h the need for the nop-free version for the R10000 family went away also, so it moved over to the standard R4000 one. RM7000 was always using it and RM9000 having slightly different hazards than it's predecessors never had a good reason > is it worth the hassle? Or is the "plan" scheduled for around 2.8 or so? Given the experience with clear_user / copy_user going for the runtime generated handlers is relativly easy and can be done without alot of breakage so it's more a question of somebody doing it and I'll not try to stop any reasonable implementation. Ralf ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Kernel 2.6 for R4600 Indy 2004-10-02 20:40 ` Thiemo Seufer 2004-10-02 23:47 ` Thiemo Seufer 2004-10-03 0:58 ` Maciej W. Rozycki @ 2004-10-03 11:40 ` Thomas Bogendoerfer 2 siblings, 0 replies; 23+ messages in thread From: Thomas Bogendoerfer @ 2004-10-03 11:40 UTC (permalink / raw) To: Thiemo Seufer; +Cc: linux-mips, ralf On Sat, Oct 02, 2004 at 10:40:14PM +0200, Thiemo Seufer wrote: > Thiemo Seufer wrote: > [snip] > > > With this fix the machines goes userspace (reverse engineered by sound > > > of hard disk) but seems to die somewhere. Probably the same bug as seen > > > on other archs - die on first fork. > > > > The last problem happens only on r4000 and r4400, and occasionally > > also shows up as "illegal instruction" or "unaligned access". It > > turned out to be a broken TLB handler. I temporarily switched (for > > 32bit kernels) from except_vec0_r4000 to except_vec0_r45k_bvahwbug. > > This may cause an avoidable performance loss, but at least it allows > > my R4400SC-200 (V6.0) Indy to run current 2.6 CVS. > > One more nop is enough to make it work. This should probably go in > a hazard definition. excellent, this gets up my Indigo 2 with a 200 MHz CPU and my M700: root@(none):/# cat /proc/cpuinfo system type : Jazz MIPS_Magnum_4000 processor : 0 cpu model : R4000PC V3.0 FPU V0.0 BogoMIPS : 49.76 wait instruction : no microsecond timers : yes tlb_entries : 48 extra interrupt vector : no hardware watchpoint : yes VCED exceptions : 0 VCEI exceptions : 0 Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessary a good idea. [ RFC1925, 2.3 ] ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2004-10-07 12:30 UTC | newest] Thread overview: 23+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2004-09-23 13:54 Kernel 2.6 for R4600 Indy Stuart Longland 2004-09-23 14:51 ` Ladislav Michl 2004-09-23 15:00 ` Stephen P. Becker 2004-09-24 0:16 ` Stuart Longland 2004-09-24 9:07 ` Florian Lohoff 2004-09-24 15:42 ` Stuart Longland 2004-09-24 16:44 ` Florian Lohoff 2004-09-24 13:05 ` Stephen P. Becker 2004-09-24 13:17 ` Robin Humble 2004-09-24 13:27 ` Stephen P. Becker 2004-09-24 13:43 ` Robin Humble 2004-09-24 15:13 ` Stephen P. Becker 2004-09-23 15:48 ` Florian Lohoff 2004-10-02 18:50 ` Thiemo Seufer 2004-10-02 20:40 ` Thiemo Seufer 2004-10-02 23:47 ` Thiemo Seufer 2004-10-03 0:58 ` Maciej W. Rozycki 2004-10-04 14:52 ` Ralf Baechle 2004-10-04 23:48 ` Maciej W. Rozycki 2004-10-05 19:04 ` Ralf Baechle 2004-10-05 19:35 ` Maciej W. Rozycki 2004-10-07 12:28 ` Ralf Baechle 2004-10-03 11:40 ` Thomas Bogendoerfer
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.