> > there is one thing i can think of, disable_irq() has changed it's behavior
> > with the IO-APIC code. Here is a dirty patch that reverts the behavior,
> > wondering wether the problems change. (make sure you dont run with this
> > patch for too long time, it's slightly incorrect)
>
> No, this patch doesn't make any difference in IDE behaviour.
> But I had to boot with 'init=/bin/sh' to do the tests, the system
> stopped already during the rc-scripts with this patch...
[as i said, 'slightly incorrect' ;)]
> Can this problem be caused by hardware and/or BIOS ?
> All the reports I have seen have been with Gigabyte 586DX boards,
> and there have been reports with other boards where IDE seems to work.
i guess that board has an onboard EIDE controller?
another thing you could try: revert the previous patch and apply this one.
Since you use only one IDE channel, it should be just fine. What i'm
trying to do is to simplify the IRQ setup in your case, so we can figure
out what component causes trouble. We already know that UP-interrupts work
fine.
-- mingo
--- linux/drivers/block/.ide.c.orig Mon Mar 9 14:49:35 1998
+++ linux/drivers/block/ide.c Mon Mar 9 14:50:42 1998
@@ -1147,13 +1147,13 @@
del_timer(&hwgroup->timer);
ide_get_lock(&ide_lock, ide_intr, hwgroup);
hwgroup->active = 1;
- do {
+/* do {
disable_irq(hwif->irq);
- } while ((hwif = hwif->next) != hgif);
+ } while ((hwif = hwif->next) != hgif); */
ide_do_request (hwgroup);
- do {
+/* do {
enable_irq(hwif->irq);
- } while ((hwif = hwif->next) != hgif);
+ } while ((hwif = hwif->next) != hgif); */
}
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu