Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution

[Alan Cox]

On Mon, 8 Jan 2018 11:08:36 +0100
Peter Zijlstra  wrote:

> On Fri, Jan 05, 2018 at 10:30:16PM -0800, Dan Williams wrote:
> > On Fri, Jan 5, 2018 at 6:22 PM, Eric W. Biederman  
> > wrote:  
> > > In at least one place (mpls) you are patching a fast path.  Compile out
> > > or don't load mpls by all means.  But it is not acceptable to change the
> > > fast path without even considering performance.  
> > 
> > Performance matters greatly, but I need help to identify a workload
> > that is representative for this fast path to see what, if any, impact
> > is incurred. Even better is a review that says "nope, 'index' is not
> > subject to arbitrary userspace control at this point, drop the patch."  
> 
> I think we're focussing a little too much on pure userspace. That is, we
> should be saying under the attackers control. Inbound network packets
> could equally be under the attackers control.

Inbound network packets don't come with a facility to read back and do
cache timimg. For the more general case, timing attacks on network
activity are not exactly new, and you have to mitigate them in user space
because most of them are about how many instructions you execute on each
path. The ancient classic being telling if a user exists by seeing if the
password was actually checked.

Alan

Re: [PATCH] iSCSI-target: Use common error handling code in iscsi_decode_text_input()

[Alan Cox]

On Fri, 3 Nov 2017 22:33:08 +0100
SF Markus Elfring  wrote:

> From: Markus Elfring 
> Date: Fri, 3 Nov 2017 22:20:38 +0100
> 
> Add a jump target so that a bit of exception handling can be better reused
> at the end of this function.

Why not look at what the C compiler generates before making the code less
readable ?

Alan

Re: [PATCH V8 5/5] libata: Align DMA buffer to dma_get_cache_alignment()

[Alan Cox]

> This function is called only for the PIO mode commands, so I doubt this 
> is 
> necessary...

That is true but there are platforms out there that issue disk level PIO
commands via DMA (or can do so). Indeed the Cyrix MediaGX could do that
in the 1990s but I never add support 8)

So I think it makes sense to allocate the buffers DMA aligned, but it
doesn't seem to explain the situation in this case and I think it would
be helpful to know what platform and ATA driver is tripping this and wny
they are the only people in the universe to have the problem.

Alan

Re: scsi target, likely GPL violation

[Alan Cox]

On Mon, 12 Nov 2012 09:08:43 -0500
Theodore Ts'o ty...@mit.edu wrote:

 On Sun, Nov 11, 2012 at 10:15:02AM -0500, Bradley M. Kuhn wrote:
  Andy's initial email ended with the request: Please explain.  Thus,
  Andy's email seemed designed to seek facts, which I think is a
  reasonable and good thing to do here.  Meanwhile, the facts *still*
  aren't clear here yet.
 
 ... and the statement, When did you stop beating your wife? is also
 a request for information?

Ted can you explain what this has to do with the original discussion ?
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: scsi target, likely GPL violation

[Alan Cox]

   1. Yes, I've got first hand proof of a GPL violation (in which case
  we'll then move to seeing how we can remedy this) or
   2. A genuine public apology for the libel, which I'll do my best to
  prevail on RTS to accept.
  
  Because any further discussion of unsubstantiated allegations of this
  nature exposes us all to jeopardy of legal sanction.
 
 That asks for moderation until we have a better investigation of the
 facts.  It definitely doesn't try to prejudge them or express preference
 for a specific outcome as your misquote makes out.

So how can you demand a public apology for libel or instant first hand
proof and now claim you just wanted moderation ? It's not hard to see why
your position was misinterpreted ?

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

Re: scsi target, likely GPL violation

[Alan Cox]

 For our commercial target core, we only use Linux kernel symbols that
 are not marked as GPL. In addition, we define the API between the target

And this has what meaning ?

The Linux kernel is a GPL work, any derivative work is a GPL work. The
symbol tags are just a guidance.

You do not have permission to build a non GPL derivative work of any code
I own. The licensing determination is *derivative work* not symbols
marked with _GPL. This has been stated publically by many developers many
times.

So either your work is truely not derivative of the kernel (which I find
wildly improbable) or you have a problem and since you are aware of the
complaints publically I guess probably a triple damages sized problem. But
that's one for your lawyers and whatever opinion they have on the subject.

You do btw have a second thing to consider - there are US patent grants
for some functions in the kernel that only extend to GPL code so utilising
some of the subsystems in the USA may give you other problems even if you
can somehow manage to demonstrate your work is not derivative.

 RTS OS is based on a stock Linux enterprise kernel. This Linux kernel
 has naturally the ability to load either one of our standalone
 self-contained target module versions without any modifications.

That's not the usual test for derivative work I've heard applied.

I fail to understand the maintainer question however. If you were trying
to block people adding target features that competed that would be a
different thing.

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

Re: scsi target, likely GPL violation

[Alan Cox]

On Fri, 09 Nov 2012 11:52:19 -0800
Andy Grover agro...@redhat.com wrote:

 On 11/09/2012 03:03 AM, Alan Cox wrote:
  I fail to understand the maintainer question however. If you were trying
  to block people adding target features that competed that would be a
  different thing.
 
 You think it's ok for us to have an unrepentant GPL violator as a
 subsystem maintainer??
 
 If that's really what you're saying then I think that's crazy.

If he was a GPL violator and had been shown so it would be.

However it's alleged GPL violator, and we could have the same argument
about say Nvidia or half a dozen other contributors and companies before
we get to things like the GPLv2 versus DRM question (all the necessary
scripts including the key).

But RH could always sue him, or simply provide an open alternative I
guess (or indeed let secure boot and the RHEL plans for it put him out of
business) ;)

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

[PATCH] mpt: missing break

[Alan Cox]

From: Alan Cox a...@linux.intel.com

This happens to do the right thing in all cases on fibre channel but not on
other media types

Signed-off-by: Alan Cox a...@linux.intel.com
---

 drivers/message/fusion/mptscsih.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/message/fusion/mptscsih.c 
b/drivers/message/fusion/mptscsih.c
index 0c3ced7..164afa7 100644
--- a/drivers/message/fusion/mptscsih.c
+++ b/drivers/message/fusion/mptscsih.c
@@ -792,6 +792,7 @@ mptscsih_io_done(MPT_ADAPTER *ioc, MPT_FRAME_HDR *mf, 
MPT_FRAME_HDR *mr)
 * than an unsolicited DID_ABORT.
 */
sc-result = DID_RESET  16;
+   break;
 
case MPI_IOCSTATUS_SCSI_EXT_TERMINATED: /* 0x004C */
if (ioc-bus_type == FC)

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

Re: [RESEND PATCH] scsi: make struct scsi_varlen_cdb_hdr packed

[Alan Cox]

  The alignment is fine (the offset of the u16 is 8 bytes), but
  unfortunately with the metag port of gcc, sizeof(struct
  scsi_varlen_cdb_hdr) is rounded up to a 4 byte boundary (even though the
  largest data member alignment is only 2 bytes), which is 12 bytes
  instead of 10.
 
 That sounds to be a bug in your compiler ... it shouldn't be rounding up
 structure sizes if the structure can fit in 10 bytes.  This isn't
 happening in any other architecture that I know of (otherwise we'd have
 had a reported build break).

It's not a bug for the alignment rules of the processor as far as I can
see. The architectural definition is perfectly entitled to have tail
padding in this case.

The x86 equivalent would be

struct foo {
double x;
int a;
};


which is *NOT* 12 bytes long.

It is indeed a portability bug in the scsi layer.

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

Re: [PATCH 3/3] block: add back command filter modification via sysfs

[Alan Cox]

O
 + if (!q-cmd_filter) {
 + q-cmd_filter = kmalloc(sizeof(struct blk_cmd_filter),
 + GFP_KERNEL);
 + blk_set_cmd_filter_defaults(q-cmd_filter);

Out of memory - memset - oops
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] block: add back command filter modification via sysfs

[Alan Cox]

 +ssize_t blk_filter_store(struct request_queue *q,
 +  const char *page, size_t count, int rw)
 +{
 + unsigned long okbits[BLK_SCSI_CMD_PER_LONG], *target_okbits;
 + bool set;
 + const char *p = page;
 + char *endp;
 + int start = -1, cmd;
 +
 + if (!q-cmd_filter) {
 + q-cmd_filter = kmalloc(sizeof(struct blk_cmd_filter),
 + GFP_KERNEL);
 + blk_set_cmd_filter_defaults(q-cmd_filter);
 + }
 +

This also needs CAP_SYS_RAWIO otherwise you have a capability escalation
path.

I'm not really in favour of this patch as is. It's not as flexible as
doing it with a BPF filter which if we are going to have a new API is
going to be cleaner, faster and has a clear understood API plus tools.

With BPF you can do things like enabling command A with option B on a
specific device for a certain block range.


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

[PATCH] aha152x: Allow use on 64bit systems

[Alan Cox]

From: Alan Cox a...@linux.intel.com

This is reported to work, known to work on PCMCIA and a code check shows no
problems on the other bits of the code.

Signed-off-by: Alan Cox a...@linux.intel.com
---

 drivers/scsi/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 6c810db..74bf1aa 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -444,7 +444,7 @@ config SCSI_ACARD
 
 config SCSI_AHA152X
tristate Adaptec AHA152X/2825 support
-   depends on ISA  SCSI  !64BIT
+   depends on ISA  SCSI
select SCSI_SPI_ATTRS
select CHECK_SIGNATURE
---help---

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

Re: [PATCH] scsi_error: Fix language abuse.

[Alan Cox]

On Fri, 08 Feb 2008 20:32:54 -0500
Douglas Gilbert [EMAIL PROTECTED] wrote:

 Alan Cox wrote:
  The word illegal has a precise dictionary meaning of prohibited by
  law. 
 
 Also contrary to or forbidden by official rules, regulations, etc.

The OED I have here doesn't seem to think so, however if the words are
the ones used in the T10 documentation then I'm happy to drop the patch.

Alan
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] megaraid: outb_p extermination

[Alan Cox]

From conversations with the maintainers the _p isn't needed so kill it.
That removes the last non ISA _p user from the SCSI layer to my knowledge.

Signed-off-by: Alan Cox [EMAIL PROTECTED]

diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.24-mm1/drivers/scsi/megaraid.c 
linux-2.6.24-mm1/drivers/scsi/megaraid.c
--- linux.vanilla-2.6.24-mm1/drivers/scsi/megaraid.c2008-02-06 
14:14:41.0 +
+++ linux-2.6.24-mm1/drivers/scsi/megaraid.c2008-02-06 14:35:38.0 
+
@@ -151,19 +151,19 @@
 */
if( adapter-flag  BOARD_IOMAP ) {
 
-   outb_p(adapter-mbox_dma  0xFF,
+   outb(adapter-mbox_dma  0xFF,
adapter-host-io_port + MBOX_PORT0);
 
-   outb_p((adapter-mbox_dma  8)  0xFF,
+   outb((adapter-mbox_dma  8)  0xFF,
adapter-host-io_port + MBOX_PORT1);
 
-   outb_p((adapter-mbox_dma  16)  0xFF,
+   outb((adapter-mbox_dma  16)  0xFF,
adapter-host-io_port + MBOX_PORT2);
 
-   outb_p((adapter-mbox_dma  24)  0xFF,
+   outb((adapter-mbox_dma  24)  0xFF,
adapter-host-io_port + MBOX_PORT3);
 
-   outb_p(ENABLE_MBOX_BYTE,
+   outb(ENABLE_MBOX_BYTE,
adapter-host-io_port + ENABLE_MBOX_REGION);
 
irq_ack(adapter);
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] scsi_error: Fix language abuse.

[Alan Cox]

The word illegal has a precise dictionary meaning of prohibited by
law. The error messages are therefore incorrect as so far nobody has
made SCSI violations a criminal offence.

This corrects scsi to match various other subsystems I've slowly been
ridding of this.

Pedantically-signed-off-by: Alan Cox [EMAIL PROTECTED]

diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.24-mm1/drivers/scsi/constants.c 
linux-2.6.24-mm1/drivers/scsi/constants.c
--- linux.vanilla-2.6.24-mm1/drivers/scsi/constants.c   2008-02-06 
14:14:40.0 +
+++ linux-2.6.24-mm1/drivers/scsi/constants.c   2008-02-06 14:35:16.0 
+
@@ -606,10 +606,10 @@
{0x2001, Access denied - initiator pending-enrolled},
{0x2002, Access denied - no access rights},
{0x2003, Access denied - invalid mgmt id key},
-   {0x2004, Illegal command while in write capable state},
+   {0x2004, Invalid command while in write capable state},
{0x2005, Obsolete},
-   {0x2006, Illegal command while in explicit address mode},
-   {0x2007, Illegal command while in implicit address mode},
+   {0x2006, Invalid command while in explicit address mode},
+   {0x2007, Invalid command while in implicit address mode},
{0x2008, Access denied - enrollment conflict},
{0x2009, Access denied - invalid LU identifier},
{0x200A, Access denied - invalid proxy token},
@@ -620,7 +620,7 @@
{0x2102, Invalid address for write},
{0x2103, Invalid write crossing layer jump},
 
-   {0x2200, Illegal function (use 20 00, 24 00, or 26 00)},
+   {0x2200, Invalid function (use 20 00, 24 00, or 26 00)},
 
{0x2400, Invalid field in cdb},
{0x2401, CDB decryption error},
@@ -697,7 +697,7 @@
{0x2C02, Invalid combination of windows specified},
{0x2C03, Current program area is not empty},
{0x2C04, Current program area is empty},
-   {0x2C05, Illegal power condition request},
+   {0x2C05, Invalid power condition request},
{0x2C06, Persistent prevent conflict},
{0x2C07, Previous busy status},
{0x2C08, Previous task set full status},
@@ -1014,7 +1014,7 @@
{0x6300, End of user area encountered on this track},
{0x6301, Packet does not fit in available space},
 
-   {0x6400, Illegal mode for this track},
+   {0x6400, Invalid mode for this track},
{0x6401, Invalid packet size},
 
{0x6500, Voltage fault},
@@ -1124,7 +1124,7 @@
Not Ready,/* 2: The addressed target is not ready */
Medium Error, /* 3: Data error detected on the medium */
Hardware Error,   /* 4: Controller or device failure */
-   Illegal Request,  /* 5: Error in request */
+   Invalid Request,  /* 5: Error in request */
Unit Attention,   /* 6: Removable medium was changed, or
  the target has been reset, or ... */
Data Protect, /* 7: Access to the data is blocked */
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] scsi_error: Fix language abuse.

[Alan Cox]

 http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf
 
 By a simple text search.
 
 I don't think the pedantry is worth the confusion ...

Ok so we should file a formal change request with T10 instead perhaps ?

Alan
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH rc8-mm1] hotfix libata-scsi corruption

[Alan Cox]

 However, I'd like to see if we can track the problem through the SG_IO
 direct path ... how many adjacent page bytes are corrupt?  Just a few or
 a large number (I'm wondering if it's an off by one or off by alignment
 type bug)?

Which ATA controller is involved - in theory ATA DMA is byte aligned safe
(or dword anyway) in practice I don't know if we've ever tested the non
512 byte aligned case historically for ATA just ATAPI ?

Alan
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: INITIO scsi driver fails to work properly

[Alan Cox]

Ok my attempt to get the card failed so we are going to have to do this
the hard way. See where this patch crashes and what it prints

(On top of the other patches)

diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.24-rc8-mm1/drivers/scsi/initio.c 
linux-2.6.24-rc8-mm1/drivers/scsi/initio.c
--- linux.vanilla-2.6.24-rc8-mm1/drivers/scsi/initio.c  2008-01-19 
14:22:43.0 +
+++ linux-2.6.24-rc8-mm1/drivers/scsi/initio.c  2008-01-21 14:54:48.0 
+
@@ -2537,10 +2537,12 @@
struct Scsi_Host *dev = dev_id;
unsigned long flags;
int r;
-   
+
+   printk(ISR\n);
spin_lock_irqsave(dev-host_lock, flags);
r = initio_isr((struct initio_host *)dev-hostdata);
spin_unlock_irqrestore(dev-host_lock, flags);
+   printk(ISR DONE %d\n, r);
if (r)
return IRQ_HANDLED;
else
@@ -2643,6 +2645,7 @@
struct initio_host *host = (struct initio_host *) 
cmd-device-host-hostdata;
struct scsi_ctrl_blk *cmnd;
 
+   printk(SCB QUEUE\n);
cmd-scsi_done = done;
 
cmnd = initio_alloc_scb(host);
@@ -2650,7 +2653,9 @@
return SCSI_MLQUEUE_HOST_BUSY;
 
initio_build_scb(host, cmnd, cmd);
+   printk(SCB EXEC\n);
initio_exec_scb(host, cmnd);
+   printk(SCB EXEC DONE\n);
return 0;
 }
 
@@ -2766,6 +2771,8 @@
struct scsi_cmnd *cmnd; /* Pointer to SCSI request block */
struct initio_host *host;
struct scsi_ctrl_blk *cblk;
+   
+   printk(SCB POST\n);
 
host = (struct initio_host *) host_mem;
cblk = (struct scsi_ctrl_blk *) cblk_mem;
@@ -2934,9 +2941,11 @@
 
pci_set_drvdata(pdev, shost);
 
+   printk(SAH\n);
error = scsi_add_host(shost, pdev-dev);
if (error)
goto out_free_irq;
+   printk(SSH\n);
scsi_scan_host(shost);
return 0;
 out_free_irq:
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Megaraid: Use of outb_p

[Alan Cox]

I notice the MegaRAID driver uses outb_p. Can someone at LSI confirm that
the delays between each I/O are required, and if so how long they must be.

I'm trying to sort out the use of in/outb_p and where it is unneccessary
or used for non ISA devices.

(Please cc me on the reply)
Alan

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

Re: Megaraid: Use of outb_p

[Alan Cox]

On Fri, 18 Jan 2008 13:32:12 -0700
Yang, Bo [EMAIL PROTECTED] wrote:

 Alan, 
 
 The in/outb_p in MegaRAID scsi driver is used for our old io mapped
 megaraid controller.  There are still some customers are using those old
 controller.  Please keep them.

Do they need the I/O delays. If they need a delay they should use outb
and a udelay() of the correct length. If they do not need a delay they
should use outb()

Which is the correct change to make ?

Alan
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: sata_nv does not function in kernel 2.6.20.21

[Alan Cox]

 Error -16 is EBUSY, which causes the driver load to fail due to the 
 Unable to reserve mem region message.
 
 This means that the sata_nv driver needed to use PCI BAR 6, but was 
 unable to for some reason.  Given that sata_nv uses devres like other 
 libata drivers, IMO the likely cause is outside the ATA subsystem (PCI? 
 ACPI?).

Actually it looks to me like there is something very odd going on here.
The sata_nv code checks each of the 6 resources exists (wrongly - it does
it before pcim_enable_device so the check is probably not valid). That
would report -ENODEV.

EBUSY implies all 6 resources were assigned but one couldn't be mapped.
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: INITIO scsi driver fails to work properly

[Alan Cox]

 Yes it works under 2.6.16.13.  See the beginning of this thread, i
 mention there some things about newer versions.

It worked (ish.. it has problems and always has had) before the big
updates, and according to my tester after the big update + two patches
that escaped somewhere in the process. Unfortunately my tester no longer
has the card to dig further.

The 0x0 bug was fixed a while ago but seems to have sat in -mm for a bit.
Don't know about further stuff.
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: INITIO scsi driver fails to work properly

[Alan Cox]

 Our reporter has applied patches since then and now reports the exact
 same symptoms that Filippos does. (It just hangs after loading the driver.)

Can you add me to the cc of the Red Hat bug, or give me the #
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Maybe Sorry for that but where should i write .)

[Alan Cox]

 Actually, the correct mailing list is linux-ide.  Alan Cox began working
 on the driver.  Cc'ing both.

Unless I get further info from Initio I don't expect anything to happen.
They simply don't provide enough info to write a driver.
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] scsi: Use new __dma_buffer to align sense buffer in scsi_cmnd

[Alan Cox]

On Fri, 21 Dec 2007 13:30:08 +1100
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:

 The sense buffer ins scsi_cmnd can nowadays be DMA'ed into directly
 by some low level drivers (that typically happens with USB mass
 storage).

Should that not be fixed in USB storage by using pci_alloc_coherent on the
PCI device of the hub not peeing directly into kernel space ?

It's also incomplete as a fix because I don't see what guarantees the
buffer size will always exceed cache line size

Alan
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: INITIO scsi driver fails to work properly

[Alan Cox]

 initio doesn't seem to have a maintainer...
 
 Are you able to identify any earlier kernel which worked OK?
 
 Maybe it's a new device?  If you can get the `lspci -vvxx' output
 for that device we can take a look.

If I remember rightly the fixes for this went into the scsi tree a couple
of months ago. The patch is in the -mm tree as well. No idea why its
gotten stuck as an obvious one liner.

Alan
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: INITIO scsi driver fails to work properly

[Alan Cox]

On Mon, 17 Dec 2007 16:40:53 +0200
Boaz Harrosh [EMAIL PROTECTED] wrote:

 On Mon, Dec 17 2007 at 15:05 +0200, Alan Cox [EMAIL PROTECTED] wrote:
  initio doesn't seem to have a maintainer...
 
  Are you able to identify any earlier kernel which worked OK?
 
  Maybe it's a new device?  If you can get the `lspci -vvxx' output
  for that device we can take a look.
  
  If I remember rightly the fixes for this went into the scsi tree a couple
  of months ago. The patch is in the -mm tree as well. No idea why its
  gotten stuck as an obvious one liner.
  
  Alan
  -
 You mean this one:
 http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commitdiff;h=ba2c270154cc90c9a8bfc45b7bed4cca78c75aaf
 
 It's only queued for 2.6.25 via scsi-misc.
 
 I have found another bug. (See other mail in thread). I Will wait for testing
 and submit a proper patch.

That one yes - which really should have gone straight into the main tree
as the initio driver has been broken all the time it sits queued for
future patches. It can't make the problem any worse - the driver does not
work.
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 2.6.24-rc3-mm2: Result: hostbyte=0x01 driverbyte=0x00\nend_request: I/O error

[Alan Cox]

  [  225.378426] sd 2:0:1:0: [sdb] Result: hostbyte=0x01 driverbyte=0x00
  [  225.378659] end_request: I/O error, dev sdb, sector 141295703
  [  225.390133] sd 2:0:1:0: [sdb] Result: hostbyte=0x01 driverbyte=0x00
  [  225.391988] end_request: I/O error, dev sdb, sector 141295703
  [  225.392463] sd 2:0:1:0: [sdb] Result: hostbyte=0x01 driverbyte=0x00
  [  225.392625] end_request: I/O error, dev sdb, sector 141295703
  [  225.392999] sd 2:0:1:0: [sdb] Result: hostbyte=0x01 driverbyte=0x00
  [  225.393161] end_request: I/O error, dev sdb, sector 141295703
  [  225.393571] sd 2:0:1:0: [sdb] Result: hostbyte=0x01 driverbyte=0x00
  [  225.393731] end_request: I/O error, dev sdb, sector 141295703
  [  225.394382] sd 2:0:1:0: [sdb] Result: hostbyte=0x01 driverbyte=0x00
  [  225.394544] end_request: I/O error, dev sdb, sector 141295703
  [  225.395247] sd 2:0:1:0: [sdb] Result: hostbyte=0x01 driverbyte=0x00
  [  225.395412] end_request: I/O error, dev sdb, sector 141295703
 
 I don't know whether this failure was a scsi thing or an ata thing?

