On Fri, Oct 31, 2003 at 07:52:21PM +0100, Bartlomiej Zolnierkiewicz wrote:
>
> [ http://www.ussg.iu.edu/hypermail/linux/kernel/0308.1/1164.html
> for people seeing this subject for the first time ]
Sorry the reply is so belated, but by the time this patch came along I
was feeling like I had been more than a little foolish to test this on
a live (and very necessary) system as I had been doing. I've finally
gotten hardware rearranged so that I can feel safe about this.
> Can you try booting with "hdX=autotune" (hdX==your drive) kernel parameter?
> The next thing to try is the attached patch (against 2.4.23-pre9), which
> sanitizes 66MHz clock usage -> now 66MHz clock is "enabled" before starting
Okay, by now I have 2.4.23 installed, and with that version (and booting
from a drive not connected to the Promise controller, a mirror pair on
a 3ware controller, in fact) I no longer seem to be able to recreate
the corruption that was previously so repeatable. The autotune
parameter makes no difference: it just works.
If this issue is still of interest (ie, it's just by luck that .23
works), I can do further testing for a while, but the drive that's on
the Promise will be getting repurposed sooner or later.
--
Faced with the choice between changing one's mind and proving there is
no need to do so, almost everyone gets busy on the proof. -- JKG
On Sunday 04 of January 2004 02:12, Martin Maney wrote:
> Okay, by now I have 2.4.23 installed, and with that version (and booting
> from a drive not connected to the Promise controller, a mirror pair on
> a 3ware controller, in fact) I no longer seem to be able to recreate
> the corruption that was previously so repeatable. The autotune
> parameter makes no difference: it just works.
>
> If this issue is still of interest (ie, it's just by luck that .23
> works), I can do further testing for a while, but the drive that's on
> the Promise will be getting repurposed sooner or later.
I see nothing in 2.4.23 which can explain this.
Probably if you boot from Promise you will see corruption again.
--bart
On Sun, Jan 04, 2004 at 03:07:48AM +0100, Bartlomiej Zolnierkiewicz wrote:
> I see nothing in 2.4.23 which can explain this.
> Probably if you boot from Promise you will see corruption again.
If tin's flags are correct I forgot to reply to this after testing
that. In fact I did *not* observe the corruption when I booted from
the Promise, but I didn't have the same file (an XFree86 source
archive) that I was using previously. I think I know which version it
was, and I'll see about retesting with that. If that works I'll try to
recreate a kernel of the version I originally encountered this with and
try that. Probably won't have time until the weekend, what with the
twins' birthday party this evening.
--
The trouble with customizing your environment is that it just doesn't
propagate, so it's not even worth the trouble. -- Joel Spolsky
I keep my life in a CVS repository. -- Joey Hess
On Thu, Jan 08, 2004 at 10:25:08AM -0600, Martin Maney wrote:
> On Sun, Jan 04, 2004 at 03:07:48AM +0100, Bartlomiej Zolnierkiewicz wrote:
> > I see nothing in 2.4.23 which can explain this.
> > Probably if you boot from Promise you will see corruption again.
> that. In fact I did *not* observe the corruption when I booted from
> the Promise, but I didn't have the same file (an XFree86 source
Okay, color me as having no idea what's going on...
Jiggered things around to boot from the drive connected to the Promise
(hereafter the old drive) again, with a copy of the original test
object (xfree86_4.2.1.orig.tar.gz from Branden's Debian archives). It
still works with 2.4.23. Rebuilt 2.4.22 (didn't have any of the patches
around, and I'm 99% sure I tested with 22-final just before giving up
originally); that works too. Shutdown and physically removed the 3ware
card from the machine; dug up the grub boot disk that I'd forgotten I
would need for this, booted into 2.4.22 again. Still, it works.
Maybe it's because the Promise chip knows it's no longer needed? :-/
--
...and of course you must be careful not to overwrite the bounds of
memory blocks, free a memory block twice, forget to free a memory block,
use a memory block after it's been freed, use memory that you haven't
explicitly allocated, etc. We C++ programmers have developed tricks
to help us deal with this sort of thing, in much the same way that people
who suffer severe childhood trauma develop psychological mechanisms to
insulate themselves from those experiences. -- Joseph A. Knapka