public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* CDROM troubles
@ 2001-05-06 10:05 Phil Stracchino
  2001-05-06 21:42 ` Phil Stracchino
  0 siblings, 1 reply; 5+ messages in thread
From: Phil Stracchino @ 2001-05-06 10:05 UTC (permalink / raw)
  To: Linux-KERNEL

Hey folks,
I'm seeing a problem with mounting CDs using a Toshiba XM-6401TA CDROM
drive attached to an Adaptec AHA1542CF controller (scsi1) on kernel 2.4.3
and 2.4.4.  The behavior seems to be fairly consistent as follows:

first mount and unmount works normally, no unusual events logged
second mount and unmount works normally, no unusual events logged
third mount locks up the machine.  looks like a kernel panic.

Any ideas?


-- 
 Linux Now!   ..........Because friends don't let friends use Microsoft.
 phil stracchino   --   the renaissance man   --   mystic zen biker geek
    Vr00m:  2000 Honda CBR929RR   --   Cage:  2000 Dodge Intrepid R/T
 Previous vr00mage:  1986 VF500F (sold), 1991 VFR750F3 (foully murdered)

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: CDROM troubles
  2001-05-06 10:05 CDROM troubles Phil Stracchino
@ 2001-05-06 21:42 ` Phil Stracchino
  2001-05-06 22:01   ` Jens Axboe
  0 siblings, 1 reply; 5+ messages in thread
From: Phil Stracchino @ 2001-05-06 21:42 UTC (permalink / raw)
  To: Linux-KERNEL

On Sun, May 06, 2001 at 03:05:00AM -0700, Phil Stracchino wrote:
> Hey folks,
> I'm seeing a problem with mounting CDs using a Toshiba XM-6401TA CDROM
> drive attached to an Adaptec AHA1542CF controller (scsi1) on kernel 2.4.3
> and 2.4.4.  The behavior seems to be fairly consistent as follows:
> 
> first mount and unmount works normally, no unusual events logged
> second mount and unmount works normally, no unusual events logged
> third mount locks up the machine.  looks like a kernel panic.
> 
> Any ideas?


Panic is confirmed.  This time, it lived long enough to log:
 
May  6 14:05:05 babylon5 kernel: Kernel panic: scsi_free:Bad offset

Since it involves the CDROM, the aha1542 driver is implicated.  Why it's
getting a bad offset, I don't understand enough about the SCSI drivers to
know; all the scsi_free calls in aha1542.c look identical to me.
 
Would any Linux SCSI gurus care to let me know any diagnostic procedures
recommended for nailing this one?


-- 
 Linux Now!   ..........Because friends don't let friends use Microsoft.
 phil stracchino   --   the renaissance man   --   mystic zen biker geek
    Vr00m:  2000 Honda CBR929RR   --   Cage:  2000 Dodge Intrepid R/T
 Previous vr00mage:  1986 VF500F (sold), 1991 VFR750F3 (foully murdered)

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: CDROM troubles
  2001-05-06 21:42 ` Phil Stracchino
@ 2001-05-06 22:01   ` Jens Axboe
  2001-05-06 23:17     ` CDROM troubles -- some progress, problem remains Phil Stracchino
  0 siblings, 1 reply; 5+ messages in thread
From: Jens Axboe @ 2001-05-06 22:01 UTC (permalink / raw)
  To: Linux-KERNEL; +Cc: Phil Stracchino

