Problem with AHA152X driver in 2.4.19

Hi all,

I just built 2.4.19 and checked that the problem that had been introduced in the aha152x driver between 2.4.19-pre8 and pre10 (bad initialization due to lost interrupt) had been corrected. However, I have experienced another problem related to blocking factor.

Using tar without specifying a blocking factor works fine but as soon as I specify one, tar exits with a segmentation violation immediately after trying to write to the tape. There is a also a message about a NULL pointer dereference written to /var/log/messages (see below).

The exact command I used is (taken from a shell script):

tar --create --blocking-factor 96 --file=/dev/st0 --listed-incremental=$JOURNAL --verbose --preserve --one-file-system --atime-preserve $1

The very same script worked flawlessly with 2.4.19-pre8 and before. If I remove the blocking-factor option, everything is back to normal.

Marc

----------------------------------------------------------------------

Aug  3 17:44:55 socrate kernel: Unable to handle kernel NULL pointer dereference
 at virtual address 0000001b
Aug  3 17:44:55 socrate kernel:  printing eip:
Aug  3 17:44:55 socrate kernel: c68a21d9
Aug  3 17:44:55 socrate kernel: *pde = 00000000
Aug  3 17:44:55 socrate kernel: Oops: 0000
Aug  3 17:44:55 socrate kernel: CPU:    0
Aug  3 17:44:55 socrate kernel: EIP:    0010:[<c68a21d9>]    Not tainted
Aug  3 17:44:55 socrate kernel: EFLAGS: 00010002
Aug  3 17:44:55 socrate kernel: eax: 00000000   ebx: c2575000   ecx: c26e9e30   
edx: c1d9a240
Aug  3 17:44:55 socrate kernel: esi: c251c000   edi: 0000000c   ebp: c251c000   
esp: c2691e4c
Aug  3 17:44:55 socrate kernel: ds: 0018   es: 0018   ss: 0018
Aug  3 17:44:55 socrate kernel: Process tar (pid: 1141, stackpage=c2691000)
Aug  3 17:44:55 socrate kernel: Stack: 00000297 c116fdb4 c2575000 c68a22e3 c2575
000 00000000 00000000 00000000 
Aug  3 17:44:55 socrate kernel:        c687fab0 c687f517 c2575000 c687fab0 00000
000 c2575000 c116fdb4 c25750b8 
Aug  3 17:44:55 socrate kernel:        c116fdb4 c688662f c2575000 c2575000 00000
000 c251c000 c5995c00 c116fd60 
Aug  3 17:44:55 socrate kernel: Call Trace:    [<c68a22e3>] [<c687fab0>] [<c687f
517>] [<c687fab0>] [<c688662f>]
Aug  3 17:44:55 socrate kernel:   [<c6885a5f>] [<c6885ab9>] [<c68984cc>] [<c6898
300>] [<c6899ce6>] [<c0132bc8>]
Aug  3 17:44:55 socrate kernel:   [<c013266f>] [<c01088b3>]
Aug  3 17:44:55 socrate kernel: 
Aug  3 17:44:55 socrate kernel: Code: 0f b6 50 1b 8b 14 95 dc 24 27 c0 2b 82 a0 

00 00 00 69 c0 a3

You need to run through the oops through the ksymoops decoder (see REPORTING-BUGS in the kernel)

Sorry about that. Here is a new one:

