Messages in this thread Patch in this message | | | Date | Thu, 14 Aug 1997 03:43:53 +0200 (MET DST) | From | Tomasz Motylewski <> | Subject | beta report on 2.0.pre31 |
| |
In general, getting better and better. But not all of the problems have been eliminated for me by 2.0.31-5
MACHINE: dual Pentium 200, 128 MB RAM, GA-586DX motherboard, onboard Adaptec UW AIC-7880, 2 SCSI disks WDIGTL Model: ENTERPRISE Rev: 1.61 (4 GB) SCSI CDROM, Matrox Millenium SVGA 4 MB, 3c509B PnP, SoundBlaster 32 AWE PnP.
Problems remaining with 2.0.31-5 (Linus)
1. detecting only 64 MB of memory -was already detecting 128 MB in 2.0.31-2 (DaveM). Search for: +! Modifications to detect > 64M RAM by Larry M. Augustin lma@varesearch.com 4/16/97. Patch will follow.
2. 3c509.c messages: Waiting for 3c509 to discard packet, status 2001. (each few minutes or more - very annoying) Go to: http://cesdis.gsfc.nasa.gov/linux/drivers/3c509.html Patch included. It is really very simple patch. 3. ping -f localhost 3862 packets transmitted, 177 packets received, 95% packet loss ping -f localhost -s 1000 5285 packets transmitted, 39 packets received, 99% packet loss ping -f localhost -s 2000 4298 packets transmitted, 21 packets received, 99% packet loss Is it a feature? Numbers of received packets are always the same.
SOLVED PROBLEMS: (first good version referenced)
2.0.31-1 (DaveM): solved problems with booting SMP kernel - aic7xxx resetting the bus all the time - some fixes for aic7xxx . 2.0.31-4 (Linus) - Leonard's SMP deadlock.5 patch incorporated - solved problems with machine stopping for 10s (interrupts disabled!) when pressing CapsLock during some moderate load (best was xsnow -snowflakes 700 or moving the PS/2 mouse in Xserver). Was it that CapsLock bug Alan was referring to? I had this problem even in 2.1.36/37
As for buffer cache patches, I did not have problems to be removed - lots of memory, "512 760 2500" in /proc/sys/vm/freepages. With 2.0.31-2 (DaveM) i was getting "try_to_free_page: state(0) stop(3) i(2) sleep instead of fail" once a few days. I was testing various versions of Werner's patches and they were really improving interactive performance.
For 2.0.31-2 (DaveM) and Werner-Jul29 patch +aic7xxx patch I run 50 copies of DaveM forking program + make -j zImage + netscape + drvmidi. It was running well until loadavg 90. netscape was only a bit slower. But then it suddenly broke down - display was being refreshed line by line, running "free" took one minute. After that I saw in logs:
Aug 3 20:03:30 crds kernel: aic7xxx: Command complete near Qfull count, qoutcnt = 16. Aug 3 20:14:37 crds kernel: aic7xxx: Command complete near Qfull count, qoutcnt = 16. Aug 3 20:14:50 crds kernel: scsi : aborting command due to timeout : pid 426194, scsi0, channel 0, id 9, lun 0 Write (10) 00 00 7e ce a8 00 00 08 00 Aug 3 20:14:50 crds kernel: scsi : aborting command due to timeout : pid 426242, scsi0, channel 0, id 8, lun 0 Read (6) 13 9f b8 02 00 Aug 3 20:14:50 crds kernel: scsi : aborting command due to timeout : pid 426243, scsi0, channel 0, id 8, lun 0 Read (6) 13 9f ba 02 00 Aug 3 20:14:50 crds kernel: scsi : aborting command due to timeout : pid 426244, scsi0, channel 0, id 8, lun 0 Read (6) 13 9f bc 02 00 Aug 3 20:15:05 crds kernel: scsi : aborting command due to timeout : pid 426194, scsi0, channel 0, id 9, lun 0 Write (10) 00 00 7e ce a8 00 00 08 00 Aug 3 20:15:05 crds kernel: SCSI host 0 abort (pid 426194) timed out - resetting Aug 3 20:15:05 crds kernel: SCSI bus is being reset for host 0 channel 0. Aug 3 20:15:05 crds kernel: (scsi0:9:0) Abort_reset, scb flags 0x1, while idle, LASTPHASE = 0x1, SCSISIGI 0x0, SEQADDR 0x6, SSTAT0 0x5, SSTAT1 0xa
and much more junk like that. But after compilation had finished the system recovered. Also, the whole compilation took only 20 minutes (usual time 13 minutes (remember about that 50 forking and idle looping processes))
After all that testing I have decided to compare 2.0.31-5(Linus) and pre2.0.31_DAVEM_FINAL. Details in next mail. But you may already look into http://crds.chemie.unibas.ch/linux/
-- Tomasz Motylewski
From kaukasoi@elektroni.ee.tut.fi Thu Jul 10 14:55:50 1997 From: Petri Kaukasoina <kaukasoi@elektroni.ee.tut.fi> To: linux-kernel@vger.rutgers.edu Date: Thu, 10 Jul 1997 14:55:49 +0300 Subject: Re: pre-patch-2.0.31-2 and 3c509
On Thu, Jul 10, 1997 at 06:56:55AM -0400, Jeff Garzik wrote: > I'm beating my P133 w/ 3c509 to death on a news server, and getting > this... > > Waiting for 3c509 to discard packet, status 2001. > Waiting for 3c509 to discard packet, status 2011. > Waiting for 3c509 to discard packet, status 2001.
There is a fix for that in http://cesdis.gsfc.nasa.gov/linux/drivers/3c509.html
The fix is this:
--- linux/drivers/net/3c509.c.orig Wed Oct 30 03:42:40 1996 +++ linux/drivers/net/3c509.c Wed Mar 19 13:26:39 1997 @@ -682,8 +682,9 @@ printk("%s: Couldn't allocate a sk_buff of size %d.\n", dev->name, pkt_len); } - lp->stats.rx_dropped++; outw(RxDiscard, ioaddr + EL3_CMD); + lp->stats.rx_dropped++; + SLOW_DOWN_IO; while (inw(ioaddr + EL3_STATUS) & 0x1000) printk(" Waiting for 3c509 to discard packet, status %x.\n", inw(ioaddr + EL3_STATUS) );
| |