Date: Sun, 21 Jun 1998 16:39:49 -0700 (PDT)
From: Michael Schmitz <SCHMITZ@LCBVAX.CCHEM.BERKELEY.EDU>
To: SCHMITZ@LCBVAX.CCHEM.BERKELEY.EDU
CC: linux-m68k@lists.linux-m68k.org, Lars.Froehlich@t-online.de
Subject: RE: L68K: [comp.os.linux.m68k] Linux 2.0.33pl1 doesn't boot...
Sender: owner-linux-m68k@phil.uni-sb.de

Hi,

followup to my speculations:

>>Looks like this is the following part (Geert will correct me if my interpretation
>>is off; if you used Jes' precompiled kernel we can disassemble the address in 
>>question to figure out what exactly happens):
>
>->      if (irq == hwgroup->hwif->irq && (handler = hwgroup->handler) != NULL) {
>
>You don't have any IDE disks, so hwgroup hasn't been populated. I'm not sure
>if hwgroup->hwif exists (not NULL), but without finding a drive, hwgroup->drive
>is pretty sure not set. Probably the first case; hwgroup->handler != NULL means
>there's an IDE request been issued before.
>
>We had the same problem in 2.1.x, it was solved there by passing NULL instead of
>ide_intr to stdma_lock(). No one ever came up with an explanation why this worked
>...

Geert and Roman haven't yelled at me yet, and I've looked a bit closer - I'm 
pretty sure the ST-DMA lock isn't released when no IDE drive is found
(hwif->present is set to 1 in the probe code only if a drive is present, to prevent
the driver from initializing block device and interrupts otherwise).

The following patch should fix the problem.

[patch deleted, see below]

I've uploaded a 2.0.33pl1 kernel with this fix to the incoming directory in
Erlangen, could you please test it (possibly after Roman moved it to testing)?

If this patch fixes the problem, we can talk about making it foolproof.

	Michael

------------------------------------------------------------------------------
To: Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de>,
        Michael Schmitz <schmitzm@uclink4.berkeley.edu>
Subject: Correction: idelock patch is SNAFU
Mail-Copies-To: never
From: James Troup <james@nocrew.org>
Date: 15 Jul 1998 18:32:34 +0100
Sender: James Troup <james@junk.nocrew.org>

Hi,

I'm afraid the IDE lock patch is FUBAR.  It tries to talk about
ide_get_lock while not inside #ifdef CONFIG_ATARI which plainly won't
work.  Corrected patch follows.

--- drivers/block/ide.c.orig	Wed Jul 15 18:28:05 1998
+++ drivers/block/ide.c	Wed Jul 15 18:27:34 1998
@@ -3909,6 +3909,24 @@
 	void (*rfn)(void);
 	
 	if (!hwif->present){
+#if defined (CONFIG_ATARI)
+	        /* 
+ 		 * MSch: release ST-DMA lock if no drives found. Otherwise,
+ 		 * all sort of funny things may happen. I.e. the SCSI initial
+ 		 * bus reset interrupt will be routed to ide_intr, and the 
+ 		 * SCSI requests would hang with the ST-DMA lock still held by
+ 		 * the unused IDE code.
+ 		 * Normally, the lock is given up in init_irq() ...
+ 		 * I hope I can get away without cli() and waking up the 
+ 		 * lock wait queue here, it's still early in the boot. Might
+ 		 * get module users in trouble ??
+ 		 */
+ 		if (MACH_IS_ATARI && ide_got_lock) {
+ 			printk("ide: no drives found, giving up lock!\n");
+ 			ide_got_lock = 0;
+ 			stdma_release();
+ 		}
+#endif
 #if defined(CONFIG_AMIGA) || defined (CONFIG_ATARI)
 		/*
 		 * irq was disabled for probing. We gotta re-enable it


-- 
James
~Yawn And Walk North~                                  http://yawn.nocrew.org/
