Skip to contentSkip to conversation

BUG Report 2.4.0-test11-pre3: NMI Watchdoch detected LOCKUP atCPU[01]

DISCUSSION Gert Wollny 2 participants 2 messages Nov 16, 2000 1 message not in the archive SCSI

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

#1 lore raw

Hello,

i think it got it nailed, please try the attached patch (it is against 11-pre4, but it should work against all test11).

Explanation:
with test7-pre6 in the imm-module the new scsi - code was enabled (see imm.h).
This causes the locking of the io_request_lock in scsi_register_host (scsi.c) during detection of the ZIP drive. Seems, that the request_module call for the parport_pc doesn't like this.
The patch does, what the comment in scsi.c suggests: Enable the new code only, after the drive is detected.

Have a nice day

Gert

drivers/scsi/imm.c +5 -2
diff -ru 2.4.0-test11-pre4/drivers/scsi/imm.c 2.4.0-test11-pre4-my/drivers/scsi/imm.c
@@ -212,8 +212,11 @@
 	    return 0;
 	try_again = 1;
 	goto retry_entry;
-    } else
-	return 1;		/* return number of hosts detected */
+    } else {
+	 /* now enable the new code */
+	 host->use_new_eh_code = 1;
+	 return 1;		/* return number of hosts detected */
+    }	 
 }
 
 /* This is to give the imm driver a way to modify the timings (and other
drivers/scsi/imm.h +5 -2
diff -ru 2.4.0-test11-pre4/drivers/scsi/imm.h 2.4.0-test11-pre4-my/drivers/scsi/imm.h
@@ -10,7 +10,7 @@
 #ifndef _IMM_H
 #define _IMM_H
 
-#define   IMM_VERSION   "2.04 (for Linux 2.4.0)"
+#define   IMM_VERSION   "2.05 (for Linux 2.4.0)"
 
 /* 
  * 10 Apr 1998 (Good Friday) - Received EN144302 by email from Iomega.
@@ -60,6 +60,9 @@
  *    added CONFIG_SCSI_IZIP_SLOW_CTR option
  *                                                      [2.03]
  *  Fix kernel panic on scsi timeout.		20Aug00 [2.04]
+ *
+ *  Fix a lockup during detection of drive      14Nov00 [2.05]
+ *  <[email protected]>
  */
 /* ------ END OF USER CONFIGURABLE PARAMETERS ----- */
 
@@ -172,7 +175,7 @@
                 eh_device_reset_handler:        NULL,                   \
                 eh_bus_reset_handler:           imm_reset,              \
                 eh_host_reset_handler:          imm_reset,              \
-		use_new_eh_code:		1,			\
+		use_new_eh_code:		0,			\
 		bios_param:		        imm_biosparam,		\
 		this_id:			7,			\
 		sg_tablesize:			SG_ALL,			\
#2 lore raw
Quoted 15 lines · Gert Wollny

Hello,

i think it got it nailed, please try the attached patch (it is against 11-pre4, but it should work against all test11).

Explanation:
with test7-pre6 in the imm-module the new scsi - code was enabled (see imm.h).
This causes the locking of the io_request_lock in scsi_register_host (scsi.c) during detection of the ZIP drive. Seems, that the request_module call for the parport_pc doesn't like this.
The patch does, what the comment in scsi.c suggests: Enable the new code only, after the drive is detected.

Quoted 1 line

Have a nice day

Thank you Gert. I turned off Winbond support as before and it truly is "safe to say no" now. Your patch seems to work. Good Job.

Still outstanding:

If (mode=SPP && Zip100) Log_msg("Spp is godawful slow, set for EPP in bios");
// I don't know off top of my head if Zip250 can use ECP or not // Zip100 is EPP at best

Imm driver reports Zip100 at 101 MB

ECP/EPP setting in Bios yields SPP for Zip100. 1284 spec says you should be able to set mode 100 to get EPP and even tho it's a M$ extension most chipsets should support it.

Speed Sucks: Hdparm reports 496k/sec for EPP on a 64 MB buffered disk read. 1284 spec says 500k/2 MB for EPP and Iomega says it can do 1.4 MB sustained for Zip100. Not that it matters but SPP runs 96k/sec.

I'm coding up a parport-poker to get familiar then I'll take a stab at these if someone doesn't beat me to it.

Quoted 10 lines

Gert

------------------------------------------------------------------------
Name: imm-lockup.patch
imm-lockup.patch Type: Plain Text (TEXT/PLAIN)
Encoding: BASE64
Description: the patch

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/