The ATA layer would print diagnostics if it failed the command so I'm a
bit baffled by the report. It looks like the SCSI mid layer rejected it
before we even got it ?
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Unify sysfs filenames for firmware version

[Alan Cox]

  Management stuff always seems to be tied to a single card. It's one of
  the things that puts me off hardware RAID.
 
 There are 113 cards this driver works for in concert. Maybe my tail
 feathers are showing ;-

You might want to mention the card firmware in question run on 3 or 4
entirely different processors too

  Do the management folks actually have some ideas about what sort of
  interface they'd like in sysfs?
 
 Simple answer:
   No
 
 Detailed answer (I digress):

Linuxy answer:

Something like netlink

Alan
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Process Scheduling Issue using sg/libata

[Alan Cox]

 SFF ATA controllers are peculiar in that...
 
 1. it doesn't have reliable IRQ pending bit.
 
 2. it doesn't have reliable IRQ mask bit.
 
 3. some controllers tank the machine completely if status or data
 register is accessed differently than the chip likes.

And 4. which is a killer for a lot of RT users

An I/O cycle to a taskfile style controller generally goes at ISA type
speed down the wire to the drive and back again. The CPU is stalled for
this and there is nothing we can do about it.

 
 So, it's not like we're all dickheads.  We know it's good to take those
 out of irq handler.  The hardware just isn't very forgiving and I bet
 you'll get obscure machine lockups if the RT kernel arbitrarily pushes
 ATA PIO data transfers into kernel threads.
 
 I think doing what IDE has been doing (disabling IRQ from interrupt
 controller) is the way to go.

Agreed - at which point RT or otherwise you can push it out. If you need
to do serious (sub 1mS) ATA then also go get a non SFF controller.

Alan
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: What still uses the block layer?

[Alan Cox]

  /dev/sd-ide-b   - second IDE HDD,
  /dev/sr-sata-0  - first SATA CD-ROM,

I wouldn't try dividing those by pata v sata. You'll cause all sorts of
problems in the process because of PATA-SATA and SATA-PATA bridges.
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OOM killer gripe (was Re: What still uses the block layer?)

[Alan Cox]

 I'm sure somebody will eventually write an OLS paper or something on the 
 advisability of making swapping decisions with 4k granularity when disks 
 really want bigger I/O transactions. 

Funnily enough someone thought of that many years ago. They even added
and documented it, then they made it adjustable.

See the vm section of Documentation/filesystems/proc.txt

Alan
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: What still uses the block layer?

[Alan Cox]

 This is where we disagree.  The existence of devices you cannot stably 
 enumerate does not eliminate the existence of devices you trivially can.

trivially 

You are I assume familiar in full with EDD 3.0, EDD 1.x and the Ralf
Brown documentation on the BIOS drive mappings and tables for different
BIOSes ?

If you are then you could add EDD 1.x spport, FADT parsing and update the
EDD driver to produce links to the drives in BIOS map order. Would be
quite useful but very few people on the planet actually know all the
arcana to do this.

Alan
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [git patches] libata update

[Alan Cox]

 ACPI Exception (exoparg2-0442): AE_AML_PACKAGE_LIMIT, Index
 (0) is beyond end of object [20070126]
 ACPI Error (psparse-0537): Method parse/execution failed
 [\_SB_.PCI0.IDE0.GTM_] (Node 810100318a20), AE_AML_PACKAGE_LIMIT
 ACPI Error (psparse-0537): Method parse/execution failed
 [\_SB_.PCI0.IDE0.CHN0._GTM] (Node 8101003187c0),
 AE_AML_PACKAGE_LIMIT
 ata9: ACPI get timing mode failed (AE 0x300d)

Looks like an ACPI BIOS problem. In that situation we'll just give up on
using ACPI information

Not much else we can do as Nvidia don't document how to do a reliable
40/80 wire test and just told us to use the BIOS.
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] faster workaround

[Alan Cox]

 -static void ata_fill_sg(struct ata_queued_cmd *qc)
 +void ata_fill_sg(struct ata_queued_cmd *qc)
  {
   struct ata_port *ap = qc-ap;
   struct scatterlist *sg;
 @@ -4217,10 +4217,15 @@ int ata_check_atapi_dma(struct ata_queue
   */
  void ata_qc_prep(struct ata_queued_cmd *qc)
  {
 + struct ata_port *ap = qc-ap;
 +
   if (!(qc-flags  ATA_QCFLAG_DMAMAP))
   return;
  
 - ata_fill_sg(qc);
 + if (ap-ops-fill_sg)
 + ap-ops-fill_sg(qc);
 + else
 + ata_fill_sg(qc);
  }

Its probably better to simply make your own sil_qc_prep function for this
case rather than touch the core code.

 - .sg_tablesize   = LIBATA_MAX_PRD,
 + .sg_tablesize   = 120, /* max 15 kiB sectors ? */

If you are just fiddling with the way the data is split then
LIBATA_MAX_PRD - 1 should be totally safe)

   .cmd_per_lun= ATA_SHT_CMD_PER_LUN,
   .emulated   = ATA_SHT_EMULATED,
 - .use_clustering = ATA_SHT_USE_CLUSTERING,
 + .use_clustering = 1,

Un-needed

   .proc_name  = DRV_NAME,
 - .dma_boundary   = ATA_DMA_BOUNDARY,
 + .dma_boundary   = 0x1fff,

Ok

   .slave_configure= ata_scsi_slave_config,
   .slave_destroy  = ata_scsi_slave_destroy,
   .bios_param = ata_std_bios_param,

 + /* Errata workaround: if last segment is exactly 8K, split
 +  * into 7.5K and 512b pieces.
 +  */
 + len = le32_to_cpu(ap-prd[idx].flags_len)  0x;
 + if (len == 8192) {
 + addr = le32_to_cpu(ap-prd[idx].addr);
 + ap-prd[idx].flags_len = cpu_to_le32(15 * 512);
 +
 + idx++;
 + ap-prd[idx].addr = cpu_to_le32(addr + (15 * 512));
 + ap-prd[idx].flags_len = cpu_to_le32(512 | ATA_PRD_EOT);
 + }
 +}

And since in this approach we are merely splitting the last PRD entry in
some obscure cases we might as well do it by default as it should have no
performance impact of any note done this way.


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

Re: [PATCH 3/3] faster workaround

[Alan Cox]

 The problem is that the 3112 generates Data FIS's of a size other than a 
 multiple of 512 bytes.  Spec-legal, but exposed firmware bugs in many 
 early SATA drives.  Early Seagate hard drives choked when the formula 
 (sector%15)==1 was satisfied (or something along those lines).

And the 3114 is the same ?

 2) Once we identified, over time, the set of drives affected by this 
 3112 quirk (aka drives that didn't fully comply to SATA spec), the 
 debugging of corruption cases largely shifted to the standard routine: 
 update the BIOS, replace the cables/RAM/power/mainboard/slot/etc. to be 
 certain of problem location.

Except for the continued series of later SI + Nvidia chipset (mostly)
pattern which seems unanswered but also being later chips I assume
unrelated to this problem.
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: What's in linux-2.6-block.git for 2.6.24

[Alan Cox]

 Sep 18 18:50:01 treogen [   63.44] ata1.00: status: {DRDY }
 Sep 18 18:50:01 treogen [   63.44] ata1: hard resetting link

Timed out waiting for data transfers to complete that didn't. Does sound
like the device got told the wrong sized transfer.


It then falls off the bus because Jeff hasn't merged Mark Lord's DRQ
draining patch.

Alan
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] libata: slightly improved req-sense, send-diag no-ops

[Alan Cox]

 REQUEST SENSE -- as we autosense, R.S. just returns zeroes
 
 SEND DIAGNOSTIC -- our default (no-op) self-test succeeds, all
  other requests for testing fail.
 
 Signed-off-by: Jeff Garzik [EMAIL PROTECTED]

Acked-by: Alan Cox [EMAIL PROTECTED]

Possibly our default SEND_DIAGNOSTIC should turn into smart or just
return whether the drive failed the power up diagnostic ?
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] dtc: Fix typo

[Alan Cox]

Signed-off-by: Alan Cox [EMAIL PROTECTED]

(and pointed out by several people)

diff -u --exclude-from /usr/src/exclude --new-file --recursive 
linux.vanilla-2.6.23rc6-mm1/drivers/scsi/dtc.c 
linux-2.6.23rc6-mm1/drivers/scsi/dtc.c
--- linux.vanilla-2.6.23rc6-mm1/drivers/scsi/dtc.c  2007-09-18 
15:32:56.0 +0100
+++ linux-2.6.23rc6-mm1/drivers/scsi/dtc.c  2007-09-18 16:26:56.0 
+0100
@@ -242,7 +242,7 @@
if (check_signature(base + 
signatures[sig].offset, signatures[sig].string, 
strlen(signatures[sig].string))) {
addr = 
bases[current_base].address;
 #if (DTCDEBUG  DTCDEBUG_INIT)
-   printk(KERB_DEBUG scsi-dtc : 
detected board.\n);
+   printk(KERN_DEBUG scsi-dtc : 
detected board.\n);
 #endif
goto found;
}
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] eata_pio: Clean up proc handling, bracketing and use cpu_relax()

[Alan Cox]

So its ancient, its crap, but it kept showing up in my scans for stuff
that wanted fixing...

- Redo the proc code to be far cleaner
- Clean various return (0) type constructs
- Use cpu_relax()

The various waits ought to time out but thats another issue and probably
not worth solving.

Signed-off-by: Alan Cox [EMAIL PROTECTED]