[-- Attachment #1: Type: text/plain, Size: 1124 bytes --]

On Sun, May 06 2001, Phil Stracchino wrote:
> On Sun, May 06, 2001 at 03:05:00AM -0700, Phil Stracchino wrote:
> > Hey folks,
> > I'm seeing a problem with mounting CDs using a Toshiba XM-6401TA CDROM
> > drive attached to an Adaptec AHA1542CF controller (scsi1) on kernel 2.4.3
> > and 2.4.4.  The behavior seems to be fairly consistent as follows:
> > 
> > first mount and unmount works normally, no unusual events logged
> > second mount and unmount works normally, no unusual events logged
> > third mount locks up the machine.  looks like a kernel panic.
> > 
> > Any ideas?
> 
> 
> Panic is confirmed.  This time, it lived long enough to log:
>  
> May  6 14:05:05 babylon5 kernel: Kernel panic: scsi_free:Bad offset
> 
> Since it involves the CDROM, the aha1542 driver is implicated.  Why it's
> getting a bad offset, I don't understand enough about the SCSI drivers to
> know; all the scsi_free calls in aha1542.c look identical to me.
>  
> Would any Linux SCSI gurus care to let me know any diagnostic procedures
> recommended for nailing this one?

The panic should be fixed with attached patch.

-- 
Jens Axboe


[-- Attachment #2: sr-scatter-1 --]
[-- Type: text/plain, Size: 1208 bytes --]

diff -urN --exclude-from /home/axboe/cdrom/exclude /opt/kernel/linux-2.4.4-pre2/drivers/scsi/sr.c linux/drivers/scsi/sr.c
--- /opt/kernel/linux-2.4.4-pre2/drivers/scsi/sr.c	Mon Feb 19 19:25:17 2001
+++ linux/drivers/scsi/sr.c	Mon Apr  9 09:18:46 2001
@@ -262,7 +262,7 @@
 static int sr_scatter_pad(Scsi_Cmnd *SCpnt, int s_size)
 {
 	struct scatterlist *sg, *old_sg = NULL;
-	int i, fsize, bsize, sg_ent;
+	int i, fsize, bsize, sg_ent, sg_count;
 	char *front, *back;
 
 	back = front = NULL;
@@ -290,17 +290,24 @@
 	/*
 	 * extend or allocate new scatter-gather table
 	 */
-	if (SCpnt->use_sg)
+	sg_count = SCpnt->use_sg;
+	if (sg_count)
 		old_sg = (struct scatterlist *) SCpnt->request_buffer;
 	else {
-		SCpnt->use_sg = 1;
+		sg_count = 1;
 		sg_ent++;
 	}
 
-	SCpnt->sglist_len = ((sg_ent * sizeof(struct scatterlist)) + 511) & ~511;
-	if ((sg = scsi_malloc(SCpnt->sglist_len)) == NULL)
+	i = ((sg_ent * sizeof(struct scatterlist)) + 511) & ~511;
+	if ((sg = scsi_malloc(i)) == NULL)
 		goto no_mem;
 
+	/*
+	 * no more failing memory allocs possible, we can safely assign
+	 * SCpnt values now
+	 */
+	SCpnt->sglist_len = i;
+	SCpnt->use_sg = sg_count;
 	memset(sg, 0, SCpnt->sglist_len);
 
 	i = 0;


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: CDROM troubles -- some progress, problem remains
  2001-05-06 22:01   ` Jens Axboe
@ 2001-05-06 23:17     ` Phil Stracchino
  2001-05-09 17:54       ` CDROM troubles -- followup Phil Stracchino
  0 siblings, 1 reply; 5+ messages in thread
From: Phil Stracchino @ 2001-05-06 23:17 UTC (permalink / raw)
  To: Linux-KERNEL

On Mon, May 07, 2001 at 12:01:16AM +0200, Jens Axboe wrote:
> On Sun, May 06 2001, Phil Stracchino wrote:
> > On Sun, May 06, 2001 at 03:05:00AM -0700, Phil Stracchino wrote:
> > > Hey folks,
> > > I'm seeing a problem with mounting CDs using a Toshiba XM-6401TA CDROM
> > > drive attached to an Adaptec AHA1542CF controller (scsi1) on kernel 2.4.3
> > > and 2.4.4.  The behavior seems to be fairly consistent as follows:
> > > 
> > > first mount and unmount works normally, no unusual events logged
> > > second mount and unmount works normally, no unusual events logged
> > > third mount locks up the machine.  looks like a kernel panic.
> > > 
> > > Any ideas?
> > 
> > 
> > Panic is confirmed.  This time, it lived long enough to log:
> >  
> > May  6 14:05:05 babylon5 kernel: Kernel panic: scsi_free:Bad offset
> > 
> > Since it involves the CDROM, the aha1542 driver is implicated.  Why it's
> > getting a bad offset, I don't understand enough about the SCSI drivers to
> > know; all the scsi_free calls in aha1542.c look identical to me.
> >  
> > Would any Linux SCSI gurus care to let me know any diagnostic procedures
> > recommended for nailing this one?
> 
> The panic should be fixed with attached patch.


The patch does indeed seem to prevent the panic, but not the underlying
problem.  Here's the results of a series of mount/umount operations after
applying the patch:

	*** CD inserted
VFS: Disk change detected on device sr(11,0)
	*** first mount (succeeded)
ISO 9660 Extensions: RRIP_1991A
	*** second mount (succeeded)
ISO 9660 Extensions: RRIP_1991A
	*** third mount (succeeded)
ISO 9660 Extensions: RRIP_1991A
	*** fourth and subsequent mounts failed
sr: ran out of mem for scatter pad
 I/O error: dev 0b:00, sector 252
isofs_read_super: bread failed, dev=0b:00, iso_blknum=63, block=126
sr: ran out of mem for scatter pad
 I/O error: dev 0b:00, sector 0
sr: ran out of mem for scatter pad
 I/O error: dev 0b:00, sector 64
sr: ran out of mem for scatter pad
 I/O error: dev 0b:00, sector 0
	*** the last manual mount attempt
sr: ran out of mem for scatter pad
 I/O error: dev 0b:00, sector 64
	*** at this point I logged out, then logged back in as a different
	    user
Warning - running *really* short on DMA buffers
Warning - running *really* short on DMA buffers
Warning - running *really* short on DMA buffers
Warning - running *really* short on DMA buffers
Warning - running *really* short on DMA buffers
Warning - running *really* short on DMA buffers
Warning - running *really* short on DMA buffers
Warning - running *really* short on DMA buffers
Warning - running *really* short on DMA buffers
Warning - running *really* short on DMA buffers
Warning - running *really* short on DMA buffers
sr: ran out of mem for scatter pad
 I/O error: dev 0b:00, sector 0
sr: ran out of mem for scatter pad
 I/O error: dev 0b:00, sector 64
Warning - running *really* short on DMA buffers
Warning - running *really* short on DMA buffers
Warning - running *really* short on DMA buffers
Warning - running *really* short on DMA buffers
Warning - running *really* short on DMA buffers
Warning - running *really* short on DMA buffers
Warning - running *really* short on DMA buffers
Warning - running *really* short on DMA buffers
Warning - running *really* short on DMA buffers
Warning - running *really* short on DMA buffers
Warning - running *really* short on DMA buffers
Warning - running *really* short on DMA buffers
Warning - running *really* short on DMA buffers
Warning - running *really* short on DMA buffers
Warning - running *really* short on DMA buffers

The kernel is continuing to spew these warnings.  At the time of finishing
this message, there are now 51 of them.



-- 
 Linux Now!   ..........Because friends don't let friends use Microsoft.
 phil stracchino   --   the renaissance man   --   mystic zen biker geek
    Vr00m:  2000 Honda CBR929RR   --   Cage:  2000 Dodge Intrepid R/T
 Previous vr00mage:  1986 VF500F (sold), 1991 VFR750F3 (foully murdered)

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: CDROM troubles -- followup
  2001-05-06 23:17     ` CDROM troubles -- some progress, problem remains Phil Stracchino
@ 2001-05-09 17:54       ` Phil Stracchino
  0 siblings, 0 replies; 5+ messages in thread
From: Phil Stracchino @ 2001-05-09 17:54 UTC (permalink / raw)
  To: Linux-KERNEL

On Sun, May 06, 2001 at 04:17:01PM -0700, Phil Stracchino wrote:
> The patch does indeed seem to prevent the panic, but not the underlying
> problem.  Here's the results of a series of mount/umount operations after
> applying the patch:
> 
> 	*** CD inserted
> VFS: Disk change detected on device sr(11,0)
> 	*** first mount (succeeded)
> ISO 9660 Extensions: RRIP_1991A
> 	*** second mount (succeeded)
> ISO 9660 Extensions: RRIP_1991A
> 	*** third mount (succeeded)
> ISO 9660 Extensions: RRIP_1991A
> 	*** fourth and subsequent mounts failed
> sr: ran out of mem for scatter pad
>  I/O error: dev 0b:00, sector 252
> isofs_read_super: bread failed, dev=0b:00, iso_blknum=63, block=126
> sr: ran out of mem for scatter pad
>  I/O error: dev 0b:00, sector 0
> sr: ran out of mem for scatter pad
>  I/O error: dev 0b:00, sector 64
> sr: ran out of mem for scatter pad
>  I/O error: dev 0b:00, sector 0
> 	*** the last manual mount attempt
> sr: ran out of mem for scatter pad
>  I/O error: dev 0b:00, sector 64


I have just updated to kernel 2.4.4-ac6 and modutils-2.4.6.  While the
sr-scatter patch alone did not fix this problem, after uupgrading to -ac6,
the problem no longer appears to be present.  


-- 
 Linux Now!   ..........Because friends don't let friends use Microsoft.
 phil stracchino   --   the renaissance man   --   mystic zen biker geek
    Vr00m:  2000 Honda CBR929RR   --   Cage:  2000 Dodge Intrepid R/T
 Previous vr00mage:  1986 VF500F (sold), 1991 VFR750F3 (foully murdered)

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2001-05-09 17:54 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-05-06 10:05 CDROM troubles Phil Stracchino
2001-05-06 21:42 ` Phil Stracchino
2001-05-06 22:01   ` Jens Axboe
2001-05-06 23:17     ` CDROM troubles -- some progress, problem remains Phil Stracchino
2001-05-09 17:54       ` CDROM troubles -- followup Phil Stracchino

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox