Andries.Brouwer | 1 Sep 01:29 2002
Picon
Picon

Feiya 5-in-1 Card Reader

I have a USB 5-in-1 Card Reader, that will read CF and SM and SD/MMC.
Under Linux it appears as three SCSI devices.
For today, the report is on the CF part.

The CF part works fine under ordinary usb-storage SCSI simulation,
with one small problem: 8 and 32 MB cards, that are detected as
having 15872 and 63488 sectors by other readers, are detected as
having 15873 and 63489 sectors by this Feiya reader
(0x090c / 0x1132).
In the good old days probably nobody would have noticed, but these
days the partition reading code also wants to read the last sector.
This results in the SCSI code taking the device off line:

[USB storage does a READ_10, which fails since the sector is past
the end of the disk. Then it tries a READ_6 and nothing ever happens,
probably because the device does not support READ_6. Then the
error handler does an abort which triggers some bugs in scsiglue.c
and transport.c, then the error handler does a device reset, then
a host reset, then a bus reset, and finally the device is taken offline.]

The patch below does not address any bugs in the SCSI error code
(a big improvement would be just to rip it all out - this error code
never achieves anything useful but has crashed many a machine)
and does not fix the USB code either.
It just adds a flag to the unusual_devices section mentioning that
this device (my revision is 1.00) has this bug.

Without the patch the kernel crashes, or insmod usb-storage hangs.
With the patch the CF part of the device works perfectly.

(Continue reading)

Andries.Brouwer | 2 Sep 02:41 2002
Picon
Picon

[PATCH] MODE SENSE in sd.c; sddr09.c

In sd.c we call MODE SENSE (6) in order to find out whether the
device is write protected. The info we need is in byte 2, the
header of the MODE SENSE answer, but in the request we have to
specify (i) what page(s) we want, and (ii) how many bytes we want.

Long ago we asked for 12 bytes from page 1 (Daniel Roche, 1.3.35).
Matthew Dharm made this 8 bytes from page 3F (all pages), patch-2.4.0-test8.
In patch-2.4.10 the 8 was increased to 255.

I found on the one hand devices that only react to page 0
(the vendor page), and return an error for page 3F.
And on the other hand devices that are unable to handle requests
for more bytes than they actually have.

So, it seems that the cautious way to ask for MODE SENSE data is
to first ask for the header only, see how much is available,
and then ask for everything.

The patch below first separates out the MODE SENSE call,
and then tries it three times: on all pages (3F), only the first
four bytes; on the vendor page (0), only the first four bytes;
on all pages (3F), 255 bytes.

This should be at least as robust as our current code.
I tried it on 8 SCSI devices (of which 2 fail under 2.5.33)
and found no problems.

Below - maybe I should have sent it in a separate mail -
a diff of usb/storage/sddr09.c teaching the code there
how to return less than a full page.
(Continue reading)

Rusty Russell | 2 Sep 04:54 2002
Picon

[PATCH] 2.5.33 __NO_VERSION__ useless since 2.3

....but people keep copying it.  Pointed out by Keith Owens.

Please apply your pieces and forward to Linus next update.

Yes, I'm getting lazy,
Trivial Rusty.

Attachment (remove_no_version.patch.2.5.33.gz): application/octet-stream, 15 KiB
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
Rob Turk | 2 Sep 13:00 2002
Picon

Re: [PATCH] MODE SENSE in sd.c; sddr09.c

