From owner-linux-origin@oss.sgi.com Tue Sep 5 14:03:56 2000 Received: by oss.sgi.com id ; Tue, 5 Sep 2000 14:03:46 -0700 Received: from u-43.karlsruhe.ipdial.viaginterkom.de ([62.180.18.43]:16388 "EHLO u-43.karlsruhe.ipdial.viaginterkom.de") by oss.sgi.com with ESMTP id ; Tue, 5 Sep 2000 14:03:26 -0700 Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Tue, 5 Sep 2000 10:02:17 +0200 Date: Tue, 5 Sep 2000 10:02:17 +0200 From: Ralf Baechle To: linux-origin@oss.sgi.com Subject: rpm on diskless systems Message-ID: <20000905100217.A825@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing I recently reported to some people that I had big problems running rpm on my diskless Origin. rpm is behaving ok on my Origin when running from local disk. It's also running ok on my laptop when I nfs-mount something from localhost. I therefore assume it's a special interaction between rpm and IRIX as nfs server. Ralf From owner-linux-origin@oss.sgi.com Tue Sep 12 15:36:13 2000 Received: by oss.sgi.com id ; Tue, 12 Sep 2000 15:36:04 -0700 Received: from u-207.karlsruhe.ipdial.viaginterkom.de ([62.180.18.207]:44805 "EHLO u-207.karlsruhe.ipdial.viaginterkom.de") by oss.sgi.com with ESMTP id ; Tue, 12 Sep 2000 15:35:36 -0700 Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Tue, 12 Sep 2000 19:34:24 +0200 Date: Tue, 12 Sep 2000 19:34:24 +0200 From: Ralf Baechle To: linux-origin@oss.sgi.com, Ulf Carlsson , Keith M Wesolowski , "Maciej W. Rozycki" Subject: ld.so bug Message-ID: <20000912193424.A4052@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing We've got a bug in the dynamic linker which makes it die when it's not loaded to the address it's linked to. This is bug number one but the second bug is the fact that it gets loaded to the wrong address. I suspect this may also happen at times on a 32-bit kernel also but it's happening much easier on mips64. Easiest way to show this is to run /lib/ld.so.1 - it will always die on MIPS64. This brings us to bug number three - gdb 4.16 only prints junk from the resulting corefile; I assume that the 64-bit kernel doesn't write the registers properly into the core file. Kanoj, got an idea why the kernel might load ld.so to a different address than it is linked for? Note that ldd is running ld.so directly, therefore on an Origin it will always say ``not a dynamic executable''. This again will confuse libtool into producing wrong library and rpm into generating packages without library dependency information and probably a few more neat little resulting bugs. Btw, this same problem should also affect glibc 2.2. Ralf From owner-linux-origin@oss.sgi.com Tue Sep 12 16:15:35 2000 Received: by oss.sgi.com id ; Tue, 12 Sep 2000 16:15:25 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:51272 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 12 Sep 2000 16:15:09 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA17399; Tue, 12 Sep 2000 16:07:27 -0700 (PDT) mail_from (kanoj@google.engr.sgi.com) Received: from google.engr.sgi.com (google.engr.sgi.com [163.154.10.145]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id QAA75092; Tue, 12 Sep 2000 16:14:36 -0700 (PDT) Received: (from kanoj@localhost) by google.engr.sgi.com (SGI-8.9.3/8.9.3) id QAA82825; Tue, 12 Sep 2000 16:12:05 -0700 (PDT) From: Kanoj Sarcar Message-Id: <200009122312.QAA82825@google.engr.sgi.com> Subject: Re: ld.so bug To: ralf@oss.sgi.com (Ralf Baechle) Date: Tue, 12 Sep 2000 16:12:05 -0700 (PDT) Cc: linux-origin@oss.sgi.com, ulfc@cthulhu.engr.sgi.com (Ulf Carlsson), wesolows@foobazco.org (Keith M Wesolowski), macro@ds2.pg.gda.pl (Maciej W. Rozycki) In-Reply-To: <20000912193424.A4052@bacchus.dhis.org> from "Ralf Baechle" at Sep 12, 2000 07:34:24 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing > > We've got a bug in the dynamic linker which makes it die when it's not > loaded to the address it's linked to. This is bug number one but the > second bug is the fact that it gets loaded to the wrong address. I > suspect this may also happen at times on a 32-bit kernel also but it's > happening much easier on mips64. Easiest way to show this is to run > /lib/ld.so.1 - it will always die on MIPS64. This brings us to bug number > three - gdb 4.16 only prints junk from the resulting corefile; I assume > that the 64-bit kernel doesn't write the registers properly into the core > file. > > Kanoj, got an idea why the kernel might load ld.so to a different address > than it is linked for? I don't clearly understand what is going on, but I would start off by looking at SET_PERSONALITY and TASK_UNMAPPED_BASE when you run /lib/ld.so.1. May or may not yield anything ... Kanoj > > Note that ldd is running ld.so directly, therefore on an Origin it will > always say ``not a dynamic executable''. This again will confuse > libtool into producing wrong library and rpm into generating packages > without library dependency information and probably a few more > neat little resulting bugs. > > Btw, this same problem should also affect glibc 2.2. > > Ralf > From owner-linux-origin@oss.sgi.com Wed Sep 13 15:55:04 2000 Received: by oss.sgi.com id ; Wed, 13 Sep 2000 15:54:44 -0700 Received: from u-169.karlsruhe.ipdial.viaginterkom.de ([62.180.10.169]:14087 "EHLO u-169.karlsruhe.ipdial.viaginterkom.de") by oss.sgi.com with ESMTP id ; Wed, 13 Sep 2000 15:54:14 -0700 Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Wed, 13 Sep 2000 23:49:16 +0200 Date: Wed, 13 Sep 2000 23:49:16 +0200 From: Ralf Baechle To: Kanoj Sarcar Cc: linux-origin@oss.sgi.com, Ulf Carlsson , Keith M Wesolowski , "Maciej W. Rozycki" Subject: Re: ld.so bug Message-ID: <20000913234916.A7496@bacchus.dhis.org> References: <20000912193424.A4052@bacchus.dhis.org> <200009122312.QAA82825@google.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200009122312.QAA82825@google.engr.sgi.com>; from kanoj@google.engr.sgi.com on Tue, Sep 12, 2000 at 04:12:05PM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Tue, Sep 12, 2000 at 04:12:05PM -0700, Kanoj Sarcar wrote: > > We've got a bug in the dynamic linker which makes it die when it's not > > loaded to the address it's linked to. This is bug number one but the > > second bug is the fact that it gets loaded to the wrong address. I > > suspect this may also happen at times on a 32-bit kernel also but it's > > happening much easier on mips64. Easiest way to show this is to run > > /lib/ld.so.1 - it will always die on MIPS64. This brings us to bug number > > three - gdb 4.16 only prints junk from the resulting corefile; I assume > > that the 64-bit kernel doesn't write the registers properly into the core > > file. > > > > Kanoj, got an idea why the kernel might load ld.so to a different address > > than it is linked for? > > I don't clearly understand what is going on, but I would start off by > looking at SET_PERSONALITY and TASK_UNMAPPED_BASE when you run > /lib/ld.so.1. May or may not yield anything ... I checked binfmt_elf32.c; the load address which I saw is defined by the constant ELF_ET_DYN_BASE which is defined in which should have triggered the bug I'm observing a long time ago and also on the 32-bit kernels. In short - there is no kernel bug. I'm just building libc binaries with the fix applied and will probably have rpms ready by tomorrow. Ralf From owner-linux-origin@oss.sgi.com Thu Sep 14 10:50:20 2000 Received: by oss.sgi.com id ; Thu, 14 Sep 2000 10:50:10 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:8307 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 14 Sep 2000 10:49:44 -0700 Received: from google.engr.sgi.com (google.engr.sgi.com [163.154.10.145]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA14273 for ; Thu, 14 Sep 2000 10:42:03 -0700 (PDT) mail_from (kanoj@google.engr.sgi.com) Received: (from kanoj@localhost) by google.engr.sgi.com (SGI-8.9.3/8.9.3) id KAA95175; Thu, 14 Sep 2000 10:48:27 -0700 (PDT) From: Kanoj Sarcar Message-Id: <200009141748.KAA95175@google.engr.sgi.com> Subject: mips64 partitioned support on Linux To: linux-origin@oss.sgi.com, snia_linux@google.engr.sgi.com Date: Thu, 14 Sep 2000 10:48:27 -0700 (PDT) Cc: fgodfrey@google.engr.sgi.com, rja@google.engr.sgi.com, jh@google.engr.sgi.com, ggg@google.engr.sgi.com X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing Just thought I would let you guys know that I have been able to run a make -j6 kernel build on a (slightly hacked) mips64 top of trunk kernel running on a non nasid-0 system. This is by using a kernel whose text and data is mapped via k2seg/tlb (which is how kernel text replication also works in IRIX), and using calias space for pernode exception handlers. Kanoj From owner-linux-origin@oss.sgi.com Fri Sep 22 06:26:33 2000 Received: by oss.sgi.com id ; Fri, 22 Sep 2000 06:26:23 -0700 Received: from [131.188.77.254] ([131.188.77.254]:20484 "EHLO lappi") by oss.sgi.com with ESMTP id ; Fri, 22 Sep 2000 06:26:16 -0700 Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Fri, 22 Sep 2000 15:26:04 +0200 Date: Fri, 22 Sep 2000 15:26:04 +0200 From: Ralf Baechle To: linux-mips@oss.sgi.com, linux-mips@fnet.fr, linux-origin@oss.sgi.com Subject: libc upgrade Message-ID: <20000922152604.A2627@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing I've uploaded the hopefully last glibc 2.0.6 release to oss.sgi.com. The rpm package filenames are: glibc-2.0.6-6lm.src.rpm, glibc-2.0.6-6lm.mips.rpm, glibc-devel-2.0.6-6lm.mips.rpm, glibc-profile-2.0.6-6lm.mips.rpm, glibc-debug-2.0.6-6lm.mips.rpm This release fix a number of bug that have been hanging in the dynamic linker basically forever and is urgently recommended to install. Once more rpm in it's stupidity being a static linked program breaks. I therefore also provide new rpm binaries: rpm-3.0-6.0lm.mips.rpm rpm-devel-3.0-6.0lm.mips.rpm No new source package for rpm since this is just a recompile of the package. Not that also other software which has been statically linked against libdl needs to be rebuilt against this library release. IMPORTANT: you must install these new rpm binaries before you upgrade glibc! Ralf From owner-linux-origin@oss.sgi.com Fri Sep 22 06:27:33 2000 Received: by oss.sgi.com id ; Fri, 22 Sep 2000 06:27:23 -0700 Received: from [131.188.77.254] ([131.188.77.254]:20484 "EHLO lappi") by oss.sgi.com with ESMTP id ; Fri, 22 Sep 2000 06:27:16 -0700 Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Fri, 22 Sep 2000 15:26:57 +0200 Date: Fri, 22 Sep 2000 15:26:57 +0200 From: Ralf Baechle To: linux-origin@oss.sgi.com Subject: libc upgrade Message-ID: <20000922152657.A2649@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i X-Mailer: Mutt 1.0.1i X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing I've uploaded the hopefully last glibc 2.0.6 release to oss.sgi.com. The rpm package filenames are: glibc-2.0.6-6lm.src.rpm, glibc-2.0.6-6lm.mips.rpm, glibc-devel-2.0.6-6lm.mips.rpm, glibc-profile-2.0.6-6lm.mips.rpm, glibc-debug-2.0.6-6lm.mips.rpm This release fix a number of bug that have been hanging in the dynamic linker basically forever and is urgently recommended to install. Once more rpm in it's stupidity being a static linked program breaks. I therefore also provide new rpm binaries: rpm-3.0-6.0lm.mips.rpm rpm-devel-3.0-6.0lm.mips.rpm No new source package for rpm since this is just a recompile of the package. Not that also other software which has been statically linked against libdl needs to be rebuilt against this library release. IMPORTANT: you must install these new rpm binaries before you upgrade glibc! Ralf From owner-linux-origin@oss.sgi.com Mon Sep 25 02:31:14 2000 Received: by oss.sgi.com id ; Mon, 25 Sep 2000 02:31:04 -0700 Received: from noose.gt.owl.de ([62.52.19.4]:38148 "HELO noose.gt.owl.de") by oss.sgi.com with SMTP id ; Mon, 25 Sep 2000 02:30:59 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id D3B457FD; Mon, 25 Sep 2000 11:37:09 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 3023A9014; Mon, 25 Sep 2000 11:24:13 +0200 (CEST) Date: Mon, 25 Sep 2000 11:24:13 +0200 From: Florian Lohoff To: Ralf Baechle Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr, linux-origin@oss.sgi.com Subject: Re: libc upgrade Message-ID: <20000925112413.B3247@paradigm.rfc822.org> References: <20000922152604.A2627@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <20000922152604.A2627@bacchus.dhis.org>; from ralf@oss.sgi.com on Fri, Sep 22, 2000 at 03:26:04PM +0200 Organization: rfc822 - pure communication Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Fri, Sep 22, 2000 at 03:26:04PM +0200, Ralf Baechle wrote: > I've uploaded the hopefully last glibc 2.0.6 release to oss.sgi.com. The > rpm package filenames are: > > glibc-2.0.6-6lm.src.rpm, Build fails on mipsel ... gcc rpcinfo.c -c -O2 -g -w -I. -I.. -I../libio -I../sysdeps/mips/elf -I../crypt/sysdeps/unix -I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pthread -I../linuxthreads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix -I../linuxthreads/sysdeps/mips -I../linuxthreads/sysdeps/pthread/cmpxchg -I../sysdeps/unix/sysv/linux/mips -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix/mips -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/mips/mipsel -I../sysdeps/mips -I../sysdeps/wordsize-32 -I../sysdeps/ieee754 -I../sysdeps/libm-ieee754 -I../sysdeps/generic -I../sysdeps/stub -D_LIBC_REENTRANT -D_PATH_RPC='"/etc/rpc"' -include ../libc-symbols.h -o rpcinfo.o gcc -nostdlib -nostartfiles -o rpcinfo -Wl,-dynamic-linker=/lib/ld.so.1 -g ../csu/start.o ../csu/crti.o `gcc --print-file-name=crtbegin.o` rpcinfo.o -Wl,-rpath-link=..:../elf:../nss ../libc.so.6 ../elf/ld.so.1 ../libc.a -lgcc `gcc --print-file-name=crtend.o` ../csu/crtn.o /bin/sh: invalid character 45 in exportstr for full-config-sysdirs LD_LIBRARY_PATH=..:../elf:../nss ../elf/ld.so.1 ./rpcgen -c rpcsvc/bootparam.x -o xbootparam.T /bin/sh: invalid character 45 in exportstr for full-config-sysdirs make[1]: *** [xbootparam.stmp] Segmentation fault make[1]: Leaving directory `/usr/src/redhat/BUILD/glibc-2.0.6/sunrpc' make: *** [sunrpc/others] Error 2 Bad exit status from /var/tmp/rpm-tmp.29023 (%build) Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 "Write only memory - Oops. Time for my medication again ..." From owner-linux-origin@oss.sgi.com Mon Sep 25 04:22:55 2000 Received: by oss.sgi.com id ; Mon, 25 Sep 2000 04:22:44 -0700 Received: from u-194.karlsruhe.ipdial.viaginterkom.de ([62.180.10.194]:51461 "EHLO u-194.karlsruhe.ipdial.viaginterkom.de") by oss.sgi.com with ESMTP id ; Mon, 25 Sep 2000 04:22:35 -0700 Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Mon, 25 Sep 2000 13:20:57 +0200 Date: Mon, 25 Sep 2000 13:20:56 +0200 From: Ralf Baechle To: Florian Lohoff Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr, linux-origin@oss.sgi.com Subject: Re: libc upgrade Message-ID: <20000925132056.A7598@bacchus.dhis.org> References: <20000922152604.A2627@bacchus.dhis.org> <20000925112413.B3247@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000925112413.B3247@paradigm.rfc822.org>; from flo@rfc822.org on Mon, Sep 25, 2000 at 11:24:13AM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Mon, Sep 25, 2000 at 11:24:13AM +0200, Florian Lohoff wrote: > Build fails on mipsel ... These messages look like file corruption. Maybe one of the `features' of the 2.4.0-test kernels and not libc at all? Ralf From owner-linux-origin@oss.sgi.com Mon Sep 25 07:21:15 2000 Received: by oss.sgi.com id ; Mon, 25 Sep 2000 07:21:06 -0700 Received: from noose.gt.owl.de ([62.52.19.4]:11780 "HELO noose.gt.owl.de") by oss.sgi.com with SMTP id ; Mon, 25 Sep 2000 07:20:56 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id 4477D801; Mon, 25 Sep 2000 16:27:07 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 8F1DA9014; Mon, 25 Sep 2000 16:15:00 +0200 (CEST) Date: Mon, 25 Sep 2000 16:15:00 +0200 From: Florian Lohoff To: Ralf Baechle Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr, linux-origin@oss.sgi.com Subject: Re: libc upgrade Message-ID: <20000925161500.A4773@paradigm.rfc822.org> References: <20000922152604.A2627@bacchus.dhis.org> <20000925112413.B3247@paradigm.rfc822.org> <20000925132056.A7598@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <20000925132056.A7598@bacchus.dhis.org>; from ralf@oss.sgi.com on Mon, Sep 25, 2000 at 01:20:56PM +0200 Organization: rfc822 - pure communication Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Mon, Sep 25, 2000 at 01:20:56PM +0200, Ralf Baechle wrote: > On Mon, Sep 25, 2000 at 11:24:13AM +0200, Florian Lohoff wrote: > > > Build fails on mipsel ... > > These messages look like file corruption. Maybe one of the `features' > of the 2.4.0-test kernels and not libc at all? I dont think so - I succeeded to compile ~2000 Packages of debian on this kernel and its noticeably the first execution with the "new" ld.so LD_LIBRARY_PATH=..:../elf:../nss ../elf/ld.so.1 ./rpcgen -c rpcsvc/bootparam.x -o xbootparam.T /bin/sh: invalid character 45 in exportstr for full-config-sysdirs make[1]: *** [xbootparam.stmp] Segmentation fault Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 "Write only memory - Oops. Time for my medication again ..." From owner-linux-origin@oss.sgi.com Mon Sep 25 13:16:07 2000 Received: by oss.sgi.com id ; Mon, 25 Sep 2000 13:15:57 -0700 Received: from u-53.karlsruhe.ipdial.viaginterkom.de ([62.180.20.53]:9222 "EHLO u-53.karlsruhe.ipdial.viaginterkom.de") by oss.sgi.com with ESMTP id ; Mon, 25 Sep 2000 13:15:26 -0700 Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Mon, 25 Sep 2000 22:14:15 +0200 Date: Mon, 25 Sep 2000 22:14:14 +0200 From: Ralf Baechle To: Florian Lohoff Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr, linux-origin@oss.sgi.com Subject: Re: libc upgrade Message-ID: <20000925221414.A6190@bacchus.dhis.org> References: <20000922152604.A2627@bacchus.dhis.org> <20000925112413.B3247@paradigm.rfc822.org> <20000925132056.A7598@bacchus.dhis.org> <20000925161500.A4773@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000925161500.A4773@paradigm.rfc822.org>; from flo@rfc822.org on Mon, Sep 25, 2000 at 04:15:00PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Mon, Sep 25, 2000 at 04:15:00PM +0200, Florian Lohoff wrote: > > > Build fails on mipsel ... > > > > These messages look like file corruption. Maybe one of the `features' > > of the 2.4.0-test kernels and not libc at all? > > I dont think so - I succeeded to compile ~2000 Packages of debian > on this kernel and its noticeably the first execution with the "new" ld.so I week of CPU time on an Origin building packages: No problems ... I'm actually fairly close to get a RH 6.2 built - as far as that is possible with glibc 2.0. > LD_LIBRARY_PATH=..:../elf:../nss ../elf/ld.so.1 ./rpcgen -c rpcsvc/bootparam.x -o xbootparam.T > /bin/sh: invalid character 45 in exportstr for full-config-sysdirs > make[1]: *** [xbootparam.stmp] Segmentation fault Ok, second theory. What linker where you using to build all this programs? The new ld.so needs to know what ld has built programs due to some pretty stupid pre-2.9.something brokeness in R_MIPS_32 reloction handling. Ralf From owner-linux-origin@oss.sgi.com Mon Sep 25 13:53:27 2000 Received: by oss.sgi.com id ; Mon, 25 Sep 2000 13:53:17 -0700 Received: from u-53.karlsruhe.ipdial.viaginterkom.de ([62.180.20.53]:13062 "EHLO u-53.karlsruhe.ipdial.viaginterkom.de") by oss.sgi.com with ESMTP id ; Mon, 25 Sep 2000 13:52:48 -0700 Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Mon, 25 Sep 2000 22:52:01 +0200 Date: Mon, 25 Sep 2000 22:52:01 +0200 From: Ralf Baechle To: John Hawkes Cc: Kanoj Sarcar , linux-origin@oss.sgi.com Subject: Re: posix0 "eth0: RX overflow" Message-ID: <20000925225201.C6190@bacchus.dhis.org> References: <00fd01c02721$353bf620$6401a8c0@marin1.sfba.home.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <00fd01c02721$353bf620$6401a8c0@marin1.sfba.home.com>; from hawkes@cthulhu.engr.sgi.com on Mon, Sep 25, 2000 at 11:48:33AM -0700 X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Mon, Sep 25, 2000 at 11:48:33AM -0700, John Hawkes wrote: > FYI, I built a kernel (with Lockmeter in it) from this morning's mips64 > sources, and after a fairly heavy AIM7-like load for 15 minutes, I saw > multiple "eth0: RX overflow" messages and networking no longer worked. A known problem with the IOC3 network driver. For some reason in 99% of cases it fails to reinitialize the driver after it receives such a RX overflow interrupt. > Also, I can't rlogin to posix0 more than once. That is, I can rlogin > with one window, but not with a second window. Maybe /etc/securetty? I normally use telnet and haven't noticed any problems. We got another fairly bad problem with the kernel. It seems that it's leaking filedescriptors. Even when I kill all processes except init and my last shell I occasionally can't remount / read-only resulting in a fsck on reboot. I would suspect that this happens somewhere in the binary compatibility code. Oh, and I verified that the recent console changes broke /dev/console. Ralf From owner-linux-origin@oss.sgi.com Mon Sep 25 14:59:57 2000 Received: by oss.sgi.com id ; Mon, 25 Sep 2000 14:59:47 -0700 Received: from pneumatic-tube.sgi.com ([204.94.214.22]:13125 "EHLO pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP id ; Mon, 25 Sep 2000 14:59:21 -0700 Received: from google.engr.sgi.com (google.engr.sgi.com [163.154.10.145]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA02735; Mon, 25 Sep 2000 15:05:43 -0700 (PDT) mail_from (kanoj@google.engr.sgi.com) Received: (from kanoj@localhost) by google.engr.sgi.com (SGI-8.9.3/8.9.3) id OAA89098; Mon, 25 Sep 2000 14:57:34 -0700 (PDT) From: Kanoj Sarcar Message-Id: <200009252157.OAA89098@google.engr.sgi.com> Subject: Re: posix0 "eth0: RX overflow" To: ralf@oss.sgi.com (Ralf Baechle) Date: Mon, 25 Sep 2000 14:57:34 -0700 (PDT) Cc: hawkes@cthulhu.engr.sgi.com (John Hawkes), linux-origin@oss.sgi.com In-Reply-To: <20000925225201.C6190@bacchus.dhis.org> from "Ralf Baechle" at Sep 25, 2000 10:52:01 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing > > On Mon, Sep 25, 2000 at 11:48:33AM -0700, John Hawkes wrote: > > > FYI, I built a kernel (with Lockmeter in it) from this morning's mips64 > > sources, and after a fairly heavy AIM7-like load for 15 minutes, I saw > > multiple "eth0: RX overflow" messages and networking no longer worked. > > A known problem with the IOC3 network driver. For some reason in 99% of > cases it fails to reinitialize the driver after it receives such a RX > overflow interrupt. > > > Also, I can't rlogin to posix0 more than once. That is, I can rlogin > > with one window, but not with a second window. > > Maybe /etc/securetty? I normally use telnet and haven't noticed any > problems. > > We got another fairly bad problem with the kernel. It seems that it's > leaking filedescriptors. Even when I kill all processes except init and > my last shell I occasionally can't remount / read-only resulting in a > fsck on reboot. I would suspect that this happens somewhere in the binary > compatibility code. > > Oh, and I verified that the recent console changes broke /dev/console. > Is this an issue on IP22 or IP27s? Also, let me know what experiments you tried to come to this conclusion, it has been a while since we talked about this. Kanoj > Ralf > From owner-linux-origin@oss.sgi.com Mon Sep 25 16:33:38 2000 Received: by oss.sgi.com id ; Mon, 25 Sep 2000 16:33:28 -0700 Received: from noose.gt.owl.de ([62.52.19.4]:59150 "HELO noose.gt.owl.de") by oss.sgi.com with SMTP id ; Mon, 25 Sep 2000 16:33:08 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id B685E812; Tue, 26 Sep 2000 01:38:50 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id D5B5F9014; Tue, 26 Sep 2000 01:04:16 +0200 (CEST) Date: Tue, 26 Sep 2000 01:04:16 +0200 From: Florian Lohoff To: Ralf Baechle Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr, linux-origin@oss.sgi.com Subject: Re: libc upgrade Message-ID: <20000926010416.B3761@paradigm.rfc822.org> References: <20000922152604.A2627@bacchus.dhis.org> <20000925112413.B3247@paradigm.rfc822.org> <20000925132056.A7598@bacchus.dhis.org> <20000925161500.A4773@paradigm.rfc822.org> <20000925221414.A6190@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <20000925221414.A6190@bacchus.dhis.org>; from ralf@oss.sgi.com on Mon, Sep 25, 2000 at 10:14:14PM +0200 Organization: rfc822 - pure communication Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Mon, Sep 25, 2000 at 10:14:14PM +0200, Ralf Baechle wrote: > On Mon, Sep 25, 2000 at 04:15:00PM +0200, Florian Lohoff wrote: > > LD_LIBRARY_PATH=..:../elf:../nss ../elf/ld.so.1 ./rpcgen -c rpcsvc/bootparam.x -o xbootparam.T > > /bin/sh: invalid character 45 in exportstr for full-config-sysdirs > > make[1]: *** [xbootparam.stmp] Segmentation fault > > Ok, second theory. What linker where you using to build all this programs? > The new ld.so needs to know what ld has built programs due to some pretty > stupid pre-2.9.something brokeness in R_MIPS_32 reloction handling. egcs 1.0.3a binutils 2.8.1 (Very conservative) Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 "Write only memory - Oops. Time for my medication again ..." From owner-linux-origin@oss.sgi.com Mon Sep 25 17:48:49 2000 Received: by oss.sgi.com id ; Mon, 25 Sep 2000 17:48:39 -0700 Received: from u-53.karlsruhe.ipdial.viaginterkom.de ([62.180.20.53]:57608 "EHLO u-53.karlsruhe.ipdial.viaginterkom.de") by oss.sgi.com with ESMTP id ; Mon, 25 Sep 2000 17:48:00 -0700 Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Tue, 26 Sep 2000 02:46:56 +0200 Date: Tue, 26 Sep 2000 02:46:56 +0200 From: Ralf Baechle To: Florian Lohoff Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr, linux-origin@oss.sgi.com Subject: Re: libc upgrade Message-ID: <20000926024656.A8306@bacchus.dhis.org> References: <20000922152604.A2627@bacchus.dhis.org> <20000925112413.B3247@paradigm.rfc822.org> <20000925132056.A7598@bacchus.dhis.org> <20000925161500.A4773@paradigm.rfc822.org> <20000925221414.A6190@bacchus.dhis.org> <20000926010416.B3761@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000926010416.B3761@paradigm.rfc822.org>; from flo@rfc822.org on Tue, Sep 26, 2000 at 01:04:16AM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Tue, Sep 26, 2000 at 01:04:16AM +0200, Florian Lohoff wrote: > On Mon, Sep 25, 2000 at 10:14:14PM +0200, Ralf Baechle wrote: > > On Mon, Sep 25, 2000 at 04:15:00PM +0200, Florian Lohoff wrote: > > > LD_LIBRARY_PATH=..:../elf:../nss ../elf/ld.so.1 ./rpcgen -c rpcsvc/bootparam.x -o xbootparam.T > > > /bin/sh: invalid character 45 in exportstr for full-config-sysdirs > > > make[1]: *** [xbootparam.stmp] Segmentation fault > > > > Ok, second theory. What linker where you using to build all this programs? > > The new ld.so needs to know what ld has built programs due to some pretty > > stupid pre-2.9.something brokeness in R_MIPS_32 reloction handling. > > egcs 1.0.3a binutils 2.8.1 (Very conservative) That's actually the one combination I haven't tested. Looking into it and don't hold your breath :-(. Ralf From owner-linux-origin@oss.sgi.com Tue Sep 26 01:20:22 2000 Received: by oss.sgi.com id ; Tue, 26 Sep 2000 01:20:12 -0700 Received: from t111.niisi.ras.ru ([193.232.173.111]:30530 "EHLO t111.niisi.ras.ru") by oss.sgi.com with ESMTP id ; Tue, 26 Sep 2000 01:19:41 -0700 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id NAA06351; Wed, 1 Jan 1997 13:42:26 +0300 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id LAA10418; Tue, 26 Sep 2000 11:51:43 +0300 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id MAA15053; Tue, 26 Sep 2000 12:16:48 +0300 (MSK) Message-ID: <39D05E8B.A7F4A2D9@niisi.msk.ru> Date: Tue, 26 Sep 2000 12:30:03 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Ralf Baechle CC: Florian Lohoff , linux-mips@oss.sgi.com, linux-mips@fnet.fr, linux-origin@oss.sgi.com Subject: Re: libc upgrade References: <20000922152604.A2627@bacchus.dhis.org> <20000925112413.B3247@paradigm.rfc822.org> <20000925132056.A7598@bacchus.dhis.org> <20000925161500.A4773@paradigm.rfc822.org> <20000925221414.A6190@bacchus.dhis.org> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing Ralf, BTW, what should we use as system headers with glibc nowadays ? Should it be old HardHat kernel-headers-2.1.100 or newer 2.2.x ? > I week of CPU time on an Origin building packages: No problems ... I'm > actually fairly close to get a RH 6.2 built - as far as that is possible > with glibc 2.0. > Do you have the packages somewhere on the net ? I am personally interested in disk packages (fdisk, msdostools &co.) and the packages required in order to run 2.2 kernels. Old HardHat cfdisk, for example, seems to create partitions in the big endian format. At least, the rest see garbage after cfdisk creates a partition table. Regards, Gleb. From owner-linux-origin@oss.sgi.com Tue Sep 26 01:30:22 2000 Received: by oss.sgi.com id ; Tue, 26 Sep 2000 01:30:12 -0700 Received: from t111.niisi.ras.ru ([193.232.173.111]:52546 "EHLO t111.niisi.ras.ru") by oss.sgi.com with ESMTP id ; Tue, 26 Sep 2000 01:29:40 -0700 Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6]) by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id NAA06412; Wed, 1 Jan 1997 13:52:26 +0300 Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id MAA10527; Tue, 26 Sep 2000 12:00:39 +0300 Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id MAA15222; Tue, 26 Sep 2000 12:24:45 +0300 (MSK) Message-ID: <39D06065.FC00C7A0@niisi.msk.ru> Date: Tue, 26 Sep 2000 12:37:57 +0400 From: "Gleb O. Raiko" Organization: NIISI RAN X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Florian Lohoff CC: Ralf Baechle , linux-mips@oss.sgi.com, linux-mips@fnet.fr, linux-origin@oss.sgi.com Subject: Re: libc upgrade References: <20000922152604.A2627@bacchus.dhis.org> <20000925112413.B3247@paradigm.rfc822.org> <20000925132056.A7598@bacchus.dhis.org> <20000925161500.A4773@paradigm.rfc822.org> <20000925221414.A6190@bacchus.dhis.org> <20000926010416.B3761@paradigm.rfc822.org> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing > > Ok, second theory. What linker where you using to build all this programs? > > The new ld.so needs to know what ld has built programs due to some pretty > > stupid pre-2.9.something brokeness in R_MIPS_32 reloction handling. > > egcs 1.0.3a binutils 2.8.1 (Very conservative) > Well, another question. Ralf uploaded cross tools rpms year ago. Does anybody have native rmps for big endian ? Also, does anybody have cross tools for sparc glibc 2.1 (RH6.x sparc distribution) ? I can't compile cross gcc on my Ultra, it seems like a bug in the sparc compiler, the process fails in parsing an enum decl in a header. Regards, Gleb. From owner-linux-origin@oss.sgi.com Tue Sep 26 03:39:52 2000 Received: by oss.sgi.com id ; Tue, 26 Sep 2000 03:39:43 -0700 Received: from noose.gt.owl.de ([62.52.19.4]:2052 "HELO noose.gt.owl.de") by oss.sgi.com with SMTP id ; Tue, 26 Sep 2000 03:39:13 -0700 Received: by noose.gt.owl.de (Postfix, from userid 10) id A77B77F3; Tue, 26 Sep 2000 12:44:58 +0200 (CEST) Received: by paradigm.rfc822.org (Postfix, from userid 1000) id 8F1FB9014; Tue, 26 Sep 2000 12:36:00 +0200 (CEST) Date: Tue, 26 Sep 2000 12:36:00 +0200 From: Florian Lohoff To: "Gleb O. Raiko" Cc: Ralf Baechle , linux-mips@oss.sgi.com, linux-mips@fnet.fr, linux-origin@oss.sgi.com Subject: Re: libc upgrade Message-ID: <20000926123600.A413@paradigm.rfc822.org> References: <20000922152604.A2627@bacchus.dhis.org> <20000925112413.B3247@paradigm.rfc822.org> <20000925132056.A7598@bacchus.dhis.org> <20000925161500.A4773@paradigm.rfc822.org> <20000925221414.A6190@bacchus.dhis.org> <20000926010416.B3761@paradigm.rfc822.org> <39D06065.FC00C7A0@niisi.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <39D06065.FC00C7A0@niisi.msk.ru>; from raiko@niisi.msk.ru on Tue, Sep 26, 2000 at 12:37:57PM +0400 Organization: rfc822 - pure communication Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Tue, Sep 26, 2000 at 12:37:57PM +0400, Gleb O. Raiko wrote: > > > Ok, second theory. What linker where you using to build all this programs? > > > The new ld.so needs to know what ld has built programs due to some pretty > > > stupid pre-2.9.something brokeness in R_MIPS_32 reloction handling. > > > > egcs 1.0.3a binutils 2.8.1 (Very conservative) > > > > Well, another question. Ralf uploaded cross tools rpms year ago. Does > anybody have native rmps for big endian ? Also, does anybody have cross > tools for sparc glibc 2.1 (RH6.x sparc distribution) ? I can't compile > cross gcc on my Ultra, it seems like a bug in the sparc compiler, the > process fails in parsing an enum decl in a header. I tried to compile cross gcc/binutils from CVS a couple of times for Linux/Sparc (Ultra) which didnt work as somewhere in the middle the beast meant to use the native "as" instead of mipsel-linux-as Flo -- Florian Lohoff flo@rfc822.org +49-5201-669912 "Write only memory - Oops. Time for my medication again ..." From owner-linux-origin@oss.sgi.com Tue Sep 26 08:08:45 2000 Received: by oss.sgi.com id ; Tue, 26 Sep 2000 08:08:40 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:10577 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Tue, 26 Sep 2000 08:08:14 -0700 Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA18795; Tue, 26 Sep 2000 08:00:00 -0700 (PDT) mail_from (cngam@cray.com) Received: from tulip-e185.americas.sgi.com (tulip.americas.sgi.com [128.162.185.208]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.1) with ESMTP id KAA15991; Tue, 26 Sep 2000 10:05:03 -0500 (CDT) Received: from cray.com (fsgi241.americas.sgi.com [128.162.195.1]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw) with ESMTP id KAA02039; Tue, 26 Sep 2000 10:05:03 -0500 (CDT) Message-ID: <39D0BB1E.21360647@cray.com> Date: Tue, 26 Sep 2000 10:05:02 -0500 From: Colin Ngam Reply-To: cngam@americas.sgi.com Organization: SSO X-Mailer: Mozilla 4.61C-SGI [en] (X11; I; IRIX 6.5 IP22) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: John Hawkes , Kanoj Sarcar , linux-origin@oss.sgi.com, srn@sgi.com, pfg@sgi.com Subject: Re: posix0 "eth0: RX overflow" References: <00fd01c02721$353bf620$6401a8c0@marin1.sfba.home.com> <20000925225201.C6190@bacchus.dhis.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing Ralf Baechle wrote: > On Mon, Sep 25, 2000 at 11:48:33AM -0700, John Hawkes wrote: > > > FYI, I built a kernel (with Lockmeter in it) from this morning's mips64 > > sources, and after a fairly heavy AIM7-like load for 15 minutes, I saw > > multiple "eth0: RX overflow" messages and networking no longer worked. > > A known problem with the IOC3 network driver. For some reason in 99% of > cases it fails to reinitialize the driver after it receives such a RX > overflow interrupt. Ralf, I have seen this pretty often on the SNIA64 machine too and I normally see it on the way to multi-user .. Are you saying that in 99% of the time when we get RX overflow, we can reinit the driver and card? I was led to believe that we NEVER been able to recover from an RX overflow situation. The bottom line is that for SNIA64, this may be our only ethernet connection and we need to stabilize it. Are you actively engaged in this problem? Thanks. Colin > > > > Also, I can't rlogin to posix0 more than once. That is, I can rlogin > > with one window, but not with a second window. > > Maybe /etc/securetty? I normally use telnet and haven't noticed any > problems. > > We got another fairly bad problem with the kernel. It seems that it's > leaking filedescriptors. Even when I kill all processes except init and > my last shell I occasionally can't remount / read-only resulting in a > fsck on reboot. I would suspect that this happens somewhere in the binary > compatibility code. > > Oh, and I verified that the recent console changes broke /dev/console. > > Ralf From owner-linux-origin@oss.sgi.com Tue Sep 26 10:54:46 2000 Received: by oss.sgi.com id ; Tue, 26 Sep 2000 10:54:26 -0700 Received: from rotor.chem.unr.edu ([134.197.32.176]:38415 "EHLO rotor.chem.unr.edu") by oss.sgi.com with ESMTP id ; Tue, 26 Sep 2000 10:53:55 -0700 Received: (from wesolows@localhost) by rotor.chem.unr.edu (8.9.3/8.9.3) id KAA16855; Tue, 26 Sep 2000 10:48:05 -0700 Date: Tue, 26 Sep 2000 10:48:05 -0700 From: Keith M Wesolowski To: "Gleb O. Raiko" Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr, linux-origin@oss.sgi.com Subject: Re: libc upgrade Message-ID: <20000926104805.C15401@chem.unr.edu> References: <20000922152604.A2627@bacchus.dhis.org> <20000925112413.B3247@paradigm.rfc822.org> <20000925132056.A7598@bacchus.dhis.org> <20000925161500.A4773@paradigm.rfc822.org> <20000925221414.A6190@bacchus.dhis.org> <20000926010416.B3761@paradigm.rfc822.org> <39D06065.FC00C7A0@niisi.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <39D06065.FC00C7A0@niisi.msk.ru>; from raiko@niisi.msk.ru on Tue, Sep 26, 2000 at 12:37:57PM +0400 X-Complaints-To: postmaster@chem.unr.edu Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Tue, Sep 26, 2000 at 12:37:57PM +0400, Gleb O. Raiko wrote: > Well, another question. Ralf uploaded cross tools rpms year ago. Does > anybody have native rmps for big endian ? Also, does anybody have cross > tools for sparc glibc 2.1 (RH6.x sparc distribution) ? I can't compile > cross gcc on my Ultra, it seems like a bug in the sparc compiler, the > process fails in parsing an enum decl in a header. Native rpms, no. Native tarballs that "work," yes. I do have cross tools (again, not RPMs) for sparc glibc 2.1 - it's my main devel environment. I also have a script that builds an entire cross toolchain and kernel for any versions of gcc/binutils/glibc/kernel that you supply, and it's tested mainly on sparc glibc 2.1. I have not yet had any problems building such a cross toolchain, with a mainly stock RH6.2 system (make has to be upgraded to build recent glibc). Information on how I'm doing this is at http://foobazco.org/~wesolows/mips-cross.html. I recommend using the make-cross tools, however, located at ftp://oss.sgi.com/pub/linux/mips/mips-linux/simple/crossdev/. HTH. -- Keith M Wesolowski wesolows@chem.unr.edu University of Nevada http://www.chem.unr.edu Chemistry Department Systems and Network Administrator From owner-linux-origin@oss.sgi.com Tue Sep 26 14:08:17 2000 Received: by oss.sgi.com id ; Tue, 26 Sep 2000 14:08:07 -0700 Received: from u-146.karlsruhe.ipdial.viaginterkom.de ([62.180.10.146]:265 "EHLO u-146.karlsruhe.ipdial.viaginterkom.de") by oss.sgi.com with ESMTP id ; Tue, 26 Sep 2000 14:07:43 -0700 Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Tue, 26 Sep 2000 23:06:50 +0200 Date: Tue, 26 Sep 2000 23:06:50 +0200 From: Ralf Baechle To: Florian Lohoff Cc: "Gleb O. Raiko" , linux-mips@oss.sgi.com, linux-mips@fnet.fr, linux-origin@oss.sgi.com Subject: Re: libc upgrade Message-ID: <20000926230650.B10991@bacchus.dhis.org> References: <20000922152604.A2627@bacchus.dhis.org> <20000925112413.B3247@paradigm.rfc822.org> <20000925132056.A7598@bacchus.dhis.org> <20000925161500.A4773@paradigm.rfc822.org> <20000925221414.A6190@bacchus.dhis.org> <20000926010416.B3761@paradigm.rfc822.org> <39D06065.FC00C7A0@niisi.msk.ru> <20000926123600.A413@paradigm.rfc822.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000926123600.A413@paradigm.rfc822.org>; from flo@rfc822.org on Tue, Sep 26, 2000 at 12:36:00PM +0200 X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Tue, Sep 26, 2000 at 12:36:00PM +0200, Florian Lohoff wrote: > > Well, another question. Ralf uploaded cross tools rpms year ago. Does > > anybody have native rmps for big endian ? Also, does anybody have cross > > tools for sparc glibc 2.1 (RH6.x sparc distribution) ? I can't compile > > cross gcc on my Ultra, it seems like a bug in the sparc compiler, the > > process fails in parsing an enum decl in a header. > > I tried to compile cross gcc/binutils from CVS a couple of times > for Linux/Sparc (Ultra) which didnt work as somewhere in the > middle the beast meant to use the native "as" instead of > mipsel-linux-as gcc tries to run as on /lib/gcc-lib///as, then //bin/as, then the native as from $PATH. So check if you were using the same target configuration name (mips-linux and mips-unknown-linux-gnu are different!) for both gcc and binutils. Ralf From owner-linux-origin@oss.sgi.com Tue Sep 26 15:48:47 2000 Received: by oss.sgi.com id ; Tue, 26 Sep 2000 15:48:37 -0700 Received: from u-146.karlsruhe.ipdial.viaginterkom.de ([62.180.10.146]:16137 "EHLO u-146.karlsruhe.ipdial.viaginterkom.de") by oss.sgi.com with ESMTP id ; Tue, 26 Sep 2000 15:48:08 -0700 Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Wed, 27 Sep 2000 00:47:23 +0200 Date: Wed, 27 Sep 2000 00:47:22 +0200 From: Ralf Baechle To: "Gleb O. Raiko" Cc: Florian Lohoff , linux-mips@oss.sgi.com, linux-mips@fnet.fr, linux-origin@oss.sgi.com Subject: Re: libc upgrade Message-ID: <20000927004722.B8644@bacchus.dhis.org> References: <20000922152604.A2627@bacchus.dhis.org> <20000925112413.B3247@paradigm.rfc822.org> <20000925132056.A7598@bacchus.dhis.org> <20000925161500.A4773@paradigm.rfc822.org> <20000925221414.A6190@bacchus.dhis.org> <39D05E8B.A7F4A2D9@niisi.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <39D05E8B.A7F4A2D9@niisi.msk.ru>; from raiko@niisi.msk.ru on Tue, Sep 26, 2000 at 12:30:03PM +0400 X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Tue, Sep 26, 2000 at 12:30:03PM +0400, Gleb O. Raiko wrote: > BTW, what should we use as system headers with glibc nowadays ? Should > it be old HardHat kernel-headers-2.1.100 or newer 2.2.x ? Definately not the old hardhat kernel headers. I'm using 2.2 header and recommend doing the same for best success with packages for current distributions based on this kernel. Building some packages may actually require a newer version but in general the lastest 2.2 headers are the best. > > I week of CPU time on an Origin building packages: No problems ... I'm > > actually fairly close to get a RH 6.2 built - as far as that is possible > > with glibc 2.0. > > Do you have the packages somewhere on the net ? I am personally > interested in disk packages (fdisk, msdostools &co.) and the packages > required in order to run 2.2 kernels. Old HardHat cfdisk, for example, > seems to create partitions in the big endian format. At least, the rest > see garbage after cfdisk creates a partition table. I've got a hacked utils-linux package, I think it's in the redhat-6.0 packages that are on oss. I don't really intend to upload all the stuff to oss, they're just a big test for the changed compile environment which I'm using, that is binutils-current and gcc-current. Before I even fiddle with stuff like glibc 2.2 etc. I want to know that the tools are reasonably solid. So far they seem to be good after applying a few minor but essential patches. Still need to test building a kernel. Ralf From owner-linux-origin@oss.sgi.com Wed Sep 27 16:39:24 2000 Received: by oss.sgi.com id ; Wed, 27 Sep 2000 16:39:15 -0700 Received: from u-141.karlsruhe.ipdial.viaginterkom.de ([62.180.18.141]:62980 "EHLO u-141.karlsruhe.ipdial.viaginterkom.de") by oss.sgi.com with ESMTP id ; Wed, 27 Sep 2000 16:38:56 -0700 Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Wed, 27 Sep 2000 12:35:06 +0200 Date: Wed, 27 Sep 2000 12:35:06 +0200 From: Ralf Baechle To: linux-origin@oss.sgi.com Subject: IRIX ELF specialist ... Message-ID: <20000927123506.B28950@bacchus.dhis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing I have some question about IRIXism in IRIX 5 / 6 ELF files, can anybody point me to a specialist? Thanks, Ralf From owner-linux-origin@oss.sgi.com Thu Sep 28 16:30:48 2000 Received: by oss.sgi.com id ; Thu, 28 Sep 2000 16:30:39 -0700 Received: from u-123.karlsruhe.ipdial.viaginterkom.de ([62.180.19.123]:4358 "EHLO u-123.karlsruhe.ipdial.viaginterkom.de") by oss.sgi.com with ESMTP id ; Thu, 28 Sep 2000 16:30:27 -0700 Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Fri, 29 Sep 2000 00:13:31 +0200 Date: Fri, 29 Sep 2000 00:13:31 +0200 From: Ralf Baechle To: Colin Ngam Cc: John Hawkes , Kanoj Sarcar , linux-origin@oss.sgi.com, srn@sgi.com, pfg@sgi.com Subject: Re: posix0 "eth0: RX overflow" Message-ID: <20000929001331.A7004@bacchus.dhis.org> References: <00fd01c02721$353bf620$6401a8c0@marin1.sfba.home.com> <20000925225201.C6190@bacchus.dhis.org> <39D0BB1E.21360647@cray.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="n8g4imXOkfNTN/H1" X-Mailer: Mutt 1.0.1i In-Reply-To: <39D0BB1E.21360647@cray.com>; from cngam@americas.sgi.com on Tue, Sep 26, 2000 at 10:05:02AM -0500 X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii On Tue, Sep 26, 2000 at 10:05:02AM -0500, Colin Ngam wrote: > I have seen this pretty often on the SNIA64 machine too and I normally see > it on the way to multi-user .. > > Are you saying that in 99% of the time when we get RX overflow, we can > reinit the driver and card? I was led to believe that we NEVER been able to > recover > from an RX overflow situation. > > The bottom line is that for SNIA64, this may be our only ethernet connection > and > we need to stabilize it. Are you actively engaged in this problem? Attached is my current version of the IOC3 driver. It has just survived some hours of extremly heavy network traffic. Yet there are some loose ends, I've seen crashes which went away without me actually having fixed them ... Please try this one on SN0/SN1 also and tell me your experiences. Ralf --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ioc3-eth.c" /* * 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. * * Driver for SGI's IOC3 based Ethernet cards as found in the PCI card. * * Copyright (C) 1999, 2000 Ralf Baechle * Copyright (C) 1995, 1999, 2000 by Silicon Graphics, Inc. * * Reporting bugs: * * If you find problems with this drivers, then if possible do the * following. Hook up a terminal to the MSC port, send an NMI to the CPUs * by typing ^Tnmi (where ^T stands for -T). You'll see something * like: * 1A 000: * 1A 000: *** NMI while in Kernel and no NMI vector installed on node 0 * 1A 000: *** Error EPC: 0xffffffff800265e4 (0xffffffff800265e4) * 1A 000: *** Press ENTER to continue. * * Next enter the command ``lw i:0x86000f0 0x18'' and include this * commands output which will look like below with your bugreport. * * 1A 000: POD MSC Dex> lw i:0x86000f0 0x18 * 1A 000: 92000000086000f0: 0021f28c 00000000 00000000 00000000 * 1A 000: 9200000008600100: a5000000 01cde000 00000000 000004e0 * 1A 000: 9200000008600110: 00000650 00000000 00110b15 00000000 * 1A 000: 9200000008600120: 006d0005 77bbca0a a5000000 01ce0000 * 1A 000: 9200000008600130: 80000500 00000500 00002538 05690008 * 1A 000: 9200000008600140: 00000000 00000000 000003e1 0000786d * * To do: * * - Handle allocation failures in ioc3_alloc_skb() more gracefully. * - Handle allocation failures in ioc3_init_rings(). * - Use prefetching for large packets. What is a good lower limit for * prefetching? * - We're probably allocating a bit too much memory. * - Workarounds for various PHYs. * - Proper autonegotiation. * - What exactly is net_device_stats.tx_dropped supposed to count? * - Use hardware checksums. * - Convert to using the PCI infrastructure / IOC3 meta driver. */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include /* 32 RX buffers. This is tunable in the range of 16 <= x < 512. */ #define RX_BUFFS 64 /* Private ioctls that de facto are well known and used for examply by mii-tool. */ #define SIOCGMIIPHY (SIOCDEVPRIVATE) /* Read from current PHY */ #define SIOCGMIIREG (SIOCDEVPRIVATE+1) /* Read any PHY register */ #define SIOCSMIIREG (SIOCDEVPRIVATE+2) /* Write any PHY register */ /* These exist in other drivers; we don't use them at this time. */ #define SIOCGPARAMS (SIOCDEVPRIVATE+3) /* Read operational parameters */ #define SIOCSPARAMS (SIOCDEVPRIVATE+4) /* Set operational parameters */ /* Private per NIC data of the driver. */ struct ioc3_private { struct ioc3 *regs; int phy; unsigned long *rxr; /* pointer to receiver ring */ struct ioc3_etxd *txr; struct sk_buff *rx_skbs[512]; struct sk_buff *tx_skbs[128]; struct net_device_stats stats; int rx_ci; /* RX consumer index */ int rx_pi; /* RX producer index */ int tx_ci; /* TX consumer index */ int tx_pi; /* TX producer index */ int txqlen; u32 emcr, ehar_h, ehar_l; struct timer_list negtimer; spinlock_t ioc3_lock; }; static int ioc3_ioctl(struct net_device *dev, struct ifreq *rq, int cmd); static void ioc3_set_multicast_list(struct net_device *dev); static int ioc3_start_xmit(struct sk_buff *skb, struct net_device *dev); static void ioc3_timeout(struct net_device *dev); static inline unsigned int ioc3_hash(const unsigned char *addr); static inline void ioc3_stop(struct net_device *dev); static void ioc3_init(struct net_device *dev); static const char ioc3_str[] = "IOC3 Ethernet"; /* We use this to acquire receive skb's that we can DMA directly into. */ #define ALIGNED_RX_SKB_ADDR(addr) \ ((((unsigned long)(addr) + (128 - 1)) & ~(128 - 1)) - (unsigned long)(addr)) #define ioc3_alloc_skb(__length, __gfp_flags) \ ({ struct sk_buff *__skb; \ __skb = alloc_skb((__length) + 128, (__gfp_flags)); \ if (__skb) { \ int __offset = ALIGNED_RX_SKB_ADDR(__skb->data); \ if(__offset) \ skb_reserve(__skb, __offset); \ } \ __skb; \ }) /* BEWARE: The IOC3 documentation documents the size of rx buffers as 1644 while it's actually 1664. This one was nasty to track down ... */ #define RX_OFFSET 10 #define RX_BUF_ALLOC_SIZE (1664 + RX_OFFSET + 128) /* DMA barrier to separate cached and uncached accesses. */ #define BARRIER() \ __asm__("sync" ::: "memory") #define IOC3_SIZE 0x100000 #define ioc3_r(reg) \ ({ \ u32 __res; \ __res = ioc3->reg; \ __res; \ }) #define ioc3_w(reg,val) \ do { \ (ioc3->reg = (val)); \ } while(0) static inline u32 mcr_pack(u32 pulse, u32 sample) { return (pulse << 10) | (sample << 2); } static int nic_wait(struct ioc3 *ioc3) { u32 mcr; do { mcr = ioc3_r(mcr); } while (!(mcr & 2)); return mcr & 1; } static int nic_reset(struct ioc3 *ioc3) { int presence; ioc3_w(mcr, mcr_pack(500, 65)); presence = nic_wait(ioc3); ioc3_w(mcr, mcr_pack(0, 500)); nic_wait(ioc3); return presence; } static inline int nic_read_bit(struct ioc3 *ioc3) { int result; ioc3_w(mcr, mcr_pack(6, 13)); result = nic_wait(ioc3); ioc3_w(mcr, mcr_pack(0, 100)); nic_wait(ioc3); return result; } static inline void nic_write_bit(struct ioc3 *ioc3, int bit) { if (bit) ioc3_w(mcr, mcr_pack(6, 110)); else ioc3_w(mcr, mcr_pack(80, 30)); nic_wait(ioc3); } /* * Read a byte from an iButton device */ static u32 nic_read_byte(struct ioc3 *ioc3) { u32 result = 0; int i; for (i = 0; i < 8; i++) result = (result >> 1) | (nic_read_bit(ioc3) << 7); return result; } /* * Write a byte to an iButton device */ static void nic_write_byte(struct ioc3 *ioc3, int byte) { int i, bit; for (i = 8; i; i--) { bit = byte & 1; byte >>= 1; nic_write_bit(ioc3, bit); } } static u64 nic_find(struct ioc3 *ioc3, int *last) { int a, b, index, disc; u64 address = 0; nic_reset(ioc3); /* Search ROM. */ nic_write_byte(ioc3, 0xf0); /* Algorithm from ``Book of iButton Standards''. */ for (index = 0, disc = 0; index < 64; index++) { a = nic_read_bit(ioc3); b = nic_read_bit(ioc3); if (a && b) { printk("NIC search failed (not fatal).\n"); *last = 0; return 0; } if (!a && !b) { if (index == *last) { address |= 1UL << index; } else if (index > *last) { address &= ~(1UL << index); disc = index; } else if ((address & (1UL << index)) == 0) disc = index; nic_write_bit(ioc3, address & (1UL << index)); continue; } else { if (a) address |= 1UL << index; else address &= ~(1UL << index); nic_write_bit(ioc3, a); continue; } } *last = disc; return address; } static int nic_init(struct ioc3 *ioc3) { const char *type; u8 crc; u8 serial[6]; int save = 0, i; type = "unknown"; while (1) { u64 reg; reg = nic_find(ioc3, &save); switch (reg & 0xff) { case 0x91: type = "DS1981U"; break; default: if (save == 0) { /* Let the caller try again. */ return -1; } continue; } nic_reset(ioc3); /* Match ROM. */ nic_write_byte(ioc3, 0x55); for (i = 0; i < 8; i++) nic_write_byte(ioc3, (reg >> (i << 3)) & 0xff); reg >>= 8; /* Shift out type. */ for (i = 0; i < 6; i++) { serial[i] = reg & 0xff; reg >>= 8; } crc = reg & 0xff; break; } printk("Found %s NIC", type); if (type != "unknown") { printk (" registration number %02x:%02x:%02x:%02x:%02x:%02x," " CRC %02x", serial[0], serial[1], serial[2], serial[3], serial[4], serial[5], crc); } printk(".\n"); return 0; } /* * Read the NIC (Number-In-a-Can) device. */ static void ioc3_get_eaddr(struct net_device *dev, struct ioc3 *ioc3) { u8 nic[14]; int i; int tries = 2; /* There may be some problem with the battery? */ ioc3_w(gpcr_s, (1 << 21)); while (tries--) { if (!nic_init(ioc3)) break; udelay(500); } if (tries < 0) { printk("Failed to read MAC address\n"); return; } /* Read Memory. */ nic_write_byte(ioc3, 0xf0); nic_write_byte(ioc3, 0x00); nic_write_byte(ioc3, 0x00); for (i = 13; i >= 0; i--) nic[i] = nic_read_byte(ioc3); printk("Ethernet address is "); for (i = 2; i < 8; i++) { dev->dev_addr[i - 2] = nic[i]; printk("%02x", nic[i]); if (i < 7) printk(":"); } printk(".\n"); } /* Caller must hold the ioc3_lock ever for MII readers. This is also used to protect the transmitter side but it's low contention. */ static u16 mii_read(struct ioc3 *ioc3, int phy, int reg) { while (ioc3->micr & MICR_BUSY); ioc3->micr = (phy << MICR_PHYADDR_SHIFT) | reg | MICR_READTRIG; while (ioc3->micr & MICR_BUSY); return ioc3->midr & MIDR_DATA_MASK; } static void mii_write(struct ioc3 *ioc3, int phy, int reg, u16 data) { while (ioc3->micr & MICR_BUSY); ioc3->midr = data; ioc3->micr = (phy << MICR_PHYADDR_SHIFT) | reg; while (ioc3->micr & MICR_BUSY); } static int ioc3_mii_init(struct net_device *dev, struct ioc3_private *ip, struct ioc3 *ioc3); static struct net_device_stats *ioc3_get_stats(struct net_device *dev) { struct ioc3_private *ip = (struct ioc3_private *) dev->priv; struct ioc3 *ioc3 = ip->regs; ip->stats.collisions += (ioc3->etcdc & ETCDC_COLLCNT_MASK); return &ip->stats; } static inline void ioc3_rx(struct net_device *dev, struct ioc3_private *ip, struct ioc3 *ioc3) { struct sk_buff *skb, *new_skb; int rx_entry, n_entry, len; struct ioc3_erxbuf *rxb; unsigned long *rxr; u32 w0, err; rxr = (unsigned long *) ip->rxr; /* Ring base */ rx_entry = ip->rx_ci; /* RX consume index */ n_entry = ip->rx_pi; skb = ip->rx_skbs[rx_entry]; rxb = (struct ioc3_erxbuf *) (skb->data - RX_OFFSET); w0 = rxb->w0; while (w0 & ERXBUF_V) { err = rxb->err; /* It's valid ... */ if (err & ERXBUF_GOODPKT) { len = (w0 >> ERXBUF_BYTECNT_SHIFT) & 0x7ff; skb_trim(skb, len); skb->protocol = eth_type_trans(skb, dev); netif_rx(skb); ip->rx_skbs[rx_entry] = NULL; /* Poison */ new_skb = ioc3_alloc_skb(RX_BUF_ALLOC_SIZE, GFP_ATOMIC); if (!new_skb) { /* Ouch, drop packet and just recycle packet to keep the ring filled. */ ip->stats.rx_dropped++; new_skb = skb; goto next; } new_skb->dev = dev; /* Because we reserve afterwards. */ skb_put(new_skb, (1664 + RX_OFFSET)); rxb = (struct ioc3_erxbuf *) new_skb->data; skb_reserve(new_skb, RX_OFFSET); ip->stats.rx_packets++; /* Statistics */ ip->stats.rx_bytes += len; } else { /* The frame is invalid and the skb never reached the network layer so we can just recycle it. */ new_skb = skb; ip->stats.rx_errors++; } if (err & ERXBUF_CRCERR) /* Statistics */ ip->stats.rx_crc_errors++; if (err & ERXBUF_FRAMERR) ip->stats.rx_frame_errors++; next: ip->rx_skbs[n_entry] = new_skb; rxr[n_entry] = (0xa5UL << 56) | ((unsigned long) rxb & TO_PHYS_MASK); rxb->w0 = 0; /* Clear valid flag */ n_entry = (n_entry + 1) & 511; /* Update erpir */ /* Now go on to the next ring entry. */ rx_entry = (rx_entry + 1) & 511; skb = ip->rx_skbs[rx_entry]; rxb = (struct ioc3_erxbuf *) (skb->data - RX_OFFSET); w0 = rxb->w0; } ioc3->erpir = (n_entry << 3) | ERPIR_ARM; ip->rx_pi = n_entry; ip->rx_ci = rx_entry; } static inline void ioc3_tx(struct net_device *dev, struct ioc3_private *ip, struct ioc3 *ioc3) { unsigned long packets, bytes; int tx_entry, o_entry; struct sk_buff *skb; u32 etcir; spin_lock(&ip->ioc3_lock); etcir = ioc3->etcir; tx_entry = (etcir >> 7) & 127; o_entry = ip->tx_ci; packets = 0; bytes = 0; while (o_entry != tx_entry) { packets++; skb = ip->tx_skbs[o_entry]; bytes += skb->len; dev_kfree_skb_irq(skb); ip->tx_skbs[o_entry] = NULL; o_entry = (o_entry + 1) & 127; /* Next */ etcir = ioc3->etcir; /* More pkts sent? */ tx_entry = (etcir >> 7) & 127; } ip->stats.tx_packets += packets; ip->stats.tx_bytes += bytes; ip->txqlen -= packets; if (ip->txqlen < 128) netif_wake_queue(dev); ip->tx_ci = o_entry; spin_unlock(&ip->ioc3_lock); } /* * Deal with fatal IOC3 errors. This condition might be caused by a hard or * software problems, so we should try to recover * more gracefully if this ever happens. In theory we might be flooded * with such error interrupts if something really goes wrong, so we might * also consider to take the interface down. */ static void ioc3_error(struct net_device *dev, struct ioc3_private *ip, struct ioc3 *ioc3, u32 eisr) { if (eisr & EISR_RXOFLO) { printk(KERN_ERR "%s: RX overflow.\n", dev->name); } if (eisr & EISR_RXBUFOFLO) { printk(KERN_ERR "%s: RX buffer overflow.\n", dev->name); } if (eisr & EISR_RXMEMERR) { printk(KERN_ERR "%s: RX PCI error.\n", dev->name); } if (eisr & EISR_RXPARERR) { printk(KERN_ERR "%s: RX SSRAM parity error.\n", dev->name); } if (eisr & EISR_TXBUFUFLO) { printk(KERN_ERR "%s: TX buffer underflow.\n", dev->name); } if (eisr & EISR_TXMEMERR) { printk(KERN_ERR "%s: TX PCI error.\n", dev->name); } ioc3_stop(dev); ioc3_init(dev); ioc3_mii_init(dev, ip, ioc3); dev->trans_start = jiffies; netif_wake_queue(dev); } /* The interrupt handler does all of the Rx thread work and cleans up after the Tx thread. */ static void ioc3_interrupt(int irq, void *_dev, struct pt_regs *regs) { struct net_device *dev = (struct net_device *)_dev; struct ioc3_private *ip = dev->priv; struct ioc3 *ioc3 = ip->regs; const u32 enabled = EISR_RXTIMERINT | EISR_RXOFLO | EISR_RXBUFOFLO | EISR_RXMEMERR | EISR_RXPARERR | EISR_TXBUFUFLO | EISR_TXEXPLICIT | EISR_TXMEMERR; u32 eisr; eisr = ioc3->eisr & enabled; while (eisr) { ioc3->eisr = eisr; ioc3->eisr; /* Flush */ if (eisr & (EISR_RXOFLO | EISR_RXBUFOFLO | EISR_RXMEMERR | EISR_RXPARERR | EISR_TXBUFUFLO | EISR_TXMEMERR)) ioc3_error(dev, ip, ioc3, eisr); if (eisr & EISR_RXTIMERINT) ioc3_rx(dev, ip, ioc3); if (eisr & EISR_TXEXPLICIT) ioc3_tx(dev, ip, ioc3); eisr = ioc3->eisr & enabled; } } static void negotiate(unsigned long data) { struct net_device *dev = (struct net_device *) data; struct ioc3_private *ip = (struct ioc3_private *) dev->priv; struct ioc3 *ioc3 = ip->regs; mod_timer(&ip->negtimer, jiffies + 20 * HZ); } static int ioc3_mii_init(struct net_device *dev, struct ioc3_private *ip, struct ioc3 *ioc3) { u16 word, mii0; int i, phy; spin_lock_irq(&ip->ioc3_lock); phy = -1; for (i = 0; i < 32; i++) { word = mii_read(ioc3, i, 2); if ((word != 0xffff) & (word != 0x0000)) { phy = i; break; /* Found a PHY */ } } if (phy == -1) { spin_unlock_irq(&ip->ioc3_lock); return -ENODEV; } ip->phy = phy; /* Autonegotiate 100mbit and fullduplex. */ mii0 = mii_read(ioc3, ip->phy, 0); mii_write(ioc3, ip->phy, 0, mii0 | 0x3100); ip->negtimer.function = &negotiate; ip->negtimer.data = (unsigned long) dev; mod_timer(&ip->negtimer, jiffies); /* Run it now */ spin_unlock_irq(&ip->ioc3_lock); return 0; } static inline void ioc3_clean_rx_ring(struct ioc3_private *ip) { struct sk_buff *skb; int i; for (i = ip->rx_ci; i & 15; i++) { ip->rx_skbs[ip->rx_pi] = ip->rx_skbs[ip->rx_ci]; ip->rxr[ip->rx_pi++] = ip->rxr[ip->rx_ci++]; } ip->rx_pi &= 511; ip->rx_ci &= 511; for (i = ip->rx_ci; i != ip->rx_pi; i = (i+1) & 511) { struct ioc3_erxbuf *rxb; skb = ip->rx_skbs[i]; rxb = (struct ioc3_erxbuf *) (skb->data - RX_OFFSET); rxb->w0 = 0; } } static inline void ioc3_clean_tx_ring(struct ioc3_private *ip) { struct sk_buff *skb; int i; for (i=0; i < 128; i++) { skb = ip->tx_skbs[i]; if (skb) { ip->tx_skbs[i] = NULL; dev_kfree_skb_any(skb); } ip->txr[i].cmd = 0; } ip->tx_pi = 0; ip->tx_ci = 0; } static void ioc3_free_rings(struct ioc3_private *ip) { struct sk_buff *skb; int rx_entry, n_entry; if (ip->txr) { ioc3_clean_tx_ring(ip); free_pages((unsigned long)ip->txr, 2); ip->txr = NULL; } if (ip->rxr) { n_entry = ip->rx_ci; rx_entry = ip->rx_pi; while (n_entry != rx_entry) { skb = ip->rx_skbs[n_entry]; if (skb) dev_kfree_skb_any(skb); n_entry = (n_entry + 1) & 511; } free_page((unsigned long)ip->rxr); ip->rxr = NULL; } } static void ioc3_alloc_rings(struct net_device *dev, struct ioc3_private *ip, struct ioc3 *ioc3) { struct ioc3_erxbuf *rxb; unsigned long *rxr; int i; if (ip->rxr == NULL) { /* Allocate and initialize rx ring. 4kb = 512 entries */ ip->rxr = (unsigned long *) get_free_page(GFP_KERNEL|GFP_ATOMIC); rxr = (unsigned long *) ip->rxr; /* Now the rx buffers. The RX ring may be larger but we only allocate 16 buffers for now. Need to tune this for performance and memory later. */ for (i = 0; i < RX_BUFFS; i++) { struct sk_buff *skb; skb = ioc3_alloc_skb(RX_BUF_ALLOC_SIZE, GFP_ATOMIC); if (!skb) { show_free_areas(); continue; } ip->rx_skbs[i] = skb; skb->dev = dev; /* Because we reserve afterwards. */ skb_put(skb, (1664 + RX_OFFSET)); rxb = (struct ioc3_erxbuf *) skb->data; rxr[i] = (0xa5UL << 56) | ((unsigned long) rxb & TO_PHYS_MASK); skb_reserve(skb, RX_OFFSET); } ip->rx_ci = 0; ip->rx_pi = RX_BUFFS; } if (ip->txr == NULL) { /* Allocate and initialize tx rings. 16kb = 128 bufs. */ ip->txr = (struct ioc3_etxd *)__get_free_pages(GFP_KERNEL|GFP_ATOMIC, 2); ip->tx_pi = 0; ip->tx_ci = 0; } } static void ioc3_init_rings(struct net_device *dev, struct ioc3_private *ip, struct ioc3 *ioc3) { unsigned long ring; ioc3_free_rings(ip); ioc3_alloc_rings(dev, ip, ioc3); ioc3_clean_rx_ring(ip); ioc3_clean_tx_ring(ip); /* Now the rx ring base, consume & produce registers. */ ring = (0xa5UL << 56) | ((unsigned long)ip->rxr & TO_PHYS_MASK); ioc3->erbr_h = ring >> 32; ioc3->erbr_l = ring & 0xffffffff; ioc3->ercir = (ip->rx_ci << 3); ioc3->erpir = (ip->rx_pi << 3) | ERPIR_ARM; ring = (0xa5UL << 56) | ((unsigned long)ip->txr & TO_PHYS_MASK); ip->txqlen = 0; /* nothing queued */ /* Now the tx ring base, consume & produce registers. */ ioc3->etbr_h = ring >> 32; ioc3->etbr_l = ring & 0xffffffff; ioc3->etpir = (ip->tx_pi << 7); ioc3->etcir = (ip->tx_ci << 7); ioc3->etcir; /* Flush */ } static inline void ioc3_ssram_disc(struct ioc3_private *ip) { struct ioc3 *ioc3 = ip->regs; volatile u32 *ssram0 = &ioc3->ssram[0x0000]; volatile u32 *ssram1 = &ioc3->ssram[0x4000]; unsigned int pattern = 0x5555; /* Assume the larger size SSRAM and enable parity checking */ ioc3->emcr |= (EMCR_BUFSIZ | EMCR_RAMPAR); *ssram0 = pattern; *ssram1 = ~pattern & IOC3_SSRAM_DM; if ((*ssram0 & IOC3_SSRAM_DM) != pattern || (*ssram1 & IOC3_SSRAM_DM) != (~pattern & IOC3_SSRAM_DM)) { /* set ssram size to 64 KB */ ip->emcr = EMCR_RAMPAR; ioc3->emcr &= ~EMCR_BUFSIZ; } else { ip->emcr = EMCR_BUFSIZ | EMCR_RAMPAR; } } static void ioc3_init(struct net_device *dev) { struct ioc3_private *ip = dev->priv; struct ioc3 *ioc3 = ip->regs; ioc3->emcr = EMCR_RST; /* Reset */ ioc3->emcr; /* flush WB */ udelay(4); /* Give it time ... */ ioc3->emcr = 0; ioc3->emcr; /* Misc registers */ ioc3->erbar = 0; ioc3->etcsr = (17<etcdc; /* Clear on read */ ioc3->ercsr = 15; /* RX low watermark */ ioc3->ertr = 0; /* Interrupt immediately */ ioc3->emar_h = (dev->dev_addr[5] << 8) | dev->dev_addr[4]; ioc3->emar_l = (dev->dev_addr[3] << 24) | (dev->dev_addr[2] << 16) | (dev->dev_addr[1] << 8) | dev->dev_addr[0]; ioc3->ehar_h = ip->ehar_h; ioc3->ehar_l = ip->ehar_l; ioc3->ersr = 42; /* XXX should be random */ ioc3_init_rings(dev, ip, ioc3); ip->emcr |= ((RX_OFFSET / 2) << EMCR_RXOFF_SHIFT) | EMCR_TXDMAEN | EMCR_TXEN | EMCR_RXDMAEN | EMCR_RXEN; ioc3->emcr = ip->emcr; ioc3->eier = EISR_RXTIMERINT | EISR_RXOFLO | EISR_RXBUFOFLO | EISR_RXMEMERR | EISR_RXPARERR | EISR_TXBUFUFLO | EISR_TXEXPLICIT | EISR_TXMEMERR; ioc3->eier; } static inline void ioc3_stop(struct net_device *dev) { struct ioc3_private *ip = dev->priv; struct ioc3 *ioc3 = ip->regs; ioc3->emcr = 0; /* Shutup */ ioc3->eier = 0; /* Disable interrupts */ ioc3->eier; /* Flush */ } static int ioc3_open(struct net_device *dev) { struct ioc3_private *ip; if (request_irq(dev->irq, ioc3_interrupt, 0, ioc3_str, dev)) { printk(KERN_ERR "%s: Can't get irq %d\n", dev->name, dev->irq); return -EAGAIN; } ip = (struct ioc3_private *) dev->priv; ip->ehar_h = 0; ip->ehar_l = 0; ioc3_init(dev); netif_start_queue(dev); MOD_INC_USE_COUNT; return 0; } static int ioc3_close(struct net_device *dev) { struct ioc3_private *ip = dev->priv; del_timer(&ip->negtimer); netif_stop_queue(dev); ioc3_stop(dev); /* Flush */ free_irq(dev->irq, dev); ioc3_free_rings(ip); MOD_DEC_USE_COUNT; return 0; } static int ioc3_pci_init(struct pci_dev *pdev) { u16 mii0, mii_status, mii2, mii3, mii4; struct net_device *dev = NULL; // XXX struct ioc3_private *ip; struct ioc3 *ioc3; unsigned long ioc3_base, ioc3_size; u32 vendor, model, rev; int phy; dev = init_etherdev(0, sizeof(struct ioc3_private)); if (!dev) return -ENOMEM; ip = dev->priv; memset(ip, 0, sizeof(*ip)); /* * This probably needs to be register_netdevice, or call * init_etherdev so that it calls register_netdevice. Quick * hack for now. */ netif_device_attach(dev); dev->irq = pdev->irq; ioc3_base = pdev->resource[0].start; ioc3_size = pdev->resource[0].end - ioc3_base; ioc3 = (struct ioc3 *) ioremap(ioc3_base, ioc3_size); ip->regs = ioc3; spin_lock_init(&ip->ioc3_lock); ioc3_stop(dev); ip->emcr = 0; ioc3_init(dev); init_timer(&ip->negtimer); ioc3_mii_init(dev, ip, ioc3); phy = ip->phy; if (phy == -1) { printk(KERN_CRIT"%s: Didn't find a PHY, goodbye.\n", dev->name); ioc3_stop(dev); free_irq(dev->irq, dev); ioc3_free_rings(ip); return -ENODEV; } mii0 = mii_read(ioc3, phy, 0); mii_status = mii_read(ioc3, phy, 1); mii2 = mii_read(ioc3, phy, 2); mii3 = mii_read(ioc3, phy, 3); mii4 = mii_read(ioc3, phy, 4); vendor = (mii2 << 12) | (mii3 >> 4); model = (mii3 >> 4) & 0x3f; rev = mii3 & 0xf; printk(KERN_INFO"Using PHY %d, vendor 0x%x, model %d, rev %d.\n", phy, vendor, model, rev); printk(KERN_INFO "%s: MII transceiver found at MDIO address " "%d, config %4.4x status %4.4x.\n", dev->name, phy, mii0, mii_status); ioc3_ssram_disc(ip); printk("IOC3 SSRAM has %d kbyte.\n", ip->emcr & EMCR_BUFSIZ ? 128 : 64); ioc3_get_eaddr(dev, ioc3); /* The IOC3-specific entries in the device structure. */ dev->open = ioc3_open; dev->hard_start_xmit = ioc3_start_xmit; dev->tx_timeout = ioc3_timeout; dev->watchdog_timeo = 5 * HZ; dev->stop = ioc3_close; dev->get_stats = ioc3_get_stats; dev->do_ioctl = ioc3_ioctl; dev->set_multicast_list = ioc3_set_multicast_list; return 0; } static int __init ioc3_probe(void) { static int called = 0; int cards = 0; if (called) return -ENODEV; called = 1; if (pci_present()) { struct pci_dev *pdev = NULL; while ((pdev = pci_find_device(PCI_VENDOR_ID_SGI, PCI_DEVICE_ID_SGI_IOC3, pdev))) { if (ioc3_pci_init(pdev)) return -ENOMEM; cards++; } } return cards ? -ENODEV : 0; } static void __exit ioc3_cleanup_module(void) { /* Later, when we really support modules. */ } static int ioc3_start_xmit(struct sk_buff *skb, struct net_device *dev) { unsigned long data; struct ioc3_private *ip = dev->priv; struct ioc3 *ioc3 = ip->regs; unsigned int len; struct ioc3_etxd *desc; int produce; spin_lock_irq(&ip->ioc3_lock); data = (unsigned long) skb->data; len = skb->len; produce = ip->tx_pi; desc = &ip->txr[produce]; if (len <= 104) { /* Short packet, let's copy it directly into the ring. */ memcpy(desc->data, skb->data, skb->len); if (len < ETH_ZLEN) { /* Very short packet, pad with zeros at the end. */ memset(desc->data + len, 0, ETH_ZLEN - len); len = ETH_ZLEN; } desc->cmd = len | ETXD_INTWHENDONE | ETXD_D0V; desc->bufcnt = len; } else if ((data ^ (data + len)) & 0x4000) { unsigned long b2, s1, s2; b2 = (data | 0x3fffUL) + 1UL; s1 = b2 - data; s2 = data + len - b2; desc->cmd = len | ETXD_INTWHENDONE | ETXD_B1V | ETXD_B2V; desc->bufcnt = (s1 << ETXD_B1CNT_SHIFT) | (s2 << ETXD_B2CNT_SHIFT); desc->p1 = (0xa5UL << 56) | (data & TO_PHYS_MASK); desc->p2 = (0xa5UL << 56) | (data & TO_PHYS_MASK); } else { /* Normal sized packet that doesn't cross a page boundary. */ desc->cmd = len | ETXD_INTWHENDONE | ETXD_B1V; desc->bufcnt = len << ETXD_B1CNT_SHIFT; desc->p1 = (0xa5UL << 56) | (data & TO_PHYS_MASK); } BARRIER(); dev->trans_start = jiffies; ip->tx_skbs[produce] = skb; /* Remember skb */ produce = (produce + 1) & 127; ip->tx_pi = produce; ioc3->etpir = produce << 7; /* Fire ... */ ip->txqlen++; if (ip->txqlen > 127) netif_stop_queue(dev); spin_unlock_irq(&ip->ioc3_lock); return 0; } static void ioc3_timeout(struct net_device *dev) { struct ioc3_private *ip = dev->priv; struct ioc3 *ioc3 = ip->regs; printk(KERN_ERR "%s: transmit timed out, resetting\n", dev->name); ioc3_stop(dev); ioc3_init(dev); ioc3_mii_init(dev, ip, ioc3); dev->trans_start = jiffies; netif_wake_queue(dev); } /* * Given a multicast ethernet address, this routine calculates the * address's bit index in the logical address filter mask */ #define CRC_MASK 0xEDB88320 static inline unsigned int ioc3_hash(const unsigned char *addr) { unsigned int temp = 0; unsigned char byte; unsigned int crc; int bits, len; len = ETH_ALEN; for (crc = ~0; --len >= 0; addr++) { byte = *addr; for (bits = 8; --bits >= 0; ) { if ((byte ^ crc) & 1) crc = (crc >> 1) ^ CRC_MASK; else crc >>= 1; byte >>= 1; } } crc &= 0x3f; /* bit reverse lowest 6 bits for hash index */ for (bits = 6; --bits >= 0; ) { temp <<= 1; temp |= (crc & 0x1); crc >>= 1; } return temp; } /* Provide ioctl() calls to examine the MII xcvr state. */ static int ioc3_ioctl(struct net_device *dev, struct ifreq *rq, int cmd) { struct ioc3_private *ip = (struct ioc3_private *) dev->priv; u16 *data = (u16 *)&rq->ifr_data; struct ioc3 *ioc3 = ip->regs; int phy = ip->phy; switch (cmd) { case SIOCGMIIPHY: /* Get the address of the PHY in use. */ if (phy == -1) return -ENODEV; data[0] = phy; return 0; case SIOCGMIIREG: /* Read any PHY register. */ spin_lock_irq(&ip->ioc3_lock); data[3] = mii_read(ioc3, data[0], data[1]); spin_unlock_irq(&ip->ioc3_lock); return 0; case SIOCSMIIREG: /* Write any PHY register. */ if (!capable(CAP_NET_ADMIN)) return -EPERM; spin_lock_irq(&ip->ioc3_lock); mii_write(ioc3, data[0], data[1], data[2]); spin_unlock_irq(&ip->ioc3_lock); return 0; default: return -EOPNOTSUPP; } return -EOPNOTSUPP; } static void ioc3_set_multicast_list(struct net_device *dev) { struct dev_mc_list *dmi = dev->mc_list; struct ioc3_private *ip = dev->priv; struct ioc3 *ioc3 = ip->regs; char *addr = dmi->dmi_addr; u64 ehar = 0; int i; if (dev->flags & IFF_PROMISC) { /* Set promiscuous. */ /* Unconditionally log net taps. */ printk(KERN_INFO "%s: Promiscuous mode enabled.\n", dev->name); ip->emcr |= EMCR_PROMISC; ioc3->emcr = ip->emcr; ioc3->emcr; } else { ip->emcr &= ~EMCR_PROMISC; ioc3->emcr = ip->emcr; /* Clear promiscuous. */ ioc3->emcr; if ((dev->flags & IFF_ALLMULTI) || (dev->mc_count > 64)) { /* Too many for hashing to make sense or we want all multicast packets anyway, so skip computing all the hashes and just accept all packets. */ ip->ehar_h = 0xffffffff; ip->ehar_l = 0xffffffff; } else { for (i = 0; i < dev->mc_count; i++) { dmi = dmi->next; if (!(*addr & 1)) continue; ehar |= (1UL << ioc3_hash(addr)); } ip->ehar_h = ehar >> 32; ip->ehar_l = ehar & 0xffffffff; } ioc3->ehar_h = ip->ehar_h; ioc3->ehar_l = ip->ehar_l; } } #ifdef MODULE MODULE_AUTHOR("Ralf Baechle "); MODULE_DESCRIPTION("SGI IOC3 Ethernet driver"); #endif /* MODULE */ module_init(ioc3_probe); module_exit(ioc3_cleanup_module); --n8g4imXOkfNTN/H1-- From owner-linux-origin@oss.sgi.com Fri Sep 29 09:53:00 2000 Received: by oss.sgi.com id ; Fri, 29 Sep 2000 09:52:40 -0700 Received: from deliverator.sgi.com ([204.94.214.10]:17790 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Fri, 29 Sep 2000 09:52:17 -0700 Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA02295; Fri, 29 Sep 2000 09:44:32 -0700 (PDT) mail_from (cngam@cray.com) Received: from tulip-e185.americas.sgi.com (tulip.americas.sgi.com [128.162.185.208]) by zeus-fddi.americas.sgi.com (8.9.3/craymail-smart-nospam1.1) with ESMTP id LAA6236740; Fri, 29 Sep 2000 11:50:58 -0500 (CDT) Received: from cray.com (fsgi241.americas.sgi.com [128.162.195.1]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6mw-e) with ESMTP id LAA15442; Fri, 29 Sep 2000 11:50:58 -0500 (CDT) Message-ID: <39D4C86C.D514328A@cray.com> Date: Fri, 29 Sep 2000 11:50:53 -0500 From: Colin Ngam Reply-To: cngam@americas.sgi.com Organization: SSO X-Mailer: Mozilla 4.61C-SGI [en] (X11; I; IRIX 6.5 IP22) X-Accept-Language: en MIME-Version: 1.0 To: Ralf Baechle CC: Colin Ngam , John Hawkes , Kanoj Sarcar , linux-origin@oss.sgi.com, srn@sgi.com, pfg@sgi.com Subject: Re: posix0 "eth0: RX overflow" References: <00fd01c02721$353bf620$6401a8c0@marin1.sfba.home.com> <20000925225201.C6190@bacchus.dhis.org> <39D0BB1E.21360647@cray.com> <20000929001331.A7004@bacchus.dhis.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing Ralf Baechle wrote: > On Tue, Sep 26, 2000 at 10:05:02AM -0500, Colin Ngam wrote: > > > I have seen this pretty often on the SNIA64 machine too and I normally see > > it on the way to multi-user .. > > > > Are you saying that in 99% of the time when we get RX overflow, we can > > reinit the driver and card? I was led to believe that we NEVER been able to > > recover > > from an RX overflow situation. > > > > The bottom line is that for SNIA64, this may be our only ethernet connection > > and > > we need to stabilize it. Are you actively engaged in this problem? > > Attached is my current version of the IOC3 driver. It has just survived > some hours of extremly heavy network traffic. Yet there are some loose > ends, I've seen crashes which went away without me actually having fixed > them ... Please try this one on SN0/SN1 also and tell me your experiences. > > Ralf > > ------------------------------------------------------------------------ > > ioc3-eth.cName: ioc3-eth.c > Type: Plain Text (text/plain) Thanks Ralf. I still do not have the machine here connected to the network in Eagan .. I am going to seek Chad's help to merge the files. As far as I know the changes for Little Endian has been isolated in the .h files .. we have some hack in there for MAC address but rather isolated a merge should not be that bad. Colin From owner-linux-origin@oss.sgi.com Fri Sep 29 16:07:14 2000 Received: by oss.sgi.com id ; Fri, 29 Sep 2000 16:07:04 -0700 Received: from u-53.karlsruhe.ipdial.viaginterkom.de ([62.180.19.53]:64774 "EHLO u-53.karlsruhe.ipdial.viaginterkom.de") by oss.sgi.com with ESMTP id ; Fri, 29 Sep 2000 16:06:51 -0700 Received: (ralf@lappi) by lappi.waldorf-gmbh.de id ; Sat, 30 Sep 2000 01:06:28 +0200 Date: Sat, 30 Sep 2000 01:06:28 +0200 From: Ralf Baechle To: Colin Ngam Cc: John Hawkes , Kanoj Sarcar , linux-origin@oss.sgi.com, srn@sgi.com, pfg@sgi.com Subject: Re: posix0 "eth0: RX overflow" Message-ID: <20000930010627.A29215@bacchus.dhis.org> References: <00fd01c02721$353bf620$6401a8c0@marin1.sfba.home.com> <20000925225201.C6190@bacchus.dhis.org> <39D0BB1E.21360647@cray.com> <20000929001331.A7004@bacchus.dhis.org> <39D4C86C.D514328A@cray.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <39D4C86C.D514328A@cray.com>; from cngam@americas.sgi.com on Fri, Sep 29, 2000 at 11:50:53AM -0500 X-Accept-Language: de,en,fr Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Fri, Sep 29, 2000 at 11:50:53AM -0500, Colin Ngam wrote: > I still do not have the machine here connected to the network in Eagan .. > > I am going to seek Chad's help to merge the files. > > As far as I know the changes for Little Endian has been isolated in the > .h files .. we have some hack in there for MAC address but rather isolated > a merge should not be that bad. In my other email you should have received a patch which should be appliable right away. Ralf