I really don't think the ide.c patch has any relevance as the IDE disks
aren't being actively accessed by anything. But...this is the one variable
left. I suppose I could test without this if somebody insists...
I ran as a single PIII/450 and it worked without the ide.c patch -- dual
PIII/450's would lockup quickly. Dual PIII/450's with non-SMP kernel would
lockup too. So, maybe a bug/hardware problem in the PIII/450's ??
________________________________________
Michael D. Black Principal Engineer
mblack@csi.cc 407-676-2923,x203
http://www.csi.cc Computer Science Innovations
http://www.csi.cc/~mike My home page
FAX 407-676-2355
----- Original Message -----
From: Mike Black <mblack@csihq.com>
To: Stephen C. Tweedie <sct@redhat.com>
Sent: Thursday, September 30, 1999 9:53 AM
Subject: Re: 2.2.12 still "attempt to access beyond end of device" (
I've got one script that virtually guarantees a lockup within minutes (very
heavy I/O - multiple pipes)
I went back to 2.0.37 and it locked up.
I tried 2.2.6 and later and they all locked up.
I was using the EIP patch and all the lockups were different -- nothing
repeatable
I moved my SCSI chassis and Adaptec 2940U2W to another machine (Single
PII/400) and it worked for 20 hours -- no problem. This system had NO ide
drives.
I moved the SCSI chassis and Adaptec back to my SOHO SY-6BIA (Dual PIII/450)
and it locked up in a couple minutes doing a kernel compile. This other
system does have two other IDE drives that weren't being used much (if at
all).
I've now removed the 2nd CPU from the SOHO and am runnning stress tests
again with the NMI oopser enabled.
Next lockup, I'm going to run with the ide.c patch that appeared on digest
#4536...after that I'm going to move the PIII/450 to the other box and run
there.
*** linux/drivers/block/ide.c Mon Aug 9 12:04:39 1999
- --- linux.ide-race/drivers/block/ide.c Wed Sep 29 13:14:58 1999
***************
*** 1170,1182 ****
bdev->current_request = hwgroup->rq = drive->queue;
spin_unlock_irqrestore(&io_request_lock, io_flags);
if (hwif->irq != masked_irq)
disable_irq(hwif->irq);
- - spin_unlock_irqrestore(&hwgroup->spinlock,
*hwgroup_flags);
start_request(drive);
- - spin_lock_irqsave(&hwgroup->spinlock, *hwgroup_flags);
if (hwif->irq != masked_irq)
enable_irq(hwif->irq);
}
}
- --- 1170,1182 ----
bdev->current_request = hwgroup->rq = drive->queue;
spin_unlock_irqrestore(&io_request_lock, io_flags);
+ spin_unlock_irqrestore(&hwgroup->spinlock, *hwgroup_flags);
if (hwif->irq != masked_irq)
disable_irq(hwif->irq);
start_request(drive);
if (hwif->irq != masked_irq)
enable_irq(hwif->irq);
+ spin_lock_irqsave(&hwgroup->spinlock, *hwgroup_flags);
}
}
________________________________________
Michael D. Black Principal Engineer
mblack@csi.cc 407-676-2923,x203
http://www.csi.cc Computer Science Innovations
http://www.csi.cc/~mike My home page
FAX 407-676-2355
----- Original Message -----
From: Stephen C. Tweedie <sct@redhat.com>
To: Mike Black <mblack@csihq.com>
Cc: Stephen C. Tweedie <sct@redhat.com>
Sent: Thursday, September 30, 1999 9:38 AM
Subject: Re: 2.2.12 still "attempt to access beyond end of device" (
Hi,
On Wed, 15 Sep 1999 09:41:45 -0400, "Mike Black" <mblack@csihq.com>
said:
> I'm going to run the 2.2.12pre7 until it locks up and then go back to
2.0.36
> (or whatever the latest is there) and see how that behaves.
Did you get anywhere with this? It would be tremendously useful to find
out exactly when the corruptions started. In particular, can you
reproduce on 2.2.5 or 2.2.7?
It looks as if I may have a reproducer here, too, finally.
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/