lkml.org 
[lkml]   [1997]   [Aug]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
Subjectbeta 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) );
\
 
 \ /
  Last update: 2005-03-22 13:40    [W:1.277 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site