<Andries.Brouwer <at> cwi.nl> wrote in message
news:cistron.UTC200209020041.g820fGS22828.aeb <at> smtp.cwi.nl...
> In sd.c we call MODE SENSE (6) in order to find out whether the
> device is write protected. The info we need is in byte 2, the
> header of the MODE SENSE answer, but in the request we have to
> specify (i) what page(s) we want, and (ii) how many bytes we want.
>
> Long ago we asked for 12 bytes from page 1 (Daniel Roche, 1.3.35).
> Matthew Dharm made this 8 bytes from page 3F (all pages),
patch-2.4.0-test8.
> In patch-2.4.10 the 8 was increased to 255.
>
> I found on the one hand devices that only react to page 0
> (the vendor page), and return an error for page 3F.
> And on the other hand devices that are unable to handle requests
> for more bytes than they actually have.
>
> So, it seems that the cautious way to ask for MODE SENSE data is
> to first ask for the header only, see how much is available,
> and then ask for everything.
>
> The patch below first separates out the MODE SENSE call,
> and then tries it three times: on all pages (3F), only the first
> four bytes; on the vendor page (0), only the first four bytes;
> on all pages (3F), 255 bytes.
>

Andries,

Would it be possible to move away from using 'standard' 255 bytes? Many SCSI
(Continue reading)

Andries Brouwer | 2 Sep 14:38 2002
Picon
Picon

Re: [PATCH] MODE SENSE in sd.c; sddr09.c

On Mon, Sep 02, 2002 at 01:00:39PM +0200, Rob Turk wrote:

> > The patch below first separates out the MODE SENSE call,
> > and then tries it three times: on all pages (3F), only the first
> > four bytes; on the vendor page (0), only the first four bytes;
> > on all pages (3F), 255 bytes.
> 
> Would it be possible to move away from using 'standard' 255 bytes? Many SCSI
> device don't like requests for odd byte counts on 16-bit SCSI busses, and
> IDE isn't too crazy about it either. How about asking for 254 instead??

Well, as you can see I did move away from the 255. I ask for 4 bytes.
Only if that fails do I fall back on what we do today.

Andries
-
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

James Bottomley | 3 Sep 16:35 2002

Re: aic7xxx sets CDR offline, how to reset?

> Doug Ledford writes:
> 
>  > took the device off line.  So, in short, the mid layer isn't waiting
> long   > enough, or when it gets sense indicated not ready it needs to
> implement a   > waiting queue with a timeout to try rekicking things a
> few times and don't   > actually mark the device off line until a longer
> period of time has   > elasped without the device coming back.
> 
> There is a kernel config CONFIG_AIC7XXX_RESET_DELAY_MS (default 15s).
> Would increasing it help?

Justin Gibbs writes:
> This currently only effects the initial bus reset delay.  If the
> driver holds off commands after subsequent bus resets, it can cause
> undeserved timeouts on the commands it has intentionally deferred.
> The mid-layer has a 5 second delay after bus resets, but I haven't
> verified that this is honored correctly during error recovery.

I'm planning a major re-write of this area in the error handler.  The way I 
think it should go is:

1) Quiesce host (set in_recovery flag)
2) Suspend active timers on this host
3) Proceed down the error correction track (eliminate abort and go down 
device, bus and host resets and finally set the device offline).
5) On each error recovery wait out a recovery timer for the device to become 
active before talking to it again.  Send all affected commands back to the 
block layer to await reissue (note: it would now be illegal for commands to 
lie to the mid layer and say they've done the reset when they haven't).
6) issue a TUR using a command allocated to the eh for that purpose.  Process 
(Continue reading)

James Bottomley | 3 Sep 16:57 2002

Re: [PATCH] Re: GFP_ATOMIC allocations...

patmans <at> us.ibm.com said:
> How about with printk instead of BUG_ON? BUG_ON is better in the long
> run, but I would rather printk for now. 

I'd still rather use BUG_ON, if we change from GFP_ATOMIC to GFP_KERNEL, since 
we're guaranteeing to kmalloc that we have a user context if it needs to 
sleep.  Otherwise things that shouldn't work will be fine until the system 
runs low on memory an then they'll mysteriously panic with "scheduling in 
interrupt".  It's the job of the caller to kmalloc to verify that it is 
running in a context that can sleep in low memory situations.

