Re: [PATCH] aacraid 2.6: Address sparse warnings
> + u32 temp = le32_to_cpu(psg->sg[i-1].count) -
> + (byte_count - scsicmd->request_bufflen);
> + psg->sg[i-1].count = cpu_to_le32(temp);
You really want {be,le}*_{add,sub} helpers. I needed them on various
occasions, too. Al, what do you think about adding these helpers to a
common header somewhere?
> +#define LE32_ALL_ONES ((__force __le32)0x)
I don't like having this in an actual driver. It might make sense to
either have this in a common header or actually allowing to assign all
ones to __l32*/__be* variables. Al?
-
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] Use proper seq_file api for /proc/scsi/scsi
On Thu, Apr 07, 2005 at 12:24:12PM +0100, Christoph Hellwig wrote: > On Thu, Apr 07, 2005 at 01:21:23PM +0200, Hannes Reinecke wrote: > > > /proc/scsi/scsi is deprecated and even only compiled in if > > > "legacy /proc/scsi/ support" is enabled. Please move over to lssci which > > > is using sysfs ASAP. > > > > > Ah. And that's enough reason for it not to work properly? > > Deprecated as it may be, but one could at least expect it to _work_. > > It works for those setups that already worked with 2.4.x, aka only a few > luns. Even if it's deprecated, wouldn't it be good to fix it as long as it's there, unless it hurts something else? Or at least fix the out of memory error, even if it doesn't display all the luns? jeremy - 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: proc_name in sysfs
Hi, Patrick Mansfield a écrit : On Thu, Apr 07, 2005 at 08:35:16AM +0200, Frederic TEMPORELLI wrote: Hi, Sorry, no such "driver" directory in /sys/class/scsi_host/hostX/ Doug answered that. thx, I've just try the script and it works... (mea culpa, I should have look in details to the symlinks) Why do you need it? If you answer the above you might get better/other suggestions. We already have scripts for getting HBAs informations, and these scripts are based on /sys/class/scsi_host/hostX/proc_name to define how to process informations (we don't care about WWPN when using U320 adapter). => I'll change our scripts according to Doug's solution, this should be fine. Thanks again... -- Frederic TEMPORELLI - 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 1/1] drivers/scsi/: Use the DMA_32BIT_MASK constant
The previous patch did not compile cleanly on all architectures so
here's a fixed one.
Use the DMA_32BIT_MASK constant from dma-mapping.h when calling
pci_set_dma_mask() or pci_set_consistent_dma_mask()
This patch includes dma-mapping.h explicitly because it caused errors
on some architectures otherwise.
See http://marc.theaimsgroup.com/?t=10800199301&r=1&w=2 for details
Signed-off-by: Tobias Klauser <[EMAIL PROTECTED]>
Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
---
drivers/scsi/sata_vsc.c|0
kj-domen/drivers/scsi/BusLogic.c |7 ---
kj-domen/drivers/scsi/a100u2w.c|3 ++-
kj-domen/drivers/scsi/aacraid/aachba.c |9 +
kj-domen/drivers/scsi/aacraid/linit.c |7 ---
kj-domen/drivers/scsi/aic7xxx/aic79xx_osm.c|3 ++-
kj-domen/drivers/scsi/aic7xxx/aic7xxx_osm.c|3 ++-
kj-domen/drivers/scsi/atp870u.c|3 ++-
kj-domen/drivers/scsi/dpt_i2o.c|5 +++--
kj-domen/drivers/scsi/eata.c |3 ++-
kj-domen/drivers/scsi/gdth.c |7 ---
kj-domen/drivers/scsi/initio.c |3 ++-
kj-domen/drivers/scsi/ips.c|5 +++--
kj-domen/drivers/scsi/megaraid.c |7 ---
kj-domen/drivers/scsi/megaraid/megaraid_mbox.c |5 +++--
kj-domen/drivers/scsi/nsp32.c |3 ++-
kj-domen/drivers/scsi/qla1280.c|5 +++--
kj-domen/drivers/scsi/qlogicfc.c |5 +++--
18 files changed, 50 insertions(+), 33 deletions(-)
diff -puN drivers/scsi/BusLogic.c~dma_mask-drivers_scsi drivers/scsi/BusLogic.c
--- kj/drivers/scsi/BusLogic.c~dma_mask-drivers_scsi2005-04-05
12:57:47.0 +0200
+++ kj-domen/drivers/scsi/BusLogic.c2005-04-05 12:57:47.0 +0200
@@ -41,6 +41,7 @@
#include
#include
#include
+#include
#include
#include
@@ -676,7 +677,7 @@ static int __init BusLogic_InitializeMul
if (pci_enable_device(PCI_Device))
continue;
- if (pci_set_dma_mask(PCI_Device, (u64) 0x))
+ if (pci_set_dma_mask(PCI_Device, DMA_32BIT_MASK))
continue;
Bus = PCI_Device->bus->number;
@@ -831,7 +832,7 @@ static int __init BusLogic_InitializeMul
if (pci_enable_device(PCI_Device))
continue;
- if (pci_set_dma_mask(PCI_Device, (u64) 0x))
+ if (pci_set_dma_mask(PCI_Device, DMA_32BIT_MASK))
continue;
Bus = PCI_Device->bus->number;
@@ -885,7 +886,7 @@ static int __init BusLogic_InitializeFla
if (pci_enable_device(PCI_Device))
continue;
- if (pci_set_dma_mask(PCI_Device, (u64) 0x))
+ if (pci_set_dma_mask(PCI_Device, DMA_32BIT_MASK))
continue;
Bus = PCI_Device->bus->number;
diff -puN drivers/scsi/a100u2w.c~dma_mask-drivers_scsi drivers/scsi/a100u2w.c
--- kj/drivers/scsi/a100u2w.c~dma_mask-drivers_scsi 2005-04-05
12:57:47.0 +0200
+++ kj-domen/drivers/scsi/a100u2w.c 2005-04-05 12:57:47.0 +0200
@@ -89,6 +89,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1052,7 +1053,7 @@ static int __devinit inia100_probe_one(s
if (pci_enable_device(pdev))
goto out;
- if (pci_set_dma_mask(pdev, 0xULL)) {
+ if (pci_set_dma_mask(pdev, DMA_32BIT_MASK)) {
printk(KERN_WARNING "Unable to set 32bit DMA "
"on inia100 adapter, ignoring.\n");
goto out_disable_device;
diff -puN drivers/scsi/aacraid/aachba.c~dma_mask-drivers_scsi
drivers/scsi/aacraid/aachba.c
--- kj/drivers/scsi/aacraid/aachba.c~dma_mask-drivers_scsi 2005-04-05
12:57:47.0 +0200
+++ kj-domen/drivers/scsi/aacraid/aachba.c 2005-04-05 12:57:47.0
+0200
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
@@ -692,12 +693,12 @@ int aac_get_adapter_info(struct aac_dev*
dev->dac_support = (dacmode!=0);
}
if(dev->dac_support != 0) {
- if (!pci_set_dma_mask(dev->pdev, 0xULL) &&
- !pci_set_consistent_dma_mask(dev->pdev,
0xULL)) {
+ if (!pci_set_dma_mask(dev->pdev, DMA_64BIT_MASK) &&
+ !pci_set_consistent_dma_mask(dev->pdev,
DMA_64BIT_MASK)) {
printk(KERN_INFO"%s%d: 64 Bit DAC enabled\n",
dev->name, dev->id);
- } else if (!pci_set_dma_mask(dev->pdev, 0xULL) &&
- !pci_set_consistent_dma_mask(dev->pdev, 0xULL))
{
+ } else if (!pci_set_dma_mask(dev->pdev, DMA_32BIT_MASK) &
Re: [PATCH] Use proper seq_file api for /proc/scsi/scsi
On Fri, Apr 08, 2005 at 12:23:46AM -0700, Jeremy Higdon wrote: > > It works for those setups that already worked with 2.4.x, aka only a few > > luns. > > Even if it's deprecated, wouldn't it be good to fix it as long as > it's there, unless it hurts something else? Or at least fix the > out of memory error, even if it doesn't display all the luns? What other error would you return? I don't particularly care what exact error code to return, but putting in Hannes patch would be a bad idea because it a) poke deep into driver model internals, and we absolutely want to avoid that b) sets a bad precedence that we'll continue adding features to deprecated interface and thus encurage people to contiue using it. Note that /proc/scsi/* has been deprecated since mid-2.5.x. - 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] Use proper seq_file api for /proc/scsi/scsi
On Fri, 2005-04-08 at 08:56 +0100, Christoph Hellwig wrote: > On Fri, Apr 08, 2005 at 12:23:46AM -0700, Jeremy Higdon wrote: > > > It works for those setups that already worked with 2.4.x, aka only a few > > > luns. > > > > Even if it's deprecated, wouldn't it be good to fix it as long as > > it's there, unless it hurts something else? Or at least fix the > > out of memory error, even if it doesn't display all the luns? > > What other error would you return? I don't particularly care what exact > error code to return, but putting in Hannes patch would be a bad idea because > it > > a) poke deep into driver model internals, and we absolutely want to avoid > that > b) sets a bad precedence that we'll continue adding features to deprecated > interface and thus encurage people to contiue using it. Note that > /proc/scsi/* has been deprecated since mid-2.5.x. so how about starting to remove it? eg give it its final resting date, start defaulting the config option to "n" and such... - 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] Use proper seq_file api for /proc/scsi/scsi
On Fri, Apr 08, 2005 at 08:56:43AM +0100, Christoph Hellwig wrote: > On Fri, Apr 08, 2005 at 12:23:46AM -0700, Jeremy Higdon wrote: > > Even if it's deprecated, wouldn't it be good to fix it as long as > > it's there, unless it hurts something else? Or at least fix the > > out of memory error, even if it doesn't display all the luns? > > What other error would you return? I don't particularly care what exact Hmm. Well maybe you're right -- an error is probably better than no error if not printing all devices. > error code to return, but putting in Hannes patch would be a bad idea because > it > > a) poke deep into driver model internals, and we absolutely want to avoid > that > b) sets a bad precedence that we'll continue adding features to deprecated > interface and thus encurage people to contiue using it. Note that > /proc/scsi/* has been deprecated since mid-2.5.x. Just as a sanity check, you meant "lsscsi" and not "lssci" in your original reply, right? jeremy - 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: proc_name in sysfs
Christoph Hellwig wrote: On Wed, Apr 06, 2005 at 01:40:04PM +0200, Frederic TEMPORELLI wrote: Hello, We are using HBAs modules names from "proc_name" interface in sysfs: /sys/class/scsi_host/hostX/proc_name. But with new Emulex drivers (8.0.21 and +), proc_name is reporting (previous drivers were reporting "lpfc"). => In the driver code, .proc_name field from scsi_host_template structure is no more initialized. James Smart told us that the "removal" of .proc_name field (not really removed, but no more initialized) was part of the /proc interfaces removal (suggested by scsi-linux feedback). So: 1/ now, what is the aim of proc_name interface (reporting "") in sysfs ? 2/ now, how can we get the adapter module name from sysfs ? => I'm just thinking that .proc_name field has to be kept initialized and/or something has to be changed to replace the confusing "proc" prefix. The real problem is that someone decided to export the proc_name in sysfs. It's supposed to be only procfs-specific but someone violated that rule. Forget the "proc_" part. It is effectively the lld_name. Allowing the LLD to name itself to the scsi subsystem makes sense, especially when the LLD is made up of several kernel modules. See my previous example comparing the output of lsscsi -H and scan_host.sh . Not sure how to proceed forward with this. Doug Gilbert - 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
Proper handling of data underrun
Hi, Documentation/scsi/scsi_mid_low_api.txt says: resid- an LLD should set this signed integer to the ... underflow- LLD should place (DID_ERROR << 16) in 'result' if ... ZFCP is setting resid and DID_ERROR if an underrun is indicated in the FCP-response. In some error situations it occurs that the storage box reports a BUSY or TASK_SET_FULL scsi state as well as data underrun in the FCP-response. Now zfcp sets DID_ERROR in host_byte as suggested in scsi_mid_low_api.txt. And the BUSY/TASK_SET_FULL state is returned in stauts_byte. Problem is: Due to the its fastfail-operation the scsi-stack won't do any retry for this kind of failed commands because DID_ERROR is evaluated before BUSY/TASK_SET_FULL. What is the proper handling of situations where the device reports a BUSY/TASK_SET_FULL and a data underrun? Regards, Andreas - 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: Proper handling of data underrun
Andreas Herrmann wrote: Hi, Documentation/scsi/scsi_mid_low_api.txt says: resid- an LLD should set this signed integer to the ... underflow- LLD should place (DID_ERROR << 16) in 'result' if ... underflow- LLD should place (DID_ERROR << 16) in 'result' if actual number of bytes transferred is less than this figure. Not many LLDs implement this check and some that do just output an error message to the log rather than report a DID_ERROR. Better for an LLD to implement 'resid'. Andreas, The last sentence is were the stress should be. It implies the LLD should use one or the other, preferably resid. Historically 'underflow' has been there the longest but was insufficient to distinguish between serious underflows (e.g. on a READ of a block device) and informative underflows (e.g. fetching a mode page with an arbitrarily large buffer). So 'resid' was added later and conveys more information and doesn't jump to conclusions that it is a serious error. Perhaps 'underflow' should be marked as deprecated. ZFCP is setting resid and DID_ERROR if an underrun is indicated in the FCP-response. In some error situations it occurs that the storage box reports a BUSY or TASK_SET_FULL scsi state as well as data underrun in the FCP-response. Is any data conveyed or is the underflow value the same as the requested length? Now zfcp sets DID_ERROR in host_byte as suggested in scsi_mid_low_api.txt. And the BUSY/TASK_SET_FULL state is returned in stauts_byte. Problem is: Due to the its fastfail-operation the scsi-stack won't do any retry for this kind of failed commands because DID_ERROR is evaluated before BUSY/TASK_SET_FULL. What is the proper handling of situations where the device reports a BUSY/TASK_SET_FULL and a data underrun? See what happens if 'underflow' is ignored (i.e. not written to be the LLD) and DID_ERROR is not set in the host_byte. Doug Gilbert - 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: [OOPS] 2.6.11 - NMI lockup with CFQ scheduler
On Thu, 2005-04-07 at 16:45 +0200, Jens Axboe wrote: > So clear ->request_queue instead. Will do. Did you want me to look after your patch and add this, or do you want to send it to Linus (after the purdah is over)? James - 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: [OOPS] 2.6.11 - NMI lockup with CFQ scheduler
On Fri, Apr 08 2005, James Bottomley wrote: > On Thu, 2005-04-07 at 16:45 +0200, Jens Axboe wrote: > > So clear ->request_queue instead. > > > Will do. Did you want me to look after your patch and add this, or do > you want to send it to Linus (after the purdah is over)? Just queue it with the rest of your changes, that is fine with me. -- Jens Axboe - 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] Use proper seq_file api for /proc/scsi/scsi
On Fri, Apr 08, 2005 at 01:10:11AM -0700, Jeremy Higdon wrote: > Just as a sanity check, you meant "lsscsi" and not "lssci" in your original > reply, right? Yes. - 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: Proper handling of data underrun
Douglas Gilbert <[EMAIL PROTECTED]> wrote: > underflow- LLD should place (DID_ERROR << 16) in 'result' if > actual number of bytes transferred is less than this > figure. Not many LLDs implement this check and some > that do just output an error message to the log > rather than report a DID_ERROR. Better for an LLD > to implement 'resid'. > Andreas, > The last sentence is were the stress should be. It implies > the LLD should use one or the other, preferably resid. Ok. BTW, resid is used in scsi_lib.c to set rq->data_len. Who is actually evaluating this field -- the block layer (I have seen some usage in elevator.c)? > Historically 'underflow' has been there the longest but was > insufficient to distinguish between serious underflows > (e.g. on a READ of a block device) and informative underflows > (e.g. fetching a mode page with an arbitrarily large buffer). > So 'resid' was added later and conveys more information and > doesn't jump to conclusions that it is a serious error. > Perhaps 'underflow' should be marked as deprecated. > Is any data conveyed or is the underflow value the same > as the requested length? Value is the same as the requested length. > See what happens if 'underflow' is ignored (i.e. not > written to be the LLD) and DID_ERROR is not set in > the host_byte. Yes I will give it a try. Thanks. Regards, Andreas - 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] Hotplug support for BusLogic scsi controller
Hi
This patch adds hotplug support to the driver for BusLogic scsi
controllers. It's required to boot from a BusLogic controller when using
modular kernels with hotplug-based initramfs.
Regards,
Juerg
--
Signed-off-by: Juerg Billeter <[EMAIL PROTECTED]>
--- linux-2.6.10/drivers/scsi/BusLogic.c.orig 2004-12-25 11:15:23.612408071
+0100
+++ linux-2.6.10/drivers/scsi/BusLogic.c2004-12-25 11:17:51.639882495
+0100
@@ -79,6 +79,15 @@
static struct BusLogic_DriverOptions
BusLogic_DriverOptions[BusLogic_MaxHostAdapters];
+static struct pci_device_id buslogic_pci_tbl[] = {
+ { PCI_VENDOR_ID_BUSLOGIC, PCI_DEVICE_ID_BUSLOGIC_MULTIMASTER,
PCI_ANY_ID, PCI_ANY_ID, },
+ { PCI_VENDOR_ID_BUSLOGIC, PCI_DEVICE_ID_BUSLOGIC_MULTIMASTER_NC,
PCI_ANY_ID, PCI_ANY_ID, },
+ { PCI_VENDOR_ID_BUSLOGIC, PCI_DEVICE_ID_BUSLOGIC_FLASHPOINT,
PCI_ANY_ID, PCI_ANY_ID, },
+ { } /* Terminating entry */
+};
+MODULE_DEVICE_TABLE(pci, buslogic_pci_tbl);
+
+
/*
BusLogic can be assigned a string by insmod.
*/
-
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] aacraid 2.6: Address sparse warnings
On Fri, Apr 08, 2005 at 08:13:51AM +0100, Christoph Hellwig wrote:
> > + u32 temp = le32_to_cpu(psg->sg[i-1].count) -
> > + (byte_count - scsicmd->request_bufflen);
> > + psg->sg[i-1].count = cpu_to_le32(temp);
>
> You really want {be,le}*_{add,sub} helpers. I needed them on various
> occasions, too. Al, what do you think about adding these helpers to a
> common header somewhere?
*shrug*
Are you asking for suggestions regarding the suitable place for such
helpers? include/linux/byteorder/generic.h would be the obvious
candidate...
> > +#define LE32_ALL_ONES ((__force __le32)0x)
>
> I don't like having this in an actual driver. It might make sense to
> either have this in a common header or actually allowing to assign all
> ones to __l32*/__be* variables. Al?
It doesn't make sense, period. Use cpu_to_le32(~0U) - calculations will
be done at compile time and it's self-documenting. Definition above
is not more efficient or easier to type, so...
-
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] Hotplug support for BusLogic scsi controller
On Fri, Apr 08, 2005 at 06:22:57PM +0200, Juerg Billeter wrote: > This patch adds hotplug support to the driver for BusLogic scsi > controllers. It's required to boot from a BusLogic controller when using > modular kernels with hotplug-based initramfs. It's a start, I suppose. It's not really hotplug support though; for that you'd need to implement the whole pci_driver infrastructure. It'd be worth someone doing (and the BusLogic cards are currently unmaintained, I believe), so if you want to do that, we'd be only too happy to review your patches. BTW, you may want to use the PCI_DEVICE() macro to make the lines shorter. -- "Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception." -- Mark Twain - 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] Hotplug support for BusLogic scsi controller
On Fre, 2005-04-08 at 17:46 +0100, Matthew Wilcox wrote:
> On Fri, Apr 08, 2005 at 06:22:57PM +0200, Juerg Billeter wrote:
> > This patch adds hotplug support to the driver for BusLogic scsi
> > controllers. It's required to boot from a BusLogic controller when using
> > modular kernels with hotplug-based initramfs.
>
> It's a start, I suppose. It's not really hotplug support though; for that
> you'd need to implement the whole pci_driver infrastructure. It'd be
> worth someone doing (and the BusLogic cards are currently unmaintained,
> I believe), so if you want to do that, we'd be only too happy to review
> your patches.
Sorry, but I'm not really into kernel hacking - as you may have guessed,
so I'd probably need too much time to convert the BusLogic driver to a
new-style driver. But as my small patch at least makes the coldplug-part
of hotplug work, I thought it'd make sense to merge it upstream as it
may help other users. Maybe I'll learn to write drivers someday...
BTW: If the BusLogic driver is unmaintained, the MAINTAINERS file should
probably be updated.
>
> BTW, you may want to use the PCI_DEVICE() macro to make the lines shorter.
>
Done, updated patch follows.
--
Signed-off-by: Juerg Billeter <[EMAIL PROTECTED]>
diff -puNr linux-2.6.11.orig/drivers/scsi/BusLogic.c
linux-2.6.11/drivers/scsi/BusLogic.c
--- linux-2.6.11.orig/drivers/scsi/BusLogic.c 2005-03-02 08:38:38.0
+0100
+++ linux-2.6.11/drivers/scsi/BusLogic.c2005-04-08 19:03:02.514619743
+0200
@@ -79,6 +79,15 @@ static int BusLogic_DriverOptionsCount;
static struct BusLogic_DriverOptions
BusLogic_DriverOptions[BusLogic_MaxHostAdapters];
+static struct pci_device_id buslogic_pci_tbl[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_BUSLOGIC,
PCI_DEVICE_ID_BUSLOGIC_MULTIMASTER) },
+ { PCI_DEVICE(PCI_VENDOR_ID_BUSLOGIC,
PCI_DEVICE_ID_BUSLOGIC_MULTIMASTER_NC) },
+ { PCI_DEVICE(PCI_VENDOR_ID_BUSLOGIC, PCI_DEVICE_ID_BUSLOGIC_FLASHPOINT)
},
+ { } /* Terminating entry */
+};
+MODULE_DEVICE_TABLE(pci, buslogic_pci_tbl);
+
+
/*
BusLogic can be assigned a string by insmod.
*/
-
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
flush barriers and SCSI/3w-xxxx with latest 2.6 kernels
Hi, I was just enabling flush barriers on machine using a 3ware controller (by adding barrier=flush to the filesystem options) since this is working wonderfully here at home. But when the filesystems are mounted, the filesystems turns them off because they are unsupported: Apr 8 19:59:46 websrv2 reiserfs: disabling flush barriers on dm-3 "cat /sys/block/sda/device/queue_type" said "none" instead of ordered. An "echo 254 > /sys/block/sda/device/queue_length" fixed this, but it seems that I can't enable this afterwards. I put back a simple tw_slave_configure method to the 3w-.c driver (that calls adjust_queue_depth) and now queue_type shows "ordered" from the beginning. But flush barriers are still not working. A quick peek at the code reveils that scsi_alloc_queue is called before slave_configure. scsi_alloc_queue calls blk_queue_ordered only there. It's reading another ordered_tag which is not set. Why is there an sdev->ordered_tags and another shost->ordered_tag. Should ordered_tag be set to 1 in driver_template or is this really not supported? I am missing something here? signature.asc Description: This is a digitally signed message part
RE: [PATCH] aacraid 2.6: Address sparse warnings
Al Viro sez: > > > +#define LE32_ALL_ONES ((__force __le32)0x) > > I don't like having this in an actual driver. It might make sense to > > either have this in a common header or actually allowing to assign all > > ones to __l32*/__be* variables. Al? > It doesn't make sense, period. Use cpu_to_le32(~0U) - calculations will > be done at compile time and it's self-documenting. Definition above > is not more efficient or easier to type, so... As long as this is guaranteed on all platforms to do the right thing ... paranoid about compiler optimizations. MarkH, this should be an easy regroup :-) Sincerely -- Mark Salyzyn - 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] aacraid 2.6: Address sparse warnings
On Fri, Apr 08, 2005 at 02:41:58PM -0400, Salyzyn, Mark wrote:
> As long as this is guaranteed on all platforms to do the right thing ...
> paranoid about compiler optimizations. MarkH, this should be an easy
> regroup :-)
Well, let's see.
cpu_to_le32(~0U) -> __cpu_to_le32(~0U) ->
[on little-endian]
((__force __le32)(__u32)(~0U)) -> ((__le32)(__u32)(~0U))
[on big-endian]
((__force __le32)__swab32((~0U))) ->
((__le32)__swab32((~0U))) ->
((__le32) (__builtin_constant_p((__u32)((~0U))) ?
___swab32(((~0U)))
: __fswab32(((~0U) ->
((__le32) (__builtin_constant_p((__u32)((~0U))) ?
({
__u32 __x = ((~0U));
((__u32)(
(((__u32)(__x) & (__u32)0x00ffUL) << 24) |
(((__u32)(__x) & (__u32)0xff00UL) << 8) |
(((__u32)(__x) & (__u32)0x00ffUL) >> 8) |
(((__u32)(__x) & (__u32)0xff00UL) >> 24) ));
})
: __fswab32(((~0U)
And that's enough - __builtin_constant_p((__u32)((~0U)) is known at compile
time and is non-zero. The rest is obvious and yes, gcc does understand
that __x is constant and so is the expression above.
IOW, all cpu_to_...() will be simplified to constants at compile
time. They will not be _constant_ _expressions_ from C point of view (IOW,
you can't say e.g.
enum {
A = cpu_to_le32(~0U)
};
- that's what __constant_cpu_to_le32() is for), but they certainly will be
evaluated by compiler.
-
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: SYM8xx_2 driver ignores certain EEPROM settings
Help! Help! I'm being ignored! I just found out that this problem (the driver no longer reading the user's adjustments from the SCSI BIOS EEPROM configuration data) not only removes the possibility to limit transfer speed and width for single devices or entire channels. It also makes the driver ignore the adapter ordering in multiple-channel setups. This machine here has an LSI 21002, where the LVD channel is on device function 1 and the UW channel is on 0. Naturally the user will set the adapter order in BIOS such that the system HDD (on the LVD channel) becomes /dev/sda regardless of other drives on the UW channel. Now, with the latest driver releases ignoring this BIOS adjustment, the channels are scanned in order of appearance on the PCI bus rather than in the order the user wants ... in this case, the LVD channel ends up becoming sym1, which means that whenever I connect my external MO drive to the U/UW channel, I get a kernel panic because Linux can't find its system volume. Not good. Please talk to me ... thanks! regards, Peter On Saturday 26 February 2005 20:34, Peter Missel wrote: > Greetings! > > Now that producing another pair of coasters reminded me that this here > system has a problem on SCSI branch 1, I'd like to inquire about the > current state of affairs regarding this topic. (Also, I've encountered > another machine I'd like to upgrade to a newer Linux kernel but can't since > it's using this very feature-that-went-missing.) > > Is there a patch I can install and try out, or anything else I can do? > > best regards, > Peter Missel > > On Friday 31 December 2004 15:53, Matthew Wilcox wrote: > > On Fri, Dec 31, 2004 at 01:43:42PM +0100, Peter Missel wrote: > > > Hello Matthew! > > > > > > I hope I'm turning to the right person with my report. > > > > Yep, that's me. Best to keep linux-scsi in the loop too. That way > > other people prod me when I've been inattentive ;-) > > > > > After updating to SuSE > > > Linux 9.2, kernel 2.6.8, which brought rev. 2.1.18j of the LSI SCSI > > > driver, I see that the driver's speed/width negotiation no longer > > > considers any limitations configured in the adapter's BIOS. My previous > > > installation, using kernel 2.4.20 and its included LSI SCSI driver, did > > > that perfectly fine. > > > > Yes, that's right. I'm not a big fan of dealing with distro kernels > > because they make changes without informing me. An earlier SuSE kernel > > commented out the domain validation calls from the sym2 driver -- without > > putting the previous code back in. However, that problem doesn't seem to > > be present in this kernel. > > > > > For example (and that's why I noticed), if in SCSI BIOS a certain SCSI > > > channel (or a single device) has been limited by the user to 10 MT/s, > > > the Linux SCSI driver nonetheless negotiates to 20 MT/s. > > > > > > It is necessary to stick to the settings from BIOS (as read from > > > EEPROM), simply because there might be a good reason why the user did > > > that. In my particular case, I need to restrict the sym0 channel from > > > doing Ultra (20 MT/s) altogether because the total cable length doesn't > > > allow me to, > > > > The Domain Validation code is supposed to catch problems like this, and > > automatically fall back to a setting that works without requiring the > > user to set magic bits in their NVRAM. Are you actually experiencing > > problems due to the faster speed, or is it just that you know the cable > > is out of spec? > > > > Hm, I see we skip the write tests, presumably because the drive doesn't > > support a write buffer. Drat. > > > > > and I > > > have one device restricted further to 5 MT/s because I own a buggy > > > Fujitsu MO that claims 10 MT/s capability but (according to Fujitsu's > > > support answer back when I bought it) has a SCSI interface chip on that > > > can't actually do that. > > > > Buggy drive firmware keeps on biting us ;-( It does seem worth honouring > > the NVRAM settings, but the thing is that we then have to support such > > fixes in each driver. > > > > > Below please see a snippet from /var/log/boot.msg; the external branch > > > (including the MO) is disconnected so I can use the system at all. You > > > can still see from dev 0.0.1.0 that 20 MT/s are being set up although > > > the adapter's EEPROM settings mandate a maximum of 10 MT/s for the > > > entire sym0 channel. Also, in line 5 of the snippet, you see the sym0 > > > host is being logged as "Fast-40 SE" which should read lower. The "SCAN > > > AT BOOT" parameter from the same EEPROM is read correctly. > > > > > > Being a system BIOS developper, I have the means to do an EEPROM dump > > > of my SCSI adapter. So in case this is helpful to you, I'll do that as > > > soon as I'm back to work on Jan 10. > > > > I don't need you to do that -- I know the ability has been removed from > > the driver. I bet I can put it back without disturbing things too much. > > > > > <5>SCSI subsystem ini