diff -u --exclude-from /usr/src/exclude --new-file --recursive 
linux.vanilla-2.6.23rc6-mm1/drivers/scsi/eata_pio.c 
linux-2.6.23rc6-mm1/drivers/scsi/eata_pio.c
--- linux.vanilla-2.6.23rc6-mm1/drivers/scsi/eata_pio.c 2007-09-18 
15:14:00.0 +0100
+++ linux-2.6.23rc6-mm1/drivers/scsi/eata_pio.c 2007-09-18 16:27:03.0 
+0100
@@ -107,59 +107,44 @@
 static int eata_pio_proc_info(struct Scsi_Host *shost, char *buffer, char 
**start, off_t offset,
  int length, int rw)
 {
-static u8 buff[512];
-int size, len = 0;
-off_t begin = 0, pos = 0;
-
-if (rw)
-   return -ENOSYS;
-if (offset == 0)
-   memset(buff, 0, sizeof(buff));
+   int len = 0;
+   off_t begin = 0, pos = 0;
+
+   if (rw)
+   return -ENOSYS;
 
-size = sprintf(buffer+len, EATA (Extended Attachment) PIO driver version: 

+   len += sprintf(buffer+len, EATA (Extended Attachment) PIO driver 
version: 
   %d.%d%s\n,VER_MAJOR, VER_MINOR, VER_SUB);
-len += size; pos = begin + len;
-size = sprintf(buffer + len, queued commands: %10ld\n
+   len += sprintf(buffer + len, queued commands: %10ld\n
   processed interrupts:%10ld\n, queue_counter, int_counter);
-len += size; pos = begin + len;
-
-size = sprintf(buffer + len, \nscsi%-2d: HBA %.10s\n,
+   len += sprintf(buffer + len, \nscsi%-2d: HBA %.10s\n,
   shost-host_no, SD(shost)-name);
-len += size; 
-pos = begin + len;
-size = sprintf(buffer + len, Firmware revision: v%s\n, 
+   len += sprintf(buffer + len, Firmware revision: v%s\n, 
   SD(shost)-revision);
-len += size;
-pos = begin + len;
-size = sprintf(buffer + len, IO: PIO\n);
-len += size; 
-pos = begin + len;
-size = sprintf(buffer + len, Base IO : %#.4x\n, (u32) shost-base);
-len += size; 
-pos = begin + len;
-size = sprintf(buffer + len, Host Bus: %s\n, 
+   len += sprintf(buffer + len, IO: PIO\n);
+   len += sprintf(buffer + len, Base IO : %#.4x\n, (u32) shost-base);
+   len += sprintf(buffer + len, Host Bus: %s\n, 
   (SD(shost)-bustype == 'P')?PCI :
   (SD(shost)-bustype == 'E')?EISA:ISA );
 
-len += size; 
-pos = begin + len;
+   pos = begin + len;
 
-if (pos  offset) {
-   len = 0;
-   begin = pos;
-}
-if (pos  offset + length)
-   goto stop_output;
+   if (pos  offset) {
+   len = 0;
+   begin = pos;
+   }
+   if (pos  offset + length)
+   goto stop_output;
 
- stop_output:
-DBG(DBG_PROC, printk(2pos: %ld offset: %ld len: %d\n, pos, offset, len));
-*start=buffer+(offset-begin);   /* Start of wanted data */
-len-=(offset-begin);/* Start slop */
-if(lenlength)
-   len = length;   /* Ending slop */
-DBG(DBG_PROC, printk(3pos: %ld offset: %ld len: %d\n, pos, offset, len));
+stop_output:
+   DBG(DBG_PROC, printk(2pos: %ld offset: %ld len: %d\n, pos, offset, 
len));
+   *start = buffer + (offset - begin);   /* Start of wanted data */
+   len -= (offset - begin);/* Start slop */
+   if (len  length)
+   len = length;   /* Ending slop */
+   DBG(DBG_PROC, printk(3pos: %ld offset: %ld len: %d\n, pos, offset, 
len));
 
-return (len); 
+   return len;
 }
 
 static int eata_pio_release(struct Scsi_Host *sh)
@@ -438,7 +423,7 @@
returning DID_BUS_BUSY, done.\n, cmd-pid);
done(cmd);
cp-status = FREE;
-   return (0);
+   return 0;
}
/* FIXME: timeout */
while (!(inb(base + HA_RSTATUS)  HA_SDRQ))
@@ -452,7 +437,7 @@
Queued base %#.4lx pid: %ld 
slot %d irq %d\n, sh-base, cmd-pid, y, sh-irq));
 
-   return (0);
+   return 0;
 }
 
 static int eata_pio_abort(struct scsi_cmnd *cmd)
@@ -589,23 +574,28 @@
cp.cp_cdb[5] = 0;
 
if (eata_pio_send_command(base, EATA_CMD_PIO_SEND_CP))
-   return (NULL);
-   while (!(inb(base + HA_RSTATUS)  HA_SDRQ));
+   return NULL;
+
+   while (!(inb(base + HA_RSTATUS)  HA_SDRQ))
+   cpu_relax();
+
outsw(base + HA_RDATA, cp, cplen);
outb(EATA_CMD_PIO_TRUNC, base + HA_WCOMMAND);
for (z = 0; z  cppadlen; z++)
outw(0, base + HA_RDATA);
 
-   while (inb(base + HA_RSTATUS)  HA_SBUSY);
+   while (inb(base + HA_RSTATUS)  HA_SBUSY)
+   cpu_relax

Re: [PATCH] t128: Indent and add printk levels

[Alan Cox]

On Thu, 26 Jul 2007 11:51:08 -0600
Matthew Wilcox [EMAIL PROTECTED] wrote:

 On Thu, Jul 26, 2007 at 06:50:44PM +0100, Alan Cox wrote:
  -[4] __initdata = {{0, IRQ_AUTO}, {0, IRQ_AUTO},
  -{0 ,IRQ_AUTO}, {0, IRQ_AUTO}};
  +[4] __initdata = { {

Fair comment - fixed - will send a replacement diff later
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] t128: Indent and add printk levels

[Alan Cox]

Signed-off-by: Alan Cox [EMAIL PROTECTED]

diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.23rc1-mm1/drivers/scsi/t128.c 
linux-2.6.23rc1-mm1/drivers/scsi/t128.c
--- linux.vanilla-2.6.23rc1-mm1/drivers/scsi/t128.c 2007-07-26 
15:01:46.0 +0100
+++ linux-2.6.23rc1-mm1/drivers/scsi/t128.c 2007-07-26 15:29:47.0 
+0100
@@ -101,7 +101,7 @@
  * 14 10-12
  * 15 9-11
  */
- 
+
 /*
  * $Log: t128.c,v $
  */
@@ -123,33 +123,40 @@
 #include NCR5380.h
 
 static struct override {
-unsigned long address;
-int irq;
+   unsigned long address;
+   int irq;
 } overrides
 #ifdef T128_OVERRIDE
-[] __initdata = T128_OVERRIDE;
+[] __initdata = T128_OVERRIDE;
 #else
-[4] __initdata = {{0, IRQ_AUTO}, {0, IRQ_AUTO},
-{0 ,IRQ_AUTO}, {0, IRQ_AUTO}};
+[4] __initdata = { {
+0, IRQ_AUTO}, {
+0, IRQ_AUTO}, {
+0, IRQ_AUTO}, {
+0, IRQ_AUTO}};
 #endif
 
 #define NO_OVERRIDES ARRAY_SIZE(overrides)
 
 static struct base {
-unsigned int address;
-int noauto;
+   unsigned int address;
+   int noauto;
 } bases[] __initdata = {
-{ 0xcc000, 0}, { 0xc8000, 0}, { 0xdc000, 0}, { 0xd8000, 0}
+   {
+   0xcc000, 0}, {
+   0xc8000, 0}, {
+   0xdc000, 0}, {
+   0xd8000, 0}
 };
 
 #define NO_BASES ARRAY_SIZE(bases)
 
 static struct signature {
-const char *string;
-int offset;
+   const char *string;
+   int offset;
 } signatures[] __initdata = {
-{TSROM: SCSI BIOS, Version 1.12, 0x36},
-};
+   {
+TSROM: SCSI BIOS, Version 1.12, 0x36},};
 
 #define NO_SIGNATURES ARRAY_SIZE(signatures)
 
@@ -163,21 +170,21 @@
  *
  */
 
-void __init t128_setup(char *str, int *ints){
-static int commandline_current = 0;
-int i;
-if (ints[0] != 2) 
-   printk(t128_setup : usage t128=address,irq\n);
-else 
-   if (commandline_current  NO_OVERRIDES) {
-   overrides[commandline_current].address = ints[1];
-   overrides[commandline_current].irq = ints[2];
-   for (i = 0; i  NO_BASES; ++i)
-   if (bases[i].address == ints[1]) {
-   bases[i].noauto = 1;
-   break;
-   }
-   ++commandline_current;
+void __init t128_setup(char *str, int *ints)
+{
+   static int commandline_current = 0;
+   int i;
+   if (ints[0] != 2)
+   printk(t128_setup : usage t128=address,irq\n);
+   else if (commandline_current  NO_OVERRIDES) {
+   overrides[commandline_current].address = ints[1];
+   overrides[commandline_current].irq = ints[2];
+   for (i = 0; i  NO_BASES; ++i)
+   if (bases[i].address == ints[1]) {
+   bases[i].noauto = 1;
+   break;
+   }
+   ++commandline_current;
}
 }
 
@@ -194,100 +201,96 @@
  *
  */
 
-int __init t128_detect(struct scsi_host_template * tpnt){
-static int current_override = 0, current_base = 0;
-struct Scsi_Host *instance;
-unsigned long base;
-void __iomem *p;
-int sig, count;
-
-tpnt-proc_name = t128;
-tpnt-proc_info = t128_proc_info;
-
-for (count = 0; current_override  NO_OVERRIDES; ++current_override) {
-   base = 0;
-   p = NULL;
-
-   if (overrides[current_override].address) {
-   base = overrides[current_override].address;
-   p = ioremap(bases[current_base].address, 0x2000);
-   if (!p)
+int __init t128_detect(struct scsi_host_template *tpnt)
+{
+   static int current_override = 0, current_base = 0;
+   struct Scsi_Host *instance;
+   unsigned long base;
+   void __iomem *p;
+   int sig, count;
+
+   tpnt-proc_name = t128;
+   tpnt-proc_info = t128_proc_info;
+
+   for (count = 0; current_override  NO_OVERRIDES; ++current_override) {
base = 0;
-   } else 
-   for (; !base  (current_base  NO_BASES); ++current_base) {
+   p = NULL;
+
+   if (overrides[current_override].address) {
+   base = overrides[current_override].address;
+   p = ioremap(bases[current_base].address, 0x2000);
+   if (!p)
+   base = 0;
+   } else
+   for (; !base  (current_base  NO_BASES); 
++current_base) {
 #if (TDEBUG  TDEBUG_INIT)
-printk(scsi-t128 : probing address %08x\n, bases[current_base].address);
+   printk(KERN_DEBUG scsi-t128 : probing address 
%08x\n, bases[current_base].address);
 #endif
-   if (bases[current_base].noauto)
-   continue;
-   p = ioremap(bases[current_base].address, 0x2000);
-   if (!p)
-   continue;
-   for (sig = 0; sig  NO_SIGNATURES; ++sig) 
-   if (check_signature(p + signatures[sig].offset

[PATCH] aacraid: Resend, Fix security hole

[Alan Cox]

On the SCSI layer ioctl path there is no implicit permissions check for
ioctls (and indeed other drivers implement unprivileged ioctls). aacraid
however allows all sorts of very admin only things to be done so should
check.

Signed-off-by: Alan Cox [EMAIL PROTECTED]

diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.23rc1/drivers/scsi/aacraid/linit.c 
linux-2.6.23rc1/drivers/scsi/aacraid/linit.c
--- linux.vanilla-2.6.23rc1/drivers/scsi/aacraid/linit.c2007-07-23 
12:56:12.0 +0100
+++ linux-2.6.23rc1/drivers/scsi/aacraid/linit.c2007-07-23 
12:57:45.0 +0100
@@ -636,6 +636,8 @@
 static int aac_cfg_ioctl(struct inode *inode,  struct file *file,
unsigned int cmd, unsigned long arg)
 {
+   if (!capable(CAP_SYS_ADMIN))
+   return -EPERM;
return aac_do_ioctl(file-private_data, cmd, (void __user *)arg);
 }
 
@@ -689,6 +691,8 @@
 
 static long aac_compat_cfg_ioctl(struct file *file, unsigned cmd, unsigned 
long arg)
 {
+   if (!capable(CAP_SYS_ADMIN))
+   return -EPERM;
return aac_compat_do_ioctl((struct aac_dev *)file-private_data, cmd, 
arg);
 }
 #endif
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] dmx3191d: Coding style police

[Alan Cox]

Signed-off-by: Alan Cox [EMAIL PROTECTED]

diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.22-rc4-mm2/drivers/scsi/dmx3191d.c 
linux-2.6.22-rc4-mm2/drivers/scsi/dmx3191d.c
--- linux.vanilla-2.6.22-rc4-mm2/drivers/scsi/dmx3191d.c2007-06-07 
14:24:28.0 +0100
+++ linux-2.6.22-rc4-mm2/drivers/scsi/dmx3191d.c2007-06-14 
13:48:18.0 +0100
@@ -113,13 +113,13 @@
scsi_scan_host(shost);
return 0;
 
- out_free_irq:
+out_free_irq:
free_irq(shost-irq, shost);
- out_release_region:
+out_release_region:
release_region(io, DMX3191D_REGION_LEN);
- out_disable_device:
+out_disable_device:
pci_disable_device(pdev);
- out:
+out:
return error;
 }
 
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] dtc: Coding police and printk levels

[Alan Cox]

Seems printk levels hadn't been invented last time this driver was tidied
up.

Signed-off-by: Alan Cox [EMAIL PROTECTED]

diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.22-rc4-mm2/drivers/scsi/dtc.c 
linux-2.6.22-rc4-mm2/drivers/scsi/dtc.c
--- linux.vanilla-2.6.22-rc4-mm2/drivers/scsi/dtc.c 2007-06-07 
14:24:28.0 +0100
+++ linux-2.6.22-rc4-mm2/drivers/scsi/dtc.c 2007-06-14 13:43:37.0 
+0100
@@ -137,11 +137,9 @@
 #ifdef OVERRIDE
 [] __initdata = OVERRIDE;
 #else
-[4] __initdata = { {
-0, IRQ_AUTO}, {
-0, IRQ_AUTO}, {
-0, IRQ_AUTO}, {
-0, IRQ_AUTO}};
+[4] __initdata = { 
+   { 0, IRQ_AUTO }, { 0, IRQ_AUTO }, { 0, IRQ_AUTO }, { 0, IRQ_AUTO }
+};
 #endif
 
 #define NO_OVERRIDES ARRAY_SIZE(overrides)
@@ -176,7 +174,7 @@
  * Inputs : str - unused, ints - array of integer parameters with ints[0]
  * equal to the number of ints.
  *
-*/
+ */
 
 static void __init dtc_setup(char *str, int *ints)
 {
@@ -233,7 +231,7 @@
} else
for (; !addr  (current_base  NO_BASES); 
++current_base) {
 #if (DTCDEBUG  DTCDEBUG_INIT)
-   printk(scsi-dtc : probing address %08x\n, 
bases[current_base].address);
+   printk(KERN_DEBUG scsi-dtc : probing address 
%08x\n, bases[current_base].address);
 #endif
if (bases[current_base].noauto)
continue;
@@ -244,7 +242,7 @@
if (check_signature(base + 
signatures[sig].offset, signatures[sig].string, 
strlen(signatures[sig].string))) {
addr = 
bases[current_base].address;
 #if (DTCDEBUG  DTCDEBUG_INIT)
-   printk(scsi-dtc : detected 
board.\n);
+   printk(KERB_DEBUG scsi-dtc : 
detected board.\n);
 #endif
goto found;
}
@@ -253,7 +251,7 @@
}
 
 #if defined(DTCDEBUG)  (DTCDEBUG  DTCDEBUG_INIT)
-   printk(scsi-dtc : base = %08x\n, addr);
+   printk(KERN_DEBUG scsi-dtc : base = %08x\n, addr);
 #endif
 
if (!addr)
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ppa: Coding police and printk levels

[Alan Cox]

Add printk levels
Clean up some oddities of formatting
Fix goto labels

Signed-off-by: Alan Cox [EMAIL PROTECTED]

diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.22-rc4-mm2/drivers/scsi/ppa.c 
linux-2.6.22-rc4-mm2/drivers/scsi/ppa.c
--- linux.vanilla-2.6.22-rc4-mm2/drivers/scsi/ppa.c 2007-06-07 
14:24:28.0 +0100
+++ linux-2.6.22-rc4-mm2/drivers/scsi/ppa.c 2007-06-14 13:36:48.0 
+0100
@@ -129,11 +129,11 @@
if ((length  10)  (strncmp(buffer, recon_tmo=, 10) == 0)) {
x = simple_strtoul(buffer + 10, NULL, 0);
dev-recon_tmo = x;
-   printk(ppa: recon_tmo set to %ld\n, x);
+   printk(KERN_INFO ppa: recon_tmo set to %ld\n, x);
return length;
}
-   printk(ppa /proc: invalid variable\n);
-   return (-EINVAL);
+   printk(KERN_WARNING ppa /proc: invalid variable\n);
+   return -EINVAL;
 }
 
 static int ppa_proc_info(struct Scsi_Host *host, char *buffer, char **start, 
off_t offset, int length, int inout)
@@ -216,7 +216,7 @@
 
/* Counter expired - Time out occurred */
ppa_fail(dev, DID_TIME_OUT);
-   printk(ppa timeout in ppa_wait\n);
+   printk(KERN_WARNING ppa timeout in ppa_wait\n);
return 0;   /* command timed out */
 }
 
@@ -248,7 +248,7 @@
return;
udelay(5);
}
-   printk(ppa: ECP sync failed as data still present in FIFO.\n);
+   printk(KERN_WARNING ppa: ECP sync failed as data still present 
in FIFO.\n);
}
 }
 
@@ -328,7 +328,7 @@
break;
 
default:
-   printk(PPA: bug in ppa_out()\n);
+   printk(KERN_ERR PPA: bug in ppa_out()\n);
r = 0;
}
return r;
@@ -381,7 +381,7 @@
break;
 
default:
-   printk(PPA: bug in ppa_ins()\n);
+   printk(KERN_ERR PPA: bug in ppa_ins()\n);
r = 0;
break;
}
@@ -633,7 +633,7 @@
struct scsi_cmnd *cmd = dev-cur_cmd;
 
if (!cmd) {
-   printk(PPA: bug in ppa_interrupt\n);
+   printk(KERN_ERR PPA: bug in ppa_interrupt\n);
return;
}
if (ppa_engine(dev, cmd)) {
@@ -646,31 +646,31 @@
case DID_OK:
break;
case DID_NO_CONNECT:
-   printk(ppa: no device at SCSI ID %i\n, cmd-device-target);
+   printk(KERN_DEBUG ppa: no device at SCSI ID %i\n, 
cmd-device-target);
break;
case DID_BUS_BUSY:
-   printk(ppa: BUS BUSY - EPP timeout detected\n);
+   printk(KERN_DEBUG ppa: BUS BUSY - EPP timeout detected\n);
break;
case DID_TIME_OUT:
-   printk(ppa: unknown timeout\n);
+   printk(KERN_DEBUG ppa: unknown timeout\n);
break;
case DID_ABORT:
-   printk(ppa: told to abort\n);
+   printk(KERN_DEBUG ppa: told to abort\n);
break;
case DID_PARITY:
-   printk(ppa: parity error (???)\n);
+   printk(KERN_DEBUG ppa: parity error (???)\n);
break;
case DID_ERROR:
-   printk(ppa: internal driver error\n);
+   printk(KERN_DEBUG ppa: internal driver error\n);
break;
case DID_RESET:
-   printk(ppa: told to reset device\n);
+   printk(KERN_DEBUG ppa: told to reset device\n);
break;
case DID_BAD_INTR:
-   printk(ppa: bad interrupt (???)\n);
+   printk(KERN_WARNING ppa: bad interrupt (???)\n);
break;
default:
-   printk(ppa: bad return code (%02x)\n,
+   printk(KERN_WARNING ppa: bad return code (%02x)\n,
   (cmd-result  16)  0xff);
}
 #endif
@@ -724,8 +724,7 @@
 
if (retv) {
if (time_after(jiffies, dev-jstart + (1 * 
HZ))) {
-   printk
-   (ppa: Parallel port cable is 
unplugged!!\n);
+   printk(KERN_ERR ppa: Parallel port 
cable is unplugged.\n);
ppa_fail(dev, DID_BUS_BUSY);
return 0;
} else {
@@ -755,11 +754,9 @@
case 4: /* Phase 4 - Setup scatter/gather buffers */
if (cmd-use_sg) {
/* if many buffers are available, start filling the 
first */
-   cmd-SCp.buffer =
-   (struct scatterlist *) cmd-request_buffer;
+   cmd-SCp.buffer = (struct scatterlist *) 
cmd-request_buffer;
cmd-SCp.this_residual = cmd

Re: [patch 4/6] ps3: Disk Storage Driver

[Alan Cox]

  Any particular reason why this is done as a separate block device driver
  rather than as SCSI?
 
 Because no new fake SCSI drivers are accepted anymore.

Where did drivers/ata come from ;)

How about making it a fake ata driver if James is being fussy 8)
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch 4/6] ps3: Disk Storage Driver

[Alan Cox]

 That sounds like a good idea for my virtual I/O case on
 Niagara too actually :-)

It was actually meant semi-seriously in that drivers/ata sits on top of
the abstract parts of drivers/scsi which James keeps asking for someone to
get split properly off and which would sort all these out.

 Another quirk I have to deal with is that under LDOMs you
 can export full disks and also just slices.  So I'll have
 to get down into the partition machinery to support that
 somehow.

If your slices don't fit the PC worldview you might want to look at
dmraid and just use device mapper to handle them. It is a lot more
flexible and we could actually bin all our partition code and use this
but for back compatibility.

Alan
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/5] SCSI/initio fixes, cleanups, PCI API support

[Alan Cox]

On Sun, 27 May 2007 10:52:00 -0400
Jeff Garzik [EMAIL PROTECTED] wrote:

 
 This patchset presents the path to PCI API support in the initio driver.
 
 But the first patch really begs the question:  Has this driver really
 been broken since Oct 2003?  If so, let's just delete it.

Jeff. I (and Christoph) have already done a complete initio overhaul
including the PCI API and Hotplug and submitted it.

Has it been broken - no. The value was always NULL so it always worked on
x86-32. Its a sucky driver but its not defunct.
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [scsi] Remove __GFP_DMA

[Alan Cox]

  That didn't used to work right on the AMD boards when I tried it last as
  we ended up with a buffer that was mapped by the IOMMU for some reason
  and that was not below 2GB.
 
 The physical address you mean? If that is still happening then it needs 
 to get fixed. The allocation should not succeed if it can't provide 
 memory that's inside the DMA mask for the device..

But the allocation can succeed - using GFP_DMA at least you can do it as
you get memory below 2^24 you don't need to map via the IOMMU
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [scsi] Remove __GFP_DMA

[Alan Cox]

On Wed, 23 May 2007 15:17:08 -0400
Salyzyn, Mark [EMAIL PROTECTED] wrote:

 The 31 bit limit for some of these cards is a problem, we currently only
 do __GFP_DMA for bounce buffer sg elements allocated for user supplied
 references in ioctls.
 
 I figure we should be using pci_alloc_consistent calls for these
 allocations to more accurately acquire memory within the 31 bit limit if
 necessary, we could switch to these to remove the need for the __GFP_DMA
 flag in the aacraid driver?

That didn't used to work right on the AMD boards when I tried it last as
we ended up with a buffer that was mapped by the IOMMU for some reason
and that was not below 2GB.

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

Re: why does x86 make defconfig build a single, lonely module?

[Alan Cox]

On Mon, 14 May 2007 19:29:12 +0200 (MEST)
Jan Engelhardt [EMAIL PROTECTED] wrote:

 
 On May 13 2007 12:48, James Bottomley wrote:
 
  Why does ATA select SCSI anyway? Surely PATA doesn't require it?
 
 That's a bit offtopic and to the wrong list.
 
 libata-pata does require SCSI ...
 
 And in the long run, that SCSI parts which are actually used by ATA
 should be factored out so that SCSI really is SCSI again, and not
 Common layer for SCSI, SATA and PATA or so.

The common layer for the queueing is one thing, but the ATAPI devices
(CD-ROM etc) are SCSI commands over an ATA bus. A subset of SCSI commands
badly over an ATA bus but SCSI commands nevertheless - so they have the
same basic dependancies as USB storage does.

Alan
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: HDIO_DRIVE_CMD and hdparm

[Alan Cox]

   - SCSI doesn't handle HDIO_DRIVE_CMD(null), and returns EINVAL
 = fine for hdparm
   - If a block device doesn't support the ioctl, blkdev_driver_ioctl() returns
 ENOTTY
 = hdparm error message

Those are both correct
-ENOTTY I don't know this ioctl
-EINVAL I know this ioctl, usage wrong
0   Hey it worked

ENOIOCTLCMD Internal (not user exposed)
for fallthrough

ENOSYS  CD-ROM being weird.

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

[PATCH]: Fix old SCSI adapter crashes with CD-ROM

[Alan Cox]

The CD-ROM layer doesn't bounce requests for old ISA controllers (and
nor should it). However they get injected into the SCSI layer via
sr_ioctl which also doesn't bounce them and SCSI then passes the buffer
along to a device with unchecked_isa_dma set which either panics or
truncates the buffer to 24bits.