A printk is fine for diagnostic purposes, but I bet someone who has a problem device won't report the issue
until they see a panic.

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

Pete Zaitcev | 3 Sep 18:07 2002
Picon

Re: GFP_ATOMIC allocations...

> Date: Fri, 30 Aug 2002 09:22:57 -0700
> From: Patrick Mansfield <patmans <at> us.ibm.com>

>[...]
> Do we really call scan_scsis and scsi_build_commandblocks while not in user
> context? Who is the caller (to scsi_register_host)?
> 
> Here is Pete's response saying he found such a case, but not where:

I did a call graph, but I discarded it since. IIRC it showed
some paths, but perhaps I made a mistake. Please ignore it.

The "fix" did not go anywhere, actually. Arjan explained that
if a box runs out of atomics, it's bad anyway. We reduced the
queue size in the driver that the guy used.

-- Pete
-
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

rwhron | 3 Sep 20:06 2002
Picon
Picon

[patch] qlogic "this should not happen"

Patch tested on 2.5.31, 2.5.31-mm1, 2.5.32-mm1, 2.5.32-mm2.

Without patch, 2.5.x during heavy benchmark/stress testing
eventually locks up with these final messages:

kernel: qlogicfc0 : no handle slots, this should not happen.
kernel: hostdata->queued is 6, in_ptr: 7d

Derived from Doug Ledford's patch:
http://marc.theaimsgroup.com/?l=linux-kernel&m=103005703808312&w=2
and Eric Weigle's patch:
http://marc.theaimsgroup.com/?l=linux-kernel&m=103005790509079&w=2

2.5.33 locked up without the patch.  

diff -ruN linux-2.5.33/drivers/scsi/qlogicfc.c linux/drivers/scsi/qlogicfc.c
--- linux-2.5.33/drivers/scsi/qlogicfc.c        2002-07-24 19:09:03.000000000 -0400
+++ linux/drivers/scsi/qlogicfc.c       2002-09-01 16:44:33.000000000 -0400
 <at>  <at>  -1342,18 +1342,11  <at>  <at> 

        num_free = QLOGICFC_REQ_QUEUE_LEN - REQ_QUEUE_DEPTH(in_ptr, out_ptr);
        num_free = (num_free > 2) ? num_free - 2 : 0;
-       host->can_queue = hostdata->queued + num_free;
+       host->can_queue = host->host_busy + num_free;
        if (host->can_queue > QLOGICFC_REQ_QUEUE_LEN)
                host->can_queue = QLOGICFC_REQ_QUEUE_LEN;
        host->sg_tablesize = QLOGICFC_MAX_SG(num_free);

-       /* this is really gross */
-       if (host->can_queue <= host->host_busy){
(Continue reading)

Doug Ledford | 3 Sep 20:23 2002
Picon

Re: aic7xxx sets CDR offline, how to reset?

On Tue, Sep 03, 2002 at 09:35:02AM -0500, James Bottomley wrote:
> 
> 1) Quiesce host (set in_recovery flag)

Right.

> 2) Suspend active timers on this host

Right.

> 3) Proceed down the error correction track (eliminate abort and go down 
> device, bus and host resets and finally set the device offline).

Leave abort active.  It does actually work in certain scenarios.  The CD 
burner scenario that started this thread is an example of somewhere that 
an abort should actually do the job.

> 5) On each error recovery wait out a recovery timer for the device to become 
> active before talking to it again.  Send all affected commands back to the 
> block layer to await reissue (note: it would now be illegal for commands to 
> lie to the mid layer and say they've done the reset when they haven't).
> 6) issue a TUR using a command allocated to the eh for that purpose.  Process 
> the return code (in particular, if the device says NOT READY, wait some more). 
>  Only if the TUR definitively fails proceed up the recovery chain all the way 
> to taking the device offline.

Right.

> I also plan to expose the suspend and resume timers API in some form for FC 
> drivers to use.
(Continue reading)


Gmane