Date: Fri, 26 Feb 1999 17:13:20 -0500 From: Andrew Heybey <ath@niksun.com> To: Mike Smith <mike@smith.net.au> Cc: freebsd-hackers@freebsd.org Subject: Re: Advice wanted on tracking down bug (or hw problem?) in 3.1R Message-ID: <199902262213.RAA13223@stiegl.niksun.com> In-Reply-To: Your message of Fri, 26 Feb 1999 12:22:25 -0800. <199902262022.MAA09175@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>>On Fri, 26 Feb 1999 12:22:25 -0800, Mike Smith <mike@smith.net.au> said: mike> Could you try bzero'ing your buffers before every read? This mike> sniffs very much like short transfers rather than sniping... I have tried this (bzero'ing the buffer before every read) now. I still get the same results. As an example, here is the output from my test program when it encounters the bug: 18: unexpected value: file offset 1605560, buffer offset 32696 read (starting at i-4): 000e161fea 000e161feb 000e161fec 000e161fed 000c58ffee 000c58ffef 000c58fff0 000c58fff1 000c58fff2 000c58fff3 000c58fff4 000c58fff5 expected: 000e161fea 000e161feb 000e161fec 000e161fed 000e161fee 000e161fef 000e161ff0 000e161ff1 000e161ff2 000e161ff3 000e161ff4 000e161ff5 0x000c58ffee is the first bogus value. The program is reading 32k buffers, so this garbage is near the end of the buffer (I have seen it in the middle also, but always near the end of a page). While the printout above does not show it, the garbage extends to the end of the buffer (the test program calls abort() when it detects a bad value so I can look at it with gdb), so the total number of garbage bytes is 72. It seems to me that either the controller or the driver is reporting that the disk DMA is finished before it really is, or that the DMA is simply not copying all the bytes that it should. I start four test processes reading files: two of them read starting with file 0, two of them read starting at file 14 (out of 30) so that there are two processes reading the same file at any given time. In the example above both processes reading file 18 find the same garbage in their buffers at the same offset in the file. This leads me to believe that the garbage is ensconced in the buffer cache. andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902262213.RAA13223>