James Bottomley | 1 Dec 15:24 2007

Re: [patch] SCSI: early detection of medium not present, updated


On Thu, 2007-11-29 at 15:18 -0800, Andrew Morton wrote:
> Guys, I have this marked as needed-in-2.6.24?

Could you wait on this a bit ... since it's such an old bug.  The code
in question needs to be reworked (as the comment says).  I think the
best rework is to have the caller pass in an optional struct
scsi_sense_header into scsi_test_unit_ready() instead of the hacky
media_may_be_present, so the one place that needs this will be able to
interpret the sense codes correctly.

I can do this when I get back home ... unfortunately, I'm in Aswan today
at an Internet café ... I'll be back in Cairo tomorrow, but my US system
seems to have fallen off the internet, so I might not be able to test
any patches I come up with.  Worst case, I'll be back in Chicago on
Thursday.

James

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Alan Stern | 1 Dec 16:55 2007
Picon

Re: [patch] SCSI: early detection of medium not present, updated

On Sat, 1 Dec 2007, James Bottomley wrote:

> On Thu, 2007-11-29 at 15:18 -0800, Andrew Morton wrote:
> > Guys, I have this marked as needed-in-2.6.24?
> 
> Could you wait on this a bit ... since it's such an old bug.  The code
> in question needs to be reworked (as the comment says).  I think the
> best rework is to have the caller pass in an optional struct
> scsi_sense_header into scsi_test_unit_ready() instead of the hacky
> media_may_be_present, so the one place that needs this will be able to
> interpret the sense codes correctly.
> 
> I can do this when I get back home ... unfortunately, I'm in Aswan today
> at an Internet café ... I'll be back in Cairo tomorrow, but my US system
> seems to have fallen off the internet, so I might not be able to test
> any patches I come up with.  Worst case, I'll be back in Chicago on
> Thursday.

That's fine with me.  But the optional scsi_sense_header should be 
added in two places, not just one: There's the medium-detection code in 
sr.c already in this patch, and there's the medium-detection code in 
sd.c (it was changed in my original patch but not in this one).

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(Continue reading)

Bartlomiej Zolnierkiewicz | 1 Dec 23:53 2007
Picon

Re: [PATCH 24/28] blk_end_request: changing ide normal caller (take 3)

On Saturday 01 December 2007, Kiyoshi Ueda wrote:
> This patch converts "normal" parts of ide to use blk_end_request().
> 
> Signed-off-by: Kiyoshi Ueda <k-ueda <at> ct.jp.nec.com>
> Signed-off-by: Jun'ichi Nomura <j-nomura <at> ce.jp.nec.com>
> ---
>  drivers/ide/ide-cd.c |    6 +++---
>  drivers/ide/ide-io.c |   17 ++++++-----------
>  2 files changed, 9 insertions(+), 14 deletions(-)

[...]

