From mugen@kaibigan.com Sun Jul 12 11:18:54 1998 Received: from star.lamers.net (star.lamers.net [209.103.202.5]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id LAA10814; Sun, 12 Jul 1998 11:18:53 +0200 (MET DST) Received-Date: Sun, 12 Jul 1998 11:18:53 +0200 (MET DST) Received: from mugen ([207.171.38.185]) by star.lamers.net (8.8.8/8.8.5) with SMTP id EAA01175 for ; Sun, 12 Jul 1998 04:18:35 -0500 (CDT) Message-ID: <001b01bdad74$c9ab4be0$04000005@mugen.raydens.com> Reply-To: "mugen" From: "mugen" To: Subject: MIPS port Date: Sun, 12 Jul 1998 02:09:27 -0700 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA-1; boundary="----=_NextPart_000_0016_01BDAD3A.1924EA40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 This is a multi-part message in MIME format. ------=_NextPart_000_0016_01BDAD3A.1924EA40 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01BDAD3A.1924EA40" ------=_NextPart_000_0013_01BDAD3A.1924EA40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, i just got a used NEC RISC Station 2200, and i can't find any OS to = run with it. And im running linux on my Pentium 100 rite now. I like it alot, so if = you guys can help me on this problem, please let me know. Thank you. ------=_NextPart_000_0013_01BDAD3A.1924EA40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi, i just got a used NEC RISC = Station 2200, and=20 i can't find any OS to run with it.

And im running linux on my Pentium = 100 rite=20 now. I like it alot, so if you guys can help me on this problem, = please=20 let me know. Thank you.

------=_NextPart_000_0013_01BDAD3A.1924EA40-- ------=_NextPart_000_0016_01BDAD3A.1924EA40 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII2TCCAj0w ggGmAhEA89Rlkw7kxx7NbwoREVZYszANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAI8hmbFWfUmFqrxcd 4rPPR45MGwIzdflF75tHsbEroDU20VJwacm7pfOTW5Jg+WR+8cE/6dEV8dLAF72knReu4QfPuoGW xK5xGfbOZL+nGfVVKH98M9bCubfrJSn9KfhicEEx3cMH2xJTFmDQnQf5AGX8jWwYUCC3Z9x+/XBL LQ8wggJ5MIIB4qADAgECAhBSHzUd8nB+ACu+ylmHBNU5MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjA2MjcwMDAwMDBaFw05OTA2Mjcy MzU5NTlaMGIxETAPBgNVBAcTCEludGVybmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE0MDIG A1UECxMrVmVyaVNpZ24gQ2xhc3MgMSBDQSAtIEluZGl2aWR1YWwgU3Vic2NyaWJlcjCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEAthSmz03QBQ3YyiPQb6q0KZJjjiz4b5bXLp12SxGxNo1XycP9 HMa6/h4IujPKleq+41vNBqi3eR1EKu1z8rFSg2gQcGSR1z5r+fddnRRDm26XRZiBR9Ety927ctdM P3Gq4kDyVDm8Fu7PfOy62z9sKrMWsYYSna6TNNW41dD3PqkCAwEAAaMzMDEwDwYDVR0TBAgwBgEB /wIBATALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAMH6 9wLnV8oRdcacDPord0+HRRc749LB2g9YOY6ulZkDoaihOP55mpMXC5eGOcfKaDRmu8eIRfbIDAXu vpcl7+DUbuR/nXZczn26FKKuC5/7Z1tIpWclrxlkiPZy2CknqjcSarEoryeDGGVsje1Ank3EeKiG 7OksUL+m+Q3bsKZKMIIEFzCCA4CgAwIBAgIQRphE0eYCuqZz9pN7KG4TszANBgkqhkiG9w0BAQQF ADBiMREwDwYDVQQHEwhJbnRlcm5ldDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNDAyBgNVBAsT K1ZlcmlTaWduIENsYXNzIDEgQ0EgLSBJbmRpdmlkdWFsIFN1YnNjcmliZXIwHhcNOTcxMjAzMDAw MDAwWhcNOTgxMjAzMjM1OTU5WjCCARMxETAPBgNVBAcTCEludGVybmV0MRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE0MDIGA1UECxMrVmVyaVNpZ24gQ2xhc3MgMSBDQSAtIEluZGl2aWR1YWwgU3Vi c2NyaWJlcjFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L0NQUyBJbmNvcnAu IGJ5IFJlZi4sTElBQi5MVEQoYyk5NjE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAxIC0gTWlj cm9zb2Z0IEZ1bGwgU2VydmljZTEOMAwGA1UEAxMFbXVnZW4xITAfBgkqhkiG9w0BCQEWEm11Z2Vu QGthaWJpZ2FuLmNvbTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCzZCXT2tc1FzcuWcs3JNKrVcy2 b+1CTCpVbR6WhAuXq2o5d0Zj1hK4RUkwePiAO1wkWbXkB8iDksv90mAZ0FlPAgMBAAGjggFdMIIB WTAJBgNVHRMEAjAAMIGvBgNVHSAEgacwgDCABgtghkgBhvhFAQcBATCAMCgGCCsGAQUFBwIBFhxo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIElu Yy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAo Yyk5NyBWZXJpU2lnbgAAAAAAADARBglghkgBhvhCAQEEBAMCB4AwgYYGCmCGSAGG+EUBBgMEeBZ2 ZDQ2NTJiZDYzZjIwNDcwMjkyOTg3NjNjOWQyZjI3NTA2OWM3MzU5YmVkMWIwNTlkYTc1YmM0YmM5 NzAxNzQ3ZGE1ZDNmMjE0MWJlYWRiMmJkMmU4OTIxZmFjNmFmMWRmMTE0ODljYTBiYjQ1ZjlmM2Vh NDUxOTANBgkqhkiG9w0BAQQFAAOBgQCNdHQQTU//25R/Ic/WH1g0HSqgaofYAFcMffstIEPWKPBw Z368AMI94xfQY9qUUvdwt+2TsYW8akSo9y50PxRJhr2pHRIeBLaf+Y9kpVL1rCgxCbHpInmg7hsG GUi+/USjGBenxxqV+ozAAJ6KV3BOEtqeq029r9XQO0gF2G/G+DGCAVQwggFQAgEBMHYwYjERMA8G A1UEBxMISW50ZXJuZXQxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTQwMgYDVQQLEytWZXJpU2ln biBDbGFzcyAxIENBIC0gSW5kaXZpZHVhbCBTdWJzY3JpYmVyAhBGmETR5gK6pnP2k3sobhOzMAkG BSsOAwIaBQCgdzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBgGCSqGSIb3DQEJDzELMAkwBwYF Kw4DAh0wHAYJKoZIhvcNAQkFMQ8XDTk4MDcxMjAyMDkyN1owIwYJKoZIhvcNAQkEMRYEFMzyt+qq UJvNWmnav9zciFE84EwJMA0GCSqGSIb3DQEBAQUABECCQYkyTpT1mzqk2I8p39gpS+KKb6+k8ppN Ka9EknMITFNxDUr4yg4vBrVJw2PPeXCSz4Ov8kTddhgu04kNd1XeAAAAAAAA ------=_NextPart_000_0016_01BDAD3A.1924EA40-- From tsbogend@alpha.franken.de Sun Jul 12 11:35:17 1998 Received: from louis-blanc.univ-evry.fr (louis-blanc.univ-evry.fr [194.199.90.2]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id LAA10910; Sun, 12 Jul 1998 11:35:16 +0200 (MET DST) Received-Date: Sun, 12 Jul 1998 11:35:16 +0200 (MET DST) Received: from alpha.franken.de (root@alpha.franken.de [193.175.24.68]) by louis-blanc.univ-evry.fr with ESMTP (8.8.8/980318/louis-blanc); id LAA25338; Sun, 12 Jul 1998 11:35:15 +0200 (MET DST) Received: (from tsbogend@localhost) by alpha.franken.de (8.8.7/8.8.5) id LAA00851; Sun, 12 Jul 1998 11:29:49 +0200 Message-ID: <19980712112949.25350@alpha.franken.de> Date: Sun, 12 Jul 1998 11:29:49 +0200 From: Thomas Bogendoerfer To: linux-mips@fnet.fr, linux@cthulhu.engr.sgi.com Subject: One good and some bad news Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85 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>] From ralf@uni-koblenz.de Sun Jul 12 23:08:36 1998 Received: from informatik.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.4.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id XAA16214; Sun, 12 Jul 1998 23:08:33 +0200 (MET DST) Received-Date: Sun, 12 Jul 1998 23:08:33 +0200 (MET DST) From: ralf@uni-koblenz.de Received: from uni-koblenz.de (root@pmport-07.uni-koblenz.de [141.26.249.7]) by informatik.uni-koblenz.de (8.8.8/8.8.8) with ESMTP id XAA04763 for ; Sun, 12 Jul 1998 23:08:28 +0200 (MEST) Received: (from ralf@localhost) by uni-koblenz.de (8.8.7/8.8.7) id TAA17825; Sun, 12 Jul 1998 19:01:36 +0200 Message-ID: <19980712190135.R10756@uni-koblenz.de> Date: Sun, 12 Jul 1998 19:01:35 +0200 To: Thomas Bogendoerfer , linux-mips@fnet.fr, linux@cthulhu.engr.sgi.com Subject: Re: One good and some bad news References: <19980712112949.25350@alpha.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <19980712112949.25350@alpha.franken.de>; from Thomas Bogendoerfer on Sun, Jul 12, 1998 at 11:29:49AM +0200 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 From tsbogend@alpha.franken.de Sun Jul 12 23:39:03 1998 Received: from louis-blanc.univ-evry.fr (louis-blanc.univ-evry.fr [194.199.90.2]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id XAA16339; Sun, 12 Jul 1998 23:39:02 +0200 (MET DST) Received-Date: Sun, 12 Jul 1998 23:39:02 +0200 (MET DST) Received: from alpha.franken.de (root@alpha.franken.de [193.175.24.68]) by louis-blanc.univ-evry.fr with ESMTP (8.8.8/980318/louis-blanc); id XAA28740; Sun, 12 Jul 1998 23:39:00 +0200 (MET DST) Received: (from tsbogend@localhost) by alpha.franken.de (8.8.7/8.8.5) id UAA05074; Sun, 12 Jul 1998 20:55:23 +0200 Message-ID: <19980712205523.42509@alpha.franken.de> Date: Sun, 12 Jul 1998 20:55:23 +0200 From: Thomas Bogendoerfer To: linux-mips@fnet.fr, linux@cthulhu.engr.sgi.com Subject: Re: One good and some bad news References: <19980712112949.25350@alpha.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85 In-Reply-To: <19980712112949.25350@alpha.franken.de>; from Thomas Bogendoerfer on Sun, Jul 12, 1998 at 11:29:49AM +0200 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>] From tsbogend@alpha.franken.de Sun Jul 12 23:55:16 1998 Received: from louis-blanc.univ-evry.fr (louis-blanc.univ-evry.fr [194.199.90.2]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id XAA16524; Sun, 12 Jul 1998 23:55:15 +0200 (MET DST) Received-Date: Sun, 12 Jul 1998 23:55:15 +0200 (MET DST) Received: from alpha.franken.de (tsbogend@alpha.franken.de [193.175.24.68]) by louis-blanc.univ-evry.fr with ESMTP (8.8.8/980318/louis-blanc); id XAA28839; Sun, 12 Jul 1998 23:55:12 +0200 (MET DST) Received: (from tsbogend@localhost) by alpha.franken.de (8.8.7/8.8.5) id XAA07125; Sun, 12 Jul 1998 23:53:20 +0200 Message-ID: <19980712235319.65470@alpha.franken.de> Date: Sun, 12 Jul 1998 23:53:19 +0200 From: Thomas Bogendoerfer To: ralf@uni-koblenz.de Cc: linux-mips@fnet.fr, linux@cthulhu.engr.sgi.com Subject: Re: One good and some bad news References: <19980712112949.25350@alpha.franken.de> <19980712190135.R10756@uni-koblenz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85 In-Reply-To: <19980712190135.R10756@uni-koblenz.de>; from ralf@uni-koblenz.de on Sun, Jul 12, 1998 at 07:01:35PM +0200 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>] From ralf@uni-koblenz.de Mon Jul 13 02:36:59 1998 Received: from informatik.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.4.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id CAA18435; Mon, 13 Jul 1998 02:36:56 +0200 (MET DST) Received-Date: Mon, 13 Jul 1998 02:36:56 +0200 (MET DST) From: ralf@uni-koblenz.de Received: from uni-koblenz.de (ralf@pmport-25.uni-koblenz.de [141.26.249.25]) by informatik.uni-koblenz.de (8.8.8/8.8.8) with ESMTP id CAA21306 for ; Mon, 13 Jul 1998 02:36:53 +0200 (MEST) Received: (from ralf@localhost) by uni-koblenz.de (8.8.7/8.8.7) id CAA18524; Mon, 13 Jul 1998 02:36:08 +0200 Message-ID: <19980713023606.U10756@uni-koblenz.de> Date: Mon, 13 Jul 1998 02:36:06 +0200 To: Thomas Bogendoerfer Cc: linux-mips@fnet.fr, linux@cthulhu.engr.sgi.com Subject: Re: One good and some bad news References: <19980712112949.25350@alpha.franken.de> <19980712190135.R10756@uni-koblenz.de> <19980712235319.65470@alpha.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <19980712235319.65470@alpha.franken.de>; from Thomas Bogendoerfer on Sun, Jul 12, 1998 at 11:53:19PM +0200 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 From ralf@uni-koblenz.de Mon Jul 13 20:11:07 1998 Received: from informatik.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.4.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id UAA26806; Mon, 13 Jul 1998 20:11:03 +0200 (MET DST) Received-Date: Mon, 13 Jul 1998 20:11:03 +0200 (MET DST) From: ralf@uni-koblenz.de Received: from uni-koblenz.de (ralf@pmport-15.uni-koblenz.de [141.26.249.15]) by informatik.uni-koblenz.de (8.8.8/8.8.8) with ESMTP id UAA12406 for ; Mon, 13 Jul 1998 20:11:00 +0200 (MEST) Received: (from ralf@localhost) by uni-koblenz.de (8.8.7/8.8.7) id UAA01622; Mon, 13 Jul 1998 20:10:08 +0200 Message-ID: <19980713201006.A1201@uni-koblenz.de> Date: Mon, 13 Jul 1998 20:10:06 +0200 To: linux@engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu Subject: Netscape Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 Hi all, more good news, I just browsed the first web pages in Mozilla. It's not perfect yet. For bringing it up modified kernel, libc and lesstif is required ... Ralf From dgelbman@npiny.com Mon Jul 13 21:36:38 1998 Received: from npiny-nt1.npiny.com (npiny.com [209.109.16.37]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id VAA27518; Mon, 13 Jul 1998 21:36:36 +0200 (MET DST) Received-Date: Mon, 13 Jul 1998 21:36:36 +0200 (MET DST) Received: from DGELBMAN by npiny-nt1.npiny.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id 3346Y89M; Mon, 13 Jul 1998 15:30:43 -0400 Message-ID: <35AA6113.3360C3C9@npiny.com> Date: Mon, 13 Jul 1998 15:33:39 -0400 From: "M. David Gelbman" Organization: Network Peripherals, Inc. X-Mailer: Mozilla 4.04 [en] (WinNT; U) MIME-Version: 1.0 To: echo@psi.com Subject: Life & Software Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Help! I'm currently running the latest version of girlfriend and I've been having some problems lately. I've been running the same version of DrinkingBuddies 1.0 forever as my primary application, and all the girlfriend releases I've tried have always conflicted with it. I hear that DrinkingBuddies won't crash if girlfriend is run in background mode and the sound is turned off. But I'm embarrassed to say I can't find the switch to turn the sound off. I just run them separately, and it works okay. Girlfriend also seems to have a problem coexisting with my Golf program, often trying to abort Golf with some sort of timing incompatibility. I probably should have stayed with girlfriend 1.0, but I thought I might see better performance from girlfriend 2.0. After months of conflicts and other problems, I consulted a friend who has had experience with girlfriend 2.0. He said I probably didn't have enough cache to run girlfriend 2.0, and eventually it would require a Token Ring to run properly. He was right - as soon as I purged my cache, it uninstalled itself. Shortly after that, I installed girlfriend 3.0 beta. All the bugs were supposed to be gone, but the first time I used it, it gave me a virus anyway. I had to clean out my whole system and shut down for a while. I very cautiously upgraded to girlfriend 4.0. This time I used a SCSI probe first and also installed a virus protection program. It worked okay for a while until I discovered that girlfriend 1.0 was still in my system. I tried running girlfriend 1.0 again with girlfriend 4.0 still installed, but girlfriend 4.0 has a feature I didn't know about that automatically senses the presence of any other version of girlfriend and communicates with it in some way, which results in the immediate removal of both versions. The version I have now works pretty well, but there are still some problems. Like all versions of girlfriend, it is written in some obscure language I can't understand, much less reprogram. Frankly I think there is too much attention paid to the look and feel rather than the desired functionality. Also, to get the best connections with your hardware, you usually have to use gold-plated contacts. And I've never liked how girlfriend is totally "object-oriented." A year ago, a friend of mine upgraded his version of girlfriend to GirlFriendPlus 1.0, which is a Terminate and Stay Resident version of girlfriend. He discovered that GirlFriendPlus 1.0 expires within a year if you don't upgrade to Fiancee 1.0. So he did, but soon after that, he had to upgrade to Wife 1.0, which he describes as a huge resource hog. It has taken up all his space, so he can't load anything else. One of the primary reasons he decided to go with Wife 1.0 was because it came bundled with FreeSexPlus. Well, it turns out the resource allocation module of Wife 1.0 sometimes prohibits access to FreeSexPlus, particularly the new Plug-Ins he wanted to try. On top of that, Wife 1.0 must be running on a well warmed-up system before he can do anything. Although he did not ask for it, Wife 1.0 came with MotherInLaw which has an automatic pop-up feature he can't turn off. I told him to try installing Mistress 1.0, but he said he heard if you try to run it without first uninstalling Wife 1.0, Wife 1.0 will delete MSMoney files before doing the uninstall itself. Then Mistress 1.0 won't install anyway because of insufficient resources. From tsbogend@alpha.franken.de Tue Jul 14 00:48:04 1998 Received: from louis-blanc.univ-evry.fr (louis-blanc.univ-evry.fr [194.199.90.2]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id AAA00430; Tue, 14 Jul 1998 00:48:03 +0200 (MET DST) Received-Date: Tue, 14 Jul 1998 00:48:03 +0200 (MET DST) Received: from alpha.franken.de (root@alpha.franken.de [193.175.24.68]) by louis-blanc.univ-evry.fr with ESMTP (8.8.8/980318/louis-blanc); id AAA12137; Tue, 14 Jul 1998 00:48:01 +0200 (MET DST) Received: (from tsbogend@localhost) by alpha.franken.de (8.8.7/8.8.5) id AAA02784; Tue, 14 Jul 1998 00:08:26 +0200 Message-ID: <19980714000825.24064@alpha.franken.de> Date: Tue, 14 Jul 1998 00:08:25 +0200 From: Thomas Bogendoerfer To: ralf@uni-koblenz.de Cc: linux-mips@fnet.fr, linux@cthulhu.engr.sgi.com Subject: Re: One good and some bad news References: <19980712112949.25350@alpha.franken.de> <19980712190135.R10756@uni-koblenz.de> <19980712235319.65470@alpha.franken.de> <19980713023606.U10756@uni-koblenz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85 In-Reply-To: <19980713023606.U10756@uni-koblenz.de>; from ralf@uni-koblenz.de on Mon, Jul 13, 1998 at 02:36:06AM +0200 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>] From harald.koerfgen@netcologne.de Tue Jul 14 22:32:16 1998 Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id WAA09820; Tue, 14 Jul 1998 22:32:14 +0200 (MET DST) Received-Date: Tue, 14 Jul 1998 22:32:14 +0200 (MET DST) Received: from franz.no.dom (dial5-94.netcologne.de [194.8.195.94]) by mail2.netcologne.de (8.8.8/8.8.8) with ESMTP id WAA29498 for ; Tue, 14 Jul 1998 22:32:05 +0200 (MET DST) X-Ncc-Regid: de.netcologne Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Message-ID: X-Mailer: XFMail 1.2 [p0] on Linux X-Priority: 3 (Normal) Date: Tue, 14 Jul 1998 22:33:11 +0200 (MEST) Reply-To: "Harald Koerfgen" Organization: none Sender: harry@franz.no.dom From: Harald Koerfgen To: linux-mips@fnet.fr Subject: DECstation-Linux: 1st user process running! >>boot 3/tftp 898336+12688+115584 Linux/MIPS DECstation Boot Copyright (C) Paul M. Antoine 1995, 1996, 1997 and others, 1994, 1995, 1996, 1997, 1998 Found a REX compatible boot PROM This DECStation is a DS5000/1xx with 49152kB RAM CPU is a R3000A with 64kB I-Cache and 128kB D-Cache Got the following for the console env. variable: s Should set to serial console... Will be using PROM console! Moving Kernel Image from 80200000 to 80030000 Launching Kernel ... Loading R[23]00 MMU routines. Linux version 2.1.100 (harry@franz) (gcc version 2.7.2) #265 Tue Jul 14 21:04:28 Calibrating delay loop... 32.90 BogoMIPS Memory: 47376k/49148k available (776k kernel code, 788k data) Swansea University Computer Society NET3.039 for Linux 2.1 NET3: Unix domain sockets 0.16 for Linux NET3.038. Swansea University Computer Society TCP/IP for NET3.037 IP Protocols: ICMP, UDP, TCP Checking for 'wait' instruction... unavailable. POSIX conformance testing by UNIFIX TURBOchannel rev. 1 at 12.5 MHz (no parity) slot 0: DEC PMAZ-AA V5.3d slot 2: DEC PMAG-DA V5.3g Starting kswapd v 1.5 DECstation Z8530 serial driver version 0.01 tty00 at 0xbc100001 (irq = 3) is a Z8530 ESCC tty01 at 0xbc100009 (irq = 3) is a Z8530 ESCC tty02 at 0xbc180001 (irq = 3) is a Z8530 ESCC tty03 at 0xbc180009 (irq = 3) is a Z8530 ESCC Ramdisk driver initialized : 16 ramdisks of 4096K size RAMDISK: Compressed image found at block 0 VFS: Mounted root (ext2 filesystem). Freeing unused kernel memory: 32k freed sys_open: /dev/console do_page_fault() #2: sending SIGSEGV to sh for illegal readaccess from 00000000 (epc == 00000000, ra == 80038320) do_page_fault() #2: sending SIGSEGV to sh for illegal readaccess from 00000000 (epc == 00000000, ra == 80038320) Fellow DECstation hackers, I have started to hack on a serial device driver and put a simple program on the ramdisk to help me debuggin my driver. Unfortunately I had to find out, that this program was never executed. .text .globl __start .set noreorder __start: lui $4, %hi(device) # /dev/ttyS0 ori $4, %lo(device) li $5, 2 li $6, 0 li $2, 4005 # open syscall nop bltz $2, 1f # error? move $16, $2 # save fd move $4, $16 la $5, string li $6, 13 # count li $2, 4004 # write syscall nop move $4, $16 # fd li $2, 4006 # close syscall nop 1: li $4, 0 li $2, 4001 # exit syscall nop j 1b # never reached nop device: .asciiz "/dev/ttyS0" string: .ascii "Hello World!" .byte 0x0a So I had to go back to the roots. After having a lot of fun last weekend debugging memory and exception managment code , I finally managed to get the following boot messages (with an additional printk in sys_open): [some boring boot messages snipped] POSIX conformance testing by UNIFIX TURBOchannel rev. 1 at 12.5 MHz (no parity) slot 0: DEC PMAZ-AA V5.3d slot 2: DEC PMAG-DA V5.3g Starting kswapd v 1.5 DECstation Z8530 serial driver version 0.01 tty00 at 0xbc100001 (irq = 3) is a Z8530 ESCC tty01 at 0xbc100009 (irq = 3) is a Z8530 ESCC tty02 at 0xbc180001 (irq = 3) is a Z8530 ESCC tty03 at 0xbc180009 (irq = 3) is a Z8530 ESCC Ramdisk driver initialized : 16 ramdisks of 4096K size RAMDISK: Compressed image found at block 0 VFS: Mounted root (ext2 filesystem). Freeing unused kernel memory: 32k freed sys_open: /dev/console sys_open: /dev/ttyS0 ^^^^^^^^^^^^^^^^^^^^ Whoopee! I'll do my very best to clean up the code and upload it to Michael before going into vacation next week :-). Keep hacking. --- Regards, Harald P.S.: the serial driver is *not* working, the machine still hangs somewhere trying to to open /dev/ttyS0. P.P.S.: the violate.S program gives now endless do_page_fault() #2: sending SIGSEGV to sh for illegal readaccess from 00000000 (epc == 00000000, ra == 80038320) messages. From ralf@uni-koblenz.de Wed Jul 15 13:59:08 1998 Received: from informatik.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.4.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id NAA15970; Wed, 15 Jul 1998 13:59:06 +0200 (MET DST) Received-Date: Wed, 15 Jul 1998 13:59:06 +0200 (MET DST) From: ralf@uni-koblenz.de Received: from uni-koblenz.de (ralf@pmport-01.uni-koblenz.de [141.26.249.1]) by informatik.uni-koblenz.de (8.8.8/8.8.8) with ESMTP id NAA00500 for ; Wed, 15 Jul 1998 13:58:56 +0200 (MEST) Received: (from ralf@localhost) by uni-koblenz.de (8.8.7/8.8.7) id NAA08617; Wed, 15 Jul 1998 13:57:12 +0200 Message-ID: <19980715135712.J2938@uni-koblenz.de> Date: Wed, 15 Jul 1998 13:57:12 +0200 To: linux-mips@fnet.fr Subject: Re: DECstation-Linux: 1st user process running! References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: ; from Harald Koerfgen on Tue, Jul 14, 1998 at 10:33:11PM +0200 On Tue, Jul 14, 1998 at 10:33:11PM +0200, Harald Koerfgen wrote: Ok, the departement of nitpicking is out on the road again: > .text > .globl __start > .set noreorder > > __start: > lui $4, %hi(device) # /dev/ttyS0 > ori $4, %lo(device) %lo returns a signed offset, so this will only work if the address of device happens to be something with bit 15 cleared, which will probably be the case when you assemble your code. It won't do it for the general case. Aside, why not just using the la instruction ... > li $5, 2 > li $6, 0 > li $2, 4005 # open > syscall > nop This is not a jump or branch instruction, no need for a nop. > bltz $2, 1f # error? This won't work. We use the same syscall conventions as IRIX. The result or the _positive_ error number are in $2 on return; an error flag is in $7. So that line should read: bnez $7, 1f # error? > string: .ascii "Hello World!" > .byte 0x0a The assembler knows about the usual C escape sequences like \n. Makes live easier. > I'll do my very best to clean up the code and upload it to Michael before going > into vacation next week :-). Congratulations, nice piece of work. You don't happen to take your DEC with you on holiday, don't you ;-) Ralf From harald.koerfgen@netcologne.de Wed Jul 15 20:44:18 1998 Received: from mail2.netcologne.de (mail2.netcologne.de [194.8.194.103]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id UAA19103; Wed, 15 Jul 1998 20:44:15 +0200 (MET DST) Received-Date: Wed, 15 Jul 1998 20:44:15 +0200 (MET DST) Received: from franz.no.dom (dial8-198.netcologne.de [195.14.235.198]) by mail2.netcologne.de (8.8.8/8.8.8) with ESMTP id UAA00475 for ; Wed, 15 Jul 1998 20:44:09 +0200 (MET DST) X-Ncc-Regid: de.netcologne Message-ID: X-Mailer: XFMail 1.2 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <19980715135712.J2938@uni-koblenz.de> Date: Wed, 15 Jul 1998 20:45:15 +0200 (MEST) Reply-To: "Harald Koerfgen" Organization: none Sender: harry@franz.no.dom From: Harald Koerfgen To: linux-mips@fnet.fr Subject: Re: DECstation-Linux: 1st user process running! Hi, On 15-Jul-98 ralf@uni-koblenz.de wrote: > On Tue, Jul 14, 1998 at 10:33:11PM +0200, Harald Koerfgen wrote: > > Ok, the departement of nitpicking is out on the road again: [comments snipped] Thanks for your comments on my little test program. I fixed that. Unfortunately this didn't help my nonfunctional serial device driver ;-). >> I'll do my very best to clean up the code and upload it to Michael before >> going >> into vacation next week :-). > > Congratulations, nice piece of work. You don't happen to take your > DEC with you on holiday, don't you ;-) No, I won't. My girlfriend would probably kill me :-). > Ralf --- Regards, Harald From eugenio.sanchez@avantel.com.mx Thu Jul 16 02:22:12 1998 Received: from mty-egw1.avantel.com.mx (mty-egw1.avantel.com.mx [200.33.230.4]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id CAA22946; Thu, 16 Jul 1998 02:22:10 +0200 (MET DST) Received-Date: Thu, 16 Jul 1998 02:22:10 +0200 (MET DST) Received: from mty-igw1.avantel.com.mx (root@localhost) by mty-egw1.avantel.com.mx with ESMTP id TAA22366 for ; Wed, 15 Jul 1998 19:23:03 -0500 (CDT) Received: from mtymail.avantel.com.mx (mtymsfco01.icom.avantel.com.mx [172.24.2.4]) by mty-igw1.avantel.com.mx with SMTP id TAA22362 for ; Wed, 15 Jul 1998 19:23:03 -0500 (CDT) Received: by mtymail.avantel.com.mx with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BDB026.018DD4C0@mtymail.avantel.com.mx>; Wed, 15 Jul 1998 19:23:11 -0500 Message-ID: From: Jesus Eugenio Sanchez To: "'Linux MIPS'" Subject: Cobalt Networks' Qube Date: Wed, 15 Jul 1998 19:23:20 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Just to let you know that Cobalt has released the sources for their MIPS- based Qube. They're available at ftp://ftp.cobaltnet.com Greetings. ---- Jes=FAs Eugenio S=E1nchez Pe=F1a (eugenio.sanchez@avantel.com.mx) Avantel, S.A. x5868, v273-5868, (8) 153-5868 Visit the OrderPro home page! http://eons_linux/orderpro From ralf@uni-koblenz.de Thu Jul 16 21:13:48 1998 Received: from informatik.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.4.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id VAA28939; Thu, 16 Jul 1998 21:13:46 +0200 (MET DST) Received-Date: Thu, 16 Jul 1998 21:13:46 +0200 (MET DST) From: ralf@uni-koblenz.de Received: from uni-koblenz.de (ralf@pmport-06.uni-koblenz.de [141.26.249.6]) by informatik.uni-koblenz.de (8.8.8/8.8.8) with ESMTP id VAA20390 for ; Thu, 16 Jul 1998 21:13:40 +0200 (MEST) Received: (from ralf@localhost) by uni-koblenz.de (8.8.7/8.8.7) id VAA03925; Thu, 16 Jul 1998 21:13:33 +0200 Message-ID: <19980716211332.A3772@uni-koblenz.de> Date: Thu, 16 Jul 1998 21:13:32 +0200 To: linux@engr.sgi.com, linux-mips@fnet.fr Subject: Mozilla Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 Hi, if you want to play with Mozilla, then you'll need the kernel patch which I've just checked in. It's a tiny first attempt at writing the floating point support code for the kernel but it is at least good enough for Mozilla. Ralf From R.vandenBerg@inter.NL.net Fri Jul 17 00:09:40 1998 Received: from altrade.nijmegen.inter.nl.net (altrade.nijmegen.inter.nl.net [193.67.237.6]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id AAA00124; Fri, 17 Jul 1998 00:09:39 +0200 (MET DST) Received-Date: Fri, 17 Jul 1998 00:09:39 +0200 (MET DST) Received: from dutch.mountain by altrade.nijmegen.inter.nl.net via hn99-18.Hoorn.NL.net [193.79.46.243] with ESMTP for id AAA04248 (8.8.8/3.28); Fri, 17 Jul 1998 00:09:36 +0200 (MET DST) Received: from whale.dutch.mountain(really [192.168.1.1]) by dutch.mountain via in.smtpd with smtp id for ; Fri, 17 Jul 1998 00:08:29 +0200 (MET DST) (Smail-3.2 1996-Jul-4 #2 built 1996-Nov-26) Date: Fri, 17 Jul 1998 00:08:28 +0200 (MET DST) From: Richard van den Berg X-Sender: ravdberg@whale.dutch.mountain To: linux-mips@fnet.fr Subject: RE: __initfunc(), kernel coding logic? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 2 Jul 1998, Harald Koerfgen wrote: > If you want to do some experiments with a net driver you may want to edit > drivers/net/Space.c accordingly. After making that file a bit verbose with printk()'s I understand its functioning better (and struct). Now the initializing of the lance. Nice stuff Linux network driver code! :-) Happy Holidays! Regards, Richard From osk@hem.passagen.se Fri Jul 17 11:17:47 1998 Received: from Grynet.passagen.se (grynet.passagen.se [194.17.55.99]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id LAA04937; Fri, 17 Jul 1998 11:17:46 +0200 (MET DST) Received-Date: Fri, 17 Jul 1998 11:17:46 +0200 (MET DST) Received: from oskar (dialup100-4-49.swipnet.se [130.244.100.241]) by Grynet.passagen.se (8.8.6/8.8.6) with SMTP id LAA29770 for ; Fri, 17 Jul 1998 11:17:13 +0200 (MDT) Message-ID: <000601bdb163$e9785ce0$0100a8c0@oskar> From: "Oskar Liljeblad" To: Subject: MIPS CPU in palmtop Date: Fri, 17 Jul 1998 10:51:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 I'm considering buying a handheld PC, and porting linux to it. This particular computer uses a 32bit Philips PR31700 (TwoChipPic HCG) CPU which is MIPS R3000A-based. Will Linux/MIPS support this processor? Oskar Liljeblad (osk@hem.passagen.se) From jdouma@ivs.com Fri Jul 17 21:00:47 1998 Received: from blackberry.ivs.com (www.ivs.com [207.177.145.250]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id VAA08363; Fri, 17 Jul 1998 21:00:43 +0200 (MET DST) Received-Date: Fri, 17 Jul 1998 21:00:43 +0200 (MET DST) Received: from ivs.com (mulberry.ivs.com [207.177.145.166]) by blackberry.ivs.com (8.8.5/8.8.5) with ESMTP id LAA11473 for ; Fri, 17 Jul 1998 11:04:25 -0700 Message-ID: <35AF9F69.98D36357@ivs.com> Date: Fri, 17 Jul 1998 12:00:57 -0700 From: James Douma X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: linux-mips@fnet.fr Subject: Re: MIPS CPU in palmtop References: <000601bdb163$e9785ce0$0100a8c0@oskar> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The cobalt kernel (running on their qubes) is MIPS-II only. It should be R3000A compatible. Oskar Liljeblad wrote: > > I'm considering buying a handheld PC, and porting linux to it. This > particular computer uses a 32bit Philips PR31700 (TwoChipPic HCG) CPU which > is MIPS R3000A-based. Will Linux/MIPS support this processor? > > Oskar Liljeblad (osk@hem.passagen.se) -- James Douma -- Manager, Hardware Development Interactive Voice Systems Inc email: jdouma@ivs.com pager: 818.297.3058 Phone: 626.256.3123 Fax: 626.256.3197 From ralf@uni-koblenz.de Sat Jul 18 05:15:49 1998 Received: from informatik.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.4.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id FAA12586; Sat, 18 Jul 1998 05:15:48 +0200 (MET DST) Received-Date: Sat, 18 Jul 1998 05:15:48 +0200 (MET DST) From: ralf@uni-koblenz.de Received: from uni-koblenz.de (ralf@pmport-04.uni-koblenz.de [141.26.249.4]) by informatik.uni-koblenz.de (8.8.8/8.8.8) with ESMTP id FAA21724 for ; Sat, 18 Jul 1998 05:15:35 +0200 (MEST) Received: (from ralf@localhost) by uni-koblenz.de (8.8.7/8.8.7) id FAA02153; Sat, 18 Jul 1998 05:14:52 +0200 Message-ID: <19980718051451.G378@uni-koblenz.de> Date: Sat, 18 Jul 1998 05:14:51 +0200 To: James Douma , linux-mips@fnet.fr, osk@hem.passagen.se Subject: Re: MIPS CPU in palmtop References: <000601bdb163$e9785ce0$0100a8c0@oskar> <35AF9F69.98D36357@ivs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <35AF9F69.98D36357@ivs.com>; from James Douma on Fri, Jul 17, 1998 at 12:00:57PM -0700 On Fri, Jul 17, 1998 at 12:00:57PM -0700, James Douma wrote: > The cobalt kernel (running on their qubes) is MIPS-II only. It should > be R3000A compatible. No. The ISA level has no direct relation to the architecture of the system control coprocessor and cache architecture. Those differences are why the R3000 isn't supported in Cobalt's kernel. There is currently ongoing work to support the R3000 for sake of the DECstation port and things are beginning to look pretty well. > > I'm considering buying a handheld PC, and porting linux to it. This > > particular computer uses a 32bit Philips PR31700 (TwoChipPic HCG) CPU which > > is MIPS R3000A-based. Will Linux/MIPS support this processor? Ralf From andy@psn.ie Sat Jul 18 21:45:32 1998 Received: from soprano.psn.ie (soprano.psn.ie [194.106.150.194] (may be forged)) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id VAA18166; Sat, 18 Jul 1998 21:45:30 +0200 (MET DST) Received-Date: Sat, 18 Jul 1998 21:45:30 +0200 (MET DST) Received: from gromit.psn.ie ([194.106.150.251] helo=homer ident=andy) by soprano.psn.ie with smtp (Exim 1.92 #1) for linux-mips@fnet.fr id 0yxcyY-0005fM-00; Sat, 18 Jul 1998 20:48:58 +0100 Date: Sun, 19 Jul 1998 20:48:15 +0100 (IST) From: Andy Doran X-Sender: andy@homer To: linux-mips@fnet.fr Subject: Linux kernel Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Just writing to ask a question. Are there andy patches out there for the 2.1 kernels to bring the MIPS sections up to date? 2.1.105 is badly broken on MIPS, it doesn't even want to build without a few hours work. If there aren't any, I can send you my patch, just as soon as I clean it all up. Please let me know. ____/| Andy Doran \ o.O| =(_)= "Thou shalt not follow the NULL pointer for U chaos and madness await thee at its end."