According to Jens the right long term fix is for the CD layer to route
the requests differently but in the mean time this has been tested by a
victim and verified to sort the problem out. For the other 99.9% of users
it's a no-op and doesn't bounce data.

Signed-off-by: Alan Cox [EMAIL PROTECTED]

diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.21-rc6-mm1/drivers/scsi/sr_ioctl.c 
linux-2.6.21-rc6-mm1/drivers/scsi/sr_ioctl.c
--- linux.vanilla-2.6.21-rc6-mm1/drivers/scsi/sr_ioctl.c2007-04-12 
14:14:45.0 +0100
+++ linux-2.6.21-rc6-mm1/drivers/scsi/sr_ioctl.c2007-05-01 
14:23:40.0 +0100
@@ -187,9 +187,10 @@
struct scsi_sense_hdr sshdr;
int result, err = 0, retries = 0;
struct request_sense *sense = cgc-sense;
-
+   void *zebedee = cgc-buffer;
+   
SDev = cd-device;
-
+   
if (!sense) {
sense = kmalloc(SCSI_SENSE_BUFFERSIZE, GFP_KERNEL);
if (!sense) {
@@ -197,7 +198,22 @@
goto out;
}
}
-
+   
+   if (cgc-buflen  cd-device-host-unchecked_isa_dma) {
+   switch(cgc-data_direction) {
+   case DMA_NONE:
+   break;
+   case DMA_FROM_DEVICE:
+   case DMA_TO_DEVICE:
+   zebedee = kmalloc(cgc-buflen, 
GFP_KERNEL|GFP_DMA);
+   if (zebedee ==NULL) {
+   err = -ENOMEM;
+   goto out;
+   }
+   }
+   if (cgc-data_direction == DMA_TO_DEVICE)
+   memcpy(zebedee, cgc-buffer, cgc-buflen);
+   }
   retry:
