Messages in this thread | | | From | "Mike Black" <> | Subject | Fw: 2.2.12 still "attempt to access beyond end of device" ( | Date | Thu, 30 Sep 1999 13:53:45 -0400 |
| |
I have now replaced my dual PIII/450 with dual PIII/500 (all Intel CPUs) and put on the ide.c patch. This system is now running better. I've been running my app for 30 minutes whereas it used to lock up in about 30 seconds. So, this is now 2.2.13pre14 with raid0145-19990824-2.2.11, 2.2.12-ikd1, and the ide.c patch below.
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/
| |