Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution
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()
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()
> 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
On Mon, 12 Nov 2012 09:08:43 -0500 "Theodore Ts'o" 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
> > 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
On Fri, 09 Nov 2012 11:52:19 -0800 Andy Grover 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
Re: scsi target, likely GPL violation
> 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
[PATCH] mpt: missing break
From: Alan Cox This happens to do the right thing in all cases on fibre channel but not on other media types Signed-off-by: Alan Cox --- 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
> > 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
> +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
Re: [PATCH 3/3] block: add back command filter modification via sysfs
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
[PATCH] aha152x: Allow use on 64bit systems
From: Alan Cox 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 --- 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.
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
Re: [PATCH] scsi_error: Fix language abuse.
> 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
[PATCH] megaraid: outb_p extermination
>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.
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: Integration of SCST in the mainstream Linux kernel
> better. So for example, I personally suspect that ATA-over-ethernet is way > better than some crazy SCSI-over-TCP crap, but I'm biased for simple and > low-level, and against those crazy SCSI people to begin with. Current ATAoE isn't. It can't support NCQ. A variant that did NCQ and IP would probably trash iSCSI for latency if nothing else. 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
On Tue, 22 Jan 2008 14:30:12 -0700 "Yang, Bo" <[EMAIL PROTECTED]> wrote: > Alan/Matthew, > > I found inb_p/outb_p are defined as inb/outb in kernel src. So it > should not have problems to change inb_p/outb_p to inb/outb. Only on some platforms. On the x86 platforms the inb_p()/outb_p() includes a 2uS delay while inb/outb do not. 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
> 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
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
Re: Megaraid: Use of outb_p
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
Megaraid: Use of outb_p
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: INITIO scsi driver fails to work properly
> 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: INITIO scsi driver fails to work properly
> 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: sata_nv does not function in kernel > 2.6.20.21
> 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: Maybe Sorry for that but where should i write .)
> 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
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
> Well, the change log isn't very committal for "rush me immediately into > main line" plus, as far as I could dig out, there was no confirmation > that it actually worked. This way, I can now say please try the current Without that change it always tries to use zero as the memory/io address of the device. - 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
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: INITIO scsi driver fails to work properly
> 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: 2.6.24-rc3-mm2: Result: hostbyte=0x01 driverbyte=0x00\nend_request: I/O error
> > [ 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
> > 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
> 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?
> but in any case, historicly IDE (PATA) and SATA drives have been handled > differently, IDE drives have had fixed device names based on how they are > connected, SATA devices have had 'order found' device names from the SCSI Nope. Historically it depended whether you had a PATA controller with SATA bridge, a SATA controller with SATA drives, a PATA controller with PATA drives or a SATA controller with PATA bridge. Often the bridges are on the card or mainboard. So some VIA systems would historically use /dev/hda for the first SATA device. Even more fun is stuff like Jmicron where the BIOS settings determined whether PATA or SATA was /dev/hda 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: OOM killer gripe (was Re: What still uses the block layer?)
> 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?
> > /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: What still uses the block layer?
> 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
[PATCH] initio: Merge fallout
Fix IRQ reporting - just assign the ->pci_dev pointer earlier and use the
pci_dev irq field rather than keeping a private one
Init the spinlock as it works better on SMP that way
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --exclude-from /usr/src/exclude --new-file --recursive
linux.vanilla-2.6.23-mm1/drivers/scsi/initio.c
linux-2.6.23-mm1/drivers/scsi/initio.c
--- linux.vanilla-2.6.23-mm1/drivers/scsi/initio.c 2007-10-15
15:03:36.0 +0100
+++ linux-2.6.23-mm1/drivers/scsi/initio.c 2007-10-15 15:19:48.0
+0100
@@ -665,7 +665,7 @@
host->max_tags[i] = 0xFF;
} /* for */
printk("i91u: PCI Base=0x%04X, IRQ=%d, BIOS=0x%04X0, SCSI ID=%d\n",
- host->addr, host->irq,
+ host->addr, host->pci_dev->irq,
host->bios_addr, host->scsi_id);
/* Reset SCSI Bus */
if (host->config & HCC_SCSI_RESET) {
@@ -2892,6 +2892,8 @@
goto out_release_region;
}
+ host->pci_dev = pdev;
+
host->num_scbs = num_scb;
host->scb = scb;
host->next_pending = scb;
@@ -2906,6 +2908,7 @@
host->scb_end = tmp;
host->first_avail = scb;
host->last_avail = prev;
+ spin_lock_init(&host->avail_lock);
initio_init(host, phys_to_virt(bios_seg << 4));
@@ -2929,7 +2932,6 @@
}
pci_set_drvdata(pdev, shost);
- host->pci_dev = pdev;
error = scsi_add_host(shost, &pdev->dev);
if (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
Re: What still uses the block layer?
> You can pull a Model and Serial number via hdparm -i, but it's not as > easy to manipulate as a fixed-length MAC address. That's why people > tend to use filesystem UUID's. ATA8 at the moment looks set to add a true "MAC" or "WWN" type identifier to each device.. Right now model/serial is not always unique. - 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?
> For the desktop I don't object to the scsi layer. I object to the naming. > Merging a half-dozen different types of devices into a single name space, and They *are* SCSI devices. USB storage is a SCSI over USB transport. ATAPI is a SCSI over ATA transport. SAS is much the same thing, as is FC, and it continues. With the exception of ATA disk for historical reasons SCSI essentially won the battle of command formats. > problems to the point where common cases (like my laptop) aren't impacted by > them during early boot. I don't think anybody (outside the embedded space) > is actually upset that /dev/hda now goes through the scsi layer: they're > upset Ubuntu 7.04 no longer calls it /dev/hda. For the emedded CF using world we could do with a truely dumb ATA only CF driver, possibly even with pure polled support that used neither the IDE or the ATA layer. 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
> 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
> 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: [PATCH 3/3] faster workaround
> -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: What's in linux-2.6-block.git for 2.6.24
> 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
> 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] eata_pio: Clean up proc handling, bracketing and use cpu_relax()
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(len>length)
- 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_SDR
[PATCH] dtc: Fix typo
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
Re: [GIT PATCH] scsi bug fixes for 2.6.23-rc2
> I fully agree, and firmly believe that the current stabilisation works > incredibly well for shaking out bugs. My problem is that it doesn't > work for stabilising features. Either we have to get far more people > doing feature integration testing before the merge window, or we have to > accept feature updates after the merge window (for existing features > that are having stability issues). The other alternative is that if Linus won't take updates you ask him to revert bsg so that you don't get a half baked merge as a result of this. I'm not sure that is a good path to follow either however. - 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] t128: Indent and add printk levels
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
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);
-
[PATCH] dtc: Clean up indent damage and add printk levels
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/dtc.c
linux-2.6.23rc1-mm1/drivers/scsi/dtc.c
--- linux.vanilla-2.6.23rc1-mm1/drivers/scsi/dtc.c 2007-07-26
15:01:45.0 +0100
+++ linux-2.6.23rc1-mm1/drivers/scsi/dtc.c 2007-07-26 15:29:19.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] aacraid: Resend, Fix security hole
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
Re: [PATCH] dtc: Coding police and printk levels
On Fri, 22 Jun 2007 11:00:06 -0700
"Darrick J. Wong" <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 22, 2007 at 02:26:29PM +0100, Alan Cox wrote:
> > @@ -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");
>
> I think you meant KERN_DEBUG ?
Thanks - thats a path thats not compiled and I missed that. Will fix 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] dmx3191d: Coding style police
On Fri, 22 Jun 2007 07:26:23 -0600 Matthew Wilcox <[EMAIL PROTECTED]> wrote: > On Fri, Jun 22, 2007 at 02:24:56PM +0100, Alan Cox wrote: > > - out_free_irq: > > +out_free_irq: > > Which CodingStyle mandates that goto labels start in column 0? It > screws up diff -p to do this. The style being the fact almost all of the kernel keeps the label in column zero ? I'm not greatly fussed by the indent for goto labels, its the other stuff like missing printk labels that actually matters. However if your diff -p is buggy how about fixing your diff instead ? 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] ppa: Coding police and printk levels
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;
[PATCH] dtc: Coding police and printk levels
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] dmx3191d: Coding style police
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
Re: [patch 4/6] ps3: Disk Storage Driver
> 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 4/6] ps3: Disk Storage Driver
> > 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 5/5] SCSI/initio conversion to PCI driver API
On Sun, 27 May 2007 11:03:53 -0400 Jeff Garzik <[EMAIL PROTECTED]> wrote: > Jeff Garzik wrote: > > Prior simplifications in this patchset now permit a minimal conversion > > to the new PCI API. > > > > Further improvements and simplifications are certainly possible; those > > should be presented in a separate patchset. > > > > DO NOT APPLY (yet). For feedback (and testers?) only. > > > This only applies to patch #5. > > Patches 1 through 4 should go upstream, IMO. NAK all five. There is a complete overhaul already done. 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
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
> > 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
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?
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
> - 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
Re: [PATCH]: Fix old SCSI adapter crashes with CD-ROM (take 2)
> > 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: [PATCH]: Fix old SCSI adapter crashes with CD-ROM (take 2)
> 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-scsi&m=115981479822790&w=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
[PATCH]: Fix old SCSI adapter crashes with CD-ROM (take 2)
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
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
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: BAD_SG_DMA panic in aha1542
> 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
> 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 7/7] libata: send event when AN received
> + /* 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: [patch 1/7] libata: check for AN support
> + /*
> + * 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: InitIO SCSI: Volunteers required
> 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
> 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
> > > over-engineering. Call it sector_upper32() do it the simple way and stop > > > trying to solve a problem we don't have > > > > James said we have the same problem with dma_addr_t. > > Yes. It's in fact the far more common case and we have a bread of > macros dealing with the issue in various drivers. So we still only need it for unsigned 32/64bit values ? 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
> > +#define lower_32_bits(n) (sizeof(n) == 8 ? (u32)(n) : (n)) > > n&0x 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
Re: [PATCH] cciss: Fix warnings during compilation under 32bitenvironment
> > #if (BITS_PER_LONG > 32) || defined(CONFIG_LBD) > > #define sector_upper_32(sector) ((sector) >> 32) > > #else > > #define sector_upper_32(sector) (0) > > #endif Gak Just do sector_upper_32(sector) (((sector) >> 31) >> 1) and lose all the ifdefs, 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
InitIO SCSI: Volunteers required
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
> * 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
> For 1K/4K logical sector sizes, who knows. EFI? > 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
> 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
> 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
> 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
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
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
Re: Fw: ACARD SCSI driver update for Linux kernel v2.6
On Mer, 2005-03-30 at 12:48, jameshsu wrote: > Hello Matthew/Allen, > > Few weeks pass since we sent update driver for you to build-in in Jan 2005. > Latest, we test Linux kernel rev 2.6.11 and found the SCSI driver not > update yet. It is in 2.6.12 snapshots. > Is it possible to let us know anything Acard are still missing or any rules > not follow??!! It took a long time because your changes removed other fixes made over time and it took a lot of work to merge them back together 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: atp870u DMA mask
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
PATCH: atp870u DMA mask
Noted by James Bottomley
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
--- drivers/scsi/atp870u.c.old 2005-03-11 14:14:53.015465656 +
+++ drivers/scsi/atp870u.c 2005-03-11 14:15:24.950610776 +
@@ -2634,7 +2634,7 @@
if (pci_enable_device(pdev))
return -EIO;
-if (!pci_set_dma_mask(pdev, 0xFFUL)) {
+if (!pci_set_dma_mask(pdev, 0xUL)) {
printk(KERN_INFO "atp870u: use 32bit DMA mask.\n");
} else {
printk(KERN_ERR "atp870u: DMA mask required but not
available.\n");
-
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
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 @@
Re: 2.4.6 SCSI CDROM Mount Problem
> but which 2.4 is bad with egcs and from what release on it is safe? 2.4.3 or so. It bites the IDE blacklist matching and one of the network drivers (depca from memory). > I think it was when going from 2.4.2 to 2.4.3 when the 3c59x changes > misbehaved when compiled with gcc-2.96-[whatever-was-in-RH7.0] but went > well when compiled with egcs 1.1.2. As has been pointed out the original RH 7.0 compiler was definitely not building valid kernels (2.96-54). Alan - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED]
Re: 2.4.6 SCSI CDROM Mount Problem
> that's not true. Me and some other people (using XFS) had problems with > kernels compiled with RedHat gcc-snapshot compilers. Compiling the same The asm blocks in the XFS patches are a known problem. The standard kernel builds just fine. > kernel with egcs 1.1.2 aka kgcc resolved those problems. Mine was a none > XFS problem... Yeah. Note that egcs 1.1.2 miscompiles older 2.4.x but is fine for all those (AFAIK) after strstr was uninlined. [and needless to say when we wander off X86 the whole rule set changes] - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED]
Re: 2.4.6 SCSI CDROM Mount Problem
> This might not fix your problem, but gcc version 2.96 is known to have > problems in userspace programs and is not a supported kernel compiler. gcc 2.96-* builds 2.4.x kernels fine. Gcc 3.0 is a bit touchy. You want gcc 2.95.3 or earlier for 2.2 because the newer compilers optimise stuff we didnt want and forgot to tell it - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED]
Re: ide-scsi driver loops when ripping CDs
> I see that the newly released linux-2.4.6 still contains the broken > version (3.1.17) of sg.c. Argh. Its on my hit list ... 8) > - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED]
Re: atp870u chaos
> 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: Another aic7xxx trouble report
> SCSI subsystem drive Revision: 1.00 > scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.1.13 > > aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/255 SCBs > Your scsi controller thinks it has no disks attached to it - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED]
Re: AVA-1505 trouble
> > - if(SCSEM(SCpnt)) > > + if(SCDATA(SCpnt) && SCSEM(SCpnt)) > > Thanks (sorry for the delay in my response) - with this patch, it gets > a little further (by about 30 seconds). Now I'm getting an Oops (NULL > pointer again) in busfree_run: Thanks. It actually looks like the code shouldnt be freeing the command private data at all in the abort path. Try dropping that out entirely ? - 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]
> > > The kernel has to be on a non-SCSI device (for now). > > True. The root fs has to be on a non-SCSI device, yes? False. You can have everything on scsi - 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]
> "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]