if (!scsi_block_when_processing_errors(SDev)) {
err = -ENODEV;
@@ -206,10 +222,16 @@
 
memset(sense, 0, sizeof(*sense));
result = scsi_execute(SDev, cgc-cmd, cgc-data_direction,
- cgc-buffer, cgc-buflen, (char *)sense,
+ zebedee, cgc-buflen, (char *)sense,
  cgc-timeout, IOCTL_RETRIES, 0);
 
scsi_normalize_sense((char *)sense, sizeof(*sense), sshdr);
+   
+   if (zebedee != cgc-buffer) {
+   if (cgc-data_direction == DMA_FROM_DEVICE)
+   memcpy(cgc-buffer, zebedee, cgc-buflen);
+   kfree(zebedee); /* Time for bed */
+   }
 
/* Minimal error checking.  Ignore cases we know about, and report the 
rest. */
if (driver_byte(result) != 0) {
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH]: Fix old SCSI adapter crashes with CD-ROM

[Alan Cox]

On Tue, 8 May 2007 17:03:35 +0100
Alan Cox [EMAIL PROTECTED] wrote:

 The CD-ROM layer doesn't bounce requests for old ISA controllers (and
 nor should it). However they get injected into the SCSI layer via
 sr_ioctl which also doesn't bounce them and SCSI then passes the buffer
 along to a device with unchecked_isa_dma set which either panics or
 truncates the buffer to 24bits.

Umm duh there's a memory leak in an error case there still. Please
discard and I'll post a new one shortly
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH]: Fix old SCSI adapter crashes with CD-ROM (take 2)

[Alan Cox]

The CD-ROM layer doesn't bounce requests for old ISA controllers (and
nor should it). However they get injected into the SCSI layer via
sr_ioctl which also doesn't bounce them and SCSI then passes the buffer
along to a device with unchecked_isa_dma set which either panics or
truncates the buffer to 24bits.

According to Jens the right long term fix is for the CD layer to route
the requests differently but in the mean time this has been tested by a
victim and verified to sort the problem out. For the other 99.9% of users
it's a no-op and doesn't bounce data.

Signed-off-by: Alan Cox [EMAIL PROTECTED]

diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.21-rc6-mm1/drivers/scsi/sr_ioctl.c 
linux-2.6.21-rc6-mm1/drivers/scsi/sr_ioctl.c
--- linux.vanilla-2.6.21-rc6-mm1/drivers/scsi/sr_ioctl.c2007-04-12 
14:14:45.0 +0100
+++ linux-2.6.21-rc6-mm1/drivers/scsi/sr_ioctl.c2007-05-08 
16:55:01.446661608 +0100
@@ -187,9 +187,10 @@
struct scsi_sense_hdr sshdr;
int result, err = 0, retries = 0;
struct request_sense *sense = cgc-sense;
-
+   void *zebedee = cgc-buffer;
+   
SDev = cd-device;
-
+   
if (!sense) {
sense = kmalloc(SCSI_SENSE_BUFFERSIZE, GFP_KERNEL);
if (!sense) {
@@ -197,7 +198,22 @@
goto out;
}
}
-
+   
+   if (cgc-buflen  cd-device-host-unchecked_isa_dma) {
+   switch(cgc-data_direction) {
+   case DMA_NONE:
+   break;
+   case DMA_FROM_DEVICE:
+   case DMA_TO_DEVICE:
+   zebedee = kmalloc(cgc-buflen, 
GFP_KERNEL|GFP_DMA);
+   if (zebedee ==NULL) {
+   err = -ENOMEM;
+   goto out;
+   }
+   }
+   if (cgc-data_direction == DMA_TO_DEVICE)
+   memcpy(zebedee, cgc-buffer, cgc-buflen);
+   }
   retry:
if (!scsi_block_when_processing_errors(SDev)) {
err = -ENODEV;
@@ -206,10 +222,15 @@
 
memset(sense, 0, sizeof(*sense));
result = scsi_execute(SDev, cgc-cmd, cgc-data_direction,
- cgc-buffer, cgc-buflen, (char *)sense,
+ zebedee, cgc-buflen, (char *)sense,
  cgc-timeout, IOCTL_RETRIES, 0);
 
scsi_normalize_sense((char *)sense, sizeof(*sense), sshdr);
+   
+   if (zebedee != cgc-buffer) {
+   if (cgc-data_direction == DMA_FROM_DEVICE)
+   memcpy(cgc-buffer, zebedee, cgc-buflen);
+   }
 
/* Minimal error checking.  Ignore cases we know about, and report the 
rest. */
if (driver_byte(result) != 0) {
@@ -266,6 +287,8 @@
 
/* Wake up a process waiting for device */
   out:
+   if (zebedee != cgc-buffer)
+   kfree(zebedee); /* Time for bed */
if (!cgc-sense)
kfree(sense);
cgc-stat = err;
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH]: Fix old SCSI adapter crashes with CD-ROM (take 2)

[Alan Cox]

 Mike Christie tells me we're missing bouncing by accident in the
 scsi_execute path (but not the scsi_execute_async path).  He says this
 is the fix he proposed:
 
 http://marc.info/?l=linux-scsim=115981479822790w=2
 
 Can we just merge this instead?

Short answer: No

Long answer - it doesn't take this path.

Different bug, both want fixing I suspect.
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH]: Fix old SCSI adapter crashes with CD-ROM (take 2)

[Alan Cox]

  Long answer - it doesn't take this path.
  
  Different bug, both want fixing I suspect.
 
 Actually, it does take this path ... one of the things we've been doing
 in SCSI is slowly eliminating the old direct submission paths in favour
 of sending everything through the correct block layer paths.
 scsi_execute(), which the sr ioctl uses is just such a fixed path ...
 the bug is that it should be bouncing the request but because of an
 oversight (which Mike's patch corrects) it doesn't.

Well if Mike's patch is going in and it fixes this then I'll be more than
happy to withdraw the pending one.

 
 The ultimate goal is to be able to eliminate the unchecked_isa_dma flag
 entirely and have the block layer (or device mask allocations) fix all
 of this in every ULD.

About time ;)


Alan
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: BAD_SG_DMA panic in aha1542

[Alan Cox]

 That's as close as it gets without redoing everything from scratch.
 I'll give Alan's and James' patches a go within the next 13 hours.
 
 (Alan: what *else* would you name a variable associated with a bounce
 buffer besides Zebedee?  Thanks for the occasion to smile...)

The one I sent has a memory leak but it won't matter for basic testing.
Or you can change the final bit to


scsi_normalize_sense((char *)sense, sizeof(*sense), sshdr);

if (zebedee != cgc-buffer) {
if (cgc-data_direction == DMA_FROM_DEVICE)
memcpy(cgc-buffer, zebedee, cgc-buflen);
kfree(zebedee); /* Time for bed */
}

Alan
--

`I can hear you.` ,said Florence. `It s not true. Noddy and I are just
good friends.`
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: BAD_SG_DMA panic in aha1542

[Alan Cox]

 As before, no problems using the sda hard disk (which is the boot drive):
 everything works reliably until I touch the cdrom drive.

A little quiet contemplation and gnome number 387 suggests trying the following
(and providing more detailed information such as the last message printed before
the DMA message). Stuff a BUG() before the panic in BAD_DMA (aha1542.c) if 
needed
to get a good trace.

Please report success/failure/change.

--- drivers/scsi/sr_ioctl.c~2007-04-27 22:53:33.885035256 +0100
+++ drivers/scsi/sr_ioctl.c 2007-04-27 22:53:33.885035256 +0100
@@ -187,9 +187,10 @@
struct scsi_sense_hdr sshdr;
int result, err = 0, retries = 0;
struct request_sense *sense = cgc-sense;
-
+   void *zebedee = cgc-buffer;
+   
SDev = cd-device;
-
+   
if (!sense) {
sense = kmalloc(SCSI_SENSE_BUFFERSIZE, GFP_KERNEL);
if (!sense) {
@@ -197,7 +198,22 @@
goto out;
}
}
-
+   
+   if (cgc-buflen  cd-device-host-unchecked_isa_dma) {
+   switch(cgc-data_direction) {
+   case DMA_NONE:
+   break;
+   case DMA_FROM_DEVICE:
+   case DMA_TO_DEVICE: /* Boing said Zebedee */
+   zebedee = kmalloc(cgc-buflen, 
GFP_KERNEL|GFP_DMA);
+   if (zebedee ==NULL) {
+   err = -ENOMEM;
+   goto out;
+   }
+   }
+   if (cgc-data_direction == DMA_TO_DEVICE)
+   memcpy(zebedee, cgc-buffer, cgc-buflen);
+   }
   retry:
