From owner-freebsd-bugs Fri Mar 12 8:51:19 1999 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id EE6CD15316 for ; Fri, 12 Mar 1999 08:50:14 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.2/8.9.2) id IAA61160; Fri, 12 Mar 1999 08:50:01 -0800 (PST) (envelope-from gnats@FreeBSD.org) Date: Fri, 12 Mar 1999 08:50:01 -0800 (PST) Message-Id: <199903121650.IAA61160@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Andrew Heybey Subject: Re: kern/10243: Under heavy disk and network load read(2) can return garbage. Reply-To: Andrew Heybey Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/10243; it has been noted by GNATS. From: Andrew Heybey To: freebsd-gnats-submit@freebsd.org, mike@smith.net.au Cc: Subject: Re: kern/10243: Under heavy disk and network load read(2) can return garbage. Date: Fri, 12 Mar 1999 11:44:21 -0500 This bug (under simulataneous heavy disk and network activity reads from disk appear to suffer from short DMA tranfers resulting in incorrect data being returned by read(2)) appears to be a hardware bug. The motherboard on the systems on which I experienced the problem is an Asus P2B-LS with on-board intel ethernet and AIC7890 SCSI controller. If I change the "PCI Latency" BIOS setting from the default of 32 to 64, the problem seems to go away. At least I can run my test programs overnight without a failure while previously they would not run for more than 10-20 minutes. My hypothesis is that the 7890 is not getting sufficient PCI bus bandwidth to keep up with the disks and that there is some bug either in the controller or the disks (IBM Ultrastart 9LZX) such that they lose part of a transfer in this cas. I am not very familiar with the SCSI protocol, but I would think that there is some way that the controller could apply backpressure to the disk to ask it to slow down if the controller's FIFOs are getting full. To lose data either the controller is not applying back pressure or the disk is ignoring it. This PR can be closed, and I apologize for jumping to the conclusion that this is a FreeBSD bug. andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message