Re: [PATCH 0/7] convert semaphore to mutex in struct class
On Fri, 11 Jan 2008 10:33:16 +0800,
Dave Young [EMAIL PROTECTED] wrote:
+struct device *class_find_device(struct class *class, void *data,
+int (*match)(struct device *, void *))
+{
+ struct device *dev;
+
+ if (!class)
+ return NULL;
+
+ mutex_lock(class-mutex);
+ list_for_each_entry(dev, class-devices, node)
+ if (match(dev, data) get_device(dev))
First get the reference and then drop it if the match function returns
0 to make this analogous to the other _find_device() functions?
It's just like other _find_device() functions. Are these more get/put
really needed?
The other _find_device() functions operate on klists, which means that
there is an implicit get while the element is handled. This function
operates on a normal list, which means that getting/putting the
reference looks a bit different if we want the same effect.
-
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/7] convert semaphore to mutex in struct class
On Jan 11, 2008 4:23 PM, Cornelia Huck [EMAIL PROTECTED] wrote:
On Fri, 11 Jan 2008 10:33:16 +0800,
Dave Young [EMAIL PROTECTED] wrote:
+struct device *class_find_device(struct class *class, void *data,
+int (*match)(struct device *, void *))
+{
+ struct device *dev;
+
+ if (!class)
+ return NULL;
+
+ mutex_lock(class-mutex);
+ list_for_each_entry(dev, class-devices, node)
+ if (match(dev, data) get_device(dev))
First get the reference and then drop it if the match function returns
0 to make this analogous to the other _find_device() functions?
It's just like other _find_device() functions. Are these more get/put
really needed?
The other _find_device() functions operate on klists, which means that
there is an implicit get while the element is handled. This function
operates on a normal list, which means that getting/putting the
reference looks a bit different if we want the same effect.
Hi, you are right. Will be fixed.
Thanks.
-
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/3]: IO resource allocation using pci_request_selected_regions API
This patch modifies the IO resource allocation behavior of FUSION driver.
By using the pci_select_bars and pci_request_selected_regions API
The IORESOURCE_IO will be requested only when the driver needs the IO resource.
signed-off-by: Sathya Prakash [EMAIL PROTECTED]
---
diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c
index 52fb216..9476ad2 100644
--- a/drivers/message/fusion/mptbase.c
+++ b/drivers/message/fusion/mptbase.c
@@ -1470,9 +1470,6 @@ mpt_attach(struct pci_dev *pdev, const struct
pci_device_id *id)
if (mpt_debug_level)
printk(KERN_INFO MYNAM : mpt_debug_level=%xh\n,
mpt_debug_level);
- if (pci_enable_device(pdev))
- return r;
-
ioc = kzalloc(sizeof(MPT_ADAPTER), GFP_ATOMIC);
if (ioc == NULL) {
printk(KERN_ERR MYNAM : ERROR - Insufficient memory to add
adapter!\n);
@@ -1482,6 +1479,20 @@ mpt_attach(struct pci_dev *pdev, const struct
pci_device_id *id)
ioc-id = mpt_ids++;
sprintf(ioc-name, ioc%d, ioc-id);
+ ioc-bars = pci_select_bars(pdev, IORESOURCE_MEM);
+ if (pci_enable_device_bars(pdev, ioc-bars)) {
+ kfree(ioc);
+ printk(MYIOC_s_ERR_FMT pci_enable_device_bars() with MEM
+ failed\n,ioc-name);
+ return r;
+ }
+ if (pci_request_selected_regions(pdev, ioc-bars, mpt)) {
+ kfree(ioc);
+ printk(MYIOC_s_ERR_FMT pci_request_selected_regions() with
+ MEM failed\n,ioc-name);
+ return r;
+ }
+
dinitprintk(ioc, printk(MYIOC_s_INFO_FMT : mpt_adapter_install\n,
ioc-name));
if (!pci_set_dma_mask(pdev, DMA_64BIT_MASK)) {
@@ -1791,6 +1802,7 @@ mpt_suspend(struct pci_dev *pdev, pm_message_t state)
CHIPREG_WRITE32(ioc-chip-IntStatus, 0);
pci_disable_device(pdev);
+ pci_release_selected_regions(pdev, ioc-bars);
pci_set_power_state(pdev, device_state);
return 0;
@@ -1807,7 +1819,6 @@ mpt_resume(struct pci_dev *pdev)
MPT_ADAPTER *ioc = pci_get_drvdata(pdev);
u32 device_state = pdev-current_state;
int recovery_state;
- int err;
printk(MYIOC_s_INFO_FMT
pci-resume: pdev=0x%p, slot=%s, Previous operating state [D%d]\n,
@@ -1815,9 +1826,15 @@ mpt_resume(struct pci_dev *pdev)
pci_set_power_state(pdev, 0);
pci_restore_state(pdev);
- err = pci_enable_device(pdev);
- if (err)
- return err;
+ if (ioc-facts.Flags MPI_IOCFACTS_FLAGS_FW_DOWNLOAD_BOOT)
+ ioc-bars = pci_select_bars(ioc-pcidev, IORESOURCE_MEM |
+ IORESOURCE_IO);
+ else
+ ioc-bars = pci_select_bars(pdev, IORESOURCE_MEM);
+ if (pci_enable_device_bars(pdev, ioc-bars))
+ return 0;
+ if (pci_request_selected_regions(pdev, ioc-bars, mpt))
+ return 0;
/* enable interrupts */
CHIPREG_WRITE32(ioc-chip-IntMask, MPI_HIM_DIM);
@@ -1878,6 +1895,7 @@ mpt_signal_reset(u8 index, MPT_ADAPTER *ioc, int
reset_phase)
* -2 if READY but IOCFacts Failed
* -3 if READY but PrimeIOCFifos Failed
* -4 if READY but IOCInit Failed
+ * -5 if failed to enable_device_bars and/or
request_selected_regions
*/
static int
mpt_do_ioc_recovery(MPT_ADAPTER *ioc, u32 reason, int sleepFlag)
@@ -1976,6 +1994,18 @@ mpt_do_ioc_recovery(MPT_ADAPTER *ioc, u32 reason, int
sleepFlag)
}
}
+ if ((ret == 0) (reason == MPT_HOSTEVENT_IOC_BRINGUP)
+ (ioc-facts.Flags MPI_IOCFACTS_FLAGS_FW_DOWNLOAD_BOOT)) {
+ pci_release_selected_regions(ioc-pcidev, ioc-bars);
+ ioc-bars = pci_select_bars(ioc-pcidev, IORESOURCE_MEM |
+ IORESOURCE_IO);
+ if (pci_enable_device_bars(ioc-pcidev, ioc-bars))
+ return -5;
+ if (pci_request_selected_regions(ioc-pcidev, ioc-bars,
+ mpt))
+ return -5;
+ }
+
/*
* Device is reset now. It must have de-asserted the interrupt line
* (if it was asserted) and it should be safe to register for the
@@ -2385,6 +2415,9 @@ mpt_adapter_dispose(MPT_ADAPTER *ioc)
ioc-memmap = NULL;
}
+ pci_disable_device(ioc-pcidev);
+ pci_release_selected_regions(ioc-pcidev, ioc-bars);
+
#if defined(CONFIG_MTRR) 0
if (ioc-mtrr_reg 0) {
mtrr_del(ioc-mtrr_reg, 0, 0);
diff --git a/drivers/message/fusion/mptbase.h b/drivers/message/fusion/mptbase.h
index d7682e0..4031c15 100644
--- a/drivers/message/fusion/mptbase.h
+++ b/drivers/message/fusion/mptbase.h
@@ -629,6 +629,7 @@ typedef struct _MPT_ADAPTER
dma_addr_t HostPageBuffer_dma;
int mtrr_reg;
struct pci_dev *pcidev;/* struct pci_dev
[PATCH 1/3] mpt fusion: IO resource allocation using pci_request_selected_regions API [Resent]
This patch modifies the IO resource allocation behavior of FUSION driver.
By using the pci_select_bars and pci_request_selected_regions API
The IORESOURCE_IO will be requested only when the driver needs the IO resource.
signed-off-by: Sathya Prakash [EMAIL PROTECTED]
---
diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c
index 52fb216..9476ad2 100644
--- a/drivers/message/fusion/mptbase.c
+++ b/drivers/message/fusion/mptbase.c
@@ -1470,9 +1470,6 @@ mpt_attach(struct pci_dev *pdev, const struct
pci_device_id *id)
if (mpt_debug_level)
printk(KERN_INFO MYNAM : mpt_debug_level=%xh\n,
mpt_debug_level);
- if (pci_enable_device(pdev))
- return r;
-
ioc = kzalloc(sizeof(MPT_ADAPTER), GFP_ATOMIC);
if (ioc == NULL) {
printk(KERN_ERR MYNAM : ERROR - Insufficient memory to add
adapter!\n);
@@ -1482,6 +1479,20 @@ mpt_attach(struct pci_dev *pdev, const struct
pci_device_id *id)
ioc-id = mpt_ids++;
sprintf(ioc-name, ioc%d, ioc-id);
+ ioc-bars = pci_select_bars(pdev, IORESOURCE_MEM);
+ if (pci_enable_device_bars(pdev, ioc-bars)) {
+ kfree(ioc);
+ printk(MYIOC_s_ERR_FMT pci_enable_device_bars() with MEM
+ failed\n,ioc-name);
+ return r;
+ }
+ if (pci_request_selected_regions(pdev, ioc-bars, mpt)) {
+ kfree(ioc);
+ printk(MYIOC_s_ERR_FMT pci_request_selected_regions() with
+ MEM failed\n,ioc-name);
+ return r;
+ }
+
dinitprintk(ioc, printk(MYIOC_s_INFO_FMT : mpt_adapter_install\n,
ioc-name));
if (!pci_set_dma_mask(pdev, DMA_64BIT_MASK)) {
@@ -1791,6 +1802,7 @@ mpt_suspend(struct pci_dev *pdev, pm_message_t state)
CHIPREG_WRITE32(ioc-chip-IntStatus, 0);
pci_disable_device(pdev);
+ pci_release_selected_regions(pdev, ioc-bars);
pci_set_power_state(pdev, device_state);
return 0;
@@ -1807,7 +1819,6 @@ mpt_resume(struct pci_dev *pdev)
MPT_ADAPTER *ioc = pci_get_drvdata(pdev);
u32 device_state = pdev-current_state;
int recovery_state;
- int err;
printk(MYIOC_s_INFO_FMT
pci-resume: pdev=0x%p, slot=%s, Previous operating state [D%d]\n,
@@ -1815,9 +1826,15 @@ mpt_resume(struct pci_dev *pdev)
pci_set_power_state(pdev, 0);
pci_restore_state(pdev);
- err = pci_enable_device(pdev);
- if (err)
- return err;
+ if (ioc-facts.Flags MPI_IOCFACTS_FLAGS_FW_DOWNLOAD_BOOT)
+ ioc-bars = pci_select_bars(ioc-pcidev, IORESOURCE_MEM |
+ IORESOURCE_IO);
+ else
+ ioc-bars = pci_select_bars(pdev, IORESOURCE_MEM);
+ if (pci_enable_device_bars(pdev, ioc-bars))
+ return 0;
+ if (pci_request_selected_regions(pdev, ioc-bars, mpt))
+ return 0;
/* enable interrupts */
CHIPREG_WRITE32(ioc-chip-IntMask, MPI_HIM_DIM);
@@ -1878,6 +1895,7 @@ mpt_signal_reset(u8 index, MPT_ADAPTER *ioc, int
reset_phase)
* -2 if READY but IOCFacts Failed
* -3 if READY but PrimeIOCFifos Failed
* -4 if READY but IOCInit Failed
+ * -5 if failed to enable_device_bars and/or
request_selected_regions
*/
static int
mpt_do_ioc_recovery(MPT_ADAPTER *ioc, u32 reason, int sleepFlag)
@@ -1976,6 +1994,18 @@ mpt_do_ioc_recovery(MPT_ADAPTER *ioc, u32 reason, int
sleepFlag)
}
}
+ if ((ret == 0) (reason == MPT_HOSTEVENT_IOC_BRINGUP)
+ (ioc-facts.Flags MPI_IOCFACTS_FLAGS_FW_DOWNLOAD_BOOT)) {
+ pci_release_selected_regions(ioc-pcidev, ioc-bars);
+ ioc-bars = pci_select_bars(ioc-pcidev, IORESOURCE_MEM |
+ IORESOURCE_IO);
+ if (pci_enable_device_bars(ioc-pcidev, ioc-bars))
+ return -5;
+ if (pci_request_selected_regions(ioc-pcidev, ioc-bars,
+ mpt))
+ return -5;
+ }
+
/*
* Device is reset now. It must have de-asserted the interrupt line
* (if it was asserted) and it should be safe to register for the
@@ -2385,6 +2415,9 @@ mpt_adapter_dispose(MPT_ADAPTER *ioc)
ioc-memmap = NULL;
}
+ pci_disable_device(ioc-pcidev);
+ pci_release_selected_regions(ioc-pcidev, ioc-bars);
+
#if defined(CONFIG_MTRR) 0
if (ioc-mtrr_reg 0) {
mtrr_del(ioc-mtrr_reg, 0, 0);
diff --git a/drivers/message/fusion/mptbase.h b/drivers/message/fusion/mptbase.h
index d7682e0..4031c15 100644
--- a/drivers/message/fusion/mptbase.h
+++ b/drivers/message/fusion/mptbase.h
@@ -629,6 +629,7 @@ typedef struct _MPT_ADAPTER
dma_addr_t HostPageBuffer_dma;
int mtrr_reg;
struct pci_dev *pcidev;/* struct
Re: [patch 1/1] blktrace: Add blktrace ioctls to SCSI generic devices
On Mon, Jan 07 2008, Christof Schmitt wrote: From: Christof Schmitt [EMAIL PROTECTED] Since the SCSI layer uses the request queues from the block layer, blktrace can also be used to trace the requests to all SCSI devices (like SCSI tape drives), not only disks. The only missing part is the ioctl interface to start and stop tracing. This patch adds the SETUP, START, STOP and TEARDOWN ioctls from blktrace to the sg device files. With this change, blktrace can be used for SCSI devices like for disks, e.g.: blktrace -d /dev/sg1 -o - | blkparse -i - Signed-off-by: Christof Schmitt [EMAIL PROTECTED] Looks fine to me, queued up for 2.6.25. -- 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] cciss: section mismatch
On Thu, Jan 10 2008, Randy Dunlap wrote: From: Randy Dunlap [EMAIL PROTECTED] Mark cciss_pci_init() as __devinit, to fix section mismatch warning. WARNING: vmlinux.o(.text+0x601fc9): Section mismatch: reference to .init.text: (between 'cciss_pci_init' and 'cciss_getgeometry') Thanks Randy, added. -- 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] Don't blatt first element of prv in sg_chain()
On Mon, Jan 07 2008, Rusty Russell wrote: I realize that sg chaining is a ploy to make the rest of the kernel devs feel the pain of the SCSI subsystem. But this was a little unsubtle. Signed-off-by: Rusty Russell [EMAIL PROTECTED] diff -r b3aec596b841 include/linux/scatterlist.h --- a/include/linux/scatterlist.h Mon Jan 07 12:43:56 2008 +1100 +++ b/include/linux/scatterlist.h Mon Jan 07 15:01:51 2008 +1100 @@ -188,8 +188,8 @@ static inline void sg_chain(struct scatt /* * offset and length are unused for chain entry. Clear them. */ - prv-offset = 0; - prv-length = 0; + prv[prv_nents - 1].offset = 0; + prv[prv_nents - 1].length = 0; /* * Set lowest bit to indicate a link pointer, and make sure to clear Dang, I should have caught that. Thanks Rusty... -- 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
[PATCH 3/3] mpt fusion: Fix for module load error when mptctl and mptsas are loaded in parallel
This patch fixes a panic at mptctl_probe - mutex_init if the mptsas and mptcl
module are loaded in parallel, this is because IOC is NULL, the fix is in
mpt_device_register to call probe only with non-zero IOC pointer.
signed-off-by: Sathya Prakash [EMAIL PROTECTED]
---
diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c
index d733438..042bc86 100644
--- a/drivers/message/fusion/mptbase.c
+++ b/drivers/message/fusion/mptbase.c
@@ -729,6 +729,8 @@ mpt_device_driver_register(struct mpt_pci_driver *
dd_cbfunc, u8 cb_idx)
/* call per pci device probe entry point */
list_for_each_entry(ioc, ioc_list, list) {
+ if (!pci_get_drvdata(ioc-pcidev))
+ continue;
id = ioc-pcidev-driver ?
ioc-pcidev-driver-id_table : NULL;
if (dd_cbfunc-probe)
-
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 2/3] mpt fusion: Fix for module unload problem in flash less controller environment
This patch fixes the module unload problem in flash less 1030 controller
environment where firmware download boot functionality is invoked.
The problem is due to the firmware download is being done in the reverse order,
which this patch solves by insureing the download occurs to the last controller
being reset.
signed-off-by: Sathya Prakash [EMAIL PROTECTED]
---
diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c
index 9476ad2..d733438 100644
--- a/drivers/message/fusion/mptbase.c
+++ b/drivers/message/fusion/mptbase.c
@@ -2086,7 +2086,7 @@ mpt_do_ioc_recovery(MPT_ADAPTER *ioc, u32 reason, int
sleepFlag)
ddlprintk(ioc,
printk(MYIOC_s_DEBUG_FMT
mpt_upload: alt_%s has
cached_fw=%p \n,
ioc-name,
ioc-alt_ioc-name, ioc-alt_ioc-cached_fw));
- ioc-alt_ioc-cached_fw = NULL;
+ ioc-cached_fw = NULL;
}
} else {
printk(MYIOC_s_WARN_FMT
@@ -2292,10 +2292,12 @@ mpt_adapter_disable(MPT_ADAPTER *ioc)
int ret;
if (ioc-cached_fw != NULL) {
- ddlprintk(ioc, printk(MYIOC_s_INFO_FMT
- mpt_adapter_disable: Pushing FW onto adapter\n,
ioc-name));
- if ((ret = mpt_downloadboot(ioc, (MpiFwHeader_t
*)ioc-cached_fw, NO_SLEEP)) 0) {
- printk(MYIOC_s_WARN_FMT firmware downloadboot failure
(%d)!\n,
+ ddlprintk(ioc, printk(MYIOC_s_DEBUG_FMT %s: Pushing FW onto
+ adapter\n, __FUNCTION__, ioc-name));
+ if ((ret = mpt_downloadboot(ioc, (MpiFwHeader_t *)
+ ioc-cached_fw, CAN_SLEEP)) 0) {
+ printk(MYIOC_s_WARN_FMT
+ : firmware downloadboot failure (%d)!\n,
ioc-name, ret);
}
}
@@ -2333,13 +2335,7 @@ mpt_adapter_disable(MPT_ADAPTER *ioc)
ioc-alloc_total -= sz;
}
- if (ioc-cached_fw != NULL) {
- sz = ioc-facts.FWImageSize;
- pci_free_consistent(ioc-pcidev, sz,
- ioc-cached_fw, ioc-cached_fw_dma);
- ioc-cached_fw = NULL;
- ioc-alloc_total -= sz;
- }
+ mpt_free_fw_memory(ioc);
kfree(ioc-spi_data.nvram);
mpt_inactive_raid_list_free(ioc);
@@ -3080,44 +3076,62 @@ SendPortEnable(MPT_ADAPTER *ioc, int portnum, int
sleepFlag)
*
* If memory has already been allocated, the same (cached) value
* is returned.
- */
-void
+ *
+ * Return 0 if successfull, or non-zero for failure
+ **/
+int
mpt_alloc_fw_memory(MPT_ADAPTER *ioc, int size)
{
- if (ioc-cached_fw)
- return; /* use already allocated memory */
- if (ioc-alt_ioc ioc-alt_ioc-cached_fw) {
+ int rc;
+
+ if (ioc-cached_fw) {
+ rc = 0; /* use already allocated memory */
+ goto out;
+ }
+ else if (ioc-alt_ioc ioc-alt_ioc-cached_fw) {
ioc-cached_fw = ioc-alt_ioc-cached_fw; /* use alt_ioc's
memory */
ioc-cached_fw_dma = ioc-alt_ioc-cached_fw_dma;
- ioc-alloc_total += size;
- ioc-alt_ioc-alloc_total -= size;
+ rc = 0;
+ goto out;
+ }
+ ioc-cached_fw = pci_alloc_consistent(ioc-pcidev, size,
ioc-cached_fw_dma);
+ if (!ioc-cached_fw) {
+ printk(MYIOC_s_ERR_FMT Unable to allocate memory for the
cached firmware image!\n,
+ ioc-name);
+ rc = -1;
} else {
- if ( (ioc-cached_fw = pci_alloc_consistent(ioc-pcidev, size,
ioc-cached_fw_dma) ) )
- ioc-alloc_total += size;
+ dinitprintk(ioc, printk(MYIOC_s_DEBUG_FMT FW Image @ %p[%p],
sz=%d[%x] bytes\n,
+ ioc-name, ioc-cached_fw, (void
*)(ulong)ioc-cached_fw_dma, size, size));
+ ioc-alloc_total += size;
+ rc = 0;
}
+ out:
+ return rc;
}
+
/**
* mpt_free_fw_memory - free firmware memory
* @ioc: Pointer to MPT_ADAPTER structure
*
* If alt_img is NULL, delete from ioc structure.
* Else, delete a secondary image in same format.
- */
+ **/
void
mpt_free_fw_memory(MPT_ADAPTER *ioc)
{
int sz;
+ if (!ioc-cached_fw)
+ return;
+
sz = ioc-facts.FWImageSize;
- dinitprintk(ioc, printk(MYIOC_s_INFO_FMT free_fw_memory: FW Image @
%p[%p], sz=%d[%x] bytes\n,
- ioc-name, ioc-cached_fw, (void *)(ulong)ioc-cached_fw_dma, sz,
sz));
+ dinitprintk(ioc, printk(MYIOC_s_DEBUG_FMT free_fw_memory: FW Image @
%p[%p], sz=%d[%x] bytes\n,
+
Re: [PATCH 1/3]: IO resource allocation using pci_request_selected_regions API
On Fri, Jan 11, 2008 at 02:33:30PM +0530, Prakash, Sathya wrote: This patch modifies the IO resource allocation behavior of FUSION driver. By using the pci_select_bars and pci_request_selected_regions API The IORESOURCE_IO will be requested only when the driver needs the IO resource. Didn't benh or someone else just replace pci_request_selected_regions with a less braindead API? - 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 Jan 11, 2008 7:16 AM, James Bottomley
[EMAIL PROTECTED] wrote:
On Fri, 2008-01-04 at 02:18 +0200, Filippos Papadopoulos wrote:
First of all let me wish a happy new year.
I come back from the vacations and i compiled the initio driver with
#define DEBUG_INTERRUPT 1
#define DEBUG_QUEUE 1
#define DEBUG_STATE 1
#define INT_DISC1
I used the sources from 2.6.24-rc6-git9 kernel. At kernel boot time the
initio
driver prints the following:
scsi: Initio INI-9X00U/UW SCSI device driver
Find scb at c0c0
Append pend scb c0c0;
After 3 seconds the whole system freezes there and i have to reboot.
P.S here is the info from 'lspci -vv' running 2.6.16.13 kernel:
00:08.0 SCSI storage controller: Initio Corporation 360P (rev 02)
Subsystem: Unknown device 9292:0202
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
TAbort- TAbort- MAbort- SERR- PERR-
Latency: 32, Cache Line Size 08
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at d000 [size=256]
This proves the BAR0 to be non zero, but I also take it from your report
that the
initio: I/O port range 0x0 is busy.
message is also gone?
I havent reported initio: I/O port range 0x0 is busy.
Region 1: Memory at ef00 (32-bit, non-prefetchable) [size=4K]
[virtual] Expansion ROM at 5000 [disabled] [size=128K]
I think there's still one remaining bug from the sg_list conversion,
namely that cblk-sglen is never set, but it is used to count the number
of elements in the sg array. Could you try this patch (on top of
everything else) and see if the problem is finally fixed?
I applied the patch on 2.6.24-rc6-git9 but unfortunatelly same thing happens.
Thanks,
James
---
diff --git a/drivers/scsi/initio.c b/drivers/scsi/initio.c
index 01bf018..d038459 100644
--- a/drivers/scsi/initio.c
+++ b/drivers/scsi/initio.c
@@ -2603,6 +2603,7 @@ static void initio_build_scb(struct initio_host * host,
struct scsi_ctrl_blk * c
nseg = scsi_dma_map(cmnd);
BUG_ON(nseg 0);
if (nseg) {
+ cblk-sglen = nseg;
dma_addr = dma_map_single(host-pci_dev-dev,
cblk-sglist[0],
sizeof(struct sg_entry) *
TOTAL_SG_ENTRY,
DMA_BIDIRECTIONAL);
-
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
MPT Fusion initialization in 2.6.23.12
Hi, I have this server with an LSI Logic SAS1064 RAID enabled Ultra320 SCSI controller on the system board. I am running a vanilla 2.6.23.12 kernel. Everything runs well, except during the boot I see these logs in dmesg and the syslogs. mptbase: ioc0: IOCStatus(0x0022): Config Page Invalid Page: type=08h, page=00h, action=01h, form=0001h mptbase: ioc0: IOCStatus(0x0022): Config Page Invalid Page: type=08h, page=00h, action=01h, form=0003h mptbase: ioc0: IOCStatus(0x0022): Config Page Invalid Page: type=08h, page=00h, action=01h, form=0004h mptbase: ioc0: IOCStatus(0x0022): Config Page Invalid Page: type=08h, page=00h, action=01h, form=0005h mptbase: ioc0: IOCStatus(0x0022): Config Page Invalid Page: type=08h, page=00h, action=01h, form=0006h mptbase: ioc0: IOCStatus(0x0022): Config Page Invalid Page: type=08h, page=00h, action=01h, form=0007h mptbase: ioc0: IOCStatus(0x0022): Config Page Invalid Page: type=08h, page=00h, action=01h, form=0008h mptbase: ioc0: IOCStatus(0x0022): Config Page Invalid Page: type=08h, page=00h, action=01h, form=0009h mptbase: ioc0: IOCStatus(0x0022): Config Page Invalid Page: type=08h, page=00h, action=01h, form=000Ah mptbase: ioc0: IOCStatus(0x0022): Config Page Invalid Page: type=08h, page=00h, action=01h, form=000Bh mptbase: ioc0: IOCStatus(0x0022): Config Page Invalid Page: type=08h, page=00h, action=01h, form=000Ch mptbase: ioc0: IOCStatus(0x0022): Config Page Invalid Page: type=08h, page=00h, action=01h, form=000Dh mptbase: ioc0: IOCStatus(0x0022): Config Page Invalid Page: type=08h, page=00h, action=01h, form=000Eh mptbase: ioc0: IOCStatus(0x0022): Config Page Invalid Page: type=08h, page=00h, action=01h, form=000Fh I've traced through the mptbase.c code and can see these invalid config pages are read from the controller during initialization. This doesn't appear to cause any ill effects, but I am wondering how to resolve this? Maybe a MPT BIOS or MPT firmware upgrade will fix this? Thanks, Karen -- Karen Shaeffer Neuralscape, Palo Alto, Ca. 94306 [EMAIL PROTECTED] http://www.neuralscape.com - 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: Linux scsi / usb-mass-storage and HP printer cardreader bug + fix
Boaz Harrosh wrote: On Thu, Jan 10 2008 at 12:52 +0200, Hans de Goede [EMAIL PROTECTED] wrote: I'm not sure what the proper solution should be? I guess the proper solution would be to add a special case to the scsi layer where the read10 / write10 command is issued, and split the request in 2 there when it involves the last sector. There was another reply in this thread stating that problems reading the last sector with sd / mmc cards happen quite often, and that this is most likely not an isolated case. Regards, Hans Yes, you're right. in ULDs it is a much proper way to do this. So I guess you'll have to do that special host flag or device flag, and add a check for it in sd.c. You'll see that sd.c is already doing bufflen truncation at sd_prep_fn(), just add one more case. Yes, That will work nicely, I'll write an updated patch this evening (when I have access to the printer to test again). Regards, Hans - 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: INITIO scsi driver fails to work properly
On Fri, 2008-01-11 at 11:54 +0200, Filippos Papadopoulos wrote: On Jan 11, 2008 7:16 AM, James Bottomley [EMAIL PROTECTED] wrote: On Fri, 2008-01-04 at 02:18 +0200, Filippos Papadopoulos wrote: First of all let me wish a happy new year. I come back from the vacations and i compiled the initio driver with #define DEBUG_INTERRUPT 1 #define DEBUG_QUEUE 1 #define DEBUG_STATE 1 #define INT_DISC1 I used the sources from 2.6.24-rc6-git9 kernel. At kernel boot time the initio driver prints the following: scsi: Initio INI-9X00U/UW SCSI device driver Find scb at c0c0 Append pend scb c0c0; After 3 seconds the whole system freezes there and i have to reboot. P.S here is the info from 'lspci -vv' running 2.6.16.13 kernel: 00:08.0 SCSI storage controller: Initio Corporation 360P (rev 02) Subsystem: Unknown device 9292:0202 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 32, Cache Line Size 08 Interrupt: pin A routed to IRQ 11 Region 0: I/O ports at d000 [size=256] This proves the BAR0 to be non zero, but I also take it from your report that the initio: I/O port range 0x0 is busy. message is also gone? I havent reported initio: I/O port range 0x0 is busy. Sorry ... we appear to have several reporters of different bugs in this thread. That message was copied by Chuck Ebbert from a Red Hat bugzilla ... I was assuming it was the same problem. Region 1: Memory at ef00 (32-bit, non-prefetchable) [size=4K] [virtual] Expansion ROM at 5000 [disabled] [size=128K] I think there's still one remaining bug from the sg_list conversion, namely that cblk-sglen is never set, but it is used to count the number of elements in the sg array. Could you try this patch (on top of everything else) and see if the problem is finally fixed? I applied the patch on 2.6.24-rc6-git9 but unfortunatelly same thing happens. First off, has this driver ever worked for you in 2.6? Just booting SLES9 (2.6.5) or RHEL4 (2.6.9) ... or one of their open equivalents to check a really old kernel would be helpful. If you can get it to work, then we can proceed with a patch reversion regime based on the assumption that the problem is a recent commit. Thanks, 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: [PATCH 1/3] mpt fusion: IO resource allocation using pci_request_selected_regions API [Resent]
On Jan 11, 2008 1:07 AM, Prakash, Sathya [EMAIL PROTECTED] wrote:
This patch modifies the IO resource allocation behavior of FUSION driver.
By using the pci_select_bars and pci_request_selected_regions API
The IORESOURCE_IO will be requested only when the driver needs the IO
resource.
The plan on linux-pci is to remove and replace pci_select_bars()
and pci_enable_bars() with pci_enable_device_mmio() and pci_enable_device_io().
This is because PCI only has two bits in the config space command
register of each device to enable or disable decoding of either address space
no control over individual BARs.
See the Dec 2007 linux-pci achives. e.g.:
http://marc.info/?l=linux-pcim=119793439127148w=2
and
http://marc.info/?l=linux-kernelm=119848021005444w=2
cheers,
grant
signed-off-by: Sathya Prakash [EMAIL PROTECTED]
---
diff --git a/drivers/message/fusion/mptbase.c
b/drivers/message/fusion/mptbase.c
index 52fb216..9476ad2 100644
--- a/drivers/message/fusion/mptbase.c
+++ b/drivers/message/fusion/mptbase.c
@@ -1470,9 +1470,6 @@ mpt_attach(struct pci_dev *pdev, const struct
pci_device_id *id)
if (mpt_debug_level)
printk(KERN_INFO MYNAM : mpt_debug_level=%xh\n,
mpt_debug_level);
- if (pci_enable_device(pdev))
- return r;
-
ioc = kzalloc(sizeof(MPT_ADAPTER), GFP_ATOMIC);
if (ioc == NULL) {
printk(KERN_ERR MYNAM : ERROR - Insufficient memory to add
adapter!\n);
@@ -1482,6 +1479,20 @@ mpt_attach(struct pci_dev *pdev, const struct
pci_device_id *id)
ioc-id = mpt_ids++;
sprintf(ioc-name, ioc%d, ioc-id);
+ ioc-bars = pci_select_bars(pdev, IORESOURCE_MEM);
+ if (pci_enable_device_bars(pdev, ioc-bars)) {
+ kfree(ioc);
+ printk(MYIOC_s_ERR_FMT pci_enable_device_bars() with MEM
+ failed\n,ioc-name);
+ return r;
+ }
+ if (pci_request_selected_regions(pdev, ioc-bars, mpt)) {
+ kfree(ioc);
+ printk(MYIOC_s_ERR_FMT pci_request_selected_regions() with
+ MEM failed\n,ioc-name);
+ return r;
+ }
+
dinitprintk(ioc, printk(MYIOC_s_INFO_FMT : mpt_adapter_install\n,
ioc-name));
if (!pci_set_dma_mask(pdev, DMA_64BIT_MASK)) {
@@ -1791,6 +1802,7 @@ mpt_suspend(struct pci_dev *pdev, pm_message_t state)
CHIPREG_WRITE32(ioc-chip-IntStatus, 0);
pci_disable_device(pdev);
+ pci_release_selected_regions(pdev, ioc-bars);
pci_set_power_state(pdev, device_state);
return 0;
@@ -1807,7 +1819,6 @@ mpt_resume(struct pci_dev *pdev)
MPT_ADAPTER *ioc = pci_get_drvdata(pdev);
u32 device_state = pdev-current_state;
int recovery_state;
- int err;
printk(MYIOC_s_INFO_FMT
pci-resume: pdev=0x%p, slot=%s, Previous operating state [D%d]\n,
@@ -1815,9 +1826,15 @@ mpt_resume(struct pci_dev *pdev)
pci_set_power_state(pdev, 0);
pci_restore_state(pdev);
- err = pci_enable_device(pdev);
- if (err)
- return err;
+ if (ioc-facts.Flags MPI_IOCFACTS_FLAGS_FW_DOWNLOAD_BOOT)
+ ioc-bars = pci_select_bars(ioc-pcidev, IORESOURCE_MEM |
+ IORESOURCE_IO);
+ else
+ ioc-bars = pci_select_bars(pdev, IORESOURCE_MEM);
+ if (pci_enable_device_bars(pdev, ioc-bars))
+ return 0;
+ if (pci_request_selected_regions(pdev, ioc-bars, mpt))
+ return 0;
/* enable interrupts */
CHIPREG_WRITE32(ioc-chip-IntMask, MPI_HIM_DIM);
@@ -1878,6 +1895,7 @@ mpt_signal_reset(u8 index, MPT_ADAPTER *ioc, int
reset_phase)
* -2 if READY but IOCFacts Failed
* -3 if READY but PrimeIOCFifos Failed
* -4 if READY but IOCInit Failed
+ * -5 if failed to enable_device_bars and/or
request_selected_regions
*/
static int
mpt_do_ioc_recovery(MPT_ADAPTER *ioc, u32 reason, int sleepFlag)
@@ -1976,6 +1994,18 @@ mpt_do_ioc_recovery(MPT_ADAPTER *ioc, u32 reason, int
sleepFlag)
}
}
+ if ((ret == 0) (reason == MPT_HOSTEVENT_IOC_BRINGUP)
+ (ioc-facts.Flags MPI_IOCFACTS_FLAGS_FW_DOWNLOAD_BOOT)) {
+ pci_release_selected_regions(ioc-pcidev, ioc-bars);
+ ioc-bars = pci_select_bars(ioc-pcidev, IORESOURCE_MEM |
+ IORESOURCE_IO);
+ if (pci_enable_device_bars(ioc-pcidev, ioc-bars))
+ return -5;
+ if (pci_request_selected_regions(ioc-pcidev, ioc-bars,
+ mpt))
+ return -5;
+ }
+
/*
* Device is reset now. It must have de-asserted the interrupt line
* (if it was asserted) and it should be safe to register for the
@@ -2385,6 +2415,9 @@ mpt_adapter_dispose(MPT_ADAPTER
Re: INITIO scsi driver fails to work properly
On Jan 11, 2008 5:44 PM, James Bottomley [EMAIL PROTECTED] wrote: I havent reported initio: I/O port range 0x0 is busy. Sorry ... we appear to have several reporters of different bugs in this thread. That message was copied by Chuck Ebbert from a Red Hat bugzilla ... I was assuming it was the same problem. I applied the patch on 2.6.24-rc6-git9 but unfortunatelly same thing happens. First off, has this driver ever worked for you in 2.6? Just booting SLES9 (2.6.5) or RHEL4 (2.6.9) ... or one of their open equivalents to check a really old kernel would be helpful. If you can get it to work, then we can proceed with a patch reversion regime based on the assumption that the problem is a recent commit. Yes it works under 2.6.16.13. See the beginning of this thread, i mention there some things about newer versions. Thanks, 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: [PATCH 1/1] aacraid: add call to flush_kernel_dcache_page for architectures that require it.
On Tue, 2008-01-08 at 12:09 -0800, Salyzyn, Mark wrote: Some architectures require a call to flush_kernel_dcache_page for processor spoofed DMA operations. This attached patch is against current scsi-misc-2.6. ObligatoryDisclaimer: Please accept my condolences regarding Outlook's handling of patch attachments (inline gets damaged, use attachment). Signed-off-by: Mark Salyzyn [EMAIL PROTECTED] aachba.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff -ru a/drivers/scsi/aacraid/aachba.c b/drivers/scsi/aacraid/aachba.c --- a/drivers/scsi/aacraid/aachba.c 2008-01-08 15:01:21.503932722 -0500 +++ b/drivers/scsi/aacraid/aachba.c 2008-01-08 15:02:35.849634368 -0500 @@ -31,9 +31,9 @@ #include linux/slab.h #include linux/completion.h #include linux/blkdev.h -#include linux/dma-mapping.h #include asm/semaphore.h #include asm/uaccess.h +#include linux/highmem.h /* For flush_kernel_dcache_page */ #include scsi/scsi.h #include scsi/scsi_cmnd.h @@ -366,6 +366,9 @@ if (buf transfer_len 0) memcpy(buf + offset, data, transfer_len); +#ifdef ARCH_HAS_FLUSH_ANON_PAGE + flush_kernel_dcache_page(kmap_atomic_to_page(buf - sg-offset)); +#endif This #ifdef/#endif guard is unnecessary ... flush_kernel_dcache_page() is available on all architectures (it's a nop on most). However, ARCH_HAS_FLUSH_ANON_PAGE is the wrong guard anyway ... that's for the flush_anon_page() function ... 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
[RFC] aacraid: driver feature flags?
Feature enhancement.
Do we have a developing standard on how a driver may report to user tools via
sysfs what features are supported or not by the driver? In the following I am
proposing a 'flags' entry that will reside in the host controllers tree, with a
newline separated list of arbitrary ascii named features that indicate whether
the combination of driver and controller has support for said feature. Breaking
from the one-line output typical of sysfs entries, newline was added to tailor
for grep, or simple gets line by line string match within an application. I
added one for a compiler time check for existence of debug print output, one
for an optional manifest defined enhanced status reporting in the logs, and one
for runtime reporting whether the controller and driver supports arrays larger
than 2TB to my example below.
Suggestions?
This following patch is against current scsi-misc-2.6
ObligatoryDisclaimer: Please accept my condolences regarding Outlook's handling
of patch attachments, so one can NOT use the following to patch, it is only
present to demonstrate the idea.
drivers/scsi/aacraid/linit.c | 25 +
1 file changed, 25 insertions(+)
diff -ru a/drivers/scsi/aacraid/linit.c b/drivers/scsi/aacraid/linit.c
--- a/drivers/scsi/aacraid/linit.c 2008-01-11 11:19:11.378159940 -0500
+++ b/drivers/scsi/aacraid/linit.c 2008-01-11 11:23:19.040145945 -0500
@@ -788,6 +788,23 @@
return len;
}
+static ssize_t aac_show_flags(struct class_device *class_dev, char *buf)
+{
+ int len = 0;
+ struct aac_dev *dev = (struct
aac_dev*)class_to_shost(class_dev)-hostdata;
+
+ if (nblank(dprintk(x)))
+ len = snprintf(buf, PAGE_SIZE, dprintk\n);
+# ifdef AAC_DETAILED_STATUS_INFO
+ len += snprintf(buf + len, PAGE_SIZE - len,
+ AAC_DETAILED_STATUS_INFO\n);
+# endif
+ if (dev-raw_io_interface dev-raw_io_64)
+ len += snprintf(buf + len, PAGE_SIZE - len,
+ SAI_READ_CAPACITY_16\n);
+ return len;
+}
+
static ssize_t aac_show_kernel_version(struct class_device *class_dev,
char *buf)
{
@@ -897,6 +914,13 @@
},
.show = aac_show_vendor,
};
+static struct class_device_attribute aac_flags = {
+ .attr = {
+ .name = flags,
+ .mode = S_IRUGO,
+ },
+ .show = aac_show_flags,
+};
static struct class_device_attribute aac_kernel_version = {
.attr = {
.name = hba_kernel_version,
@@ -951,6 +975,7 @@
static struct class_device_attribute *aac_attrs[] = {
aac_model,
aac_vendor,
+ aac_flags,
aac_kernel_version,
aac_monitor_version,
aac_bios_version,
-
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] aacraid: respond to enclosure service events
Feature enhancement. Added support to respond to enclosure service events (controller AIFs) to add, online or offline physical targets reported to sg. Also added online and offlining of arrays. Removed an automatic variable definition in a sub block that hid an earlier definition, determined to be inert as the sub-block use did not interfere. Bumped the driver versioning to stamp the addition of this feature. This attached patch is against current scsi-misc-2.6 *after* series of patches from past week are applied, as there is some overlap on the aacraid.h file. ObligatoryDisclaimer: Please accept my condolences regarding Outlook's handling of patch attachments. Signed-off-by: Mark Salyzyn [EMAIL PROTECTED] drivers/scsi/aacraid/aacraid.h |5 +- drivers/scsi/aacraid/commsup.c | 99 +++-- 2 files changed, 79 insertions(+), 25 deletions(-) Sincerely -- Mark Salyzyn aacraid_enclosure.patch Description: aacraid_enclosure.patch
Re: INITIO scsi driver fails to work properly
On 01/11/2008 10:44 AM, James Bottomley wrote: This proves the BAR0 to be non zero, but I also take it from your report that the initio: I/O port range 0x0 is busy. message is also gone? I havent reported initio: I/O port range 0x0 is busy. Sorry ... we appear to have several reporters of different bugs in this thread. That message was copied by Chuck Ebbert from a Red Hat bugzilla ... I was assuming it was the same problem. Our reporter has applied patches since then and now reports the exact same symptoms that Filippos does. (It just hangs after loading the 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] cciss: section mismatch
On Thu, Jan 10, 2008 at 02:32:35PM -0800, Randy Dunlap wrote: From: Randy Dunlap [EMAIL PROTECTED] Mark cciss_pci_init() as __devinit, to fix section mismatch warning. WARNING: vmlinux.o(.text+0x601fc9): Section mismatch: reference to .init.text: (between 'cciss_pci_init' and 'cciss_getgeometry') Signed-off-by: Randy Dunlap [EMAIL PROTECTED] Acked-by: Sam Ravnborg [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: [PATCH 1/3]: IO resource allocation using pci_request_selected_regions API
On Jan 11, 2008 1:28 AM, Christoph Hellwig [EMAIL PROTECTED] wrote: On Fri, Jan 11, 2008 at 02:33:30PM +0530, Prakash, Sathya wrote: This patch modifies the IO resource allocation behavior of FUSION driver. By using the pci_select_bars and pci_request_selected_regions API The IORESOURCE_IO will be requested only when the driver needs the IO resource. Didn't benh or someone else just replace pci_request_selected_regions with a less braindead API? yes - I just posted links to that: http://marc.info/?l=linux-pcim=119793439127148w=2 grant - 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 - 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 Fri, 2008-01-11 at 18:44 +0200, Filippos Papadopoulos wrote: On Jan 11, 2008 5:44 PM, James Bottomley [EMAIL PROTECTED] wrote: I havent reported initio: I/O port range 0x0 is busy. Sorry ... we appear to have several reporters of different bugs in this thread. That message was copied by Chuck Ebbert from a Red Hat bugzilla ... I was assuming it was the same problem. I applied the patch on 2.6.24-rc6-git9 but unfortunatelly same thing happens. First off, has this driver ever worked for you in 2.6? Just booting SLES9 (2.6.5) or RHEL4 (2.6.9) ... or one of their open equivalents to check a really old kernel would be helpful. If you can get it to work, then we can proceed with a patch reversion regime based on the assumption that the problem is a recent commit. Yes it works under 2.6.16.13. See the beginning of this thread, i mention there some things about newer versions. Thanks, actually, I see this: I tried to install OpenSUSE 10.3 (kernel 2.6.22.5) and the latest OpenSUSE 11.0 Alpha 0 (kernel 2.6.24-rc4) but although the initio drivergets loaded during the installation process, yast reports that no hard disk is found. Could you try with a vanilla 2.6.22 kernel? The reason for all of this is that 2.6.22 predates Alan's conversion of this driver (which was my 95% candidate for the source of the bug). I want you to try the vanilla kernel just in case the opensuse one contains a backport. Thanks, 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: [PATCH] cciss: section mismatch
--- linux-2.6.24-rc7-git1.orig/drivers/block/cciss.c
+++ linux-2.6.24-rc7-git1/drivers/block/cciss.c
@@ -2927,7 +2927,7 @@ default_int_mode:
return;
}
-static int cciss_pci_init(ctlr_info_t *c, struct pci_dev *pdev)
+static int __devinit cciss_pci_init(ctlr_info_t *c, struct pci_dev
+*pdev)
{
ushort subsystem_vendor_id, subsystem_device_id, command;
__u32 board_id, scratchpad = 0;
Thanks, Randy.
-
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: Linux scsi / usb-mass-storage and HP printer cardreader bug + fix
Hello, Le vendredi 11 janvier 2008 à 13:48 +0100, Hans de Goede a écrit : That will work nicely, I'll write an updated patch this evening (when I have access to the printer to test again). Great news, i am impatient to test this new patch. I may face an other bug with the Transcend 1GB SD card, would be possible that the patch would be available for latests kernels ? Thanks in advance, Best regards, Guillaume B. - 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 Fri, 2008-01-11 at 17:01 +, Alan Cox wrote: 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. The statement that OpenSuse 10.3, based on 2.6.22.5, also fails indicates there may be something else that predates your reorganisation at the root of this (depending on whether the vendor kernel contains a back port or not). That's why I want to see what happens on this system with a vanilla 2.6.22 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: [PATCH 3/3] mpt fusion: Fix for module load error when mptctl and mptsas are loaded in parallel
On Fri, 2008-01-11 at 14:46 +0530, Prakash, Sathya wrote:
This patch fixes a panic at mptctl_probe - mutex_init if the mptsas and
mptcl module are loaded in parallel, this is because IOC is NULL, the fix is
in mpt_device_register to call probe only with non-zero IOC pointer.
signed-off-by: Sathya Prakash [EMAIL PROTECTED]
---
diff --git a/drivers/message/fusion/mptbase.c
b/drivers/message/fusion/mptbase.c
index d733438..042bc86 100644
--- a/drivers/message/fusion/mptbase.c
+++ b/drivers/message/fusion/mptbase.c
@@ -729,6 +729,8 @@ mpt_device_driver_register(struct mpt_pci_driver *
dd_cbfunc, u8 cb_idx)
/* call per pci device probe entry point */
list_for_each_entry(ioc, ioc_list, list) {
+ if (!pci_get_drvdata(ioc-pcidev))
+ continue;
This looks rather dubious ... it doesn't fix the race, it just manifests
differently (and non fatally) by apparently not attaching the mptctl.
Isn't a better fix to set the drvdata earlier in the process, say in
mpt_attach *before* you add the ioc to the ioc_list? That way the race
can never occur in the first place.
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: [PATCH] qla2xyz: fix section mismatch
On Thu, Jan 10, 2008 at 02:33:09PM -0800, Randy Dunlap wrote: From: Randy Dunlap [EMAIL PROTECTED] Fix section mismatch: qla2x00_remove_one() should not be __devexit. WARNING: vmlinux.o(.text+0xb014f5): Section mismatch: reference to .exit.text: (between 'qla2xxx_pci_error_detected' and 'qla2xxx_pci_mmio_enabled') Signed-off-by: Randy Dunlap [EMAIL PROTECTED] Acked-by: Sam Ravnborg [EMAIL PROTECTED] This could oops under the wrong conditions. Sam - 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 6/10] lpfc 8.2.4 : Add additional sysfs and module parameters
On Fri, 2008-01-11 at 01:53 -0500, James Smart wrote: Made link speed and link topology modifiable via sysfs Make scatter gather Segment Count into a module parameter. Signed-off-by: James Smart [EMAIL PROTECTED] OK ... I put this in, but shouldn't at least the link speed and possibly topology modifications rightly be properties of the transport class? 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: [PATCH 5/10] lpfc 8.2.4 : Make lpfc legacy I/O port free
On Fri, 2008-01-11 at 01:53 -0500, James Smart wrote: Make lpfc legacy I/O port free This is a patch written by Tomohiro Kusumi and submitted to linux-scsi: http://marc.info/?l=linux-scsim=118673720712152w=2 The original patch comment: This patch makes Emulex lpfc driver legacy I/O port free. It has already been acked quite long time ago. So I resubmit the patch. http://lkml.org/lkml/2006/11/22/28 Current lpfc driver is already using pci_select_bars() and pci_enable_device_bars() when the PCI bus has been reset. So I think this patch should also be acked. Tomohiro Kusumi Signed-off-by: Tomohiro Kusumi [EMAIL PROTECTED] Signed-off-by: James Smart [EMAIL PROTECTED] You didn't check the diffstat of this one: lpfc_init.c | 11 lpfc_init.c.orig | 2475 ++- 2 files changed, 2481 insertions(+), 5 deletions(-) I've manually removed all references to the lpfc_init.c.orig file that popped into existence with this patch and was deleted with the subsequent one. 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: [usb-storage] PATCH: usb-storage-psc1350-v4.patch (was Linux scsi / usb-mass-storage and HP printer cardreader bug + fix)
On Fri, Jan 11, 2008 at 09:14:00PM +0100, Hans de Goede wrote: Boaz Harrosh wrote: Yes, you're right. in ULDs it is a much proper way to do this. So I guess you'll have to do that special host flag or device flag, and add a check for it in sd.c. You'll see that sd.c is already doing bufflen truncation at sd_prep_fn(), just add one more case. Done, thanks for the hint. Patch implementing my fix this way attached, please apply. Well, I can't say that I'm really a big fan of matching a multi-interface device based on the interface class code, but I don't see a better solution that isn't a major coding project. This approach looks pretty reasonable to me. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver SP: I sell software for Microsoft. Can you set me free? DP: Natural Selection says I shouldn't. -- MS Salesman and Dust Puppy User Friendly, 4/2/1998 pgpq398LhM1vO.pgp Description: PGP signature
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: [PATCH] sym53_8xx_2: fixes two bugs related to chip reset
From: Krzysztof Helt [EMAIL PROTECTED]
This patch fixes two bugs pointed by James Bottomley:
1. the if (!sym_data-io_reset). That variable is only ever filled
by a stack based completion. If we find it non empty it means
this code has been entered twice and we have a severe problem,
so that should just become a BUG_ON(!sym_data-io_reset).
2. sym_data-io_reset should be set to NULL before the routine is
exited otherwise the PCI recovery code could end up completing
what will be a bogus pointer into the stack.
Big thanks to James Bottomley for help with the patch.
Signed-off-by: Krzysztof Helt [EMAIL PROTECTED]
---
This is the second version with clearing io_reset value
under lock. I haven't got that it was a race between resume
and handler functions.
diff -urp linux-ref/drivers/scsi/sym53c8xx_2/sym_glue.c
linux-new/drivers/scsi/sym53c8xx_2/sym_glue.c
--- linux-ref/drivers/scsi/sym53c8xx_2/sym_glue.c 2007-12-23
20:39:44.0 +0100
+++ linux-new/drivers/scsi/sym53c8xx_2/sym_glue.c 2008-01-10
21:26:32.0 +0100
@@ -609,22 +609,24 @@ static int sym_eh_handler(int op, char *
*/
#define WAIT_FOR_PCI_RECOVERY 35
if (pci_channel_offline(pdev)) {
- struct completion *io_reset;
int finished_reset = 0;
init_completion(eh_done);
spin_lock_irq(shost-host_lock);
/* Make sure we didn't race */
if (pci_channel_offline(pdev)) {
- if (!sym_data-io_reset)
- sym_data-io_reset = eh_done;
- io_reset = sym_data-io_reset;
+ BUG_ON(!sym_data-io_reset);
+ sym_data-io_reset = eh_done;
} else {
finished_reset = 1;
}
spin_unlock_irq(shost-host_lock);
if (!finished_reset)
- finished_reset = wait_for_completion_timeout(io_reset,
+ finished_reset = wait_for_completion_timeout
+ (sym_data-io_reset,
WAIT_FOR_PCI_RECOVERY*HZ);
+ spin_lock_irq(shost-host_lock);
+ sym_data-io_reset = NULL;
+ spin_unlock_irq(shost-host_lock);
if (!finished_reset)
return SCSI_FAILED;
}
@@ -1879,7 +1881,6 @@ static void sym2_io_resume(struct pci_de
spin_lock_irq(shost-host_lock);
if (sym_data-io_reset)
complete_all(sym_data-io_reset);
- sym_data-io_reset = NULL;
spin_unlock_irq(shost-host_lock);
}
--
Rozdajemy nagrody!
Sprawdz http://link.interia.pl/f1cbf
-
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: usb-storage-psc1350-v4.patch (was Linux scsi / usb-mass-storage and HP printer cardreader bug + fix)
Boaz Harrosh wrote:
Yes, you're right. in ULDs it is a much proper way to do this.
So I guess you'll have to do that special host flag or device
flag, and add a check for it in sd.c. You'll see that sd.c is
already doing bufflen truncation at sd_prep_fn(), just add one
more case.
Done, thanks for the hint. Patch implementing my fix this way attached, please
apply.
Thanks Regards,
Hans
This patch makes the cardreader on the HP PSC 1350 multifunction printer work,
it adds a new scsi_device and US_FL_ flag + handling, and a new
UNUSUAL_DEV_MULTI macro to support multifunction devices.
The difference between this version and the previous v3 version is that this
version has been rewritten to lower the number of sectors requested in the
scsi command when the command is generated instead of later modifying the
command in flight. This patch is against 2.6.24rc7 .
Signed-off-by: Hans de Goede [EMAIL PROTECTED]
diff -up vanilla-2.6.24-rc7/include/scsi/scsi_device.h.psc1350 vanilla-2.6.24-rc7/include/scsi/scsi_device.h
--- vanilla-2.6.24-rc7/include/scsi/scsi_device.h.psc1350 2008-01-11 19:40:31.0 +0100
+++ vanilla-2.6.24-rc7/include/scsi/scsi_device.h 2008-01-11 19:40:48.0 +0100
@@ -142,6 +142,7 @@ struct scsi_device {
unsigned fix_capacity:1; /* READ_CAPACITY is too high by 1 */
unsigned guess_capacity:1; /* READ_CAPACITY might be too high by 1 */
unsigned retry_hwerror:1; /* Retry HARDWARE_ERROR */
+ unsigned last_sector_bug:1; /* Always read last sector in a 1 sector read */
DECLARE_BITMAP(supported_events, SDEV_EVT_MAXBITS); /* supported events */
struct list_head event_list; /* asserted events */
diff -up vanilla-2.6.24-rc7/include/linux/usb_usual.h.psc1350 vanilla-2.6.24-rc7/include/linux/usb_usual.h
--- vanilla-2.6.24-rc7/include/linux/usb_usual.h.psc1350 2008-01-11 19:40:31.0 +0100
+++ vanilla-2.6.24-rc7/include/linux/usb_usual.h 2008-01-11 19:42:14.0 +0100
@@ -50,7 +50,9 @@
US_FLAG(CAPACITY_HEURISTICS, 0x1000) \
/* sometimes sizes is too big */ \
US_FLAG(MAX_SECTORS_MIN,0x2000) \
- /* Sets max_sectors to arch min */
+ /* Sets max_sectors to arch min */ \
+ US_FLAG(LAST_SECTOR_BUG,0x4000) \
+ /* Always read last sector in a 1 sector read */
#define US_FLAG(name, value) US_FL_##name = value ,
diff -up vanilla-2.6.24-rc7/drivers/scsi/sd.c.psc1350 vanilla-2.6.24-rc7/drivers/scsi/sd.c
--- vanilla-2.6.24-rc7/drivers/scsi/sd.c.psc1350 2008-01-11 19:55:43.0 +0100
+++ vanilla-2.6.24-rc7/drivers/scsi/sd.c 2008-01-11 20:48:54.0 +0100
@@ -395,6 +395,13 @@ static int sd_prep_fn(struct request_que
goto out;
}
+ /* Some devices (some sdcards for one) don't like it if the last sector
+ gets read in a larger then 1 sector read */
+ if (sdp-last_sector_bug rq-nr_sectors sdp-sector_size / 512
+ block + rq-nr_sectors == get_capacity(disk)) {
+ this_count -= sdp-sector_size / 512;
+ }
+
SCSI_LOG_HLQUEUE(2, scmd_printk(KERN_INFO, SCpnt, block=%llu\n,
(unsigned long long)block));
diff -up vanilla-2.6.24-rc7/drivers/usb/storage/libusual.c.psc1350 vanilla-2.6.24-rc7/drivers/usb/storage/libusual.c
--- vanilla-2.6.24-rc7/drivers/usb/storage/libusual.c.psc1350 2008-01-11 19:40:31.0 +0100
+++ vanilla-2.6.24-rc7/drivers/usb/storage/libusual.c 2008-01-11 19:40:48.0 +0100
@@ -45,6 +45,18 @@ static int usu_probe_thread(void *arg);
{ USB_DEVICE_VER(id_vendor, id_product, bcdDeviceMin,bcdDeviceMax), \
.driver_info = (flags)|(USB_US_TYPE_STOR24) }
+/* for multiple interface / function devices */
+#define UNUSUAL_DEV_MULTI(id_vendor, id_product, bcdDeviceMin, bcdDeviceMax, \
+ interfaceClass, vendorName, productName, useProtocol, \
+ useTransport, initFunction, flags) \
+{ .match_flags = USB_DEVICE_ID_MATCH_DEVICE_AND_VERSION| \
+ USB_DEVICE_ID_MATCH_INT_CLASS, \
+ .idVendor = (id_vendor), .idProduct = (id_product), \
+ .bcdDevice_lo = (bcdDeviceMin), .bcdDevice_hi = (bcdDeviceMax), \
+ .bInterfaceClass = (interfaceClass), \
+ .driver_info = (flags) | (USB_US_TYPE_STOR 24) \
+}
+
#define USUAL_DEV(useProto, useTrans, useType) \
{ USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, useProto, useTrans), \
.driver_info = ((useType)24) }
@@ -56,6 +68,7 @@ struct usb_device_id storage_usb_ids []
#undef USUAL_DEV
#undef UNUSUAL_DEV
+#undef UNUSUAL_DEV_MULTI
MODULE_DEVICE_TABLE(usb, storage_usb_ids);
EXPORT_SYMBOL_GPL(storage_usb_ids);
diff -up vanilla-2.6.24-rc7/drivers/usb/storage/scsiglue.c.psc1350 vanilla-2.6.24-rc7/drivers/usb/storage/scsiglue.c
--- vanilla-2.6.24-rc7/drivers/usb/storage/scsiglue.c.psc1350 2008-01-11 19:40:31.0 +0100
+++ vanilla-2.6.24-rc7/drivers/usb/storage/scsiglue.c 2008-01-11 19:40:48.0 +0100
@@ -165,6 +165,9 @@ static int slave_configure(struct scsi_d
if (us-flags US_FL_CAPACITY_HEURISTICS)
sdev-guess_capacity = 1;
+ if (us-flags US_FL_LAST_SECTOR_BUG)
+ sdev-last_sector_bug = 1;
+
/* Some devices report a SCSI revision
[PATCH 1/1] aacraid: respond to enclosure service events (take 2)
The original patch removed a default: break from the switch, which ignited a warning message regarding an unhandled enum value. This enclosed patch leaves the default case in to suppress the warning. This attached patch is against current scsi-misc-2.6. ObligatoryDisclaimer: Please accept my condolences regarding Outlook's handling of patch attachments. Signed-off-by: Mark Salyzyn [EMAIL PROTECTED] drivers/scsi/aacraid/aacraid.h |5 +- drivers/scsi/aacraid/commsup.c | 96 - 2 files changed, 79 insertions(+), 22 deletions(-) Sincerely -- Mark Salyzyn -Original Message- From: Salyzyn, Mark Sent: Friday, January 11, 2008 11:15 AM To: 'linux-scsi@vger.kernel.org' Subject: [PATCH 1/1] aacraid: respond to enclosure service events Feature enhancement. Added support to respond to enclosure service events (controller AIFs) to add, online or offline physical targets reported to sg. Also added online and offlining of arrays. Removed an automatic variable definition in a sub block that hid an earlier definition, determined to be inert as the sub-block use did not interfere. Bumped the driver versioning to stamp the addition of this feature. This attached patch is against current scsi-misc-2.6 *after* series of patches from past week are applied, as there is some overlap on the aacraid.h file. ObligatoryDisclaimer: Please accept my condolences regarding Outlook's handling of patch attachments. Signed-off-by: Mark Salyzyn [EMAIL PROTECTED] drivers/scsi/aacraid/aacraid.h |5 +- drivers/scsi/aacraid/commsup.c | 99 +++-- 2 files changed, 79 insertions(+), 25 deletions(-) Sincerely -- Mark Salyzyn aacraid_enclosure2.patch Description: aacraid_enclosure2.patch
Re: [PATCH 1/1] aacraid: add call to flush_kernel_dcache_page for architectures that require it (take 2)
On Fri, 2008-01-11 at 11:46 -0800, Salyzyn, Mark wrote: The reason for the guard was for Linux Distributions that had limited their list of exported APIs on architectures that did *not* require the flush_kernel_dcache_page ... Sorry for not filtering out Distribution kernel issues into the list! :-) That's OK, but you might want to update your distro patch. The correct guard check is ARCH_HAS_FLUSH_KERNEL_DCACHE_PAGE for them ... Dropped guard in the enclosed patch. Thanks! 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
[PATCH 1/1] aacraid: SMC vendor identification
Due to an internal limit associated with the AdapterTypeText field, SMC
required a product ID that overloaded the combined vendor and product ID. A
decision was made to ship the SMC products without a vendor string dropping the
defacto space that used to delineate vendor and product to boot. To correct
this, we needed to adjust the code in the driver to parse out the vendor and
product strings for the adapter. We match of 'AOC' in the AdapterTypeText, if
so we set the vendor to SMC and place the entire AdapterTypeText into the
product field.
This only affects the cosmetic presentation of the Adapter vendor and product
in the logs and in sysfs.
This attached patch is against current scsi-misc-2.6.
ObligatoryDisclaimer: Please accept my condolences regarding Outlook's handling
of patch attachments, use the attachment, not the inline patch.
Signed-off-by: Mark Salyzyn [EMAIL PROTECTED]
drivers/scsi/aacraid/aachba.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff -ru a/drivers/scsi/aacraid/aachba.c b/drivers/scsi/aacraid/aachba.c
--- a/drivers/scsi/aacraid/aachba.c 2008-01-11 16:28:15.129189613 -0500
+++ b/drivers/scsi/aacraid/aachba.c 2008-01-11 16:31:22.032344801 -0500
@@ -716,16 +716,21 @@
if (dev-supplement_adapter_info.AdapterTypeText[0]) {
char * cp = dev-supplement_adapter_info.AdapterTypeText;
- int c = sizeof(str-vid);
- while (*cp *cp != ' ' --c)
- ++cp;
- c = *cp;
- *cp = '\0';
- inqstrcpy (dev-supplement_adapter_info.AdapterTypeText,
- str-vid);
- *cp = c;
- while (*cp *cp != ' ')
- ++cp;
+ int c;
+ if ((cp[0] == 'A') (cp[1] == 'O') (cp[2] == 'C'))
+ inqstrcpy(SMC, str-vid);
+ else {
+ c = sizeof(str-vid);
+ while (*cp *cp != ' ' --c)
+ ++cp;
+ c = *cp;
+ *cp = '\0';
+ inqstrcpy (dev-supplement_adapter_info.AdapterTypeText,
+ str-vid);
+ *cp = c;
+ while (*cp *cp != ' ')
+ ++cp;
+ }
while (*cp == ' ')
++cp;
/* last six chars reserved for vol type */
Sincerely -- Mark Salyzyn
aacraid_SMC_vid.patch
Description: aacraid_SMC_vid.patch
Re: [PATCH] megaraid: fix section mismatch
On Thu, Jan 10, 2008 at 02:33:16PM -0800, Randy Dunlap wrote: From: Randy Dunlap [EMAIL PROTECTED] Change megaraid_pci_driver_g variable name so that it matches the modpost whitelist that allows pointers to init text/data. WARNING: vmlinux.o(.data+0x1a8e30): Section mismatch: reference to .init.text:megaraid_probe_one (between 'megaraid_pci_driver_g' and 'class_device_attr_megaraid_mbox_app_hndl') Signed-off-by: Randy Dunlap [EMAIL PROTECTED] Acked-by: Sam Ravnborg [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
[PATCH 1/1] aacraid: add call to flush_kernel_dcache_page for architectures that require it (take 2)
The reason for the guard was for Linux Distributions that had limited their list of exported APIs on architectures that did *not* require the flush_kernel_dcache_page ... Sorry for not filtering out Distribution kernel issues into the list! :-) Dropped guard in the enclosed patch. This attached patch is against current scsi-misc-2.6. ObligatoryDisclaimer: Please accept my condolences regarding Outlook's handling of patch attachments (inline gets damaged, use attachment). Signed-off-by: Mark Salyzyn [EMAIL PROTECTED] aachba.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff -ru a/drivers/scsi/aacraid/aachba.c b/drivers/scsi/aacraid/aachba.c --- a/drivers/scsi/aacraid/aachba.c 2008-01-11 14:38:53.342378372 -0500 +++ b/drivers/scsi/aacraid/aachba.c 2008-01-11 14:39:39.364534313 -0500 @@ -31,9 +31,9 @@ #include linux/slab.h #include linux/completion.h #include linux/blkdev.h -#include linux/dma-mapping.h #include asm/semaphore.h #include asm/uaccess.h +#include linux/highmem.h /* For flush_kernel_dcache_page */ #include scsi/scsi.h #include scsi/scsi_cmnd.h @@ -366,6 +366,7 @@ if (buf transfer_len 0) memcpy(buf + offset, data, transfer_len); + flush_kernel_dcache_page(kmap_atomic_to_page(buf - sg-offset)); kunmap_atomic(buf - sg-offset, KM_IRQ0); } Sincerely -- Mark Salyzyn -Original Message- From: James Bottomley [mailto:[EMAIL PROTECTED] Sent: Friday, January 11, 2008 11:41 AM To: Salyzyn, Mark Cc: 'linux-scsi@vger.kernel.org' Subject: Re: [PATCH 1/1] aacraid: add call to flush_kernel_dcache_page for architectures that require it. On Tue, 2008-01-08 at 12:09 -0800, Salyzyn, Mark wrote: Some architectures require a call to flush_kernel_dcache_page for processor spoofed DMA operations. This attached patch is against current scsi-misc-2.6. ObligatoryDisclaimer: Please accept my condolences regarding Outlook's handling of patch attachments (inline gets damaged, use attachment). Signed-off-by: Mark Salyzyn [EMAIL PROTECTED] aachba.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff -ru a/drivers/scsi/aacraid/aachba.c b/drivers/scsi/aacraid/aachba.c --- a/drivers/scsi/aacraid/aachba.c 2008-01-08 15:01:21.503932722 -0500 +++ b/drivers/scsi/aacraid/aachba.c 2008-01-08 15:02:35.849634368 -0500 @@ -31,9 +31,9 @@ #include linux/slab.h #include linux/completion.h #include linux/blkdev.h -#include linux/dma-mapping.h #include asm/semaphore.h #include asm/uaccess.h +#include linux/highmem.h /* For flush_kernel_dcache_page */ #include scsi/scsi.h #include scsi/scsi_cmnd.h @@ -366,6 +366,9 @@ if (buf transfer_len 0) memcpy(buf + offset, data, transfer_len); +#ifdef ARCH_HAS_FLUSH_ANON_PAGE + flush_kernel_dcache_page(kmap_atomic_to_page(buf - sg-offset)); +#endif This #ifdef/#endif guard is unnecessary ... flush_kernel_dcache_page() is available on all architectures (it's a nop on most). However, ARCH_HAS_FLUSH_ANON_PAGE is the wrong guard anyway ... that's for the flush_anon_page() function ... aacraid_flush_dcache4.patch Description: aacraid_flush_dcache4.patch
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: [PATCH] bsg : Add support for io vectors in bsg
James Bottomley wrote: On Thu, 2008-01-10 at 16:46 -0500, Pete Wyckoff wrote: [EMAIL PROTECTED] wrote on Thu, 10 Jan 2008 14:55 -0600: On Thu, 2008-01-10 at 15:43 -0500, Pete Wyckoff wrote: [EMAIL PROTECTED] wrote on Wed, 09 Jan 2008 09:11 +0900: On Tue, 8 Jan 2008 17:09:18 -0500 Pete Wyckoff [EMAIL PROTECTED] wrote: I took another look at the compat approach, to see if it is feasible to keep the compat handling somewhere else, without the use of #ifdef CONFIG_COMPAT and size-comparison code inside bsg.c. I don't see how. The use of iovec is within a write operation on a char device. It's not amenable to a compat_sys_ or a .compat_ioctl approach. I'm partial to #1 because the use of architecture-independent fields matches the rest of struct sg_io_v4. But if you don't want to have another iovec type in the kernel, could we do #2 but just return -EINVAL if the need for compat is detected? I.e. change dout_iovec_count to dout_iovec_length and do the math? If you are ok with removing the write/read interface and just have ioctl, we could can handle comapt stuff like others do. But I think that you (OSD people) really want to keep the write/read interface. Sorry, I think that there is no workaround to support iovec in bsg. I don't care about read/write in particular. But we do need some way to launch asynchronous SCSI commands, and currently read/write are the only way to do that in bsg. The reason is to keep multiple spindles busy at the same time. Won't multi-threading the ioctl calls achieve the same effect? Or do you trip over BKL there? There's no BKL on (new) ioctls anymore, at least. A thread per device would be feasible perhaps. But if you want any sort of pipelining out of the device, esp. in the remote iSCSI case, you need to have a good number of commands outstanding to each device. So a thread per command per device. Typical iSCSI queue depth of 128 times 16 devices for a small setup is a lot of threads. I was actually thinking of a thread per outstanding command. The pthread/pipe latency overhead is not insignificant for fast storage networks too. How about these new ioctls instead of read/write: SG_IO_SUBMIT - start a new blk_execute_rq_nowait() SG_IO_TEST - complete and return a previous req SG_IO_WAIT - wait for a req to finish, interruptibly Then old write users will instead do ioctl SUBMIT. Read users will do TEST for non-blocking fd, or WAIT for blocking. And SG_IO could be implemented as SUBMIT + WAIT. Then we can do compat_ioctl and convert up iovecs out-of-line before calling the normal functions. Let me know if you want a patch for this. Really, the thought of re-inventing yet another async I/O interface isn't very appealing. I'm fine with read/write, except Tomo is against handling iovecs because of the compat complexity with struct iovec being different on 32- vs 64-bit. There is a standard way to do compat ioctl that hides this handling in a different file (not bsg.c), which is the only reason I'm even considering these ioctls. I don't care about compat setups per se. Is there another async I/O mechanism? Userspace builds the CDBs, just needs some way to drop them in SCSI ML. BSG is almost perfect for this, but doesn't do iovec, leading to lots of memcpy. No, it's just that async interfaces in Linux have a long and fairly unhappy history. The sg driver's async interface has been pretty stable for a long time. The sync SG_IO ioctl is built on top of the async interface. That makes the async interface extremely well tested. The write()/read() async interface in sg does have one problem: when a command is dispatched via a write() it would be very useful to get back a tag but that violates write()'s second argument: 'const void * buf'. That tag could be useful both for identification of the response and by task management functions. I was hoping that the 'flags' field in sgv4 could be used to implement the variants: SG_IO_SUBMIT - start a new blk_execute_rq_nowait() SG_IO_TEST - complete and return a previous req SG_IO_WAIT - wait for a req to finish, interruptibly that way the existing SG_IO ioctl is sufficient. And if Tomo doesn't want to do it in the bsg driver, then it could be done it the sg driver. 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
[PATCH 1/3] tgt: use scsi_init_io instead of scsi_alloc_sgtable
From: Boaz Harrosh [EMAIL PROTECTED]
Date: Thu, 13 Dec 2007 16:14:27 -0800
Subject: [SCSI] tgt: use scsi_init_io instead of scsi_alloc_sgtable
If we export scsi_init_io()/scsi_release_buffers() instead of
scsi_{alloc,free}_sgtable() from scsi_lib than tgt code is much more
insulated from scsi_lib changes. As a bonus it will also gain bidi
capability when it comes.
[jejb: rebase on to sg_table and fix up rejections]
Signed-off-by: Boaz Harrosh [EMAIL PROTECTED]
Acked-by: FUJITA Tomonori [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: James Bottomley [EMAIL PROTECTED]
---
drivers/scsi/scsi_lib.c | 20 +---
drivers/scsi/scsi_tgt_lib.c | 28 +---
include/scsi/scsi_cmnd.h|4 ++--
3 files changed, 16 insertions(+), 36 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 0849c7c..5bc60f9 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -755,7 +755,7 @@ static struct scatterlist *scsi_sg_alloc(unsigned int
nents, gfp_t gfp_mask)
return mempool_alloc(sgp-pool, gfp_mask);
}
-int scsi_alloc_sgtable(struct scsi_cmnd *cmd, gfp_t gfp_mask)
+static int scsi_alloc_sgtable(struct scsi_cmnd *cmd, gfp_t gfp_mask)
{
int ret;
@@ -769,15 +769,11 @@ int scsi_alloc_sgtable(struct scsi_cmnd *cmd, gfp_t
gfp_mask)
return ret;
}
-EXPORT_SYMBOL(scsi_alloc_sgtable);
-
-void scsi_free_sgtable(struct scsi_cmnd *cmd)
+static void scsi_free_sgtable(struct scsi_cmnd *cmd)
{
__sg_free_table(cmd-sg_table, scsi_sg_free);
}
-EXPORT_SYMBOL(scsi_free_sgtable);
-
/*
* Function:scsi_release_buffers()
*
@@ -795,7 +791,7 @@ EXPORT_SYMBOL(scsi_free_sgtable);
* the scatter-gather table, and potentially any bounce
* buffers.
*/
-static void scsi_release_buffers(struct scsi_cmnd *cmd)
+void scsi_release_buffers(struct scsi_cmnd *cmd)
{
if (cmd-use_sg)
scsi_free_sgtable(cmd);
@@ -807,6 +803,7 @@ static void scsi_release_buffers(struct scsi_cmnd *cmd)
cmd-request_buffer = NULL;
cmd-request_bufflen = 0;
}
+EXPORT_SYMBOL(scsi_release_buffers);
/*
* Function:scsi_io_completion()
@@ -1008,7 +1005,7 @@ void scsi_io_completion(struct scsi_cmnd *cmd, unsigned
int good_bytes)
* Returns: 0 on success
* BLKPREP_DEFER if the failure is retryable
*/
-static int scsi_init_io(struct scsi_cmnd *cmd)
+int scsi_init_io(struct scsi_cmnd *cmd, gfp_t gfp_mask)
{
struct request *req = cmd-request;
intcount;
@@ -1023,7 +1020,7 @@ static int scsi_init_io(struct scsi_cmnd *cmd)
/*
* If sg table allocation fails, requeue request later.
*/
- if (unlikely(scsi_alloc_sgtable(cmd, GFP_ATOMIC))) {
+ if (unlikely(scsi_alloc_sgtable(cmd, gfp_mask))) {
scsi_unprep_request(req);
return BLKPREP_DEFER;
}
@@ -1043,6 +1040,7 @@ static int scsi_init_io(struct scsi_cmnd *cmd)
cmd-use_sg = count;
return BLKPREP_OK;
}
+EXPORT_SYMBOL(scsi_init_io);
static struct scsi_cmnd *scsi_get_cmd_from_req(struct scsi_device *sdev,
struct request *req)
@@ -1088,7 +1086,7 @@ int scsi_setup_blk_pc_cmnd(struct scsi_device *sdev,
struct request *req)
BUG_ON(!req-nr_phys_segments);
- ret = scsi_init_io(cmd);
+ ret = scsi_init_io(cmd, GFP_ATOMIC);
if (unlikely(ret))
return ret;
} else {
@@ -1139,7 +1137,7 @@ int scsi_setup_fs_cmnd(struct scsi_device *sdev, struct
request *req)
if (unlikely(!cmd))
return BLKPREP_DEFER;
- return scsi_init_io(cmd);
+ return scsi_init_io(cmd, GFP_ATOMIC);
}
EXPORT_SYMBOL(scsi_setup_fs_cmnd);
diff --git a/drivers/scsi/scsi_tgt_lib.c b/drivers/scsi/scsi_tgt_lib.c
index 01e03f3..91630ba 100644
--- a/drivers/scsi/scsi_tgt_lib.c
+++ b/drivers/scsi/scsi_tgt_lib.c
@@ -331,8 +331,7 @@ static void scsi_tgt_cmd_done(struct scsi_cmnd *cmd)
scsi_tgt_uspace_send_status(cmd, tcmd-itn_id, tcmd-tag);
- if (scsi_sglist(cmd))
- scsi_free_sgtable(cmd);
+ scsi_release_buffers(cmd);
queue_work(scsi_tgtd, tcmd-work);
}
@@ -353,25 +352,6 @@ static int scsi_tgt_transfer_response(struct scsi_cmnd
*cmd)
return 0;
}
-static int scsi_tgt_init_cmd(struct scsi_cmnd *cmd, gfp_t gfp_mask)
-{
- struct request *rq = cmd-request;
- int count;
-
- cmd-use_sg = rq-nr_phys_segments;
- if (scsi_alloc_sgtable(cmd, gfp_mask))
- return -ENOMEM;
-
- cmd-request_bufflen = rq-data_len;
-
- dprintk(cmd %p cnt %d %lu\n, cmd, scsi_sg_count(cmd),
- rq_data_dir(rq));
- count = blk_rq_map_sg(rq-q, rq, scsi_sglist(cmd));
- BUG_ON(count cmd-use_sg);
- cmd-use_sg = count;
- return 0;
-}
-
/* TODO: test this
[PATCH 2/3] implement scsi_data_buffer
From: Boaz Harrosh [EMAIL PROTECTED]
Date: Thu, 13 Dec 2007 13:47:40 +0200
Subject: [SCSI] implement scsi_data_buffer
In preparation for bidi we abstract all IO members of scsi_cmnd,
that will need to duplicate, into a substructure.
- Group all IO members of scsi_cmnd into a scsi_data_buffer
structure.
- Adjust accessors to new members.
- scsi_{alloc,free}_sgtable receive a scsi_data_buffer instead of
scsi_cmnd. And work on it.
- Adjust scsi_init_io() and scsi_release_buffers() for above
change.
- Fix other parts of scsi_lib/scsi.c to members migration. Use
accessors where appropriate.
- fix Documentation about scsi_cmnd in scsi_host.h
- scsi_error.c
* Changed needed members of struct scsi_eh_save.
* Careful considerations in scsi_eh_prep/restore_cmnd.
- sd.c and sr.c
* sd and sr would adjust IO size to align on device's block
size so code needs to change once we move to scsi_data_buff
implementation.
* Convert code to use scsi_for_each_sg
* Use data accessors where appropriate.
- tgt: convert libsrp to use scsi_data_buffer
- isd200: This driver still bangs on scsi_cmnd IO members,
so need changing
[jejb: rebased on top of sg_table patches fixed up conflicts
and used the synergy to eliminate use_sg and sg_count]
Signed-off-by: Boaz Harrosh [EMAIL PROTECTED]
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
Signed-off-by: James Bottomley [EMAIL PROTECTED]
---
drivers/scsi/libsrp.c|4 +-
drivers/scsi/scsi.c |2 +-
drivers/scsi/scsi_error.c| 28 +++
drivers/scsi/scsi_lib.c | 61 -
drivers/scsi/sd.c|4 +-
drivers/scsi/sr.c| 25 +
drivers/usb/storage/isd200.c |8 +++---
include/scsi/scsi_cmnd.h | 36 +++-
include/scsi/scsi_eh.h |8 ++---
include/scsi/scsi_host.h |4 +-
10 files changed, 83 insertions(+), 97 deletions(-)
diff --git a/drivers/scsi/libsrp.c b/drivers/scsi/libsrp.c
index 5cff020..6d6a76e 100644
--- a/drivers/scsi/libsrp.c
+++ b/drivers/scsi/libsrp.c
@@ -426,8 +426,8 @@ int srp_cmd_queue(struct Scsi_Host *shost, struct srp_cmd
*cmd, void *info,
sc-SCp.ptr = info;
memcpy(sc-cmnd, cmd-cdb, MAX_COMMAND_SIZE);
- sc-request_bufflen = len;
- sc-request_buffer = (void *) (unsigned long) addr;
+ sc-sdb.length = len;
+ sc-sdb.table.sgl = (void *) (unsigned long) addr;
sc-tag = tag;
err = scsi_tgt_queue_command(sc, itn_id, (struct scsi_lun *)cmd-lun,
cmd-tag);
diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index 54ff611..834d329 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -711,7 +711,7 @@ void scsi_finish_command(struct scsi_cmnd *cmd)
Notifying upper driver of completion
(result %x)\n, cmd-result));
- good_bytes = cmd-request_bufflen;
+ good_bytes = scsi_bufflen(cmd);
if (cmd-request-cmd_type != REQ_TYPE_BLOCK_PC) {
drv = scsi_cmd_to_driver(cmd);
if (drv-done)
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index 169bc59..8752a9f 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -617,29 +617,25 @@ void scsi_eh_prep_cmnd(struct scsi_cmnd *scmd, struct
scsi_eh_save *ses,
ses-cmd_len = scmd-cmd_len;
memcpy(ses-cmnd, scmd-cmnd, sizeof(scmd-cmnd));
ses-data_direction = scmd-sc_data_direction;
- ses-bufflen = scmd-request_bufflen;
- ses-buffer = scmd-request_buffer;
- ses-use_sg = scmd-use_sg;
- ses-resid = scmd-resid;
+ ses-sdb = scmd-sdb;
ses-result = scmd-result;
+ memset(scmd-sdb, 0, sizeof(scmd-sdb));
+
if (sense_bytes) {
- scmd-request_bufflen = min_t(unsigned,
+ scmd-sdb.length = min_t(unsigned,
sizeof(scmd-sense_buffer), sense_bytes);
sg_init_one(ses-sense_sgl, scmd-sense_buffer,
- scmd-request_bufflen);
- scmd-request_buffer = ses-sense_sgl;
+ scmd-sdb.length);
+ scmd-sdb.table.sgl = ses-sense_sgl;
scmd-sc_data_direction = DMA_FROM_DEVICE;
- scmd-use_sg = 1;
+ scmd-sdb.table.nents = 1;
memset(scmd-cmnd, 0, sizeof(scmd-cmnd));
scmd-cmnd[0] = REQUEST_SENSE;
- scmd-cmnd[4] = scmd-request_bufflen;
+ scmd-cmnd[4] = scmd-sdb.length;
scmd-cmd_len = COMMAND_SIZE(scmd-cmnd[0]);
} else {
- scmd-request_buffer = NULL;
- scmd-request_bufflen = 0;
scmd-sc_data_direction = DMA_NONE;
- scmd-use_sg = 0;
if (cmnd) {
memset(scmd-cmnd,
[PATCH 3/3] bidirectional command support
From: Boaz Harrosh [EMAIL PROTECTED]
Date: Thu, 13 Dec 2007 13:50:53 +0200
Subject: [SCSI] bidirectional command support
At the block level bidi request uses req-next_rq pointer for a second
bidi_read request.
At Scsi-midlayer a second scsi_data_buffer structure is used for the
bidi_read part. This bidi scsi_data_buffer is put on
request-next_rq-special. Struct scsi_cmnd is not changed.
- Define scsi_bidi_cmnd() to return true if it is a bidi request and a
second sgtable was allocated.
- Define scsi_in()/scsi_out() to return the in or out scsi_data_buffer
from this command This API is to isolate users from the mechanics of
bidi.
- Define scsi_end_bidi_request() to do what scsi_end_request() does but
for a bidi request. This is necessary because bidi commands are a bit
tricky here. (See comments in body)
- scsi_release_buffers() will also release the bidi_read scsi_data_buffer
- scsi_io_completion() on bidi commands will now call
scsi_end_bidi_request() and return.
- The previous work done in scsi_init_io() is now done in a new
scsi_init_sgtable() (which is 99% identical to old scsi_init_io())
The new scsi_init_io() will call the above twice if needed also for
the bidi_read command. Only at this point is a command bidi.
- In scsi_error.c at scsi_eh_prep/restore_cmnd() make sure bidi-lld is not
confused by a get-sense command that looks like bidi. This is done
by puting NULL at request-next_rq, and restoring.
[jejb: update to sg_table and resolve conflicts]
Signed-off-by: Boaz Harrosh [EMAIL PROTECTED]
Signed-off-by: James Bottomley [EMAIL PROTECTED]
---
drivers/scsi/scsi_error.c |3 +
drivers/scsi/scsi_lib.c | 144 -
include/scsi/scsi_cmnd.h | 23 +++-
include/scsi/scsi_eh.h|1 +
4 files changed, 141 insertions(+), 30 deletions(-)
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index 8752a9f..65d02e8 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -618,9 +618,11 @@ void scsi_eh_prep_cmnd(struct scsi_cmnd *scmd, struct
scsi_eh_save *ses,
memcpy(ses-cmnd, scmd-cmnd, sizeof(scmd-cmnd));
ses-data_direction = scmd-sc_data_direction;
ses-sdb = scmd-sdb;
+ ses-next_rq = scmd-request-next_rq;
ses-result = scmd-result;
memset(scmd-sdb, 0, sizeof(scmd-sdb));
+ scmd-request-next_rq = NULL;
if (sense_bytes) {
scmd-sdb.length = min_t(unsigned,
@@ -673,6 +675,7 @@ void scsi_eh_restore_cmnd(struct scsi_cmnd* scmd, struct
scsi_eh_save *ses)
memcpy(scmd-cmnd, ses-cmnd, sizeof(scmd-cmnd));
scmd-sc_data_direction = ses-data_direction;
scmd-sdb = ses-sdb;
+ scmd-request-next_rq = ses-next_rq;
scmd-result = ses-result;
}
EXPORT_SYMBOL(scsi_eh_restore_cmnd);
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 90d5ee0..3c681de 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -64,6 +64,8 @@ static struct scsi_host_sg_pool scsi_sg_pools[] = {
};
#undef SP
+static struct kmem_cache *scsi_bidi_sdb_cache;
+
static void scsi_run_queue(struct request_queue *q);
/*
@@ -627,6 +629,28 @@ void scsi_run_host_queues(struct Scsi_Host *shost)
scsi_run_queue(sdev-request_queue);
}
+static void scsi_finalize_request(struct scsi_cmnd *cmd, int uptodate)
+{
+ struct request_queue *q = cmd-device-request_queue;
+ struct request *req = cmd-request;
+ unsigned long flags;
+
+ add_disk_randomness(req-rq_disk);
+
+ spin_lock_irqsave(q-queue_lock, flags);
+ if (blk_rq_tagged(req))
+ blk_queue_end_tag(q, req);
+
+ end_that_request_last(req, uptodate);
+ spin_unlock_irqrestore(q-queue_lock, flags);
+
+ /*
+* This will goose the queue request function at the end, so we don't
+* need to worry about launching another command.
+*/
+ scsi_next_command(cmd);
+}
+
/*
* Function:scsi_end_request()
*
@@ -654,7 +678,6 @@ static struct scsi_cmnd *scsi_end_request(struct scsi_cmnd
*cmd, int uptodate,
{
struct request_queue *q = cmd-device-request_queue;
struct request *req = cmd-request;
- unsigned long flags;
/*
* If there are blocks left over at the end, set up the command
@@ -683,19 +706,7 @@ static struct scsi_cmnd *scsi_end_request(struct scsi_cmnd
*cmd, int uptodate,
}
}
- add_disk_randomness(req-rq_disk);
-
- spin_lock_irqsave(q-queue_lock, flags);
- if (blk_rq_tagged(req))
- blk_queue_end_tag(q, req);
- end_that_request_last(req, uptodate);
- spin_unlock_irqrestore(q-queue_lock, flags);
-
- /*
-* This will goose the queue request function at the end, so we don't
-* need to worry about launching another command.
-*/
- scsi_next_command(cmd);
+ scsi_finalize_request(cmd,
Re: [PATCH] sym53_8xx_2: fixes two bugs related to chip reset
On Fri, 11 Jan 2008 13:52:29 -0700
Matthew Wilcox [EMAIL PROTECTED] wrote:
On Fri, Jan 11, 2008 at 09:50:46PM +0100, Krzysztof Helt wrote:
+ BUG_ON(!sym_data-io_reset);
+ sym_data-io_reset = eh_done;
Isn't that BUG_ON still the wrong sense?
Unfortunately yes.
Here is the 3rd version of the patch. Thank you for your patience.
---
From: Krzysztof Helt [EMAIL PROTECTED]
This patch fixes two bugs pointed by James Bottomley:
1. the if (!sym_data-io_reset). That variable is only ever filled
by a stack based completion. If we find it non empty it means
this code has been entered twice and we have a severe problem,
so that should just become a BUG_ON(!sym_data-io_reset).
2. sym_data-io_reset should be set to NULL before the routine is
exited otherwise the PCI recovery code could end up completing
what will be a bogus pointer into the stack.
Big thanks to James Bottomley for help with the patch.
Signed-off-by: Krzysztof Helt [EMAIL PROTECTED]
---
diff -urp linux-ref/drivers/scsi/sym53c8xx_2/sym_glue.c
linux-new/drivers/scsi/sym53c8xx_2/sym_glue.c
--- linux-ref/drivers/scsi/sym53c8xx_2/sym_glue.c 2007-12-23
20:39:44.0 +0100
+++ linux-new/drivers/scsi/sym53c8xx_2/sym_glue.c 2008-01-10
21:26:32.0 +0100
@@ -609,22 +609,24 @@ static int sym_eh_handler(int op, char *
*/
#define WAIT_FOR_PCI_RECOVERY 35
if (pci_channel_offline(pdev)) {
- struct completion *io_reset;
int finished_reset = 0;
init_completion(eh_done);
spin_lock_irq(shost-host_lock);
/* Make sure we didn't race */
if (pci_channel_offline(pdev)) {
- if (!sym_data-io_reset)
- sym_data-io_reset = eh_done;
- io_reset = sym_data-io_reset;
+ BUG_ON(sym_data-io_reset);
+ sym_data-io_reset = eh_done;
} else {
finished_reset = 1;
}
spin_unlock_irq(shost-host_lock);
if (!finished_reset)
- finished_reset = wait_for_completion_timeout(io_reset,
+ finished_reset = wait_for_completion_timeout
+ (sym_data-io_reset,
WAIT_FOR_PCI_RECOVERY*HZ);
+ spin_lock_irq(shost-host_lock);
+ sym_data-io_reset = NULL;
+ spin_unlock_irq(shost-host_lock);
if (!finished_reset)
return SCSI_FAILED;
}
@@ -1879,7 +1881,6 @@ static void sym2_io_resume(struct pci_de
spin_lock_irq(shost-host_lock);
if (sym_data-io_reset)
complete_all(sym_data-io_reset);
- sym_data-io_reset = NULL;
spin_unlock_irq(shost-host_lock);
}
--
Rozdajemy nagrody!
Sprawdz http://link.interia.pl/f1cbf
-
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_transport_spi: convert to attribute groups
On Sat, Jan 05, 2008 at 10:18:27AM -0600, James Bottomley wrote: This conversion makes full use of the is_visible() callback on attribute groups. Now, each device appears only with its capability flags in the transport class directory. Previously each device appeared with the capability of the host, so this is a functionality improvement. Converting to attribute groups allows us to sweep away most of the home grown #defines that were effectively doing the same thing. James --- This depends on: [PATCH] sysfs: add filter function to groups [PATCH] fix the sysfs_add_file_to_group interfaces [PATCH] attribute_container: update to use the group interface [PATCH] add missing transport configure points for target and host Greg and Kay, there's a nasty point in the code where I'd like to use the -EEXIST return of sysfs_add_file_to_group() to indicate the file is already there, however, this also dumps a stack trace and would frighten users ... can we get rid of the printk and the WARN_ON(1)? I really don't want to, as it has caught a lot of problems in the past. What do you want to do that needs this error to happen properly? thanks, greg k-h - 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 the sysfs_add_file_to_group interfaces
On Wed, Jan 02, 2008 at 06:44:05PM -0600, James Bottomley wrote: I can't see a reason why these shouldn't work on every group. However, they only seem to work on named groups. This patch allows the group functions to work on anonymous groups (those with NULL names). Signed-off-by: James Bottomley [EMAIL PROTECTED] Feel free to add: Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED] and take it through your tree. thanks, greg k-h - 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] attribute_container: update to use the group interface
On Wed, Jan 02, 2008 at 06:48:47PM -0600, James Bottomley wrote: This patch is the beginning of moving the attribute_containers to use attribute groups exclusively. The attr element is now deprecated and will eventually be removed (along with all the hand rolled code for doing exactly what attribute groups do) when all the consumers are converted to attribute groups. Signed-off-by: James Bottomley [EMAIL PROTECTED] Feel free to add: Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED] and take it through your tree. thanks, greg k-h - 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