if (!scsi_block_when_processing_errors(SDev)) {
err = -ENODEV;
@@ -206,10 +222,13 @@
 
memset(sense, 0, sizeof(*sense));
result = scsi_execute(SDev, cgc-cmd, cgc-data_direction,
- cgc-buffer, cgc-buflen, (char *)sense,
+ zebedee, cgc-buflen, (char *)sense,
  cgc-timeout, IOCTL_RETRIES, 0);
 
scsi_normalize_sense((char *)sense, sizeof(*sense), sshdr);
+   
+   if (zebedeee != cgc-buffer  cgc-data_direction == DMA_FROM_DEVICE)
+   memcpy(cgc-buffer, zebedee, cgc-buflen);
 
/* Minimal error checking.  Ignore cases we know about, and report the 
rest. */
if (driver_byte(result) != 0) {
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch 1/7] libata: check for AN support

[Alan Cox]

 + /*
 +  * check to see if this ATAPI device supports
 +  * Asynchronous Notification
 +  */
 + if ((ap-flags  ATA_FLAG_AN)  ata_id_has_AN(id))
 + {

Bracketing police ^^^

 + /* issue SET feature command to turn this on */
 + rc = ata_dev_set_AN(dev);
 + if (rc) {
 + ata_dev_printk(dev, KERN_ERR,
 + unable to set AN\n);
 + rc = -EINVAL;
 + goto err_out_nosup;

How fatal is this - do we need to ignore the device at this point or
should we just pretend (possibly correctly) that the device itself does
not support notification. 

 @@ -299,6 +305,8 @@ struct ata_taskfile {
  #define ata_id_queue_depth(id)   (((id)[75]  0x1f) + 1)
  #define ata_id_removeable(id)((id)[0]  (1  7))
  #define ata_id_has_dword_io(id)  ((id)[50]  (1  0))
 +#define ata_id_has_AN(id)\
 + ((id[76]  (~id[76]))  ((id)[78]  (1  5)))

Might be nice to check ATA version as well to be paranoid but this all
looks ok as its a reserved field since way back when.

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

Re: [patch 7/7] libata: send event when AN received

[Alan Cox]

 + /* check the 'N' bit in word 0 of the FIS */
 + if (f[0]  (1  15)) {
 + int port_addr =  ((f[0]  0x0f00)  8);
 + struct ata_device *adev = ap-device[port_addr];

You can't be sure that the port_addr returned will be in range if a
device is malfunctioning...

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

Re: InitIO SCSI: Volunteers required

[Alan Cox]

 This doesn't change much outside the initialization and irq code, so
 any additional de-crappyfication will hopefully apply ontop.

This will actually clash horribly with the rest of the rework, so it does
need to be applied after the other changes. The driver in my tree no
longer looks much like the driver you are hacking on because its been
turned into a Linux driver.

Its just a matter of ordering of the changes to get this merged nicely.

Don't suppose you also did the other scsi offenders ?

Alan
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: InitIO SCSI: Volunteers required

[Alan Cox]

 Once again a pci_get_device conversation isn't all that helpfull at all.
 fortunately in this case I've done a patch to convert this driver to
 proper pci probing in 2004, and I've attached the forward-ported version
 below now that we've actually found some testers that weren't locatable
 back then..
 
 This doesn't change much outside the initialization and irq code, so
 any additional de-crappyfication will hopefully apply ontop.

Can this wait Christoph as it'll clash horribly with all the work I've
done. Once the original changes are checked out by folks who have
volunteered to do that I'll see these get merged in as well.

Alan

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

Re: [PATCH] utilities: add helper functions for safe 64-bit integer operations as 32-bit halves

[Alan Cox]

  +#define lower_32_bits(n) (sizeof(n) == 8 ? (u32)(n) : (n))
 
 n0x would be simpler.
 
 Do we actually have any call for this?

The only case for all of this we care about is sector_t, which is one
type, with specific properties (eg always being positive). The rest is
over-engineering. Call it sector_upper32() do it the simple way and stop
trying to solve a problem we don't have
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

InitIO SCSI: Volunteers required

[Alan Cox]

I'm looking for some testers for a revamp of the initio driver. No real
code changes other than to hopefully stop it exploding on load on 64bit,
but a major reorganisation, commenting and de-windowsification so the
code is actually readable and I can do the pci_find_device to
pci_get_device transitions.

Alan
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] libata: reimplement suspend/resume support using sdev-manage_start_stop

[Alan Cox]

 * DPM is dropped.  This also simplifies code a lot.  Suspend/resume
   status is port-wide now.

Makes sense

 * sdev-manage_start_stop is set to 1 in ata_scsi_slave_config().
   This fixes spindown on shutdown and suspend-to-disk.

Yay
 
 Signed-off-by: Tejun Heo [EMAIL PROTECTED]

Acked-by: Alan Cox [EMAIL PROTECTED]

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

Re: impact of 4k sector size on the IO FS stack

[Alan Cox]

 Now, if this disk was copied byte per byte (/bin/dd) to a
 4096-based disk, and Linux would start using a sector size of
 4096, then I would suddenly have

The ATA drives I'm aware of report 512 byte sector size, do 512 byte
I/O's but use 4K physical sectors and to get sane performance except the
OS to issue sensible sized I/O requests.
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: impact of 4k sector size on the IO FS stack

[Alan Cox]

 First generation of 1K sector drives will continue to use the same 
 512-byte ATA sector size you are familiar with.  A single 512-byte write 
 will cause the drive to perform a read-modify-write cycle.  This 
 configuration is physical 1K sector, logical 512b sector.

The problem case is read-modify-screwup

At that point we've trashed the block we were writing (a well studied
recovery case), and we've blasted some previously sane, totally
unrelated sector of data out of existance. Thats why we need to know
ideally if they are doing the write to a different physical block when
they do this, so that we don't lose the old data. My guess is they won't
as it'll be hard.
 
 A future configuration will change the logical ATA interface away from 
 512-byte sectors to 1K or 4K.  Here, it is impossible to read a quantity 
 smaller than 1K or 4K, whatever the sector size is.

That one I'm not worried about - other than guess how Redmond decide to
make partition tables work that one is mostly easy (be fun to see how
many controllers simply can't cope with the command formats)

Alan
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: impact of 4k sector size on the IO FS stack

[Alan Cox]

 For 1K/4K logical sector sizes, who knows.  EFI?  grins and runs
 Certainly seems incompatible with the current popular DOS partition format.

Its a bit messier than that. There are two interpretations of DOS
partition formats found on 2K sector size magneto opticals. One is that
everything is the same as before (as if sectors were 512 byte), the other
is a different everything is the same which scales by the 2K sector
size. The two are of course wonderfully incompatible
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: impact of 4k sector size on the IO FS stack

[Alan Cox]

 Are there other concerns in the IO or FS stack that we should bring up 
 with vendors?  I have been asked to summarize the impact of 4k sectors 
 on linux  for a disk vendor gathering and want to make sure that I put 
 all of our linux specific items into that summary...

We need to make sure the physical sector size is correctly reported by
the disk (eg in the ATA7 identify data) but I think for libata at least
the right bits are already there and we've got a fair amount of scsi disk
experience with other media sizes (eg 2K) already. 256byte/sector media
is still broken btw 8)

I would be interested to know what the disk vendors intend to use as
their strategy when (with ATA) they have a 512 byte write from an older
file system/setup into a 4K block. The case where errors magically appear
in other parts of the fs when such an error occurs are not IMHO too well
considered.

Alan
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Bug 4940 Repeatable Kernel Panic on Adaptec 2015S I20 device on bootup

[Alan Cox]

On Mon, Aug 08, 2005 at 03:16:18PM +0100, Christoph Hellwig wrote:
 Please either update the driver to use the pci_driver model or even
 better remove it completely and let everyone use the i2o drivers now
 that they have full 64bit dma and managment support.

In the mean time. I ack the fix for what we have now. I don't see the point
of fixing dpt_i2o much further given in another 6 months your wish can probably
come true.

Alan

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

Re: [RFC][PATCH] libata ATAPI alignment

[Alan Cox]

On Gwe, 2005-07-29 at 01:06 -0400, Jeff Garzik wrote:
 So, one thing that's terribly ugly about SATA ATAPI is that we need to
 pad DMA transfers to the next 32-bit boundary, if the length is not
 evenly divisible by 4.

Looks good and avoids the special case leaking into the core code.

 Complicating matters, we currently must support two methods of data
 buffer submission:  a single kernel virtual address, or a struct
 scatterlist.

For the moment - also you turn the single buffer into a one entry sglist
so its not to bad.

 Review is requested by any and all parties, as well as suggestions for
 a prettier approach.

I'd pull the code into seperate functions but thats my only real
comment.
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

PATCH: Re-merge cleanups

[Alan Cox]

This restores the Adrian Bunk and Al Viro cleanups that got trashed in
the driver update. It also fixes a few formatting glitches and adds
cpu_relax() calls to the polls spinning on the controller/bus.

Signed-off-by: Alan Cox [EMAIL PROTECTED]

Alan

--- drivers/scsi/atp870u.c.old  2005-03-11 13:45:28.146766480 +
+++ drivers/scsi/atp870u.c  2005-03-11 14:12:28.346458688 +
@@ -39,9 +39,9 @@
 #include atp870u.h
 
 static struct scsi_host_template atp870u_template;
-void send_s870(struct atp_unit *dev,unsigned char c);
-void is885(struct atp_unit *dev, unsigned int wkport,unsigned char c);
-void tscam_885(void);
+static void send_s870(struct atp_unit *dev,unsigned char c);
+static void is885(struct atp_unit *dev, unsigned int wkport,unsigned char c);
+static void tscam_885(void);
 
 static irqreturn_t atp870u_intr_handle(int irq, void *dev_id, struct pt_regs 
*regs)
 {
@@ -364,7 +364,7 @@
}
outb(j, tmport);
while ((inb(tmport)  0x01) != j) {
-  outb(j,tmport);
+   outb(j,tmport);
}
if (dev-id[c][target_id].last_len == 0) {
tmport = workport + 0x18;
@@ -491,7 +491,7 @@
/*
 *  Clear it off the queue
 */
-   dev-id[c][target_id].curr_req = 0;
+   dev-id[c][target_id].curr_req = NULL;
dev-working[c]--;
spin_unlock_irqrestore(dev-host-host_lock, flags);
/*
@@ -614,7 +614,8 @@
  *
  * Queue a command to the ATP queue. Called with the host lock held.
  */
-int atp870u_queuecommand(struct scsi_cmnd * req_p, void (*done) (struct 
scsi_cmnd *))
+static int atp870u_queuecommand(struct scsi_cmnd * req_p, 
+void (*done) (struct scsi_cmnd *))
 {
unsigned char c;
unsigned int tmport,m;  
@@ -711,7 +712,7 @@
  *
  * Caller holds the host lock.
  */
-void send_s870(struct atp_unit *dev,unsigned char c)
+static void send_s870(struct atp_unit *dev,unsigned char c)
 {
unsigned int tmport;
struct scsi_cmnd *workreq;
@@ -821,9 +822,9 @@
}
outb(j, tmport);
while ((inb(tmport)  0x01) != j) {
-  outb(j,tmport);
+   outb(j,tmport);
 #ifdef ED_DBGP
-  printk(send_s870 while loop 1\n);
+   printk(send_s870 while loop 1\n);
 #endif
}
/*
@@ -946,18 +947,18 @@
 #ifdef ED_DBGP 
printk(1. bttl %x, l %x\n,bttl, l);
 #endif 
-   while (l  0x1) {
-   (((u16 *) (prd))[i + 3]) = 0x;
-   (((u16 *) (prd))[i + 2]) = 0x;
-   (((u32 *) (prd))[i  1]) = 
cpu_to_le32(bttl);
-   l -= 0x1;
-   bttl += 0x1;
-   i += 0x04;
-   }
+   while (l  0x1) {
+   (((u16 *) (prd))[i + 3]) = 0x;
+   (((u16 *) (prd))[i + 2]) = 0x;
(((u32 *) (prd))[i  1]) = cpu_to_le32(bttl);
-   (((u16 *) (prd))[i + 2]) = cpu_to_le16(l);
-   (((u16 *) (prd))[i + 3]) = 0;
-   i += 0x04;  
+   l -= 0x1;
+   bttl += 0x1;
+   i += 0x04;
+   }
+   (((u32 *) (prd))[i  1]) = cpu_to_le32(bttl);
+   (((u16 *) (prd))[i + 2]) = cpu_to_le16(l);
+   (((u16 *) (prd))[i + 3]) = 0;
+   i += 0x04;  
}
(((u16 *) (prd))[i - 1]) = cpu_to_le16(0x8000); 
 #ifdef ED_DBGP 
@@ -1178,7 +1179,8 @@
outb(0x09, tmport);
tmport += 0x07;
 
-   while ((inb(tmport)  0x80) == 0x00);
+   while ((inb(tmport)  0x80) == 0x00)
+   cpu_relax();
tmport -= 0x08;
k = inb(tmport);
if (k != 0x16) {
@@ -1249,7 +1251,8 @@
tmport += 0x03;
outb(0x09, tmport);
tmport += 0x07;
-   while ((inb(tmport)  0x80) == 0);
+   while ((inb(tmport)  0x80) == 0)
+   cpu_relax();
tmport -= 0x08;
inb(tmport);
return;
@@ -1345,7 +1348,7 @@
 
 }
 
-void is870(struct atp_unit *dev, unsigned int wkport)
+static void is870(struct atp_unit *dev, unsigned int wkport

Re: PATCH: atp870u DMA mask

[Alan Cox]

On Gwe, 2005-03-11 at 14:40, Arjan van de Ven wrote:
  -if (!pci_set_dma_mask(pdev, 0xFFUL)) {
  +if (!pci_set_dma_mask(pdev, 0xUL)) {
 isn't it still an F short?
 And... why not use the DMA_32_BIT or whatever define.. it's there for
 exactly this reason :)

No its 32bit not 36bit DMA capable. As to DMA_32_BIT - I didn't know
about it, I'll go take a look for some examples.

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

Re: atp870u chaos

[Alan Cox]

 Is there a solution available or planned? Is the sourcecode of the driver under gpl 
or is it a good idea to contact acard?
 

The Acard driver is GPL, they dont appear to provide much documentation though.
It had some known problems with shared IRQ lines but they should have been
sorted

-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]

Re: [Re: SCSI bootup problem]

[Alan Cox]

 Mark A.Tagliaferro wrote:
  If I install LILO to floppy disk instead of Master Boot Sector will the
  standard kernel be able to boot?
 
 The kernel has to be on a non-SCSI device (for now).

Thats not true. The kernel needs to be on whatever the BIOS decides to boot

Alan

-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]

Re: AVA-1505 trouble

[Alan Cox]

 (scsi0:6:0) cannot abort running or disconnected command
 
 followed by an Oops (NULL pointer) and hard lockup.  EIP=c01c3892 points
 inside internal_done as you can see from this piece of System.map:
 
 c01c386c T aha152x_queue
 c01c3888 T internal_done
 c01c38a4 T aha152x_command
 c01c3910 T aha152x_abort
 
 This is a hard lockup (followed by a few minutes of fsck...) so the Oops

Aha - try

--- drivers/scsi/aha152x.c~ Tue Apr  3 17:55:01 2001
+++ drivers/scsi/aha152x.c  Sun Jun 10 19:54:02 2001
@@ -1494,7 +1494,7 @@
 
DPRINTK(debug_eh, INFO_LEAD internal_done called\n, CMDINFO(SCpnt));
 #endif
-   if(SCSEM(SCpnt))
+   if(SCDATA(SCpnt)  SCSEM(SCpnt))
up(SCSEM(SCpnt));
 }


It doesnt explain why you got a hang - maybe IRQ problems for one, but it 
does explain the oops. The abort freed the host scribble buffer and then
said it failed. internal_done was called as the command completed and tried
to check a dead semaphore.

-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]

Re: Kernel 2.4.4 source package apa1480 Slim SCSI

[Alan Cox]

 the adaptec aha1480 Slim Scsi.  they are normaly
 located in /drivers/scsi/pcmcia.

2.4-ac still includes it if you need it .. but ..
 
 it was not included in kernel 2.4.4 source, since it
 has been historically included under all the other
 kernels.

The aic7xxx in Linus tree should support it as well
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]

Re: Problems even with 512 block size MOs

[Alan Cox]

 Copying a 6.5 MByte file with cp returns nearly immediately on the
 commandline, but umount nearly takes forever. Maximum rate detected by
 xosview during umount was about 30 kByte.
 
 I have similar behaviour on another machine and with different disk. However
 I don't get any dmesg output despite the CONFIG_SCSI_LOGGING=y option on
 both machines.

That sounds like it isnt queueing multiple commands at a time. M/O has
an erase/write sequence so you want to queue large blocks otherwise its two
rotations per I/O

 Are all my MO disks rotten? Are the MO drives broken? Are my SCSI adapters
 broken? Or is there a bug in the SCSI layer?

SCSI layer or scsi driver I suspect.

-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]

Re: Linux Cluster using shared scsi

[Alan Cox]

 Does this package also tell the kernel to re-establish a
 reservation for all devices after a bus reset, or at least inform a
 user level program?  Finding out when there has been a bus reset has
 been a stumbling block for me.

You cannot rely on a bus reset. Imagine hot swap disks on an FC fabric. I 
suspect the controller itself needs to call back for problem events

-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]

Re: MO drives (2048 byte block vfat fs) in lk 2.4

[Alan Cox]

 The EIP resolved most often to cont_prepare_write() in
 fs/buffer. A disassembly suggests line 1802 in buffer.c
 [2.4.3ac11]. That is around a memset() between
 __block_prepare_write() and __block_commit_write() calls
 within the while loop. Most other addresses were within
 the same while loop. Perhaps someone with expertize
 in this area may like to examine that loop.

I'll take a dig. The fat code pulled out the magic buffer stuff because
it was meant to be going lower down which never happened..

Alan

-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]

Re: [RFC][PATCH] adding PCI bus information to SCSI layer

[Alan Cox]

 Also ISA adapters are not the only non-PCI adapters,
 there are the growing band of pseudo adapters that
 may or may not have a PCI bus at the bottom of some
 other protocol stack.

An ioctl might be better. We already have an ioctl for querying the lun
information for a disk. We could also return the bus information for its
controller(s) [remember multipathing]

 

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]

Re: ext2 corruption in 2.4.2, scsi only system

[Alan Cox]

 After scanning the mailing list archives, I was under the impression that
 this Buslogic issue was an AC series problem.  Is there a known problem
 with Buslogic controllers in 2.4.2?  

It seems there is. The changes in -ac and in 2.4.3pre limit the max blocks
per request which seems to make it happier

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]

Re: About DC-315U scsi driver

[Alan Cox]

  when I burn CDRs. Some files burned is different from the origin at HD.
  I use 2.2.17 with Tekram's driver,and nothing is wrong.
 
 Indeed; people report more problems on 2.4 kernels than on 2.2 kernels. I
 currently have no clue why.

2.4 causes longer continuous I/O requests to be sent to the drive for one


-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]

Re: qlogicfc broken in 2.4.2 and later?

[Alan Cox]

 When I try to load it,  I get the following messages:
 /lib/modules/2.4.3-pre2/kernel/drivers/scsi/qlogicfc.o: init_module: No
 such device
 Hint: insmod errors can be caused by incorrect module parameters, including
 invalid IO or IRQ parameters
 /lib/modules/2.4.3-pre2/kernel/drivers/scsi/qlogicfc.o: insmod
 /lib/modules/2.4.3-pre2/kernel/drivers/scsi/qlogicfc.o failed
 /lib/modules/2.4.3-pre2/kernel/drivers/scsi/qlogicfc.o: insmod qlogicfc
 failed

What does 'dmesg' say at this point
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]

Re: stability problem with SCSI in linux 2.4.2

[Alan Cox]

 I think I've found a stability problem in the SCSI subsystem of actual
 kernel 2.4.2. 

The 2.4.2 adaptec driver has plenty of problems. Either use the -ac version
and/or get Justin Gibbs new driver
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]

Re: [PATCH] s/isa//g in drivers/scsi/g_NCR5380.c and some cleanup (242)

[Alan Cox]

 (Does anybody know who the maintainer for this code is?)

There isnt one

 (An indication of how often this code path is used can be found in
 the fact that the previous define of NCR5380_write had its payload
 and address mixed up, probably making for wierd results should
 the code ever be executed.)

The driver works for me nicely. Im not convinced by the changes of direction
either. At least not without a detailed audit on the 2.2 code. Some of the
naming is very misleading in that driver

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]

Re: [PATCH] s/isa//g in drivers/scsi/g_NCR5380.c and some cleanup (242)

[Alan Cox]

 Looking at the define of NCR_5380_write
 
 #define NCR5380_write(reg, value) isa_writeb(NCR5380_map_name + +NCR53C400_mem_base 
+ (reg), value)
 
 followed by an use of NCR5380_write
 
 NCR5380_write(C400_CONTROL_STATUS_REG, CSR_BASE | CSR_TRANS_DIR);
 
 I doubt that it is not the intention to write CSR_BASE | CSR_TRANS_DIR
 at the offset C400_CONTROL_STATUS_REG. But note that this argument
 swap only is in the code produced by -DCONFIG_SCSI_G_NCR5380_MEM.
 Perhaps you use CONFIG_SCSI_G_NCR5380_PORT? Otherwise I must admit
 that I have been had...

Im running PIO. However while I agree with that one Im dubious about the
inverts on the memcpy_*io bits

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]

Re: [PATCH] s/isa//g in drivers/scsi/g_NCR5380.c and some cleanup (242)

[Alan Cox]

 I am sorry but have I inverted the arguments to the memcpy_*io calls?
 Or are you referring to something other than the arguments here?

You seem to have swapped the source/dest over in memcpy_toio cases and I need
to convince myself you did that correctly

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]

Re: Changing MAX_COMMAND_SIZE within the 2.4.x timeframe?

[Alan Cox]

 After reflection, my inclination is that the *correct* solution is to
 fix the low-level drivers to reject the SCSI-III commands themselves.  This
 is more consistent with the devolution of authority from the mid-level to
 the individual low-level drivers that has been going on.  Unfortunately a

If the requests went to the driver to call the scsi layer if it wished this
would be a lot easier to do right. Its up to the driver then if it calls
request_to_scsi, request_to_scsi3, or variants


-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]

Re: [PATCH] consolidating data direction tables

[Alan Cox]

 That could be done, but you'd never be able to drop these tables.

And ?

 I'd prefer a clean break to the new interface. It's better.
 Doug Gilbert is working on it.

You drop them after 2.6, much more polite

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]