> Index: 2.6.24-rc3-mm2/drivers/ide/ide-io.c
> ===================================================================
> --- 2.6.24-rc3-mm2.orig/drivers/ide/ide-io.c
> +++ 2.6.24-rc3-mm2/drivers/ide/ide-io.c
>  <at>  <at>  -78,14 +78,9  <at>  <at>  static int __ide_end_request(ide_drive_t
>  		ide_dma_on(drive);
>  	}
>  
> -	if (!end_that_request_chunk(rq, uptodate, nr_bytes)) {
> -		add_disk_randomness(rq->rq_disk);
> -		if (dequeue) {
> -			if (!list_empty(&rq->queuelist))
> -				blkdev_dequeue_request(rq);
> +	if (!__blk_end_request(rq, uptodate, nr_bytes)) {
> +		if (dequeue)
>  			HWGROUP(drive)->rq = NULL;
> -		}
> -		end_that_request_last(rq, uptodate);
(Continue reading)

Bartlomiej Zolnierkiewicz | 1 Dec 23:42 2007
Picon

Re: [PATCH 26/28] blk_end_request: changing ide-cd (take 3)


Hi,

On Saturday 01 December 2007, Kiyoshi Ueda wrote:
> This patch converts ide-cd (cdrom_newpc_intr()) to use blk_end_request().
> 
> ide-cd (cdrom_newpc_intr()) has some tricky behaviors below which
> need to use blk_end_request_callback().
> Needs to:
>   1. call post_transform_command() to modify request contents

Seems like post_transform_command() call can be removed (patch below).

>   2. wait completing request until DRQ_STAT is cleared

Would be great if somebody convert cdrom_newpc_intr() to use scatterlists
also for PIO transfers (ide_pio_sector() in ide-taskfile.c should serve
as a good starting base to see how to do PIO transfers using scatterlists)
so we could get rid of partial request completions in cdrom_newpc_intr()
and just fully complete request when the transfer is done.  Shouldn't be
difficult but I guess that we can live with blk_end_request_callback() for
the time being...

> after end_that_request_first() and before end_that_request_last().
> 
> As for the second one, ide-cd will wait for the interrupt from device.
> So blk_end_request_callback() has to return without completing request
> even if no leftover in the request.
> ide-cd uses a dummy callback function, which just returns value '1',
> to tell blk_end_request_callback() about that.
(Continue reading)

Geert Uytterhoeven | 2 Dec 10:34 2007

Re: [PATCH 09/28] blk_end_request: changing ps3disk (take 3)

On Fri, 30 Nov 2007, Kiyoshi Ueda wrote:
> This patch converts ps3disk to use blk_end_request().
                                     ^^^^^^^^^^^^^^^
Patch subject and description are inconsistent with actual change.

> Signed-off-by: Kiyoshi Ueda <k-ueda <at> ct.jp.nec.com>
> Signed-off-by: Jun'ichi Nomura <j-nomura <at> ce.jp.nec.com>
> ---
>  drivers/block/ps3disk.c |    6 +-----
>  1 files changed, 1 insertion(+), 5 deletions(-)
> 
> Index: 2.6.24-rc3-mm2/drivers/block/ps3disk.c
> ===================================================================
> --- 2.6.24-rc3-mm2.orig/drivers/block/ps3disk.c
> +++ 2.6.24-rc3-mm2/drivers/block/ps3disk.c
>  <at>  <at>  -280,11 +280,7  <at>  <at>  static irqreturn_t ps3disk_interrupt(int
>  	}
>  
>  	spin_lock(&priv->lock);
> -	if (!end_that_request_first(req, uptodate, num_sectors)) {
> -		add_disk_randomness(req->rq_disk);
> -		blkdev_dequeue_request(req);
> -		end_that_request_last(req, uptodate);
> -	}
> +	__blk_end_request(req, uptodate, num_sectors << 9);
        ^^^^^^^^^^^^^^^^^

With kind regards,

Geert Uytterhoeven
(Continue reading)

Thomas Bogendoerfer | 2 Dec 11:33 2007
Picon

[UPDATED PATCH] SGIWD93: use cached memory access to make driver work on IP28

SGI IP28 machines would need special treatment (enable adding addtional
wait states) when accessing memory uncached. To avoid this pain I
changed the driver to use only cached access to memory.

Signed-off-by: Thomas Bogendoerfer <tsbogend <at> alpha.franken.de>
---

Changes to last version:

- added Kconfig change to make selection for similair SGI boxes easier

 drivers/scsi/Kconfig   |    2 +-
 drivers/scsi/sgiwd93.c |   64 +++++++++++++++++++++++++++++------------------
 2 files changed, 40 insertions(+), 26 deletions(-)

diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index a6676be..2a071b0 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
 <at>  <at>  -345,7 +345,7  <at>  <at>  config ISCSI_TCP

 config SGIWD93_SCSI
 	tristate "SGI WD93C93 SCSI Driver"
-	depends on SGI_IP22 && SCSI
+	depends on SGI_HAS_WD93 && SCSI
   	help
 	  If you have a Western Digital WD93 SCSI controller on
 	  an SGI MIPS system, say Y.  Otherwise, say N.
diff --git a/drivers/scsi/sgiwd93.c b/drivers/scsi/sgiwd93.c
index eef8275..e64ddee 100644
(Continue reading)

James Bottomley | 2 Dec 18:10 2007

Re: [patch] SCSI: early detection of medium not present, updated

On Sat, 2007-12-01 at 16:25 +0200, James Bottomley wrote:
> On Thu, 2007-11-29 at 15:18 -0800, Andrew Morton wrote:
> > Guys, I have this marked as needed-in-2.6.24?
> 
> Could you wait on this a bit ... since it's such an old bug.  The code
> in question needs to be reworked (as the comment says).  I think the
> best rework is to have the caller pass in an optional struct
> scsi_sense_header into scsi_test_unit_ready() instead of the hacky
> media_may_be_present, so the one place that needs this will be able to
> interpret the sense codes correctly.
> 
> I can do this when I get back home ... unfortunately, I'm in Aswan today
> at an Internet café ... I'll be back in Cairo tomorrow, but my US system
> seems to have fallen off the internet, so I might not be able to test
> any patches I come up with.  Worst case, I'll be back in Chicago on
> Thursday.

Actually, the night train is a good place to do coding.  I know this
compiles, but could someone check it out?  It's the form I think we
should do, since the ASC/ASCQ codes for esoteric conditions which we
might eventually check for are different for CDs and removable discs.

James

diff --git a/drivers/scsi/scsi_ioctl.c b/drivers/scsi/scsi_ioctl.c
index 83e1447..28b19ef 100644
--- a/drivers/scsi/scsi_ioctl.c
+++ b/drivers/scsi/scsi_ioctl.c
 <at>  <at>  -244,7 +244,7  <at>  <at>  int scsi_ioctl(struct scsi_device *sdev, int cmd, void __user *arg)
 		return scsi_set_medium_removal(sdev, SCSI_REMOVAL_ALLOW);
(Continue reading)

Alan Stern | 2 Dec 21:02 2007
Picon

Re: [patch] SCSI: early detection of medium not present, updated

On Sun, 2 Dec 2007, James Bottomley wrote:

> Actually, the night train is a good place to do coding.  I know this
> compiles, but could someone check it out?  It's the form I think we
> should do, since the ASC/ASCQ codes for esoteric conditions which we
> might eventually check for are different for CDs and removable discs.

This part is puzzling:

> +	/* try to eat the UNIT_ATTENTION if there are enough retries */
> +	do {
> +		result = scsi_execute_req(sdev, cmd, DMA_NONE, NULL, 0, sshdr,
> +					  timeout, retries);
> +	} while ((driver_byte(result) & DRIVER_SENSE) &&
> +		 sshdr && sshdr->sense_key == UNIT_ATTENTION &&
> +		 --retries);

For one thing, you've using retries to control both an outer loop and 
an inner loop -- meaning the total number of attempts could be on the 
order of retries**2.

For another, why do you want to swallow a UNIT_ATTENTION?  Shouldn't 
that be up to the code calling scsi_test_unit_ready()?

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Michael Cree | 2 Dec 21:53 2007
Picon

Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha

On 1/12/2007, at 11:42 AM, Andrew Morton wrote:
> On Sat, 01 Dec 2007 11:30:01 +1300
> Michael Cree <mcree <at> orcon.net.nz> wrote:
>
>> Bob Tracy wrote:
>>> Andrew Morton wrote:
>>>> Could be something change in sysfs.  Please double-check the config
>>>> options, make sure that something important didn't get disabled.
>>>>
>>>  Here's
>>> hoping someone else is seeing this or can replicate it in the  
>>> meantime.
>>
>> Snap.
>>
>> 2.6.24-rc2 works fine.   2.6.24-rc3 boots on Alpha but once /dev is
>> populated no partitions of the scsi sub-system are seen.  Looks  
>> like ide
>> sub-system similarly affected.

[snip]

>> eth0: Digital DS21142/43 Tulip rev 65 at Port 0x200009400,
>> 08:00:2b:87:4c:b0, IRQ 45.
>> Linux video capture interface: v2.00
>> scsi_id[402]: scsi_id: unable to access '/block'
>
> I guess this is where things go bad.

Yes, that is what I thought too.
(Continue reading)

Bob Tracy | 3 Dec 02:17 2007

Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha

Michael Cree wrote:
> On 1/12/2007, at 11:42 AM, Andrew Morton wrote:
> > On Sat, 01 Dec 2007 11:30:01 +1300
> > Michael Cree <mcree <at> orcon.net.nz> wrote:
> >
> >> Bob Tracy wrote:
> >>>  Here's
> >>> hoping someone else is seeing this or can replicate it in the  
> >>> meantime.
> >>
> >> Snap.
> >>
> >> 2.6.24-rc2 works fine.   2.6.24-rc3 boots on Alpha but once /dev is
> >> populated no partitions of the scsi sub-system are seen.  Looks  
> >> like ide sub-system similarly affected.
> 
> [snip]
> 
> >> eth0: Digital DS21142/43 Tulip rev 65 at Port 0x200009400,
> >> 08:00:2b:87:4c:b0, IRQ 45.
> >> Linux video capture interface: v2.00
> >> scsi_id[402]: scsi_id: unable to access '/block'
> >
> > I guess this is where things go bad.
> 
> Yes, that is what I thought too.

Thanks for the confirmation of the error condition.  As best I can
recall, your boot log is substantially the same as what I saw.

(Continue reading)


Gmane