From owner-freebsd-scsi Fri Mar 12 15: 1:30 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from dingo.cdrom.com (castles321.castles.com [208.214.167.21]) by hub.freebsd.org (Postfix) with ESMTP id 8CFF214C30 for ; Fri, 12 Mar 1999 15:01:25 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id OAA01397 for ; Fri, 12 Mar 1999 14:55:51 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199903122255.OAA01397@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-scsi@freebsd.org Subject: Possible errata for the 7890? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 12 Mar 1999 14:55:51 -0800 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ------- Forwarded Message From: Andrew Heybey To: freebsd-gnats-submit@freebsd.org, mike@smith.net.au 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 ------- End of Forwarded Message -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message