Aug  4 01:51:14 socrate kernel: Unable to handle kernel NULL pointer dereference at virtual address 0000001b
Aug  4 01:51:14 socrate kernel: c68a21d9
Aug  4 01:51:14 socrate kernel: *pde = 00000000
Aug  4 01:51:14 socrate kernel: Oops: 0000
Aug  4 01:51:14 socrate kernel: CPU:    0
Aug  4 01:51:14 socrate kernel: EIP:    0010:[<c68a21d9>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
Aug  4 01:51:14 socrate kernel: EFLAGS: 00010006
Aug  4 01:51:14 socrate kernel: eax: 00000000   ebx: c2738000   ecx: c30a5e30   edx: c5c58b20
Aug  4 01:51:14 socrate kernel: esi: c5319000   edi: 0000000c   ebp: c5319000   esp: c29dde30
Aug  4 01:51:14 socrate kernel: ds: 0018   es: 0018   ss: 0018
Aug  4 01:51:14 socrate kernel: Process tar (pid: 1120, stackpage=c29dd000)
Aug  4 01:51:14 socrate kernel: Stack: 00000297 c116feb4 c2738000 c68a22e3 c2738000 00000000 00000000 00000000 
Aug  4 01:51:14 socrate kernel:        c687fab0 c687f517 c2738000 c687fab0 00000000 c2738000 c116feb4 c27380b8 
Aug  4 01:51:14 socrate kernel:        c116feb4 c688662f c2738000 c2738000 00000000 c5319000 c59d3c00 c116fe60 
Aug  4 01:51:14 socrate kernel: Call Trace:    [<c68a22e3>] [<c687fab0>] [<c687f517>] [<c687fab0>] [<c688662f>]
Aug  4 01:51:14 socrate kernel:   [<c6885a5f>] [<c6885ab9>] [<c68984cc>] [<c6898300>] [<c6899e99>] [<c689a4e0>]
Aug  4 01:51:14 socrate kernel:   [<c0132ac8>] [<c01394a5>] [<c01088b3>]
Aug  4 01:51:14 socrate kernel: Code: 0f b6 50 1b 8b 14 95 dc 24 27 c0 2b 82 a0 00 00 00 69 c0 a3 

Trace; c68a22e3 <[aha152x]aha152x_queue+13/20>
Trace; c687fab0 <[scsi_mod]scsi_done+0/90>
Trace; c687f517 <[scsi_mod]__kstrtab_scsi_deregister_blocked_host+17/27> Trace; c687fab0 <[scsi_mod]scsi_done+0/90>
Trace; c688662f <[scsi_mod]scsi_request_fn+2bf/300>
Trace; c6885a5f <[scsi_mod]__scsi_insert_special+5f/70> Trace; c6885ab9 <[scsi_mod]scsi_insert_special_req+19/30> Trace; c68984cc <[st]st_do_scsi+10c/150>
Trace; c6898300 <[st]st_sleep_done+0/c0>
Trace; c6899e99 <[st]read_tape+119/390>
Trace; c689a4e0 <[st]st_read+3d0/500>
Trace; c0132ac8 <sys_read+98/100>
Trace; c01394a5 <sys_stat64+65/70>
Trace; c01088b3 <system_call+33/40>
Code; c68a21d9 <[aha152x]aha152x_internal_queue+f9/1f0> 00000000 <_EIP>:
Code; c68a21d9 <[aha152x]aha152x_internal_queue+f9/1f0> <=====
0: 0f b6 50 1b movzbl 0x1b(%eax),%edx <=====
Code; c68a21dd <[aha152x]aha152x_internal_queue+fd/1f0>
4: 8b 14 95 dc 24 27 c0 mov 0xc02724dc(,%edx,4),%edx
Code; c68a21e4 <[aha152x]aha152x_internal_queue+104/1f0>
b: 2b 82 a0 00 00 00 sub 0xa0(%edx),%eax
Code; c68a21ea <[aha152x]aha152x_internal_queue+10a/1f0>
11: 69 c0 a3 00 00 00 imul $0xa3,%eax,%eax

And while we are at it, here is the information from the driver as it starts

Aug  4 01:51:11 socrate kernel: SCSI subsystem driver Revision: 1.00
Aug  4 01:51:12 socrate kernel: aha152x: BIOS test: passed, detected 1 controller(s)
Aug  4 01:51:12 socrate kernel: aha152x: resetting bus...
Aug  4 01:51:12 socrate kernel: aha152x0: vital data: rev=1, io=0x140 (0x140/0x140), irq=11, scsiid=7, reconnect=enabled, parity=enabled, synchronous=enabled, delay=1000, extended translation=disabled
Aug  4 01:51:12 socrate kernel: aha152x0: trying software interrupt, ok.
Aug  4 01:51:12 socrate kernel: scsi0 : Adaptec 152x SCSI driver; $Revision: 2.5 $
Aug  4 01:51:13 socrate kernel: (scsi0:3:0) Synchronous Data Transfer Request period = 200 ns, offset = 8
Aug  4 01:51:13 socrate kernel:   Vendor: HP        Model: C1533A            Rev: A812
Aug  4 01:51:13 socrate kernel:   Type:   Sequential-Access                  ANSI SCSI revision: 02
Aug  4 01:51:14 socrate kernel: st: Version 20020205, bufsize 32768, wrt 30720, max init. bufs 4, s/g segs 16
Aug  4 01:51:14 socrate kernel: Attached scsi tape st0 at scsi0, channel 0, id 3, lun 0
Aug  4 01:51:14 socrate kernel: st0: Block limits 1 - 16777215 bytes.

Hi Marc,

I posted another patch a while ago. Obviously it didn't make it into 2.4.19. So this is the same thing against 2.4.19.

It fixes your problem and another one related to longtaking tape operations.

Juergen

@@ -602,7 +602,11 @@
 #define SCDONE(SCpnt)		SCDATA(SCpnt)->done
 #define SCSEM(SCpnt)		SCDATA(SCpnt)->sem
 
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,0)
+#define SG_ADDRESS(buffer)	((buffer)->address)
+#else
 #define SG_ADDRESS(buffer)	((char *) (page_address((buffer)->page)+(buffer)->offset))
+#endif
 
 /* state handling */
 static void seldi_run(struct Scsi_Host *shpnt);

@@ -2657,7 +2661,7 @@
 		 * STCNT to trigger ENSWRAP interrupt, instead of
 		 * polling for DFIFOFULL
 		 */
-		the_time=jiffies + 10*HZ;
+		the_time=jiffies + 100*HZ;
 		while(TESTLO(DMASTAT, DFIFOFULL|INTSTAT) && time_before(jiffies,the_time))
 			barrier();
 

@@ -2670,7 +2674,7 @@
 		if(TESTHI(DMASTAT, DFIFOFULL)) {
 			fifodata = 128;
 		} else {
-			the_time=jiffies + 10*HZ;
+			the_time=jiffies + 100*HZ;
 			while(TESTLO(SSTAT2, SEMPTY) && time_before(jiffies,the_time))
 				barrier();
 

@@ -2826,7 +2830,7 @@
 			CURRENT_SC->SCp.this_residual = CURRENT_SC->SCp.buffer->length;
 		}
 
-		the_time=jiffies + 10*HZ;
+		the_time=jiffies + 100*HZ;
 		while(TESTLO(DMASTAT, DFIFOEMP|INTSTAT) && time_before(jiffies,the_time))
 			barrier();