Open bugs
Hello, The bugs listed are over a month old, and haven't been addressed yet. It would be appreciated if corresponding maintainers identify whether the bugs have been fixed, or need to be worked on, and take appropriate action. In most cases, reporters are standing by and ready to provide information and necessary testing. Thanks! Memory Management=== swapping in 2.6.24-rc5-git3 http://bugzilla.kernel.org/show_bug.cgi?id=9592 Date: 12/07/2007 Regression Summary: # /proc/sys/vm# cat swappiness 0 but scp-ing 2GB file causes many processes are swapped out due to increase of the file cache size. Was looked at by Jan Kara [EMAIL PROTECTED]; KAMEZAWA Hiroyuki [EMAIL PROTECTED] - commented I/O-Storage SATA DVD drive UDF filesystem problem http://bugzilla.kernel.org/show_bug.cgi?id=9668 12/31/2007 Summary: I mount dvd discs (udf) with piix and ide_cd modules without problem (on hw decribed higher). Then I put NEC drive to new mainboard (ICH9 + jmicron SATA/PATA chips) and use ahci (jmicron) + sr_mod modules. SCSI== Problems on booting http://bugzilla.kernel.org/show_bug.cgi?id=9621 Date: 12/22/2007 Regression Summary: The boot stops / hangs on hardware detection of SCSI. I have an InitioINI-9X00U/UW When I have an usb key sticked in /dev/sba, and run lilo then, then it dont boot but give L99 99 99 99 ... error Resetting RAID attached to a FC Switch causes kernel panic and crash http://bugzilla.kernel.org/show_bug.cgi?id=9598 12/18/2007 Hardware Environment:SunFire X4200 - 2 x dual core AMD Opteron CPUs, 8GB Ram, Qlogic FC adapter. Summary: Resetting the RAID box causes the X4200 to crash. 3ware 9650SE -8LPML not recognized by 3w-9xxx driver http://bugzilla.kernel.org/show_bug.cgi?id=8908 08/19/2007 Problem Description: The 3w-9xxx kernel driver for 3ware 9xxx SATA RAID Controller series did not recognize the 3ware 9650SE-8LPML SATA RAID Controller. Plarform=== kexec buffer error http://bugzilla.kernel.org/show_bug.cgi?id=9693 Date: 01/04/2008 Regression Summary: Close of /boot/kernel-2.6.24-rc6-git11 failed: : buffer error kexec load failed, error = 1 2+ wake-ups/second in 2.6.24 http://bugzilla.kernel.org/show_bug.cgi?id=9489 Date: 12/02/2007 Summary: something is causing the system to go into a state where the cpu throws us right out of the C-state the kernel asks for Discussed: Arjan van de Ven, Mark Lord VIDEO/FB== No text consoles with FRAMEBUFFER_CONSOLE_DETECT_PRIMARY http://bugzilla.kernel.org/show_bug.cgi?id=9310 11/05/2007 still there Regression Summary: After initial boot messages all output to console stops. The last visible messages are: checking if image is initramfs...6Switched to high resolution mode on CPU 1 Switched to high resolution mode on CPU 0 After that, nothing until XOrg starts up and graphical login/desktop on VT7are displayed normal. DVB=== DVB-T Pluto2: SUSPEND/RESUME methods are missing for this driver 04/05/2007 - still present in 2.6.24 http://bugzilla.kernel.org/show_bug.cgi?id=8304 Summary: After SWSUPS resume, pluto2 card is not started properly, led getts not green and card is unable load tda firmware Hardware Environment: Acer TravelMate No one looked at it yet. Several Pluto bug: DVB-T Pluto2 PCI: When playing in dmesg I often getts: pluto2 :03:00.0: overflow irq (10) Date: 11/08/2006 still there http://bugzilla.kernel.org/show_bug.cgi?id=7473 Hardware Environment: Acer TravelMate DVB-T Pluto2: Getting tons of card hung up :( messages when card is removed from pcmcia slot Date: 11/08/2006 - still there http://bugzilla.kernel.org/show_bug.cgi?id=7472 DVB-T Pluto2: Unable to change MUX Date: 11/08/2006 http://bugzilla.kernel.org/show_bug.cgi?id=7471 KNC1 DVB-C cam module not working on driver load Date: 1/15/2007 - still there http://bugzilla.kernel.org/show_bug.cgi?id=7825 Error: DVB: registering new adapter (KNC1 DVB-C) adapter failed MAC signature check encoded MAC from EEPROM was ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff KNC1-0: MAC addr = 00:09:d6:6d:5a:f0 TDA10021: i2c-addr = 0x0c, id = 0x7c DVB: registering frontend 0 (Philips TDA10021 DVB-C)... budget-av: ci interface initialised. budget-av: cam inserted A dvb_ca adaptor 0: PC card did not respond :( build #341 failed for 2.6.24-rc6-g1842c7f in linux/./drivers/media/dvb/ttpci/budget-av.c 01/01/2008 http://bugzilla.kernel.org/show_bug.cgi?id=9671 Still there in 2.6.24.. has it been fixed? DVB-USB UMT-010 driver has certain oops when installed 01/09/2008 http://bugzilla.kernel.org/show_bug.cgi?id=9720 In the umt-010 driver the struct umt_properties sets the number of URBs for transfer to 20. But in dvb-usb.h MAX_NO_URBS_FOR_DATA_STREAM is set to 10. This causes an oops
[PATCHSET libata-dev#upstream] clean up scsi_host_templates and ata_port_operations, take #2
Hello, all. This is the second take of cleanup-sht-ops patchset. As the name suggests it reorganizes and cleans up scsi_host_template and ata_port_operation tables used by libata core and low level drivers. Please read the head message of the last take[L] for more info. Changes from the last take[L] are... * Updated to fit the current upstream. sata_mv should be fine now. * sht and ops conversions separated into two patches as Jeff requested. * Instead of using init-register model for SFF drivers which need to initialize host-private_data, @host_priv is added to ata_pci_init_one() as Alan requested. * pata_scc should now have NULL thaw after conversion. The following drivers need specific platform to build, so they need verification. If you work on one of the following drivers, please verify that the driver builds and works fine. It would be best if you can verify that the sht and ops don't change by the fifth and sixth patches using the method I'll write in another message. * pata_at32 * pata_bf54x * pata_icside * pata_ixp4xx_cf * pata_mpc52xx * pata_scc * sata_fsl This patchset is on top of upstream (bc5468f52b785ffa1fe0ea289baec2c51384d436) + prefer-hardreset patchset [1] + grace-failure-on-no-reset patch [2] + pci-allow-multiple-pcim_enable_device [3] This patchset is available as GIT branch. http://git.kernel.org/?p=linux/kernel/git/tj/libata-dev.git;a=shortlog;h=cleanup-sht-ops git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata-dev.git cleanup-sht-ops -- tejun [L] http://thread.gmane.org/gmane.linux.ide/27785 [1] http://thread.gmane.org/gmane.linux.ide/27447 [2] http://article.gmane.org/gmane.linux.ide/27781 [3] http://article.gmane.org/gmane.linux.ide/27782 - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/10] libata: normalize port_info, port_operations and sht tables
Over the time, port info, ops and sht structures developed quite a bit
of inconsistencies. This patch updates drivers.
* Enable/disable_pm callbacks added to all ahci ops tables.
* Every driver for SFF controllers now uses ata_sff_port_start()
instead of ata_port_start() unless the driver has custom
implementation.
* Every driver for SFF controllers now uses ata_pci_default_filter()
unless the driver has custom implementation.
* Removed an odd port_info-sht initialization from ata_piix.c.
Likely a merge byproduct.
* A port which has ATA_FLAG_SATA set doesn't need to set cable_detect
to ata_cable_sata(). Remove it from via and mv port ops.
* Some drivers had unnecessary .max_sectors initialization which is
ignored and was missing .slave_destroy callback. Fixed.
* Removed unnecessary sht initializations port_info's.
* Removed onsolete scsi device suspend/resume callbacks from
pata_bf54x.
* No reason to set ata_pci_default_filter() and bmdma functions for
PIO-only drivers. Remove those callbacks and replace
ata_bmdma_irq_clear with ata_noop_irq_clear.
* pata_platform sets port_start to ata_dummy_ret0. port_start can
just be set to NULL.
* sata_fsl supports NCQ but was missing qc_defer. Fixed.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
drivers/ata/ahci.c |4
drivers/ata/ata_generic.c|1 +
drivers/ata/ata_piix.c | 13 +++--
drivers/ata/pata_artop.c |1 +
drivers/ata/pata_bf54x.c |1 -
drivers/ata/pata_cmd64x.c|6 +++---
drivers/ata/pata_cs5520.c|1 +
drivers/ata/pata_cs5536.c|2 +-
drivers/ata/pata_hpt3x3.c|1 -
drivers/ata/pata_it8213.c|2 +-
drivers/ata/pata_ixp4xx_cf.c |3 +--
drivers/ata/pata_jmicron.c |3 ++-
drivers/ata/pata_marvell.c |1 +
drivers/ata/pata_mpc52xx.c |4 ++--
drivers/ata/pata_netcell.c |1 +
drivers/ata/pata_opti.c |7 +--
drivers/ata/pata_optidma.c |2 ++
drivers/ata/pata_platform.c |4
drivers/ata/pata_rz1000.c|7 +--
drivers/ata/sata_fsl.c |1 +
drivers/ata/sata_mv.c|6 --
drivers/ata/sata_nv.c| 11 ---
drivers/ata/sata_sil.c |3 ++-
drivers/ata/sata_sis.c |3 ++-
drivers/ata/sata_svw.c |3 ++-
drivers/ata/sata_uli.c |3 ++-
drivers/ata/sata_via.c | 12
drivers/ata/sata_vsc.c |3 ++-
28 files changed, 57 insertions(+), 52 deletions(-)
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 415cc77..8ff885a 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -351,6 +351,8 @@ static const struct ata_port_operations ahci_vt8251_ops = {
.port_suspend = ahci_port_suspend,
.port_resume= ahci_port_resume,
#endif
+ .enable_pm = ahci_enable_alpm,
+ .disable_pm = ahci_disable_alpm,
.port_start = ahci_port_start,
.port_stop = ahci_port_stop,
@@ -385,6 +387,8 @@ static const struct ata_port_operations ahci_p5wdh_ops = {
.port_suspend = ahci_port_suspend,
.port_resume= ahci_port_resume,
#endif
+ .enable_pm = ahci_enable_alpm,
+ .disable_pm = ahci_disable_alpm,
.port_start = ahci_port_start,
.port_stop = ahci_port_stop,
diff --git a/drivers/ata/ata_generic.c b/drivers/ata/ata_generic.c
index 2053420..db4c3cb 100644
--- a/drivers/ata/ata_generic.c
+++ b/drivers/ata/ata_generic.c
@@ -114,6 +114,7 @@ static struct scsi_host_template generic_sht = {
static struct ata_port_operations generic_port_ops = {
.set_mode = generic_set_mode,
+ .mode_filter= ata_pci_default_filter,
.tf_load= ata_tf_load,
.tf_read= ata_tf_read,
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index 9c2515f..6a32839 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -336,7 +336,7 @@ static const struct ata_port_operations piix_pata_ops = {
.irq_clear = ata_bmdma_irq_clear,
.irq_on = ata_irq_on,
- .port_start = ata_port_start,
+ .port_start = ata_sff_port_start,
};
static const struct ata_port_operations ich_pata_ops = {
@@ -367,7 +367,7 @@ static const struct ata_port_operations ich_pata_ops = {
.irq_clear = ata_bmdma_irq_clear,
.irq_on = ata_irq_on,
- .port_start = ata_port_start,
+ .port_start = ata_sff_port_start,
};
static const struct ata_port_operations piix_sata_ops = {
@@ -385,6 +385,7 @@ static const struct ata_port_operations piix_sata_ops = {
.qc_issue = ata_qc_issue_prot,
.data_xfer = ata_data_xfer,
+ .mode_filter=
[PATCH 01/10] libata: PCI device should be powered up before being accessed
PCI device should be powered up or powered up before its PCI regsiters
are accessed. Although PCI configuration register access is allowed
in D3hot, PCI device is free to reset its status when transiting from
D3hot to D0 causing configuration data to change.
Many libata SFF drivers which use ata_pci_init_one() read and update
configuration registers before calling ata_pci_init_one() which
enables the PCI device. Also, in resume paths, some drivers access
registers without resuming the PCI device.
This patch adds a call to pcim_enable_device() in init path if
register is accessed before calling ata_pci_init_one() and make resume
paths first resume PCI devices, access PCI configuration regiters then
resume ATA host.
While at it...
* cmd640 was strange in that it set -resume even when CONFIG_PM is
not. This is by-product of minimal build fix. Updated.
* In cs5530, Don't BUG() on reinit failure. Just whine and fail
resume.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
drivers/ata/pata_ali.c | 14 +-
drivers/ata/pata_amd.c | 16 +++-
drivers/ata/pata_artop.c |5 +
drivers/ata/pata_cmd640.c | 21 -
drivers/ata/pata_cmd64x.c | 15 ++-
drivers/ata/pata_cs5520.c | 15 ++-
drivers/ata/pata_cs5530.c | 18 --
drivers/ata/pata_hpt366.c | 14 +-
drivers/ata/pata_hpt37x.c |5 +
drivers/ata/pata_hpt3x2n.c |5 +
drivers/ata/pata_it821x.c | 14 +-
drivers/ata/pata_netcell.c |5 +
drivers/ata/pata_ns87415.c |6 ++
drivers/ata/pata_optidma.c |5 +
drivers/ata/pata_serverworks.c | 19 ---
drivers/ata/pata_sil680.c | 13 +++--
drivers/ata/pata_sis.c |6 +-
drivers/ata/pata_sl82c105.c|5 +
drivers/ata/pata_via.c | 14 +-
19 files changed, 195 insertions(+), 20 deletions(-)
diff --git a/drivers/ata/pata_ali.c b/drivers/ata/pata_ali.c
index 7e68edf..5ef6594 100644
--- a/drivers/ata/pata_ali.c
+++ b/drivers/ata/pata_ali.c
@@ -597,6 +597,11 @@ static int ali_init_one(struct pci_dev *pdev, const struct
pci_device_id *id)
const struct ata_port_info *ppi[] = { NULL, NULL };
u8 tmp;
struct pci_dev *isa_bridge;
+ int rc;
+
+ rc = pcim_enable_device(pdev);
+ if (rc)
+ return rc;
/*
* The chipset revision selects the driver operations and
@@ -632,8 +637,15 @@ static int ali_init_one(struct pci_dev *pdev, const struct
pci_device_id *id)
#ifdef CONFIG_PM
static int ali_reinit_one(struct pci_dev *pdev)
{
+ struct ata_host *host = dev_get_drvdata(pdev-dev);
+ int rc;
+
+ rc = ata_pci_device_do_resume(pdev);
+ if (rc)
+ return rc;
ali_init_chipset(pdev);
- return ata_pci_device_resume(pdev);
+ ata_host_resume(host);
+ return 0;
}
#endif
diff --git a/drivers/ata/pata_amd.c b/drivers/ata/pata_amd.c
index 761a666..567fe6b 100644
--- a/drivers/ata/pata_amd.c
+++ b/drivers/ata/pata_amd.c
@@ -662,10 +662,15 @@ static int amd_init_one(struct pci_dev *pdev, const
struct pci_device_id *id)
static int printed_version;
int type = id-driver_data;
u8 fifo;
+ int rc;
if (!printed_version++)
dev_printk(KERN_DEBUG, pdev-dev, version DRV_VERSION \n);
+ rc = pcim_enable_device(pdev);
+ if (rc)
+ return rc;
+
pci_read_config_byte(pdev, 0x41, fifo);
/* Check for AMD7409 without swdma errata and if found adjust type */
@@ -709,6 +714,13 @@ static int amd_init_one(struct pci_dev *pdev, const struct
pci_device_id *id)
#ifdef CONFIG_PM
static int amd_reinit_one(struct pci_dev *pdev)
{
+ struct ata_host *host = dev_get_drvdata(pdev-dev);
+ int rc;
+
+ rc = ata_pci_device_do_resume(pdev);
+ if (rc)
+ return rc;
+
if (pdev-vendor == PCI_VENDOR_ID_AMD) {
u8 fifo;
pci_read_config_byte(pdev, 0x41, fifo);
@@ -721,7 +733,9 @@ static int amd_reinit_one(struct pci_dev *pdev)
pdev-device == PCI_DEVICE_ID_AMD_COBRA_7401)
ata_pci_clear_simplex(pdev);
}
- return ata_pci_device_resume(pdev);
+
+ ata_host_resume(host);
+ return 0;
}
#endif
diff --git a/drivers/ata/pata_artop.c b/drivers/ata/pata_artop.c
index d421831..2f81480 100644
--- a/drivers/ata/pata_artop.c
+++ b/drivers/ata/pata_artop.c
@@ -446,11 +446,16 @@ static int artop_init_one (struct pci_dev *pdev, const
struct pci_device_id *id)
.port_ops = artop6260_ops,
};
const struct ata_port_info *ppi[] = { NULL, NULL };
+ int rc;
if (!printed_version++)
dev_printk(KERN_DEBUG, pdev-dev,
[PATCH 02/10] libata: reorganize ata_port_operations
Over the time, ops in ata_port_operations has become a bit confusing.
Reorganize. SFF/BMDMA ops are separated into separate a group as they
will be taken out of ata_port_operations later.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
include/linux/libata.h | 117 +---
1 files changed, 61 insertions(+), 56 deletions(-)
diff --git a/include/linux/libata.h b/include/linux/libata.h
index a7882a2..7e012d9 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -672,69 +672,74 @@ struct ata_port {
};
struct ata_port_operations {
- void (*dev_config) (struct ata_device *);
+ /*
+* Command execution
+*/
+ int (*qc_defer)(struct ata_queued_cmd *qc);
+ int (*check_atapi_dma)(struct ata_queued_cmd *qc);
+ void (*qc_prep)(struct ata_queued_cmd *qc);
+ unsigned int (*qc_issue)(struct ata_queued_cmd *qc);
- void (*set_piomode) (struct ata_port *, struct ata_device *);
- void (*set_dmamode) (struct ata_port *, struct ata_device *);
- unsigned long (*mode_filter) (struct ata_device *, unsigned long);
+ /*
+* Configuration and exception handling
+*/
+ int (*cable_detect)(struct ata_port *ap);
+ unsigned long (*mode_filter)(struct ata_device *dev, unsigned long
xfer_mask);
+ void (*set_piomode)(struct ata_port *ap, struct ata_device *dev);
+ void (*set_dmamode)(struct ata_port *ap, struct ata_device *dev);
+ int (*set_mode)(struct ata_link *link, struct ata_device
**r_failed_dev);
- void (*tf_load) (struct ata_port *ap, const struct ata_taskfile *tf);
- void (*tf_read) (struct ata_port *ap, struct ata_taskfile *tf);
+ void (*dev_config)(struct ata_device *dev);
- void (*exec_command)(struct ata_port *ap, const struct ata_taskfile
*tf);
+ void (*freeze)(struct ata_port *ap);
+ void (*thaw)(struct ata_port *ap);
+ void (*error_handler)(struct ata_port *ap);
+ void (*post_internal_cmd)(struct ata_queued_cmd *qc);
+
+ /*
+* Optional features
+*/
+ int (*scr_read)(struct ata_port *ap, unsigned int sc_reg, u32 *val);
+ int (*scr_write)(struct ata_port *ap, unsigned int sc_reg, u32 val);
+ void (*pmp_attach)(struct ata_port *ap);
+ void (*pmp_detach)(struct ata_port *ap);
+ int (*enable_pm)(struct ata_port *ap, enum link_pm policy);
+ void (*disable_pm)(struct ata_port *ap);
+
+ /*
+* Start, stop, suspend and resume
+*/
+ int (*port_suspend)(struct ata_port *ap, pm_message_t mesg);
+ int (*port_resume)(struct ata_port *ap);
+ int (*port_start)(struct ata_port *ap);
+ void (*port_stop)(struct ata_port *ap);
+ void (*host_stop)(struct ata_host *host);
+
+ /*
+* SFF / taskfile oriented ops
+*/
+ void (*dev_select)(struct ata_port *ap, unsigned int device);
u8 (*check_status)(struct ata_port *ap);
u8 (*check_altstatus)(struct ata_port *ap);
- void (*dev_select)(struct ata_port *ap, unsigned int device);
-
- void (*phy_reset) (struct ata_port *ap); /* obsolete */
- int (*set_mode) (struct ata_link *link, struct ata_device
**r_failed_dev);
-
- int (*cable_detect) (struct ata_port *ap);
-
- int (*check_atapi_dma) (struct ata_queued_cmd *qc);
-
- void (*bmdma_setup) (struct ata_queued_cmd *qc);
- void (*bmdma_start) (struct ata_queued_cmd *qc);
-
- unsigned int (*data_xfer) (struct ata_device *dev, unsigned char *buf,
- unsigned int buflen, int rw);
-
- int (*qc_defer) (struct ata_queued_cmd *qc);
- void (*qc_prep) (struct ata_queued_cmd *qc);
- unsigned int (*qc_issue) (struct ata_queued_cmd *qc);
-
- /* port multiplier */
- void (*pmp_attach) (struct ata_port *ap);
- void (*pmp_detach) (struct ata_port *ap);
-
- /* Error handlers. -error_handler overrides -eng_timeout and
-* indicates that new-style EH is in place.
+ void (*tf_load)(struct ata_port *ap, const struct ata_taskfile *tf);
+ void (*tf_read)(struct ata_port *ap, struct ata_taskfile *tf);
+ void (*exec_command)(struct ata_port *ap, const struct ata_taskfile
*tf);
+ unsigned int (*data_xfer)(struct ata_device *dev, unsigned char *buf,
+ unsigned int buflen, int rw);
+ u8 (*irq_on)(struct ata_port *);
+
+ void (*irq_clear)(struct ata_port *);
+ void (*bmdma_setup)(struct ata_queued_cmd *qc);
+ void (*bmdma_start)(struct ata_queued_cmd *qc);
+ void (*bmdma_stop)(struct ata_queued_cmd *qc);
+ u8 (*bmdma_status)(struct ata_port *ap);
+
+ /*
+* Obsolete
*/
- void (*eng_timeout) (struct ata_port *ap); /* obsolete */
-
- void (*freeze) (struct ata_port *ap);
- void (*thaw) (struct ata_port *ap);
- void
[PATCH 03/10] libata: implement and use ata_noop_irq_clear()
-irq_clear() is used to clear IRQ bit of a SFF controller and isn't
useful for drivers which don't use libata SFF HSM implementation.
However, it's a required callback and many drivers implement their own
noop version as placeholder. This patch implements ata_noop_irq_clear
and use it to replace those custom placeholders.
Also, SFF drivers which don't support BMDMA don't need to use
ata_bmdma_irq_clear(). It becomes noop if BMDMA address isn't
initialized. Convert them to use ata_noop_irq_clear().
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
drivers/ata/ahci.c | 12 +++-
drivers/ata/libata-core.c|1 +
drivers/ata/libata-sff.c |8
drivers/ata/pata_ali.c |2 +-
drivers/ata/pata_at32.c |7 +--
drivers/ata/pata_icside.c|7 +--
drivers/ata/pata_isapnp.c|2 +-
drivers/ata/pata_ixp4xx_cf.c |2 +-
drivers/ata/pata_legacy.c| 22 +++---
drivers/ata/pata_mpc52xx.c |2 +-
drivers/ata/pata_mpiix.c |2 +-
drivers/ata/pata_ns87410.c |2 +-
drivers/ata/pata_pcmcia.c|4 ++--
drivers/ata/pata_platform.c |2 +-
drivers/ata/pata_qdi.c |4 ++--
drivers/ata/pata_winbond.c |2 +-
drivers/ata/pdc_adma.c |8 +---
drivers/ata/sata_fsl.c |7 +--
drivers/ata/sata_inic162x.c |7 +--
drivers/ata/sata_mv.c| 11 +++
drivers/ata/sata_qstor.c |8 +---
drivers/ata/sata_sil24.c |8 +---
include/linux/libata.h |1 +
23 files changed, 46 insertions(+), 85 deletions(-)
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 44946bd..415cc77 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -238,7 +238,6 @@ static int ahci_scr_read(struct ata_port *ap, unsigned int
sc_reg, u32 *val);
static int ahci_scr_write(struct ata_port *ap, unsigned int sc_reg, u32 val);
static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id
*ent);
static unsigned int ahci_qc_issue(struct ata_queued_cmd *qc);
-static void ahci_irq_clear(struct ata_port *ap);
static int ahci_port_start(struct ata_port *ap);
static void ahci_port_stop(struct ata_port *ap);
static void ahci_tf_read(struct ata_port *ap, struct ata_taskfile *tf);
@@ -298,7 +297,7 @@ static const struct ata_port_operations ahci_ops = {
.qc_prep= ahci_qc_prep,
.qc_issue = ahci_qc_issue,
- .irq_clear = ahci_irq_clear,
+ .irq_clear = ata_noop_irq_clear,
.scr_read = ahci_scr_read,
.scr_write = ahci_scr_write,
@@ -334,7 +333,7 @@ static const struct ata_port_operations ahci_vt8251_ops = {
.qc_prep= ahci_qc_prep,
.qc_issue = ahci_qc_issue,
- .irq_clear = ahci_irq_clear,
+ .irq_clear = ata_noop_irq_clear,
.scr_read = ahci_scr_read,
.scr_write = ahci_scr_write,
@@ -368,7 +367,7 @@ static const struct ata_port_operations ahci_p5wdh_ops = {
.qc_prep= ahci_qc_prep,
.qc_issue = ahci_qc_issue,
- .irq_clear = ahci_irq_clear,
+ .irq_clear = ata_noop_irq_clear,
.scr_read = ahci_scr_read,
.scr_write = ahci_scr_write,
@@ -1710,11 +1709,6 @@ static void ahci_port_intr(struct ata_port *ap)
}
}
-static void ahci_irq_clear(struct ata_port *ap)
-{
- /* TODO */
-}
-
static irqreturn_t ahci_interrupt(int irq, void *dev_instance)
{
struct ata_host *host = dev_instance;
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 410f1ea..2772657 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -7556,6 +7556,7 @@ EXPORT_SYMBOL_GPL(ata_noop_qc_prep);
EXPORT_SYMBOL_GPL(ata_bmdma_setup);
EXPORT_SYMBOL_GPL(ata_bmdma_start);
EXPORT_SYMBOL_GPL(ata_bmdma_irq_clear);
+EXPORT_SYMBOL_GPL(ata_noop_irq_clear);
EXPORT_SYMBOL_GPL(ata_bmdma_status);
EXPORT_SYMBOL_GPL(ata_bmdma_stop);
EXPORT_SYMBOL_GPL(ata_bmdma_freeze);
diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index 60cd4b1..34cdab0 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -297,6 +297,14 @@ void ata_bmdma_irq_clear(struct ata_port *ap)
}
/**
+ * ata_noop_irq_clear - Noop placeholder for irq_clear
+ * @ap: Port associated with this ATA transaction.
+ */
+void ata_noop_irq_clear(struct ata_port *ap)
+{
+}
+
+/**
* ata_bmdma_status - Read PCI IDE BMDMA status
* @ap: Port associated with this ATA transaction.
*
diff --git a/drivers/ata/pata_ali.c b/drivers/ata/pata_ali.c
index 5ef6594..8a9044c 100644
--- a/drivers/ata/pata_ali.c
+++ b/drivers/ata/pata_ali.c
@@ -342,7 +342,7 @@ static struct ata_port_operations ali_early_port_ops = {
.data_xfer = ata_data_xfer,
[PATCH 09/10] libata: kill port_info-sht and -irq_handler
libata core layer doesn't care about sht or -irq_handler. Those are
only of interest to the LLD during initialization. This is confusing
and has caused several drivers to have duplicate unused initializers
for these fields.
Currently only sata_nv uses these fields. Make sata_nv use
-private_data, which is supposed to carry LLD-specific information,
instead and kill -sht and -irq_handler. nv_pi_priv structure is
defined and struct literals are used to initialize private_data.
Notational overhead is negligible.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
drivers/ata/sata_nv.c | 29 +
include/linux/libata.h |2 --
2 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/drivers/ata/sata_nv.c b/drivers/ata/sata_nv.c
index 7b7ba0e..5637b08 100644
--- a/drivers/ata/sata_nv.c
+++ b/drivers/ata/sata_nv.c
@@ -466,58 +466,61 @@ static struct ata_port_operations nv_swncq_ops = {
.port_start = nv_swncq_port_start,
};
+struct nv_pi_priv {
+ irq_handler_t irq_handler;
+ struct scsi_host_template *sht;
+};
+
+#define NV_PI_PRIV(_irq_handler, _sht) \
+ (struct nv_pi_priv){ .irq_handler = _irq_handler, .sht = _sht }
+
static const struct ata_port_info nv_port_info[] = {
/* generic */
{
- .sht= nv_sht,
.flags = ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY,
.pio_mask = NV_PIO_MASK,
.mwdma_mask = NV_MWDMA_MASK,
.udma_mask = NV_UDMA_MASK,
.port_ops = nv_generic_ops,
- .irq_handler= nv_generic_interrupt,
+ .private_data = NV_PI_PRIV(nv_generic_interrupt, nv_sht),
},
/* nforce2/3 */
{
- .sht= nv_sht,
.flags = ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY,
.pio_mask = NV_PIO_MASK,
.mwdma_mask = NV_MWDMA_MASK,
.udma_mask = NV_UDMA_MASK,
.port_ops = nv_nf2_ops,
- .irq_handler= nv_nf2_interrupt,
+ .private_data = NV_PI_PRIV(nv_nf2_interrupt, nv_sht),
},
/* ck804 */
{
- .sht= nv_sht,
.flags = ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY,
.pio_mask = NV_PIO_MASK,
.mwdma_mask = NV_MWDMA_MASK,
.udma_mask = NV_UDMA_MASK,
.port_ops = nv_ck804_ops,
- .irq_handler= nv_ck804_interrupt,
+ .private_data = NV_PI_PRIV(nv_ck804_interrupt, nv_sht),
},
/* ADMA */
{
- .sht= nv_adma_sht,
.flags = ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY |
ATA_FLAG_MMIO | ATA_FLAG_NCQ,
.pio_mask = NV_PIO_MASK,
.mwdma_mask = NV_MWDMA_MASK,
.udma_mask = NV_UDMA_MASK,
.port_ops = nv_adma_ops,
- .irq_handler= nv_adma_interrupt,
+ .private_data = NV_PI_PRIV(nv_adma_interrupt, nv_adma_sht),
},
/* SWNCQ */
{
- .sht= nv_swncq_sht,
.flags = ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY |
ATA_FLAG_NCQ,
.pio_mask = NV_PIO_MASK,
.mwdma_mask = NV_MWDMA_MASK,
.udma_mask = NV_UDMA_MASK,
.port_ops = nv_swncq_ops,
- .irq_handler= nv_swncq_interrupt,
+ .private_data = NV_PI_PRIV(nv_swncq_interrupt, nv_swncq_sht),
},
};
@@ -2316,6 +2319,7 @@ static int nv_init_one(struct pci_dev *pdev, const struct
pci_device_id *ent)
{
static int printed_version;
const struct ata_port_info *ppi[] = { NULL, NULL };
+ struct nv_pi_priv *ipriv;
struct ata_host *host;
struct nv_host_priv *hpriv;
int rc;
@@ -2352,6 +2356,7 @@ static int nv_init_one(struct pci_dev *pdev, const struct
pci_device_id *ent)
}
ppi[0] = nv_port_info[type];
+ ipriv = ppi[0]-private_data;
rc = ata_pci_prepare_sff_host(pdev, ppi, host);
if (rc)
return rc;
@@ -2390,8 +2395,8 @@ static int nv_init_one(struct pci_dev *pdev, const struct
pci_device_id *ent)
nv_swncq_host_init(host);
pci_set_master(pdev);
- return ata_host_activate(host, pdev-irq, ppi[0]-irq_handler,
-IRQF_SHARED, ppi[0]-sht);
+ return ata_host_activate(host, pdev-irq, ipriv-irq_handler,
+IRQF_SHARED, ipriv-sht);
}
#ifdef CONFIG_PM
diff --git a/include/linux/libata.h b/include/linux/libata.h
index b503a41..4101dfe 100644
--- a/include/linux/libata.h
+++
[PATCH 08/10] libata: stop overloading port_info-private_data
port_info-private_data is currently used for two purposes - to record
private data about the port_info or to specify host-private_data to
use when allocating ata_host.
This overloading is confusing and counter-intuitive in that
port_info-private_data becomes host-private_data instead of
port-private_data. In addition, port_info and host don't correspond
to each other 1-to-1. Currently, the first non-NULL
port_info-private_data is used.
This patch makes port_info-private_data just be what it is -
private_data for the port_info where LLD can jot down extra info.
libata no longer sets host-private_data to the first non-NULL
port_info-private_data, @host_priv argument is added to
ata_pci_init_one() instead. LLDs which use ata_pci_init_one() can use
this argument to pass in pointer to host private data. LLDs which
don't should use init-register model anyway and can initialize
host-private_data directly.
Adding @host_priv instead of using init-register model for LLDs which
use ata_pci_init_one() is suggested by Alan Cox.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
Cc: Alan Cox [EMAIL PROTECTED]
---
drivers/ata/ata_generic.c |2 +-
drivers/ata/libata-core.c |2 --
drivers/ata/libata-sff.c|4 +++-
drivers/ata/pata_acpi.c |2 +-
drivers/ata/pata_ali.c |2 +-
drivers/ata/pata_amd.c | 10 +-
drivers/ata/pata_artop.c|2 +-
drivers/ata/pata_atiixp.c |2 +-
drivers/ata/pata_cmd640.c |2 +-
drivers/ata/pata_cmd64x.c |2 +-
drivers/ata/pata_cs5530.c |2 +-
drivers/ata/pata_cs5535.c |2 +-
drivers/ata/pata_cs5536.c |2 +-
drivers/ata/pata_cypress.c |2 +-
drivers/ata/pata_efar.c |2 +-
drivers/ata/pata_hpt366.c | 12 ++--
drivers/ata/pata_hpt37x.c | 33 ++---
drivers/ata/pata_hpt3x2n.c |9 -
drivers/ata/pata_it8213.c |2 +-
drivers/ata/pata_it821x.c |2 +-
drivers/ata/pata_jmicron.c |2 +-
drivers/ata/pata_marvell.c |2 +-
drivers/ata/pata_netcell.c |2 +-
drivers/ata/pata_ns87410.c |2 +-
drivers/ata/pata_ns87415.c |2 +-
drivers/ata/pata_oldpiix.c |2 +-
drivers/ata/pata_opti.c |2 +-
drivers/ata/pata_optidma.c |2 +-
drivers/ata/pata_pdc202xx_old.c |2 +-
drivers/ata/pata_radisys.c |2 +-
drivers/ata/pata_rz1000.c |2 +-
drivers/ata/pata_sc1200.c |2 +-
drivers/ata/pata_serverworks.c |2 +-
drivers/ata/pata_sil680.c |2 +-
drivers/ata/pata_sis.c |8 +++-
drivers/ata/pata_sl82c105.c |2 +-
drivers/ata/pata_triflex.c |2 +-
drivers/ata/pata_via.c | 19 ---
include/linux/libata.h |2 +-
39 files changed, 74 insertions(+), 85 deletions(-)
diff --git a/drivers/ata/ata_generic.c b/drivers/ata/ata_generic.c
index a912ee0..b23e2a1 100644
--- a/drivers/ata/ata_generic.c
+++ b/drivers/ata/ata_generic.c
@@ -152,7 +152,7 @@ static int ata_generic_init_one(struct pci_dev *dev, const
struct pci_device_id
if (dev-vendor == PCI_VENDOR_ID_AL)
ata_pci_clear_simplex(dev);
- return ata_pci_init_one(dev, ppi, generic_sht);
+ return ata_pci_init_one(dev, ppi, generic_sht, NULL);
}
static struct pci_device_id ata_generic[] = {
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index bb42dd5..685e3c7 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -6905,8 +6905,6 @@ struct ata_host *ata_host_alloc_pinfo(struct device *dev,
if (!host-ops (pi-port_ops != ata_dummy_port_ops))
host-ops = pi-port_ops;
- if (!host-private_data pi-private_data)
- host-private_data = pi-private_data;
}
return host;
diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index 24f6dc5..538b4af 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -819,6 +819,7 @@ int ata_pci_activate_sff_host(struct ata_host *host,
* @pdev: Controller to be initialized
* @ppi: array of port_info, must be enough for two ports
* @sht: scsi_host_template to use when registering the host
+ * @host_priv: host private_data
*
* This is a helper function which can be called from a driver's
* xxx_init_one() probe function if the hardware uses traditional
@@ -840,7 +841,7 @@ int ata_pci_activate_sff_host(struct ata_host *host,
*/
int ata_pci_init_one(struct pci_dev *pdev,
const struct ata_port_info * const * ppi,
-struct scsi_host_template *sht)
+struct scsi_host_template *sht, void *host_priv)
{
struct device *dev = pdev-dev;
const struct ata_port_info *pi = NULL;
@@ -874,6 +875,7 @@ int ata_pci_init_one(struct
[PATCH 07/10] libata: make ata_pci_init_one() not use ops-irq_handler and pi-sht
ata_pci_init_one() is the only function which uses ops-irq_handler
and pi-sht. Other initialization functions take the same information
as arguments. This causes confusion and duplicate unused entries in
structures.
Make ata_pci_init_one() take sht as an argument and use ata_interrupt
implicitly. All current users use ata_interrupt and if different irq
handler is necessary open coding ata_pci_init_one() using
ata_prepare_sff_host() and ata_activate_sff_host can be done under ten
lines including error handling and driver which requires custom
interrupt handler is likely to require custom initialization anyway.
As ata_pci_init_one() was the last user of ops-irq_handler, this
patch also kills the field.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
drivers/ata/ata_generic.c |3 +--
drivers/ata/libata-core.c |1 -
drivers/ata/libata-sff.c|7 ---
drivers/ata/pata_acpi.c |3 +--
drivers/ata/pata_ali.c |9 +
drivers/ata/pata_amd.c | 12 +---
drivers/ata/pata_artop.c|6 +-
drivers/ata/pata_atiixp.c |3 +--
drivers/ata/pata_cmd640.c |3 +--
drivers/ata/pata_cmd64x.c |8 +---
drivers/ata/pata_cs5530.c |4 +---
drivers/ata/pata_cs5535.c |3 +--
drivers/ata/pata_cs5536.c |3 +--
drivers/ata/pata_cypress.c |3 +--
drivers/ata/pata_efar.c |3 +--
drivers/ata/pata_hpt366.c |3 +--
drivers/ata/pata_hpt37x.c |8 +---
drivers/ata/pata_hpt3x2n.c |3 +--
drivers/ata/pata_it8213.c |3 +--
drivers/ata/pata_it821x.c |4 +---
drivers/ata/pata_jmicron.c |3 +--
drivers/ata/pata_marvell.c |4 +---
drivers/ata/pata_netcell.c |3 +--
drivers/ata/pata_ns87410.c |3 +--
drivers/ata/pata_ns87415.c |4 +---
drivers/ata/pata_oldpiix.c |3 +--
drivers/ata/pata_opti.c |3 +--
drivers/ata/pata_optidma.c |4 +---
drivers/ata/pata_pdc202xx_old.c |5 +
drivers/ata/pata_radisys.c |3 +--
drivers/ata/pata_rz1000.c |3 +--
drivers/ata/pata_sc1200.c |3 +--
drivers/ata/pata_serverworks.c |6 +-
drivers/ata/pata_sil680.c |4 +---
drivers/ata/pata_sis.c | 10 +-
drivers/ata/pata_sl82c105.c |4 +---
drivers/ata/pata_triflex.c |3 +--
drivers/ata/pata_via.c |8 +---
include/linux/libata.h |4 ++--
39 files changed, 42 insertions(+), 130 deletions(-)
diff --git a/drivers/ata/ata_generic.c b/drivers/ata/ata_generic.c
index 0b5b515..a912ee0 100644
--- a/drivers/ata/ata_generic.c
+++ b/drivers/ata/ata_generic.c
@@ -120,7 +120,6 @@ static int ata_generic_init_one(struct pci_dev *dev, const
struct pci_device_id
{
u16 command;
static const struct ata_port_info info = {
- .sht = generic_sht,
.flags = ATA_FLAG_SLAVE_POSS,
.pio_mask = 0x1f,
.mwdma_mask = 0x07,
@@ -153,7 +152,7 @@ static int ata_generic_init_one(struct pci_dev *dev, const
struct pci_device_id
if (dev-vendor == PCI_VENDOR_ID_AL)
ata_pci_clear_simplex(dev);
- return ata_pci_init_one(dev, ppi);
+ return ata_pci_init_one(dev, ppi, generic_sht);
}
static struct pci_device_id ata_generic[] = {
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 4bb8e1e..bb42dd5 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -109,7 +109,6 @@ const struct ata_port_operations ata_sff_port_ops = {
.irq_on = ata_irq_on,
.port_start = ata_sff_port_start,
- .irq_handler= ata_interrupt,
};
const struct ata_port_operations ata_bmdma_port_ops = {
diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index 34cdab0..24f6dc5 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -818,6 +818,7 @@ int ata_pci_activate_sff_host(struct ata_host *host,
* ata_pci_init_one - Initialize/register PCI IDE host controller
* @pdev: Controller to be initialized
* @ppi: array of port_info, must be enough for two ports
+ * @sht: scsi_host_template to use when registering the host
*
* This is a helper function which can be called from a driver's
* xxx_init_one() probe function if the hardware uses traditional
@@ -838,7 +839,8 @@ int ata_pci_activate_sff_host(struct ata_host *host,
* Zero on success, negative on errno-based value on error.
*/
int ata_pci_init_one(struct pci_dev *pdev,
-const struct ata_port_info * const * ppi)
+const struct ata_port_info * const * ppi,
+struct scsi_host_template *sht)
{
struct device *dev = pdev-dev;
const struct ata_port_info *pi = NULL;
@@ -874,8 +876,7 @@ int ata_pci_init_one(struct pci_dev
Re: Current qc_defer implementation may lead to infinite recursion
Tejun Heo [EMAIL PROTECTED] wrote:
Elias Oltmanns wrote:
+static int piix_qc_defer(struct ata_queued_cmd *qc)
+{
+static struct ata_port *ap = NULL;
+struct ata_queued_cmd qcmd[ATA_MAX_QUEUE];
missing static?
Oh well, I must have been too tired already yesterday. There are a few
more things I got wrong last time. Please see the new patch at the end
of this email.
This time I applied the patch to 2.6.24.1 and performed a
# cat large-file /dev/null
# tail -f /var/log/kern.log
and aborted once the output of dump_stack() had occurred. This proves
that piix_qc_defer() has declined the same command 100 times in
succession. However, this will only happen if the status of all the
commands enqueued for one port hasn't changed in the meantime. This
suggests to me that the threads scheduled for command execution and
completion aren't served for some reason. Any ideas?
The foot print of piix_qc_defer() in my log files looks like this, by
the way:
Feb 12 08:53:42 denkblock kernel: piix_qc_defer(): saved current state
Feb 12 08:53:42 denkblock kernel: Pid: 31, comm: kblockd/0 Not tainted
2.6.24.1-dbg-1 #1
Feb 12 08:53:42 denkblock kernel: [e0042116] piix_qc_defer+0xac/0xeb
[ata_piix]
Feb 12 08:53:42 denkblock kernel: [e008c4e4] ata_scsi_translate+0xd6/0x10a
[libata]
Feb 12 08:53:42 denkblock kernel: [e008af20] ata_build_rw_tf+0x175/0x242
[libata]
Feb 12 08:53:42 denkblock kernel: [e006734e] scsi_done+0x0/0x16 [scsi_mod]
Feb 12 08:53:42 denkblock kernel: [e008eb8f] ata_scsi_queuecmd+0x17f/0x184
[libata]
Feb 12 08:53:42 denkblock kernel: [e008c20a] ata_scsi_rw_xlat+0x0/0x1de
[libata]
Feb 12 08:53:42 denkblock kernel: [e0067aa8] scsi_dispatch_cmd+0x197/0x20b
[scsi_mod]
Feb 12 08:53:42 denkblock kernel: [e006cb33] scsi_request_fn+0x256/0x2d7
[scsi_mod]
Feb 12 08:53:42 denkblock kernel: [e0042136] piix_qc_defer+0xcc/0xeb
[ata_piix]
Feb 12 08:53:42 denkblock kernel: [c01961d3] blk_run_queue+0x2a/0x4b
Feb 12 08:53:42 denkblock kernel: [e006bea2] scsi_queue_insert+0x84/0x8e
[scsi_mod]
Feb 12 08:53:42 denkblock kernel: [e006a70d] scsi_delete_timer+0xf/0x50
[scsi_mod]
Feb 12 08:53:42 denkblock kernel: [e0067adc] scsi_dispatch_cmd+0x1cb/0x20b
[scsi_mod]
Feb 12 08:53:42 denkblock kernel: [e006cb33] scsi_request_fn+0x256/0x2d7
[scsi_mod]
Feb 12 08:53:42 denkblock kernel: [c0195289] blk_remove_plug+0x4e/0x5a
Feb 12 08:53:42 denkblock kernel: [c01934c2] blk_unplug_work+0x0/0xc
Feb 12 08:53:42 denkblock kernel: [c01952b2]
__generic_unplug_device+0x1d/0x1f
Feb 12 08:53:42 denkblock kernel: [c0195c07] generic_unplug_device+0x6/0x8
Feb 12 08:53:42 denkblock kernel: [c01934cd] blk_unplug_work+0xb/0xc
Feb 12 08:53:42 denkblock kernel: [c0122943] run_workqueue+0x6b/0xdf
Feb 12 08:53:42 denkblock kernel: [c024dcd2] schedule+0x1f3/0x20d
Feb 12 08:53:42 denkblock kernel: [c0122f37] worker_thread+0x0/0xbd
Feb 12 08:53:42 denkblock kernel: [c0122fe9] worker_thread+0xb2/0xbd
Feb 12 08:53:42 denkblock kernel: [c0125429]
autoremove_wake_function+0x0/0x35
Feb 12 08:53:42 denkblock kernel: [c01252d2] kthread+0x36/0x5c
Feb 12 08:53:42 denkblock kernel: [c012529c] kthread+0x0/0x5c
Feb 12 08:53:42 denkblock kernel: [c0104733] kernel_thread_helper+0x7/0x10
Feb 12 08:53:42 denkblock kernel: ===
Regards,
Elias
---
drivers/ata/ata_piix.c | 42 ++
1 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index b406b39..c987462 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -167,6 +167,7 @@ static void piix_set_dmamode(struct ata_
static void ich_set_dmamode(struct ata_port *ap, struct ata_device *adev);
static int ich_pata_cable_detect(struct ata_port *ap);
static u8 piix_vmw_bmdma_status(struct ata_port *ap);
+static int piix_qc_defer(struct ata_queued_cmd *qc);
#ifdef CONFIG_PM
static int piix_pci_device_suspend(struct pci_dev *pdev, pm_message_t mesg);
static int piix_pci_device_resume(struct pci_dev *pdev);
@@ -311,6 +312,7 @@ static const struct ata_port_operations
.bmdma_start = ata_bmdma_start,
.bmdma_stop = ata_bmdma_stop,
.bmdma_status = ata_bmdma_status,
+ .qc_defer = piix_qc_defer,
.qc_prep = ata_qc_prep,
.qc_issue = ata_qc_issue_prot,
.data_xfer = ata_data_xfer,
@@ -343,6 +345,7 @@ static const struct ata_port_operations
.bmdma_start = ata_bmdma_start,
.bmdma_stop = ata_bmdma_stop,
.bmdma_status = ata_bmdma_status,
+ .qc_defer = piix_qc_defer,
.qc_prep = ata_qc_prep,
.qc_issue = ata_qc_issue_prot,
.data_xfer = ata_data_xfer,
@@ -371,6 +374,7 @@ static const struct ata_port_operations
.bmdma_start = ata_bmdma_start,
.bmdma_stop = ata_bmdma_stop,
.bmdma_status = ata_bmdma_status,
+ .qc_defer = piix_qc_defer,
.qc_prep = ata_qc_prep,
.qc_issue = ata_qc_issue_prot,
.data_xfer = ata_data_xfer,
@@ -402,6 +406,7 @@ static const struct ata_port_operations
.bmdma_start =
Re: 2.6.26-git0: IDE oops during boot
Bartlomiej Zolnierkiewicz wrote:
Hi,
On Monday 11 February 2008, Kamalesh Babulal wrote:
Nish Aravamudan wrote:
On 2/7/08, Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] wrote:
On Thursday 07 February 2008, Kamalesh Babulal wrote:
Bartlomiej Zolnierkiewicz wrote:
Hi,
On Wednesday 06 February 2008, Pavel Machek wrote:
On Wed 2008-02-06 11:53:34, Pavel Machek wrote:
Hi!
Trying to boot 2.6.25-git0 (few days old), I get
BUG: unable to handle kernel paging request at ..ffb0
IP at init_irq+0x42e
init_irq? hmm...
Call trace:
ide_device_add_all
this comes from ide-generic
(Generic IDE host driver)
ide_generic_init
kernel_init
child_rip
vgacon_cursor
kernel_init
child_rip
Excerpt from config:
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
Disabling CONFIG_IDE made my machine boot, as it was using libata
anyway.
Kamalesh/Pavel:
Could you try latest git and see if the OOPS is still there?
[ Yeah, I'm unable to reproduce it. :( ]
Thanks,
Bart
Hi Bart,
The panic is reproducible with the 2.6.24-git16 kernel, the call trace is
similar to the previous one
Thanks, I again reviewed ide-probe.c changes but nothing seems wrong...
Could you please bisect it down to the guilty commit?
Kamalesh, were you able to bisect this down? I just got hit by the
same panic on a 4-way x86_64, with 2.6.24-git22.
Thanks,
Nish
Hi Nish,
I tried bisecting and the guilty patch seems to be
36501650ec45b1db308c3b51886044863be2d762 is first bad commit
commit 36501650ec45b1db308c3b51886044863be2d762
Author: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
Date: Fri Feb 1 23:09:31 2008 +0100
ide: keep pointer to struct device instead of struct pci_dev in
ide_hwif_t
the gdb output, also points to the changes made by the guilty patch
(gdb) p ide_device_add_all
$1 = {int (u8 *, const struct ide_port_info *)} 0x804176ac
ide_device_add_all
(gdb) p/x 0x804176ac+0xb60
$2 = 0x8041820c
(gdb) l *0x8041820c
0x8041820c is in ide_device_add_all (drivers/ide/ide-probe.c:1249).
1244goto out;
1245}
1246
1247sg_init_table(hwif-sg_table, hwif-sg_max_nents);
1248
1249if (init_irq(hwif) == 0)
1250goto done;
1251
1252old_irq = hwif-irq;
1253/*
(gdb)
(gdb) p init_irq
$1 = {int (ide_hwif_t *)} 0x8041721f init_irq
(gdb) p/x 0x8041721f+0x1a4
$2 = 0x804173c3
(gdb) l *0x804173c3
0x804173c3 is in init_irq (include/asm/pci.h:101).
96 /* Returns the node based on pci bus */
97 static inline int __pcibus_to_node(struct pci_bus *bus)
98 {
99 struct pci_sysdata *sd = bus-sysdata;
100
101 return sd-node;
102 }
103
104 static inline cpumask_t __pcibus_to_cpumask(struct pci_bus *bus)
105 {
(gdb)
Thanks for the detailed analysis and sorry for the bug.
I think that this may has been just fixed by Andi's recent hwif_to_node()
fix (patch below, it is in Linus' tree already), could please verify this?
commit 1f07e988290fc45932f5028c9e2a862c37a57336
Author: Andi Kleen [EMAIL PROTECTED]
Date: Mon Feb 11 01:35:20 2008 +0100
Prevent IDE boot ops on NUMA system
Without this patch a Opteron test system here oopses at boot with
current git.
Calling to_pci_dev() on a NULL pointer gives a negative value so the
following NULL pointer check never triggers and then an illegal address
is referenced. Check the unadjusted original device pointer for NULL
instead.
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
diff --git a/include/linux/ide.h b/include/linux/ide.h
index 23fad89..a3b69c1 100644
--- a/include/linux/ide.h
+++ b/include/linux/ide.h
@@ -1295,7 +1295,7 @@ static inline void ide_dump_identify(u8 *id)
static inline int hwif_to_node(ide_hwif_t *hwif)
{
struct pci_dev *dev = to_pci_dev(hwif-dev);
- return dev ? pcibus_to_node(dev-bus) : -1;
+ return hwif-dev ? pcibus_to_node(dev-bus) : -1;
}
static inline ide_drive_t *ide_get_paired_drive(ide_drive_t *drive)
Hi Bart,
Thanks !! the patch solves the kernel panic but when after applying the
patch,kernel is not
able to mount the filesystem and panics, am i not sure what is likely causing
the panic.
Creating root device.
Mounting root filesystem.
mount: could not find filesystem
Kernel panic - not syncing: Attempted to kill init!
--
Thanks Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Current qc_defer implementation may lead to infinite recursion
Elias Oltmanns wrote:
Tejun Heo [EMAIL PROTECTED] wrote:
Elias Oltmanns wrote:
+static int piix_qc_defer(struct ata_queued_cmd *qc)
+{
+ static struct ata_port *ap = NULL;
+ struct ata_queued_cmd qcmd[ATA_MAX_QUEUE];
missing static?
Oh well, I must have been too tired already yesterday. There are a few
more things I got wrong last time. Please see the new patch at the end
of this email.
This time I applied the patch to 2.6.24.1 and performed a
# cat large-file /dev/null
# tail -f /var/log/kern.log
and aborted once the output of dump_stack() had occurred. This proves
that piix_qc_defer() has declined the same command 100 times in
succession. However, this will only happen if the status of all the
commands enqueued for one port hasn't changed in the meantime. This
suggests to me that the threads scheduled for command execution and
completion aren't served for some reason. Any ideas?
Blocked counts of 1 will cause busy looping because when blk_run_queue()
returns because it's recursing too deep, it schedules unplug work right
away, so it will easily loop 100 times. Max blocked counts should be
adjusted to two (needs some testing before actually submitting the
change). But that still shouldn't cause any lock up. What happens if
you remove the 100 times limit? Does the machine hang on IO?
Thanks.
--
tejun
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH #upstream] libata: implement libata.force module parameter
Jeff Garzik wrote: Tejun Heo wrote: This patch implements libata.force module parameter which can selectively override ATA port, link and device configurations including cable type, SATA PHY SPD limit, transfer mode and NCQ. For example, you can say use 1.5Gbps for all fan-out ports attached to the second port but allow 3.0Gbps for the PMP device itself, oh, the device attached to the third fan-out port chokes on NCQ and shouldn't go over UDMA4 by the following. libata.force=2:1.5g,2.15:3.0g,2.03:noncq,udma4 Signed-off-by: Tejun Heo [EMAIL PROTECTED] --- I guess it's about time we add something like this. More than anything else this should help debugging and can serve as a last resort to work around problems. Thanks. Documentation/kernel-parameters.txt | 35 +++ drivers/ata/libata-core.c | 375 +++- drivers/ata/libata-eh.c |8 drivers/ata/libata.h|1 4 files changed, 415 insertions(+), 4 deletions(-) ACK, but it breaks the build due to section type conflicts: drivers/ata/libata-core.c:108: error: ata_force_param_buf causes a section type conflict Given that the data is marked __initdata and the code is marked __init, I cannot see the problem. Jeff, this no longer causes build failure whether libata is configured built-in or as a module. I have no idea what's going on but there doesn't seem to be a proper solution on the horizon yet. I think we can go ahead and commit this one and convert it to __initdataconst when it becomes available. Thanks. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
IDE cdrom problem with PLEXTOR DVDR PX-608AL
Hi, I suffer from unreliable cdrom operations (failing DAE and burn sessions) with the openSUSE 2.6.18.8-0.7-bigsmp kernel. Additionally, the syslog is continuesly spammed with: Feb 12 00:03:22 kernel: hdc: cdrom_pc_intr: The drive appears confused (ireason = 0x01). Trying to recover by ending request. Feb 12 00:57:52 kernel: hdc: cdrom_pc_intr: The drive appears confused (ireason = 0x01). Trying to recover by ending request. Feb 12 01:36:21 kernel: hdc: cdrom_pc_intr: The drive appears confused (ireason = 0x01). Trying to recover by ending request. Feb 12 01:38:49 kernel: hde: cdrom_pc_intr: The drive appears confused (ireason = 0x01). Trying to recover by ending request. Feb 12 08:06:07 kernel: hde: cdrom_pc_intr: The drive appears confused (ireason = 0x01). Trying to recover by ending request. I drove that devices on a pdc20268 based Promise Ultra TX/2 100 card for some time, which had some IDE/ATAPI issues documented. After exchanging that PCI card with a Silicon Image PCI0680 based one, the problem persists. Is there any firmware/atapi protocol problem known with these drives? These are the offenders: 42: IDE 02.0: 10602 CD-ROM (DVD) [Created at block.222] UDI: /org/freedesktop/Hal/devices/storage_model_PLEXTOR_DVDR_PX_608AL Unique ID: 90A1.yYhZwSaKZZ6 Parent ID: ejN_.zzJBQoyZsp8 SysFS ID: /block/hdc SysFS BusID: 1.0 SysFS Device Link: /devices/pci:00/:00:0e.0/:02:06.0/ide1/1.0 Hardware Class: cdrom Model: PLEXTOR DVDR PX-608AL Vendor: PLEXTOR Device: DVDR PX-608AL Revision: 1.01 Serial ID: GDDL000676UE Driver: SiI_IDE, ide-cdrom Driver Modules: siimage, ide_cd Device File: /dev/hdc Device Files: /dev/hdc, /dev/disk/by-path/pci-:02:06.0-ide-0:0 Device Number: block 22:0 Features: CD-R, CD-RW, DVD, DVD-R, DVD-RW, DVD+R, DVD+RW, DVD+DL, DVDRAM Drive status: no medium Config Status: cfg=no, avail=yes, need=no, active=unknown Attached to: #34 (Unknown mass storage controller) Drive Speed: 24 43: IDE 04.0: 10602 CD-ROM (DVD) [Created at block.222] UDI: /org/freedesktop/Hal/devices/storage_model_PLEXTOR_DVDR_PX_608AL_0 Unique ID: 3Ng9.rKN6BMng3oC Parent ID: ejN_.zzJBQoyZsp8 SysFS ID: /block/hde SysFS BusID: 2.0 SysFS Device Link: /devices/pci:00/:00:0e.0/:02:06.0/ide2/2.0 Hardware Class: cdrom Model: PLEXTOR DVDR PX-608AL Vendor: PLEXTOR Device: DVDR PX-608AL Revision: 1.01 Serial ID: GGDL007101UE Driver: SiI_IDE, ide-cdrom Driver Modules: siimage, ide_cd Device File: /dev/hde Device Files: /dev/hde, /dev/disk/by-path/pci-:02:06.0-ide-1:0 Device Number: block 33:0 Features: CD-R, CD-RW, DVD, DVD-R, DVD-RW, DVD+R, DVD+RW, DVD+DL, DVDRAM Drive status: no medium Config Status: cfg=no, avail=yes, need=no, active=unknown Attached to: #34 (Unknown mass storage controller) Drive Speed: 24 hanging on this controller (now): 44: PCI 206.0: 0180 Unknown mass storage controller [Created at pci.286] UDI: /org/freedesktop/Hal/devices/pci_1095_680 Unique ID: ejN_.zzJBQoyZsp8 Parent ID: vuMS.8LoPsVNGJbF SysFS ID: /devices/pci:00/:00:0e.0/:02:06.0 SysFS BusID: :02:06.0 Hardware Class: storage Model: Silicon Image PCI0680 Ultra ATA-133 Host Controller Vendor: pci 0x1095 Silicon Image, Inc. Device: pci 0x0680 PCI0680 Ultra ATA-133 Host Controller SubVendor: pci 0x1095 Silicon Image, Inc. SubDevice: pci 0x0680 Revision: 0x02 Driver: SiI_IDE Driver Modules: siimage I/O Ports: 0x9c00-0x9c07 (rw) I/O Ports: 0x9800-0x9803 (rw) I/O Ports: 0x9400-0x9407 (rw) I/O Ports: 0x9000-0x9003 (rw) I/O Ports: 0x8c00-0x8c0f (rw) Memory Range: 0xfdfff000-0xfdfff0ff (rw,non-prefetchable) Memory Range: 0xf400-0xf407 (ro,prefetchable,disabled) IRQ: 169 (1767334 events) Module Alias: pci:v1095d0680sv1095sd0680bc01sc80i00 Driver Info #0: Driver Status: siimage is active Driver Activation Cmd: modprobe siimage Driver Info #1: Driver Status: pata_sil680 is active Driver Activation Cmd: modprobe pata_sil680 Config Status: cfg=no, avail=yes, need=no, active=unknown Attached to: #30 (PCI bridge) Any hints are highly appreciated. Pete - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Current qc_defer implementation may lead to infinite recursion
Tejun Heo [EMAIL PROTECTED] wrote: Elias Oltmanns wrote: This proves that piix_qc_defer() has declined the same command 100 times in succession. However, this will only happen if the status of all the commands enqueued for one port hasn't changed in the meantime. This suggests to me that the threads scheduled for command execution and completion aren't served for some reason. Any ideas? Blocked counts of 1 will cause busy looping because when blk_run_queue() returns because it's recursing too deep, it schedules unplug work right away, so it will easily loop 100 times. Max blocked counts should be adjusted to two (needs some testing before actually submitting the change). But that still shouldn't cause any lock up. What happens if you remove the 100 times limit? Does the machine hang on IO? Yes, it does. In fact, I had already verified that before sending the previous email. Regards, Elias - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
JMicron - hard resetting link
Hi list,
I seem to have a bug with JMicron controller in a Gigabyte GA-N680SLI-DQ6
motherboard.
http://www.gigabyte.com.tw/Support/Motherboard/BIOS_Model.aspx?ProductID=2460
Kernel is 2.6.24.
10 on-board SATA connectors, 2+4*JMicron 20360/20363 + 4*nVidia MCP55
2*200GB disks (System - SW RAID1) on the JMicron controller and
8*500 (Data - SW RAID6) - 4 on the JMicron, 4 on the nVidia controller.
Under heavy load the JMicron controller gets exceptions, then eventually
hard resetting link.
All 4 disks/connector, one after another. This of course kills the RAID
Excerpt from syslog
Feb 9 16:16:32 storage1 kernel: ata2.00: exception Emask 0x0 SAct 0x3
SErr 0x0 action 0x2 frozen
Feb 9 16:16:32 storage1 kernel: ata1.00: exception Emask 0x0 SAct 0x1f
SErr 0x0 action 0x2 frozen
Feb 9 16:16:32 storage1 kernel: ata1.00: cmd
61/08:00:73:12:d9/00:00:23:00:00/40 tag 0 ncq 4096 out
Feb 9 16:16:32 storage1 kernel: res
40/00:80:c3:7c:d3/00:01:23:00:00/40 Emask 0x4 (timeout)
Feb 9 16:16:32 storage1 kernel: ata1.00: status: { DRDY }
...
Feb 9 16:16:32 storage1 kernel: ata1.00: cmd
61/80:a0:c3:1f:d9/00:00:23:00:00/40 tag 20 ncq 65536 out
Feb 9 16:16:32 storage1 kernel: res
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Feb 9 16:16:32 storage1 kernel: ata1.00: status: { DRDY }
Feb 9 16:16:32 storage1 kernel: ata1: hard resetting link
Didn't dare to post all attachments, so
full dmesg
lspci -nn
syslog - from the error start
can be downloaded from:
http://www.huweb.hu/maques/tmp/jmicron
I'm lost.
Anyone seen such thing? What could it be? Hardware (MB, chipset, BIOS),
kernel (driver) or what?
Any suggestion? Kernel version to try, dispose hardware or shoot myself in
the head?
Thanks,
Gabor
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subject: [PATCH 1/3] Let scsi_cmnd-cmnd use request-cmd buffer
On Tue, Feb 12 2008 at 19:45 +0200, Christoph Hellwig [EMAIL PROTECTED] wrote: On Sun, Feb 10, 2008 at 09:05:17PM +0200, Boaz Harrosh wrote: - Lots of drivers still use MAX_COMMAND_SIZE. So I have left that #define but equate it to BLK_MAX_CDB. The way I see it and is reflected in the patch below is. MAX_COMMAND_SIZE - means: The longest fixed-length (*) SCSI CDB as per the SCSI standard and is not related to the implementation. BLK_MAX_CDB. - The allocated space at the request level (*)fixed-length here means commands that their size can be determined by their opcode and the CDB does not carry a length specifier, like the VARIABLE_LENGTH_CMD(0x7f) command. This is actually not exactly true and the SCSI standard also defines extended commands and vendor specific commands that can be bigger than 16 bytes. The kernel will support these using the same infrastructure used for VARLEN CDB's. So in effect MAX_COMMAND_SIZE means the maximum size command scsi-ml supports without specifying a cmd_len by ULD's A comment like this should be near the declaration of MAX_COMMAND_SIZE +#define MAX_COMMAND_SIZE 16 +#if (MAX_COMMAND_SIZE BLK_MAX_CDB) +# error MAX_COMMAND_SIZE can not be smaller than BLK_MAX_CDB +#endif No tabs between the # and the rest of the cpp command, please. Either nothing or a single space as indentation instead. Except for those two small nitpicks this looks very good to me. Nice memory saving aswel. Agree with both comments. Thanks for the review, will fix in the next submission. Boaz - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] enclosure: add support for enclosure services
On Tue, 2008-02-12 at 11:07 -0800, Kristen Carlson Accardi wrote: I understand what you are trying to do - I guess I just doubt the value you've added by doing this. I think that there's going to be so much customization that system vendors will want to add, that they are going to wind up adding a custom library regardless, so standardising those few things won't buy us anything. It depends ... if you actually have a use for the customisations, yes. If you just want the basics of who (what's in the enclousure), what (activity) and where (locate) then I think it solves your problem almost entirely. So, entirely as a straw horse, tell me what else your enclosures provide that I haven't listed in the four points. The SES standards too provide a huge range of things that no-one ever seems to implement (temperature, power, fan speeds etc). I think the users of enclosures fall int these categories 85% just want to know where their device actually is (i.e. that sdc is in enclosure slot 5) 50% like watching the activity lights 30% want to be able to have a visual locate function 20% want a visual failure indication (the other 80% rely on some OS notification instead) When you add up the overlapping needs, you get about 90% of people happy with the basics that the enclosure services provide. Could there be more ... sure; should there be more ... I don't think so ... that's what value add the user libraries can provide. James - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Open bugs
On Feb 12, 2008 9:57 AM, James Bottomley [EMAIL PROTECTED] wrote: Added linux-scsi for the SCSI ones On Tue, 2008-02-12 at 00:18 -0800, Natalie Protasevich wrote: Hello, The bugs listed are over a month old, and haven't been addressed yet. It would be appreciated if corresponding maintainers identify whether the bugs have been fixed, or need to be worked on, and take appropriate action. In most cases, reporters are standing by and ready to provide information and necessary testing. Thanks! SCSI== Problems on booting http://bugzilla.kernel.org/show_bug.cgi?id=9621 Date: 12/22/2007 Regression Summary: The boot stops / hangs on hardware detection of SCSI. I have an InitioINI-9X00U/UW When I have an usb key sticked in /dev/sba, and run lilo then, then it dont boot but give L99 99 99 99 ... error I think this was fixed by commit e2d435ea4084022ab88efa74214accb45b1f9e92 Apparently bugzilla email is on the fritz again because this bug report didn't come across linux-scsi. I just fixed that, thanks. It was incorrect assign-to party. Resetting RAID attached to a FC Switch causes kernel panic and crash http://bugzilla.kernel.org/show_bug.cgi?id=9598 12/18/2007 Hardware Environment:SunFire X4200 - 2 x dual core AMD Opteron CPUs, 8GB Ram, Qlogic FC adapter. Summary: Resetting the RAID box causes the X4200 to crash. This one looks like the usual problem of remove re-add with the SCSI device model. 3ware 9650SE -8LPML not recognized by 3w-9xxx driver http://bugzilla.kernel.org/show_bug.cgi?id=8908 08/19/2007 Problem Description: The 3w-9xxx kernel driver for 3ware 9xxx SATA RAID Controller series did not recognize the 3ware 9650SE-8LPML SATA RAID Controller. Since this one never apparently worked it's not a regression but an enhancement request, isn't it? No this is not a regression. The bug list that I post is just any bugs (mostly unattended or stalled). Sometimes those are regressions off of the Raphael's list, when they don't get resolved for a while, or just random regressions that haven't showed up on the hot list by Raphael. However, adding this PCI ID to the driver should be fairly straightforward. Does anyone know what the actual PCI IDs are? I just asked the reporter to provide this information, thanks. James - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHSET libata-dev#upstream] clean up scsi_host_templates and ata_port_operations, take #2
Tejun Heo wrote: * pata_scc should now have NULL thaw after conversion. I'm sorry. This is a bug. Please use default thaw (ata_bmdma_thaw) for pata_scc. Cheers - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
ide=reverse do we still need this?
Hi, I'm reworking the pci device list logic (we currently keep all PCI devices in 2 lists, which isn't the nicest, we should be able to get away with only 1 list.) The only bother I've found so far is the pci_get_device_reverse() function, it's used in 2 places, IDE and the calgary driver. I'm curious if we really still support the ide=reverse option? It's a config option that I don't think the distros still enable (SuSE does not). Is this still needed these days? In digging, we changed this option in 2.2.x from being called pci=reverse and no one else seems to miss it. Any thoughts? thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] pata_scc.c: add thaw ops
This patch adds default thaw ops and fixes the freeze/thaw inconsistency. Signed-off-by: Kou Ishizaki [EMAIL PROTECTED] Signed-off-by: Akira Iguchi [EMAIL PROTECTED] --- diff -pu linux-2.6.25-rc1/drivers/ata/pata_scc.c linux-2.6.25-rc1_mod/drivers/ata/pata_scc.c --- linux-2.6.25-rc1/drivers/ata/pata_scc.c 2008-02-11 07:18:14.0 +0900 +++ linux-2.6.25-rc1_mod/drivers/ata/pata_scc.c 2008-02-13 11:37:34.0 +0900 @@ -1007,6 +1007,8 @@ static const struct ata_port_operations .qc_issue = ata_qc_issue_prot, .freeze = scc_bmdma_freeze, + .thaw = ata_bmdma_thaw, + .error_handler = scc_error_handler, .post_internal_cmd = scc_bmdma_stop, - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ide=reverse do we still need this?
On Tue, Feb 12, 2008 at 04:15:07PM -0800, Greg KH wrote: I'm curious if we really still support the ide=reverse option? It's a config option that I don't think the distros still enable (SuSE does not). Is this still needed these days? My server has a consumer-grade desktop amd64 mobo, with all that implies about cheap hardware and strange/misleading bios options. It also has an add-in dual IDE card with the main data on raid1. It's set to ide=reverse, without that it doesn't boot (the add-ins are IDE, system drive is SATA, so I guess it probably tries to boot from the DVD - it's been a long time since it bit me and I don't remember the full details. That was how it was set for 2.6.18.6, and how it now boots from 2.6.22.18. I think at one time the order of the interfaces might have been different. Certainly, I carry forward a fallback without ide=reverse in lilo.conf, just in case the disks move on my next kernel upgrade. What a distro selects should cover most of that distro's users, but that is not anywhere near providing 100% coverage for *all* the hardware out there. Also, you can force your users to e.g. mount by label. So far, that hasn't been forced on me, and I really hate having to reboot that box :) Ken -- das eine Mal als Tragödie, das andere Mal als Farce - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pci_get_device_reverse(), why does Calgary need this?
Why does the calgary driver need this? Can we just use pci_get_device() instead? Why do you need to walk the device list backwards? Do you get false positives going forward? It doesn't look to be performance critical so the driver can pci_get_device until the end and use the final hit anyway. IDE reverse is more problematic but nobody seems to use it. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libata/sata_sil24 cache alignment problem?
I tell you what ... find me a parisc box that actually has IDE and we might have told you ... The NS87415 variant IDE has been tested on parisc and didn't blow up - must just be lucky. (actually, the pa8800's have IDE CD's on a cmd640 chip, but that oopses on boot for no reason we've tracked yet). With libata, old IDE or both ? and what does the oops look like ? - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH #upstream] libata: implement libata.force module parameter
This patch implements libata.force module parameter which can
selectively override ATA port, link and device configurations
including cable type, SATA PHY SPD limit, transfer mode and NCQ.
For example, you can say use 1.5Gbps for all fan-out ports attached
to the second port but allow 3.0Gbps for the PMP device itself, oh,
the device attached to the third fan-out port chokes on NCQ and
shouldn't go over UDMA4 by the following.
libata.force=2:1.5g,2.15:3.0g,2.03:noncq,udma4
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
Okay, the build failure is dependent on compiler version. 4.1.2 fails
but 4.2.1 is okay. I was using 4.2.1 so I didn't know about it.
const is dropped from the offending structure and comment is added.
Documentation/kernel-parameters.txt | 35 +++
drivers/ata/libata-core.c | 380 +++-
drivers/ata/libata-eh.c |8
drivers/ata/libata.h|1
4 files changed, 420 insertions(+), 4 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 8fd5aa4..e06ccf4 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -945,6 +945,41 @@ and is between 256 and 4096 characters. It is defined in
the file
when set.
Format: int
+ libata.force= [LIBATA] Force configurations. The format is comma
+ separated list of [ID:]VAL where ID is
+ PORT[:DEVICE]. PORT and DEVICE are decimal numbers
+ matching port, link or device. Basically, it matches
+ the ATA ID string printed on console by libata. If
+ the whole ID part is omitted, the last PORT and DEVICE
+ values are used. If ID hasn't been specified yet, the
+ configuration applies to all ports, links and devices.
+
+ If only DEVICE is omitted, the parameter applies to
+ the port and all links and devices behind it. DEVICE
+ number of 0 either selects the first device or the
+ first fan-out link behind PMP device. It does not
+ select the host link. DEVICE number of 15 selects the
+ host link and device attached to it.
+
+ The VAL specifies the configuration to force. As long
+ as there's no ambiguity shortcut notation is allowed.
+ For example, both 1.5 and 1.5G would work for 1.5Gbps.
+ The following configurations can be forced.
+
+ * Cable type: 40c, 80c, short40c, unk, ign or sata.
+ Any ID with matching PORT is used.
+
+ * SATA link speed limit: 1.5Gbps or 3.0Gbps.
+
+ * Transfer mode: pio[0-7], mwdma[0-4] and udma[0-7].
+ udma[/][16,25,33,44,66,100,133] notation is also
+ allowed.
+
+ * [no]ncq: Turn on or off NCQ.
+
+ If there are multiple matching configurations changing
+ the same attribute, the last one is used.
+
load_ramdisk= [RAM] List of ramdisks to load from floppy
See Documentation/ramdisk.txt.
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 3011919..7d752c0 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -87,6 +87,28 @@ static struct workqueue_struct *ata_wq;
struct workqueue_struct *ata_aux_wq;
+struct ata_force_param {
+ const char *name;
+ unsigned intcbl;
+ int spd_limit;
+ unsigned long xfer_mask;
+ unsigned inthorkage_on;
+ unsigned inthorkage_off;
+};
+
+struct ata_force_ent {
+ int port;
+ int device;
+ struct ata_force_param param;
+};
+
+static struct ata_force_ent *ata_force_tbl;
+static int ata_force_tbl_size;
+
+static char ata_force_param_buf[PAGE_SIZE] __initdata;
+module_param_string(force, ata_force_param_buf, sizeof(ata_force_param_buf),
0444);
+MODULE_PARM_DESC(force, Force ATA configurations including cable type, link
speed and transfer mode (see Documentation/kernel-parameters.txt for details));
+
int atapi_enabled = 1;
module_param(atapi_enabled, int, 0444);
MODULE_PARM_DESC(atapi_enabled, Enable discovery of ATAPI devices (0=off,
1=on));
@@ -130,6 +152,179 @@ MODULE_VERSION(DRV_VERSION);
/**
+ * ata_force_cbl - force cable type according to libata.force
+ * @link: ATA link of interest
+ *
+ * Force cable type according to libata.force and whine about it.
+ * The last entry which has matching port number is used, so it
+ * can be specified as part of device force parameters.
Re: JMicron - hard resetting link
Hello, Gabor FUNK wrote: What I said was that timeouts occurring due to transmission errors should be recoverable. It seems like IRQ delivery didn't work probably due to screaming IRQ. I need to see the messages before the first relevant error message. It's always a good idea to post full kernel log from boot till failure. Things which don't seem relevant are often relevant. Naturally. Full kern.log with boot: http://www.huweb.hu/maques/tmp/jmicron/kern.log (no edits, there are really only those 2 lines between Feb 6 and Feb 9's 1st exception) Hmmm... Indeed. This is the first time this mode of failure is reported. Previously there was kernel 2.6.23.9 and I noticed the following in syslog by then: Feb 6 19:10:19 storage1 kernel: ata4: D2H reg with I during NCQ, this message won't be printed again Feb 6 19:10:20 storage1 kernel: ata1: D2H reg with I during NCQ, this message won't be printed again Feb 6 19:10:20 storage1 kernel: ata2: D2H reg with I during NCQ, this message won't be printed again Feb 6 19:10:21 storage1 kernel: ata3: D2H reg with I during NCQ, this message won't be printed again I googled and saw that there was some fixes related to this (maybe it was you), so that's why we hoped that 2.6.24 will fix this. Actually the above error messages were gone, but... Yeap, those are gone. Till now, none of this kind of problem has been tracked down to MB or the controller while 90% of hardware problems turned out to be power related. I'll put a brand new, probably different PSU in the case and put the MB and the 4 disks of the problematic controller on it, and put the 2 system and other 4 disks to this one (or even another one). Yeap, please keep me posted. Meanwhile I'd welcome if you have any suggestion why controller reset causing a fatal error... BTW, the drives were accessible after the array broke (when I got there). What do you mean by 'drives were accessible'? /dev/sdX nodes were accessible? -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHSET libata-dev#upstream] clean up scsi_host_templates and ata_port_operations, take #2
Akira Iguchi wrote: Tejun Heo wrote: * pata_scc should now have NULL thaw after conversion. I'm sorry. This is a bug. Please use default thaw (ata_bmdma_thaw) for pata_scc. That change should be a separate patch. This patchset shouldn't change any actual behavior but adding ata_bmdma_thaw does change the behavior. Can you please submit a separate patch to fix it? Thanks. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] ide: warm-plug support for IDE devices and other goodies
On Tuesday 12 February 2008, Benjamin Herrenschmidt wrote:
On Fri, 2008-02-08 at 19:40 +1100, Benjamin Herrenschmidt wrote:
On Fri, 2008-02-08 at 01:44 +0100, Bartlomiej Zolnierkiewicz wrote:
- couple of fixes and preparatory patches
- rework of PowerMac media-bay support ([un]register IDE devices instead
of
[un]registering IDE interface) [ it is the main reason for spamming PPC
ML ]
Interesting... I was thinking about doing a full remove of the device at
a higher level instead but I suppose what you propose is easier.
I'll have a look test next week hopefully.
Also, the above would have the advantage of not relying on drivers/ide
infrastructure, and thus working with libata (once somebody has ported
pmac ide to libata).
Neither of these things exist at the moment so lets stick to the existing
code which is scheduled for 2.6.26 and which finally allows removal of ppc
specific ide hacks from arch/{powerpc,ppc} (500 LOC gone, patches to be
posted this week), not to mention other nice changes in the future...
Thanks,
Bart
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] ide-floppy: use rq-cmd for preparing and sending packet cmds to the drive
Hi Borislav,
On Tuesday 12 February 2008, Borislav Petkov wrote:
Hi Bart,
here's a first go at converting ide-floppy to using rq-cmd for packet
commands.
The code below is pretty rough and from what i can tell needs to be hammered a
lot more, for it raises a lot of issues:
I think that this _really_ should be done _after_ unifying ATAPI handling [*].
Otherwise you will be making some of the same changes to the _three_ copies
of (more or less) identical code and more importantly we will have to delay
unification after _all_ drivers are converted to rq-cmd[] (+ lets not forget
that I'll have more changes to review ;).
(*) please take a closer look at *_issue_pc(), *_transfer_pc() and *_pc_intr()
in ide-{floppy,tape,scsi} (the useful hint is that after making these
functions free of references to device driver specific objects/functions
we can use drive-media == ide_{floppy,tape,scsi} checks for handling
not yet fully unified / media type specific code).
1. The command control (pc-callback, request type, etc) is still done using
the pc
pointer passed to all the functions prior to issuing the command. This, imho,
can be
It sems that different callback types can be easily removed by merging code
from all callbacks into the common one which decides what to do basing on
the ATAPI command (pc-c[0] / rq-cmd[0]).
[ Probably same can be done in ide-tape's case. ]
done a lot cleaner and easier. What is the rationale here, do we want
ide_atapi_pc
removed in the long run and get by only with rq's as is the case with ide-cd?
Yes but this is also premature w.r.t. the current state of these drivers.
2. I end up allocating all the requests on the stack just like the respective
ide_atapi_pc structs and don't use the heap allocation facilities. I guess
this will
get resolved after we've decided on allocation scheme for the rq structs...
In the
meantime, the stack is probably gonna blow with additional sizeof(struct
request).
Hmm, we shouldn't be worried about increased stack usage - please take look
at the current code workflow:
- idefloppy_queue_pc_head() is only called from idefloppy_retry_pc()
(which gets rq from floppy-pc_stack[]).
- idefloppy_queue_pc_tail() already gets rq from the stack
(the changes just move the allocation from this function up)
3. idefloppy_queue_pc_{head,tail} turn into simple wrappers which begs for
merging them but this is trivial.
no need for these wrappers now = s/merging/removing/
4.Made rq-cmd_type = REQ_TYPE_ATA_PC from REQ_TYPE_SPECIAL but i guess the
final goal is REQ_TYPE_BLOCK_PC. Will have to see how is this handled in the
block layer and whether we're ready to do that.
It is not the safe until you review both IDE subsystem and block layer w.r.t.
handling of REQ_TYPE_ATA_PC vs REQ_TYPE_SPECIAL. After quick audit it seems
to be safe on the block layer level but ironically ide-floppy itself uses
blk_special_request() checks (IOW this change just broke ide-floppy ;).
Please do _not_ mix such changes with purely cleanup ones which shouldn't
(in theory) cause any functional changes (doing it in a post-patch after
having anylised potential consequences is fine).
5. This change is less intrusive but begs for a lot of simplification
afterwards
similar to ide-cd, which will probably get rid of all those create_.*_cmd()
helpers.
6. Only compile-tested. Proper testing follows...
The one more concern is with many places extracting rq from pc. This looks
backwards and un-intuitive (your patch is not to be blamed for this because
it was like that before).
Maybe we should just set rq-special to pc, pass rq where necessary and
remove pc-rq (this may be a worthy change to do in pre-patch but again,
ATAPI handling unification should come first).
In summary: the change is good but it looks a bit premature as IMO we should
try to cleanup as much as possible (ATAPI handling unification / -callbacks
/ pc-rq removal / anything else?) before attacking things like pc-c[] -
rq-cmd[] / removing static pc/rq allocations / etc.
Thanks,
Bart
--
commit 8359f6f7122e87c30467ff73895399b82610b835
Author: Borislav Petkov [EMAIL PROTECTED]
Date: Tue Feb 12 10:06:55 2008 +0100
ide-floppy: use rq-cmd for preparing and sending packet cmds to the drive
... similar to the way it is done in ide-cd.
Signed-off-by: Borislav Petkov [EMAIL PROTECTED]
diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c
index bf1ef60..ab125ad 100644
--- a/drivers/ide/ide-floppy.c
+++ b/drivers/ide/ide-floppy.c
@@ -297,16 +297,9 @@ static void idefloppy_update_buffers(ide_drive_t *drive,
* the current request so that it will be processed immediately, on the next
* pass through the driver.
*/
-static void idefloppy_queue_pc_head(ide_drive_t *drive, struct ide_atapi_pc
*pc,
- struct request *rq)
+static void idefloppy_queue_pc_head(ide_drive_t *drive, struct ide_atapi_pc
*pc)
{
- struct
Re: [PATCH] ide-scsi: do non-atomic pc-flags testing
On Tuesday 12 February 2008, Borislav Petkov wrote:
commit 272976f0f5754707f9e41da315717a6eb8d9d536
Author: Borislav Petkov [EMAIL PROTECTED]
Date: Tue Feb 12 16:22:44 2008 +0100
ide-scsi: do non-atomic pc-flags testing
Signed-off-by: Borislav Petkov [EMAIL PROTECTED]
diff --git a/drivers/scsi/ide-scsi.c b/drivers/scsi/ide-scsi.c
index 5ec421c..eb84cdc 100644
--- a/drivers/scsi/ide-scsi.c
+++ b/drivers/scsi/ide-scsi.c
@@ -319,8 +319,10 @@ static int idescsi_end_request (ide_drive_t *drive, int
uptodate, int nrsecs)
pc = opc;
rq = pc-rq;
pc-scsi_cmd-result = (CHECK_CONDITION 1) |
- ((test_bit(PC_TIMEDOUT,
pc-flags)?DID_TIME_OUT:DID_OK) 16);
- } else if (test_bit(PC_TIMEDOUT, pc-flags)) {
+ (((pc-flags PC_TIMEDOUT) ?
+ DID_TIME_OUT :
+ DID_OK) 16);
+ } else if (pc-flags PC_TIMEDOUT) {
How's about renaming flag defines to PC_FLAG_* at the same time
(like it was done for other ATAPI drivers)?
Otherwise looks good.
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] ide: warm-plug support for IDE devices and other goodies
On Fri, 2008-02-08 at 19:40 +1100, Benjamin Herrenschmidt wrote: On Fri, 2008-02-08 at 01:44 +0100, Bartlomiej Zolnierkiewicz wrote: - couple of fixes and preparatory patches - rework of PowerMac media-bay support ([un]register IDE devices instead of [un]registering IDE interface) [ it is the main reason for spamming PPC ML ] Interesting... I was thinking about doing a full remove of the device at a higher level instead but I suppose what you propose is easier. I'll have a look test next week hopefully. Also, the above would have the advantage of not relying on drivers/ide infrastructure, and thus working with libata (once somebody has ported pmac ide to libata). Ben. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] ide: warm-plug support for IDE devices and other goodies
On Tue, 2008-02-12 at 12:49 +0100, Gabriel Paubert wrote: On Fri, Feb 08, 2008 at 07:40:43PM +1100, Benjamin Herrenschmidt wrote: On Fri, 2008-02-08 at 01:44 +0100, Bartlomiej Zolnierkiewicz wrote: - couple of fixes and preparatory patches - rework of PowerMac media-bay support ([un]register IDE devices instead of [un]registering IDE interface) [ it is the main reason for spamming PPC ML ] Interesting... I was thinking about doing a full remove of the device at a higher level instead but I suppose what you propose is easier. Well, I have serious problem on a Pegasos which appeared some time between 2.6.24 and 2.6.25-rc1: at boot I get an infinite string of hdb: empty DMA table? I'm trying to bisect it right now. Pegasos doesn't use the pmac ide which is what we were discussing. It uses a VIA IDE which uses a normal PRD table. So something else must have broken... Ben. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subject: [PATCH 1/3] Let scsi_cmnd-cmnd use request-cmd buffer
On Sun, 2008-02-10 at 21:05 +0200, Boaz Harrosh wrote: - struct scsi_cmnd had a 16 bytes command buffer of its own. This is an unnecessary duplication and copy of request's cmd. It is probably left overs from the time that scsi_cmnd could function without a request attached. So clean that up. - Once above is done, few places, apart from scsi-ml, needed adjustments due to changing the data type of scsi_cmnd-cmnd. - Lots of drivers still use MAX_COMMAND_SIZE. So I have left that #define but equate it to BLK_MAX_CDB. The way I see it and is reflected in the patch below is. MAX_COMMAND_SIZE - means: The longest fixed-length (*) SCSI CDB as per the SCSI standard and is not related to the implementation. BLK_MAX_CDB. - The allocated space at the request level (*)fixed-length here means commands that their size can be determined by their opcode and the CDB does not carry a length specifier, like the VARIABLE_LENGTH_CMD(0x7f) command. This is actually not exactly true and the SCSI standard also defines extended commands and vendor specific commands that can be bigger than 16 bytes. The kernel will support these using the same infrastructure used for VARLEN CDB's. So in effect MAX_COMMAND_SIZE means the maximum size command scsi-ml supports without specifying a cmd_len by ULD's When we do this, what happens to the minority of drivers that need the command in DMAable memory ... or have you audited them all and we can now dump the DMA pool allocation for SCSI commands? James - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] enclosure: add support for enclosure services
On Tue, 12 Feb 2008 12:45:35 -0600 James Bottomley [EMAIL PROTECTED] wrote: On Tue, 2008-02-12 at 10:22 -0800, Kristen Carlson Accardi wrote: I apologize for taking so long to review this patch. I obviously agree wholeheartedly with Luben. The problem I ran into while trying to design an enclosure management interface for the SATA devices is that there is all this vendor defined stuff. For example, for the AHCI LED protocol, the only defined LED is 'activity'. For LED2 and LED3 it is up to hardware vendors to define these. For SGPIO there's all kinds of ways for hw vendors to customize. I felt that it was going to be a maintainance nightmare to have to keep track of various vendors enclosure implementations in the ahci driver, and that it'd be better to just have user space libraries take care of that. Plus, that way a vendor doesn't have to get a patch into the kernel to get their new spiffy wizzy bang blinky lights working (think of how long it takes something to even get into a vendor kernel, which is what these guys care about...). So I'm still not sold on having an enclosure abstraction in the kernel - at least for the SATA controllers. Correct me if I'm wrong, but didn't the original AHCI enclosure patch expose activity LEDs via sysfs? You are sort of wrong. we exposed a sysfs entry to enable sofware controlled activity LED, then the driver was responsible for turning it on and off. (blech, I know, but some vendors want this feature). I'm not saying there aren't a lot of non standard pieces that need to be activated by direct commands or other user activated protocol. I am saying there are a lot of standard pieces that we could do with showing in a uniform manner. The pieces I think are absolutely standard are 1. Actual enclosure presence (is this device in an enclosure) 2. Activity LED, this seems to be a feature of every enclosure. I also think the following are reasonably standard (based on the fact that most enclosure standards recommend but don't require this): 3. Locate LED (for locating the device). Even if you only have an activity LED, this is usually done by flashing the activity LED in a well defined pattern. 4. Fault. this is the least standardised of the lot, but does seem to be present in about every enclosure implementation. All I've done is standardise these four pieces ... the services actually take into account that it might not be possible to do certain of these (like fault). James I understand what you are trying to do - I guess I just doubt the value you've added by doing this. I think that there's going to be so much customization that system vendors will want to add, that they are going to wind up adding a custom library regardless, so standardising those few things won't buy us anything. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
libata/sata_sil24 cache alignment problem?
Hi All, I've implemented the Linux PCI support for a new architecture, and have run into what appears to be a bug in libata, but I don't understand why it wouldn't have been seen on other architectures. The processor is a Tile64, which is a 64 core, 64 bit VLIW processor with non-coherent DMA - DMA transfers bypass the cache, so cache coherence must be maintained manually. I am working with libata v2.0, from Linux 2.6.18, and the sata_sil24 driver for a Silicon Images SIL3531A chip. The problem occurs when the drive's model and serial numbers are read at startup via ata_dev_read_id(). They are read once on driver startup, then when the the error handler first runs it verifies that the model and serial numbers match what was read when the driver started. The problem is with the proximity of the private_data and sector_buf members of the ata_port struct, and the sector_buf not being cache aligned. ata_qc_issue() calls dma_map_single(), which in my case flushes and invalidates the cache for the buffer it's about DMA into (ata_port-sector_buf), then calls sil24_qc_issue(). sil24_qc_issue() then dereferences ata_port-private_data, which causes the cache line containing it to be read in, bringing part of the sector_buf with it, before the DMA transfer has taken place. The Tile64 processor does not have a cache invalidate instruction, only a flush/invalidate, so dma_unmap_single() can't invalidate the portion of the sector_buf that's been inadvertently read in, and I get a serial number and/or model number mismatch, due to part of the buffer being stale. Documentation/DMA-API.txt states that addresses passed to dma_map_single() and dma_unmap_single() must be cache aligned for this reason. Both calls to ata_dev_read_id() request DMA into a non cache-aligned buffer, but only the second call - via ata_dev_same_device() - has a conflict that can cause the cache line to be read back in during the very narrow window for which this vulnerability exists. Has anyone else reported a problem like this? It requires non-coherent DMA, and a lack of a cache invalidate instruction, and one of the drivers that has this problem (it looks like sata_qstor does too, I haven't looked at others), so maybe that doesn't cover any other architectures. I can provide a patch if you're interested. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] enclosure: add support for enclosure services
On Tue, 2008-02-12 at 10:22 -0800, Kristen Carlson Accardi wrote: I apologize for taking so long to review this patch. I obviously agree wholeheartedly with Luben. The problem I ran into while trying to design an enclosure management interface for the SATA devices is that there is all this vendor defined stuff. For example, for the AHCI LED protocol, the only defined LED is 'activity'. For LED2 and LED3 it is up to hardware vendors to define these. For SGPIO there's all kinds of ways for hw vendors to customize. I felt that it was going to be a maintainance nightmare to have to keep track of various vendors enclosure implementations in the ahci driver, and that it'd be better to just have user space libraries take care of that. Plus, that way a vendor doesn't have to get a patch into the kernel to get their new spiffy wizzy bang blinky lights working (think of how long it takes something to even get into a vendor kernel, which is what these guys care about...). So I'm still not sold on having an enclosure abstraction in the kernel - at least for the SATA controllers. Correct me if I'm wrong, but didn't the original AHCI enclosure patch expose activity LEDs via sysfs? I'm not saying there aren't a lot of non standard pieces that need to be activated by direct commands or other user activated protocol. I am saying there are a lot of standard pieces that we could do with showing in a uniform manner. The pieces I think are absolutely standard are 1. Actual enclosure presence (is this device in an enclosure) 2. Activity LED, this seems to be a feature of every enclosure. I also think the following are reasonably standard (based on the fact that most enclosure standards recommend but don't require this): 3. Locate LED (for locating the device). Even if you only have an activity LED, this is usually done by flashing the activity LED in a well defined pattern. 4. Fault. this is the least standardised of the lot, but does seem to be present in about every enclosure implementation. All I've done is standardise these four pieces ... the services actually take into account that it might not be possible to do certain of these (like fault). James - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] enclosure: add support for enclosure services
On Mon, 4 Feb 2008 18:01:36 -0800 (PST) Luben Tuikov [EMAIL PROTECTED] wrote: --- On Mon, 2/4/08, James Bottomley [EMAIL PROTECTED] wrote: The enclosure misc device is really just a library providing sysfs support for physical enclosure devices and their components. Who is the target audience/user of those facilities? a) The kernel itself needing to read/write SES pages? That depends on the enclosure integration, but right at the moment, it doesn't Yes, I didn't suspect so. b) A user space application using sysfs to read/write SES pages? Not an application so much as a user. The idea of sysfs is to allow users to get and set the information in addition to applications. Exactly the same argument stands for a user-space application with a user-space library. This is the classical case of where it is better to do this in user-space as opposed to the kernel. The kernel provides capability to access the SES device. The user space application and library provide interpretation and control. Thus if the enclosure were upgraded, one doesn't need to upgrade their kernel in order to utilize the new capabilities of the SES device. Plus upgrading a user-space application is a lot easier than the kernel (and no reboot necessary). Consider another thing: vendors would really like unprecedented access to the SES device in the enclosure so as your ses/enclosure code keeps state it would get out of sync when vendor user-space enclosure applications access (and modify) the SES device's pages. You can test this yourself: submit a patch that removes SES /dev/sgX support; advertise your ses/class solution and watch the fun. At the moment SES device management is done via an application (user-space) and a user-space library used by the application and /dev/sgX to send SCSI commands to the SES device. I must have missed that when I was looking for implementations; what's the URL? I'm not aware of any GPLed ones. That doesn't necessarily mean that the best course of action is to bloat the kernel. You can move your ses/enclosure stuff to a user space application library and thus start a GPLed one. But, if we have non-scsi enclosures to integrate, that makes it harder for a user application because it has to know all the implementations. So does the kernel. And as I pointed out above, it is a lot easier to upgrade a user-space application and library than it is to upgrade a new kernel and having to reboot the computer to run the new kernel. A sysfs framework on the other hand is a universal known thing for the user applications. So would a user-space ses library, a la libses.so. One could have a very good argument to not bloat the kernel with this but leave it to a user-space application and a library to do all this and communicate with the SES device via the kernel's /dev/sgX. The same thing goes for other esoteric SCSI infrastructure pieces like cd changers. On the whole, given that ATA is asking for enclosure management in kernel, it makes sense to consolidate the infrastructure and a ses ULD is a very good test bed. What is wrong with exporting the SES device as /dev/sgX and having a user-space application and library to do all this? Luben Hi, I apologize for taking so long to review this patch. I obviously agree wholeheartedly with Luben. The problem I ran into while trying to design an enclosure management interface for the SATA devices is that there is all this vendor defined stuff. For example, for the AHCI LED protocol, the only defined LED is 'activity'. For LED2 and LED3 it is up to hardware vendors to define these. For SGPIO there's all kinds of ways for hw vendors to customize. I felt that it was going to be a maintainance nightmare to have to keep track of various vendors enclosure implementations in the ahci driver, and that it'd be better to just have user space libraries take care of that. Plus, that way a vendor doesn't have to get a patch into the kernel to get their new spiffy wizzy bang blinky lights working (think of how long it takes something to even get into a vendor kernel, which is what these guys care about...). So I'm still not sold on having an enclosure abstraction in the kernel - at least for the SATA controllers. Kristen - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] block layer varlen-cdb
On Tue, Feb 12 2008 at 19:54 +0200, Boaz Harrosh [EMAIL PROTECTED] wrote: On Tue, Feb 12 2008 at 19:48 +0200, Christoph Hellwig [EMAIL PROTECTED] wrote: On Sun, Feb 10, 2008 at 09:09:41PM +0200, Boaz Harrosh wrote: - add varlen_cdb and varlen_cdb_len to hold a large user cdb if needed. They start as empty. Allocation of buffer must be done by user and held until request execution is done. - Since there can be either a fix_length command up to 16 bytes or a variable_length, larger then 16 bytes, commands but never both, we hold the two types in a union to save space. The presence of varlen_cdb_len and cmd_len==0 signals a varlen_cdb mode. this one I'm a bit confused by, why can't we just set the length of the variable length command in cmd_len aswell, and if cmd_len the length of the cmd array it's a variable length command? Note that this is both to keep the logic simpler and not to grow struct request further. Especially for the rather rare case of a bidi command. Because this will be dangerous for the Legacy block devices. Unlike scsi drivers block drivers do not have a .max_cmnd_len and upper layer will not check to make sure that the device supports the longer command. If such a command goes through, lets say bsg the drivers do blindly memcpy(,,rq-cmd_len) and will crash. Better safe then sorry, at no cost. Boaz - PS: the struct request does not grow. Because before cmd_len was unsigned but now both cmd_len and varlen_cdb_len are short so it is the same as before. Boaz - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libata/sata_sil24 cache alignment problem?
On Wed, 2008-02-13 at 02:13 +, Alan Cox wrote: I tell you what ... find me a parisc box that actually has IDE and we might have told you ... The NS87415 variant IDE has been tested on parisc and didn't blow up - must just be lucky. Actually, it's only a specific class of machines: the PCX (that's most of the 715,725 series) that are fully incoherent. PCXL hack around this by making the page uncacheable and the 64 bit machines have coherence index handling which fixes this up (mostly). (actually, the pa8800's have IDE CD's on a cmd640 chip, but that oopses on boot for no reason we've tracked yet). With libata, old IDE or both ? and what does the oops look like ? Unfortunately, there's no oops; we get a high priority machine check which means something has gone wrong somewhere and it's not pretty. It's on my todo list to track down ... I just don't have one of these boxes and CDs are hard to play with remotely. James - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
pci_get_device_reverse(), why does Calgary need this?
On Tue, Feb 12, 2008 at 04:15:06PM -0800, Greg KH wrote: Hi, I'm reworking the pci device list logic (we currently keep all PCI devices in 2 lists, which isn't the nicest, we should be able to get away with only 1 list.) The only bother I've found so far is the pci_get_device_reverse() function, it's used in 2 places, IDE and the calgary driver. Why does the calgary driver need this? Can we just use pci_get_device() instead? Why do you need to walk the device list backwards? Do you get false positives going forward? thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Open bugs
Added linux-scsi for the SCSI ones On Tue, 2008-02-12 at 00:18 -0800, Natalie Protasevich wrote: Hello, The bugs listed are over a month old, and haven't been addressed yet. It would be appreciated if corresponding maintainers identify whether the bugs have been fixed, or need to be worked on, and take appropriate action. In most cases, reporters are standing by and ready to provide information and necessary testing. Thanks! SCSI== Problems on booting http://bugzilla.kernel.org/show_bug.cgi?id=9621 Date: 12/22/2007 Regression Summary: The boot stops / hangs on hardware detection of SCSI. I have an InitioINI-9X00U/UW When I have an usb key sticked in /dev/sba, and run lilo then, then it dont boot but give L99 99 99 99 ... error I think this was fixed by commit e2d435ea4084022ab88efa74214accb45b1f9e92 Apparently bugzilla email is on the fritz again because this bug report didn't come across linux-scsi. Resetting RAID attached to a FC Switch causes kernel panic and crash http://bugzilla.kernel.org/show_bug.cgi?id=9598 12/18/2007 Hardware Environment:SunFire X4200 - 2 x dual core AMD Opteron CPUs, 8GB Ram, Qlogic FC adapter. Summary: Resetting the RAID box causes the X4200 to crash. This one looks like the usual problem of remove re-add with the SCSI device model. 3ware 9650SE -8LPML not recognized by 3w-9xxx driver http://bugzilla.kernel.org/show_bug.cgi?id=8908 08/19/2007 Problem Description: The 3w-9xxx kernel driver for 3ware 9xxx SATA RAID Controller series did not recognize the 3ware 9650SE-8LPML SATA RAID Controller. Since this one never apparently worked it's not a regression but an enhancement request, isn't it? However, adding this PCI ID to the driver should be fairly straightforward. Does anyone know what the actual PCI IDs are? James - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] block layer varlen-cdb
On Tue, Feb 12 2008 at 19:48 +0200, Christoph Hellwig [EMAIL PROTECTED] wrote: On Sun, Feb 10, 2008 at 09:09:41PM +0200, Boaz Harrosh wrote: - add varlen_cdb and varlen_cdb_len to hold a large user cdb if needed. They start as empty. Allocation of buffer must be done by user and held until request execution is done. - Since there can be either a fix_length command up to 16 bytes or a variable_length, larger then 16 bytes, commands but never both, we hold the two types in a union to save space. The presence of varlen_cdb_len and cmd_len==0 signals a varlen_cdb mode. this one I'm a bit confused by, why can't we just set the length of the variable length command in cmd_len aswell, and if cmd_len the length of the cmd array it's a variable length command? Note that this is both to keep the logic simpler and not to grow struct request further. Especially for the rather rare case of a bidi command. Because this will be dangerous for the Legacy block devices. Unlike scsi drivers block drivers do not have a .max_cmnd_len and upper layer will not check to make sure that the device supports the longer command. If such a command goes through, lets say bsg the drivers do blindly memcpy(,,rq-cmd_len) and will crash. Better safe then sorry, at no cost. Boaz - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libata/sata_sil24 cache alignment problem?
Has anyone else reported a problem like this? It requires non-coherent DMA, and a lack of a cache invalidate instruction, and one of the drivers that has this problem (it looks like sata_qstor does too, I haven't looked at others), so maybe that doesn't cover any other architectures. Nobody has, not even PA-RISC which is normally guaranteed to make life miserable in the caching area but I agree entirely with your diagnosis and that buffer should indeed be marked cache aligned I can provide a patch if you're interested. Please do. Alan - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subject: [PATCH 1/3] Let scsi_cmnd-cmnd use request-cmd buffer
On Sun, Feb 10, 2008 at 09:05:17PM +0200, Boaz Harrosh wrote: - Lots of drivers still use MAX_COMMAND_SIZE. So I have left that #define but equate it to BLK_MAX_CDB. The way I see it and is reflected in the patch below is. MAX_COMMAND_SIZE - means: The longest fixed-length (*) SCSI CDB as per the SCSI standard and is not related to the implementation. BLK_MAX_CDB. - The allocated space at the request level (*)fixed-length here means commands that their size can be determined by their opcode and the CDB does not carry a length specifier, like the VARIABLE_LENGTH_CMD(0x7f) command. This is actually not exactly true and the SCSI standard also defines extended commands and vendor specific commands that can be bigger than 16 bytes. The kernel will support these using the same infrastructure used for VARLEN CDB's. So in effect MAX_COMMAND_SIZE means the maximum size command scsi-ml supports without specifying a cmd_len by ULD's A comment like this should be near the declaration of MAX_COMMAND_SIZE +#define MAX_COMMAND_SIZE 16 +#if (MAX_COMMAND_SIZE BLK_MAX_CDB) +#error MAX_COMMAND_SIZE can not be smaller than BLK_MAX_CDB +#endif No tabs between the # and the rest of the cpp command, please. Either nothing or a single space as indentation instead. Except for those two small nitpicks this looks very good to me. Nice memory saving aswel. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: JMicron - hard resetting link
What I said was that timeouts occurring due to transmission errors should be recoverable. It seems like IRQ delivery didn't work probably due to screaming IRQ. I need to see the messages before the first relevant error message. It's always a good idea to post full kernel log from boot till failure. Things which don't seem relevant are often relevant. Naturally. Full kern.log with boot: http://www.huweb.hu/maques/tmp/jmicron/kern.log (no edits, there are really only those 2 lines between Feb 6 and Feb 9's 1st exception) Previously there was kernel 2.6.23.9 and I noticed the following in syslog by then: Feb 6 19:10:19 storage1 kernel: ata4: D2H reg with I during NCQ, this message won't be printed again Feb 6 19:10:20 storage1 kernel: ata1: D2H reg with I during NCQ, this message won't be printed again Feb 6 19:10:20 storage1 kernel: ata2: D2H reg with I during NCQ, this message won't be printed again Feb 6 19:10:21 storage1 kernel: ata3: D2H reg with I during NCQ, this message won't be printed again I googled and saw that there was some fixes related to this (maybe it was you), so that's why we hoped that 2.6.24 will fix this. Actually the above error messages were gone, but... Till now, none of this kind of problem has been tracked down to MB or the controller while 90% of hardware problems turned out to be power related. I'll put a brand new, probably different PSU in the case and put the MB and the 4 disks of the problematic controller on it, and put the 2 system and other 4 disks to this one (or even another one). Meanwhile I'd welcome if you have any suggestion why controller reset causing a fatal error... BTW, the drives were accessible after the array broke (when I got there). Thanks, Gabor - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: IDE cdrom problem with PLEXTOR DVDR PX-608AL
On Tue, Feb 12, 2008 at 10:26:17AM +0100, Hans-Peter Jansen wrote: Hi, I suffer from unreliable cdrom operations (failing DAE and burn sessions) with the openSUSE 2.6.18.8-0.7-bigsmp kernel. Hi, can please you test this with a more recent kernel. Yours is almost ancient - from Sep. 2006. Thanks. -- Regards/Gruß, Boris. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ide=reverse do we still need this?
On Wed, Feb 13, 2008 at 02:41:07AM +0100, Rene Herman wrote: On 13-02-08 01:15, Greg KH wrote: I'm reworking the pci device list logic (we currently keep all PCI devices in 2 lists, which isn't the nicest, we should be able to get away with only 1 list.) The only bother I've found so far is the pci_get_device_reverse() function, it's used in 2 places, IDE and the calgary driver. I'm curious if we really still support the ide=reverse option? It's a config option that I don't think the distros still enable (SuSE does not). Is this still needed these days? In digging, we changed this option in 2.2.x from being called pci=reverse and no one else seems to miss it. Any thoughts? While details escape me somewhat again at the monment, a few months ago I was playing around with a PCI Promise IDE controller and needed ide=reverse to save me from having to switch disks around to still have a bootable system. Or some such. Not too clear anymore, but I remember it saved the day. You couldn't just change the boot disk in grub? Or use an initramfs and /dev/disk/by-id/ to keep any future moves stable? thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pci_get_device_reverse(), why does Calgary need this?
On Wed, Feb 13, 2008 at 02:17:37AM +, Alan Cox wrote: Why does the calgary driver need this? Can we just use pci_get_device() instead? Why do you need to walk the device list backwards? Do you get false positives going forward? It doesn't look to be performance critical so the driver can pci_get_device until the end and use the final hit anyway. That would make more sense. IDE reverse is more problematic but nobody seems to use it. I've seen two posters say they use it. I'm wondering what it is really solving if they use it, and why if it's really needed, scsi never had to implement such a hack... thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ide=reverse do we still need this?
On Wed, Feb 13, 2008 at 02:43:29AM +, Ken Moffat wrote: On Tue, Feb 12, 2008 at 04:15:07PM -0800, Greg KH wrote: I'm curious if we really still support the ide=reverse option? It's a config option that I don't think the distros still enable (SuSE does not). Is this still needed these days? My server has a consumer-grade desktop amd64 mobo, with all that implies about cheap hardware and strange/misleading bios options. It also has an add-in dual IDE card with the main data on raid1. It's set to ide=reverse, without that it doesn't boot (the add-ins are IDE, system drive is SATA, so I guess it probably tries to boot from the DVD - it's been a long time since it bit me and I don't remember the full details. That was how it was set for 2.6.18.6, and how it now boots from 2.6.22.18. I think at one time the order of the interfaces might have been different. Certainly, I carry forward a fallback without ide=reverse in lilo.conf, just in case the disks move on my next kernel upgrade. Can't you just boot with /dev/disk/by-id/ and an initramfs to not have to worry about such a thing in the future? Have you tried the PATA drivers instead of IDE to see if this solves the moves around issue? If they work, then you would not need the command line option at all. thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libata/sata_sil24 cache alignment problem?
I wonder if this may be what I am seeing with the Si3124 on my Alpha based setup. I'm not sure if Alpha meets all the criteria, but the thing refuses to recognize any drivers when they are connected and I see what are supposed pci parity failures. maybe not ... ...tom Mark Mason wrote: Hi All, I've implemented the Linux PCI support for a new architecture, and have run into what appears to be a bug in libata, but I don't understand why it wouldn't have been seen on other architectures. The processor is a Tile64, which is a 64 core, 64 bit VLIW processor with non-coherent DMA - DMA transfers bypass the cache, so cache coherence must be maintained manually. I am working with libata v2.0, from Linux 2.6.18, and the sata_sil24 driver for a Silicon Images SIL3531A chip. The problem occurs when the drive's model and serial numbers are read at startup via ata_dev_read_id(). They are read once on driver startup, then when the the error handler first runs it verifies that the model and serial numbers match what was read when the driver started. The problem is with the proximity of the private_data and sector_buf members of the ata_port struct, and the sector_buf not being cache aligned. ata_qc_issue() calls dma_map_single(), which in my case flushes and invalidates the cache for the buffer it's about DMA into (ata_port-sector_buf), then calls sil24_qc_issue(). sil24_qc_issue() then dereferences ata_port-private_data, which causes the cache line containing it to be read in, bringing part of the sector_buf with it, before the DMA transfer has taken place. The Tile64 processor does not have a cache invalidate instruction, only a flush/invalidate, so dma_unmap_single() can't invalidate the portion of the sector_buf that's been inadvertently read in, and I get a serial number and/or model number mismatch, due to part of the buffer being stale. Documentation/DMA-API.txt states that addresses passed to dma_map_single() and dma_unmap_single() must be cache aligned for this reason. Both calls to ata_dev_read_id() request DMA into a non cache-aligned buffer, but only the second call - via ata_dev_same_device() - has a conflict that can cause the cache line to be read back in during the very narrow window for which this vulnerability exists. Has anyone else reported a problem like this? It requires non-coherent DMA, and a lack of a cache invalidate instruction, and one of the drivers that has this problem (it looks like sata_qstor does too, I haven't looked at others), so maybe that doesn't cover any other architectures. I can provide a patch if you're interested. - To unsubscribe from this list: send the line unsubscribe linux-ide 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-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] block layer varlen-cdb
On Sun, Feb 10, 2008 at 09:09:41PM +0200, Boaz Harrosh wrote: - add varlen_cdb and varlen_cdb_len to hold a large user cdb if needed. They start as empty. Allocation of buffer must be done by user and held until request execution is done. - Since there can be either a fix_length command up to 16 bytes or a variable_length, larger then 16 bytes, commands but never both, we hold the two types in a union to save space. The presence of varlen_cdb_len and cmd_len==0 signals a varlen_cdb mode. this one I'm a bit confused by, why can't we just set the length of the variable length command in cmd_len aswell, and if cmd_len the length of the cmd array it's a variable length command? Note that this is both to keep the logic simpler and not to grow struct request further. Especially for the rather rare case of a bidi command. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] pata_cs5536.c bugfix
Fix speed negotiation for secondary device.
Signed-off-by: Martin K. Petersen [EMAIL PROTECTED]
---
diff -r 9f5ca67cc28f drivers/ata/pata_cs5536.c
--- a/drivers/ata/pata_cs5536.c Mon Feb 11 20:52:01 2008 -0800
+++ b/drivers/ata/pata_cs5536.c Tue Feb 12 08:52:43 2008 -0500
@@ -40,7 +40,7 @@
#include asm/msr.h
#define DRV_NAME pata_cs5536
-#define DRV_VERSION0.0.6
+#define DRV_VERSION0.0.7
enum {
CFG = 0,
@@ -153,8 +153,8 @@ static void cs5536_set_piomode(struct at
struct ata_device *pair = ata_dev_pair(adev);
int mode = adev-pio_mode - XFER_PIO_0;
int cmdmode = mode;
- int dshift = ap-port_no ? IDE_D1_SHIFT : IDE_D0_SHIFT;
- int cshift = ap-port_no ? IDE_CAST_D1_SHIFT : IDE_CAST_D0_SHIFT;
+ int dshift = adev-devno ? IDE_D1_SHIFT : IDE_D0_SHIFT;
+ int cshift = adev-devno ? IDE_CAST_D1_SHIFT : IDE_CAST_D0_SHIFT;
u32 dtc, cast, etc;
if (pair)
@@ -201,7 +201,7 @@ static void cs5536_set_dmamode(struct at
struct pci_dev *pdev = to_pci_dev(ap-host-dev);
u32 dtc, etc;
int mode = adev-dma_mode;
- int dshift = ap-port_no ? IDE_D1_SHIFT : IDE_D0_SHIFT;
+ int dshift = adev-devno ? IDE_D1_SHIFT : IDE_D0_SHIFT;
if (mode = XFER_UDMA_0) {
cs5536_read(pdev, ETC, etc);
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ide-scsi: do non-atomic pc-flags testing
commit 272976f0f5754707f9e41da315717a6eb8d9d536
Author: Borislav Petkov [EMAIL PROTECTED]
Date: Tue Feb 12 16:22:44 2008 +0100
ide-scsi: do non-atomic pc-flags testing
Signed-off-by: Borislav Petkov [EMAIL PROTECTED]
diff --git a/drivers/scsi/ide-scsi.c b/drivers/scsi/ide-scsi.c
index 5ec421c..eb84cdc 100644
--- a/drivers/scsi/ide-scsi.c
+++ b/drivers/scsi/ide-scsi.c
@@ -319,8 +319,10 @@ static int idescsi_end_request (ide_drive_t *drive, int
uptodate, int nrsecs)
pc = opc;
rq = pc-rq;
pc-scsi_cmd-result = (CHECK_CONDITION 1) |
- ((test_bit(PC_TIMEDOUT,
pc-flags)?DID_TIME_OUT:DID_OK) 16);
- } else if (test_bit(PC_TIMEDOUT, pc-flags)) {
+ (((pc-flags PC_TIMEDOUT) ?
+ DID_TIME_OUT :
+ DID_OK) 16);
+ } else if (pc-flags PC_TIMEDOUT) {
if (log)
printk (KERN_WARNING ide-scsi: %s: timed out for
%lu\n,
drive-name,
pc-scsi_cmd-serial_number);
@@ -362,7 +364,7 @@ static int idescsi_expiry(ide_drive_t *drive)
#if IDESCSI_DEBUG_LOG
printk(KERN_WARNING idescsi_expiry called for %lu at %lu\n,
pc-scsi_cmd-serial_number, jiffies);
#endif
- set_bit(PC_TIMEDOUT, pc-flags);
+ pc-flags |= PC_TIMEDOUT;
return 0; /* we do not want the
ide subsystem to retry */
}
@@ -384,7 +386,7 @@ static ide_startstop_t idescsi_pc_intr (ide_drive_t *drive)
printk (KERN_INFO ide-scsi: Reached idescsi_pc_intr interrupt
handler\n);
#endif /* IDESCSI_DEBUG_LOG */
- if (test_bit(PC_TIMEDOUT, pc-flags)){
+ if (pc-flags PC_TIMEDOUT) {
#if IDESCSI_DEBUG_LOG
printk(KERN_WARNING idescsi_pc_intr: got timed out packet %lu
at %lu\n,
pc-scsi_cmd-serial_number, jiffies);
@@ -393,7 +395,8 @@ static ide_startstop_t idescsi_pc_intr (ide_drive_t *drive)
idescsi_end_request (drive, 1, 0);
return ide_stopped;
}
- if (test_and_clear_bit (PC_DMA_IN_PROGRESS, pc-flags)) {
+ if (pc-flags PC_DMA_IN_PROGRESS) {
+ pc-flags = ~PC_DMA_IN_PROGRESS;
#if IDESCSI_DEBUG_LOG
printk (ide-scsi: %s: DMA complete\n, drive-name);
#endif /* IDESCSI_DEBUG_LOG */
@@ -432,7 +435,7 @@ static ide_startstop_t idescsi_pc_intr (ide_drive_t *drive)
- discarding data\n);
temp = pc-buf_size - pc-xferred;
if (temp) {
- clear_bit(PC_WRITING, pc-flags);
+ pc-flags = ~PC_WRITING;
if (pc-sg)
idescsi_input_buffers(drive, pc,
temp);
@@ -454,14 +457,14 @@ static ide_startstop_t idescsi_pc_intr (ide_drive_t
*drive)
}
}
if (ireason IO) {
- clear_bit(PC_WRITING, pc-flags);
+ pc-flags = ~PC_WRITING;
if (pc-sg)
idescsi_input_buffers(drive, pc, bcount);
else
hwif-atapi_input_bytes(drive, pc-cur_pos,
bcount);
} else {
- set_bit(PC_WRITING, pc-flags);
+ pc-flags |= PC_WRITING;
if (pc-sg)
idescsi_output_buffers(drive, pc, bcount);
else
@@ -501,8 +504,8 @@ static ide_startstop_t idescsi_transfer_pc(ide_drive_t
*drive)
ide_set_handler(drive, idescsi_pc_intr, get_timeout(pc),
idescsi_expiry);
/* Send the actual packet */
drive-hwif-atapi_output_bytes(drive, scsi-pc-c, 12);
- if (test_bit (PC_DMA_OK, pc-flags)) {
- set_bit (PC_DMA_IN_PROGRESS, pc-flags);
+ if (pc-flags PC_DMA_OK) {
+ pc-flags |= PC_DMA_IN_PROGRESS;
hwif-dma_start(drive);
}
return ide_started;
@@ -512,10 +515,10 @@ static inline int idescsi_set_direction(struct
ide_atapi_pc *pc)
{
switch (pc-c[0]) {
case READ_6: case READ_10: case READ_12:
- clear_bit(PC_WRITING, pc-flags);
+ pc-flags = ~PC_WRITING;
return 0;
case WRITE_6: case WRITE_10: case WRITE_12:
- set_bit(PC_WRITING, pc-flags);
+ pc-flags |= PC_WRITING;
return 0;
default:
return 1;
@@ -572,7 +575,7 @@ static ide_startstop_t idescsi_issue_pc(ide_drive_t *drive,
ide_pktcmd_tf_load(drive,
Re: JMicron - hard resetting link
Gabor FUNK wrote: It shouldn't kill the RAID. Hmmm... The log is truncated. Can you please post full kernel log spanning from boot to array death? RAID dies because controller dies, then it loses 4 disks out of 8... Actually, the server last time was up and running for 2 months. Then when it failed the 1st time, I did some tests and it went on for 3 days, including building the raid and heavy test file copy. The full log from the 1st relevant error message till the death of the array is here: http://www.huweb.hu/maques/tmp/jmicron/syslog What I said was that timeouts occurring due to transmission errors should be recoverable. It seems like IRQ delivery didn't work probably due to screaming IRQ. I need to see the messages before the first relevant error message. It's always a good idea to post full kernel log from boot till failure. Things which don't seem relevant are often relevant. Move half of the drives to the new PSU and see whether the problem goes away. This is a new server, with a Chieftec GPS650AB, 650W PSU in it. Though AFAIK a harddisk consumes around 10W, and I will try to use more than one PSU-s. I've recently tracked down IO problems a server product line from a major (really, one of the top three) vendor to malfunctioning PSU, so don't trust the labeling too much. The main problem is that I can't immediately see if it helps or not. Even if it will work without this problem for a week, I can't be sure it still will in 2 months... Because of this - and because I believe that this problem related to the HW (motherboard, chipset) - I'd rather just throw away the MB and use an other one with two extra 4 port SATA cards. Till now, none of this kind of problem has been tracked down to MB or the controller while 90% of hardware problems turned out to be power related. Thanks. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: JMicron - hard resetting link
I seem to have a bug with JMicron controller in a Gigabyte GA-N680SLI-DQ6 motherboard. http://www.gigabyte.com.tw/Support/Motherboard/BIOS_Model.aspx?ProductID=2460 Kernel is 2.6.24. 10 on-board SATA connectors, 2+4*JMicron 20360/20363 + 4*nVidia MCP55 2*200GB disks (System - SW RAID1) on the JMicron controller and 8*500 (Data - SW RAID6) - 4 on the JMicron, 4 on the nVidia controller. Under heavy load the JMicron controller gets exceptions, then eventually hard resetting link. All 4 disks/connector, one after another. This of course kills the RAID It shouldn't kill the RAID. Hmmm... The log is truncated. Can you please post full kernel log spanning from boot to array death? RAID dies because controller dies, then it loses 4 disks out of 8... Actually, the server last time was up and running for 2 months. Then when it failed the 1st time, I did some tests and it went on for 3 days, including building the raid and heavy test file copy. The full log from the 1st relevant error message till the death of the array is here: http://www.huweb.hu/maques/tmp/jmicron/syslog Move half of the drives to the new PSU and see whether the problem goes away. This is a new server, with a Chieftec GPS650AB, 650W PSU in it. Though AFAIK a harddisk consumes around 10W, and I will try to use more than one PSU-s. The main problem is that I can't immediately see if it helps or not. Even if it will work without this problem for a week, I can't be sure it still will in 2 months... Because of this - and because I believe that this problem related to the HW (motherboard, chipset) - I'd rather just throw away the MB and use an other one with two extra 4 port SATA cards. Thanks, Gabor - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH] ide-floppy: use rq-cmd for preparing and sending packet cmds to the drive
Hi Bart,
here's a first go at converting ide-floppy to using rq-cmd for packet commands.
The code below is pretty rough and from what i can tell needs to be hammered a
lot more, for it raises a lot of issues:
1. The command control (pc-callback, request type, etc) is still done using
the pc
pointer passed to all the functions prior to issuing the command. This, imho,
can be
done a lot cleaner and easier. What is the rationale here, do we want
ide_atapi_pc
removed in the long run and get by only with rq's as is the case with ide-cd?
2. I end up allocating all the requests on the stack just like the respective
ide_atapi_pc structs and don't use the heap allocation facilities. I guess this
will
get resolved after we've decided on allocation scheme for the rq structs... In
the
meantime, the stack is probably gonna blow with additional sizeof(struct
request).
3. idefloppy_queue_pc_{head,tail} turn into simple wrappers which begs for
merging them but this is trivial.
4.Made rq-cmd_type = REQ_TYPE_ATA_PC from REQ_TYPE_SPECIAL but i guess the
final goal is REQ_TYPE_BLOCK_PC. Will have to see how is this handled in the
block layer and whether we're ready to do that.
5. This change is less intrusive but begs for a lot of simplification afterwards
similar to ide-cd, which will probably get rid of all those create_.*_cmd()
helpers.
6. Only compile-tested. Proper testing follows...
--
commit 8359f6f7122e87c30467ff73895399b82610b835
Author: Borislav Petkov [EMAIL PROTECTED]
Date: Tue Feb 12 10:06:55 2008 +0100
ide-floppy: use rq-cmd for preparing and sending packet cmds to the drive
... similar to the way it is done in ide-cd.
Signed-off-by: Borislav Petkov [EMAIL PROTECTED]
diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c
index bf1ef60..ab125ad 100644
--- a/drivers/ide/ide-floppy.c
+++ b/drivers/ide/ide-floppy.c
@@ -297,16 +297,9 @@ static void idefloppy_update_buffers(ide_drive_t *drive,
* the current request so that it will be processed immediately, on the next
* pass through the driver.
*/
-static void idefloppy_queue_pc_head(ide_drive_t *drive, struct ide_atapi_pc
*pc,
- struct request *rq)
+static void idefloppy_queue_pc_head(ide_drive_t *drive, struct ide_atapi_pc
*pc)
{
- struct ide_floppy_obj *floppy = drive-driver_data;
-
- ide_init_drive_cmd(rq);
- rq-buffer = (char *) pc;
- rq-cmd_type = REQ_TYPE_SPECIAL;
- rq-rq_disk = floppy-disk;
- (void) ide_do_drive_cmd(drive, rq, ide_preempt);
+ (void)ide_do_drive_cmd(drive, pc-rq, ide_preempt);
}
static struct ide_atapi_pc *idefloppy_next_pc_storage(ide_drive_t *drive)
@@ -344,7 +337,7 @@ static void idefloppy_request_sense_callback(ide_drive_t
*drive)
if (floppy-failed_pc)
debug_log(pc = %x, sense key = %x, asc = %x,
ascq = %x\n,
- floppy-failed_pc-c[0],
+ floppy-failed_pc-rq-cmd[0],
floppy-sense_key,
floppy-asc,
floppy-ascq);
@@ -375,7 +368,6 @@ static void idefloppy_pc_callback(ide_drive_t *drive)
static void idefloppy_init_pc(struct ide_atapi_pc *pc)
{
- memset(pc-c, 0, 12);
pc-retries = 0;
pc-flags = 0;
pc-req_xfer = 0;
@@ -384,11 +376,25 @@ static void idefloppy_init_pc(struct ide_atapi_pc *pc)
pc-idefloppy_callback = idefloppy_pc_callback;
}
-static void idefloppy_create_request_sense_cmd(struct ide_atapi_pc *pc)
+void ide_floppy_init_rq(ide_drive_t *drive, struct request *rq)
+{
+ struct ide_floppy_obj *floppy = drive-driver_data;
+
+ ide_init_drive_cmd(rq);
+ rq-cmd_type = REQ_TYPE_ATA_PC;
+ rq-rq_disk = floppy-disk;
+}
+
+static void idefloppy_create_request_sense_cmd(ide_drive_t *drive,
+ struct ide_atapi_pc *pc)
{
+ struct request *rq = pc-rq;
+
idefloppy_init_pc(pc);
- pc-c[0] = GPCMD_REQUEST_SENSE;
- pc-c[4] = 255;
+ ide_floppy_init_rq(drive, rq);
+
+ rq-cmd[0] = GPCMD_REQUEST_SENSE;
+ rq-cmd[4] = 255;
pc-req_xfer = 18;
pc-idefloppy_callback = idefloppy_request_sense_callback;
}
@@ -405,8 +411,8 @@ static void idefloppy_retry_pc(ide_drive_t *drive)
(void)ide_read_error(drive);
pc = idefloppy_next_pc_storage(drive);
rq = idefloppy_next_rq_storage(drive);
- idefloppy_create_request_sense_cmd(pc);
- idefloppy_queue_pc_head(drive, pc, rq);
+ idefloppy_create_request_sense_cmd(drive, pc);
+ idefloppy_queue_pc_head(drive, pc);
}
/* The usual interrupt handler called during a packet command. */
@@ -452,7 +458,7 @@ static ide_startstop_t idefloppy_pc_intr (ide_drive_t
*drive)
/* Error detected */
debug_log(%s: I/O error\n,
[PATCH] ide-floppy: rename end_request handler properly
commit 48f9b88d491aa478ffcf21e2f523e3665db0770b
Author: Borislav Petkov [EMAIL PROTECTED]
Date: Tue Feb 12 09:42:19 2008 +0100
ide-floppy: rename end_request handler properly
mv idefloppy_do_end_request - idefloppy_end_request as is the case with
ide-cd
Signed-off-by: Borislav Petkov [EMAIL PROTECTED]
diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c
index 7e62dfc..bf1ef60 100644
--- a/drivers/ide/ide-floppy.c
+++ b/drivers/ide/ide-floppy.c
@@ -213,7 +213,7 @@ static void ide_floppy_put(struct ide_floppy_obj *floppy)
* Used to finish servicing a request. For read/write requests, we will call
* ide_end_request to pass to the next buffer.
*/
-static int idefloppy_do_end_request(ide_drive_t *drive, int uptodate, int
nsecs)
+static int idefloppy_end_request(ide_drive_t *drive, int uptodate, int nsecs)
{
idefloppy_floppy_t *floppy = drive-driver_data;
struct request *rq = HWGROUP(drive)-rq;
@@ -270,7 +270,7 @@ static void ide_floppy_io_buffers(ide_drive_t *drive,
struct ide_atapi_pc *pc,
done += count;
}
- idefloppy_do_end_request(drive, 1, done 9);
+ idefloppy_end_request(drive, 1, done 9);
if (bcount) {
printk(KERN_ERR %s: leftover data in %s, bcount == %d\n,
@@ -289,7 +289,7 @@ static void idefloppy_update_buffers(ide_drive_t *drive,
struct bio *bio = rq-bio;
while ((bio = rq-bio) != NULL)
- idefloppy_do_end_request(drive, 1, 0);
+ idefloppy_end_request(drive, 1, 0);
}
/*
@@ -355,11 +355,11 @@ static void idefloppy_request_sense_callback(ide_drive_t
*drive)
floppy-ascq);
- idefloppy_do_end_request(drive, 1, 0);
+ idefloppy_end_request(drive, 1, 0);
} else {
printk(KERN_ERR Error in REQUEST SENSE itself - Aborting
request!\n);
- idefloppy_do_end_request(drive, 0, 0);
+ idefloppy_end_request(drive, 0, 0);
}
}
@@ -370,7 +370,7 @@ static void idefloppy_pc_callback(ide_drive_t *drive)
debug_log(Reached %s\n, __func__);
- idefloppy_do_end_request(drive, floppy-pc-error ? 0 : 1, 0);
+ idefloppy_end_request(drive, floppy-pc-error ? 0 : 1, 0);
}
static void idefloppy_init_pc(struct ide_atapi_pc *pc)
@@ -715,7 +715,7 @@ static void idefloppy_rw_callback(ide_drive_t *drive)
{
debug_log(Reached %s\n, __func__);
- idefloppy_do_end_request(drive, 1, 0);
+ idefloppy_end_request(drive, 1, 0);
return;
}
@@ -863,7 +863,7 @@ static ide_startstop_t idefloppy_do_request(ide_drive_t
*drive,
else
printk(KERN_ERR ide-floppy: %s: I/O error\n,
drive-name);
- idefloppy_do_end_request(drive, 0, 0);
+ idefloppy_end_request(drive, 0, 0);
return ide_stopped;
}
if (blk_fs_request(rq)) {
@@ -871,7 +871,7 @@ static ide_startstop_t idefloppy_do_request(ide_drive_t
*drive,
(rq-nr_sectors % floppy-bs_factor)) {
printk(KERN_ERR %s: unsupported r/w request size\n,
drive-name);
- idefloppy_do_end_request(drive, 0, 0);
+ idefloppy_end_request(drive, 0, 0);
return ide_stopped;
}
pc = idefloppy_next_pc_storage(drive);
@@ -884,7 +884,7 @@ static ide_startstop_t idefloppy_do_request(ide_drive_t
*drive,
} else {
blk_dump_rq_flags(rq,
ide-floppy: unsupported command in queue);
- idefloppy_do_end_request(drive, 0, 0);
+ idefloppy_end_request(drive, 0, 0);
return ide_stopped;
}
@@ -1359,7 +1359,7 @@ static ide_driver_t idefloppy_driver = {
.media = ide_floppy,
.supports_dsc_overlap = 0,
.do_request = idefloppy_do_request,
- .end_request= idefloppy_do_end_request,
+ .end_request= idefloppy_end_request,
.error = __ide_error,
.abort = __ide_abort,
#ifdef CONFIG_IDE_PROC_FS
--
Regards/Gruß,
Boris.
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: JMicron - hard resetting link
Gabor FUNK wrote: Hi list, I seem to have a bug with JMicron controller in a Gigabyte GA-N680SLI-DQ6 motherboard. http://www.gigabyte.com.tw/Support/Motherboard/BIOS_Model.aspx?ProductID=2460 Kernel is 2.6.24. 10 on-board SATA connectors, 2+4*JMicron 20360/20363 + 4*nVidia MCP55 2*200GB disks (System - SW RAID1) on the JMicron controller and 8*500 (Data - SW RAID6) - 4 on the JMicron, 4 on the nVidia controller. Under heavy load the JMicron controller gets exceptions, then eventually hard resetting link. All 4 disks/connector, one after another. This of course kills the RAID It shouldn't kill the RAID. Hmmm... The log is truncated. Can you please post full kernel log spanning from boot to array death? I'm lost. Anyone seen such thing? What could it be? Hardware (MB, chipset, BIOS), kernel (driver) or what? Any suggestion? Kernel version to try, dispose hardware or shoot myself in the head? One of common causes for this kind of problem is bad power and PSUs which are rated for high wattage aren't always good enough. Prepare a power supply (popular cheap $15 one should do) such that it can be powered up by itself. http://modtown.co.uk/mt/article2.php?id=psumod Move half of the drives to the new PSU and see whether the problem goes away. Thanks. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Current qc_defer implementation may lead to infinite recursion
Elias Oltmanns wrote: Tejun Heo [EMAIL PROTECTED] wrote: Elias Oltmanns wrote: This proves that piix_qc_defer() has declined the same command 100 times in succession. However, this will only happen if the status of all the commands enqueued for one port hasn't changed in the meantime. This suggests to me that the threads scheduled for command execution and completion aren't served for some reason. Any ideas? Blocked counts of 1 will cause busy looping because when blk_run_queue() returns because it's recursing too deep, it schedules unplug work right away, so it will easily loop 100 times. Max blocked counts should be adjusted to two (needs some testing before actually submitting the change). But that still shouldn't cause any lock up. What happens if you remove the 100 times limit? Does the machine hang on IO? Yes, it does. In fact, I had already verified that before sending the previous email. Hmmm it's supposed not to lock up although it can cause busy wait. I'll test it tomorrow. Thanks. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] ide: warm-plug support for IDE devices and other goodies
On Fri, Feb 08, 2008 at 07:40:43PM +1100, Benjamin Herrenschmidt wrote: On Fri, 2008-02-08 at 01:44 +0100, Bartlomiej Zolnierkiewicz wrote: - couple of fixes and preparatory patches - rework of PowerMac media-bay support ([un]register IDE devices instead of [un]registering IDE interface) [ it is the main reason for spamming PPC ML ] Interesting... I was thinking about doing a full remove of the device at a higher level instead but I suppose what you propose is easier. Well, I have serious problem on a Pegasos which appeared some time between 2.6.24 and 2.6.25-rc1: at boot I get an infinite string of hdb: empty DMA table? I'm trying to bisect it right now. Gabriel I'll have a look test next week hopefully. Ben. ___ Linuxppc-dev mailing list [EMAIL PROTECTED] https://ozlabs.org/mailman/listinfo/linuxppc-dev - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] ide: warm-plug support for IDE devices and other goodies
On Tue, Feb 12, 2008 at 12:49:05PM +0100, Gabriel Paubert wrote: On Fri, Feb 08, 2008 at 07:40:43PM +1100, Benjamin Herrenschmidt wrote: On Fri, 2008-02-08 at 01:44 +0100, Bartlomiej Zolnierkiewicz wrote: - couple of fixes and preparatory patches - rework of PowerMac media-bay support ([un]register IDE devices instead of [un]registering IDE interface) [ it is the main reason for spamming PPC ML ] Interesting... I was thinking about doing a full remove of the device at a higher level instead but I suppose what you propose is easier. Well, I have serious problem on a Pegasos which appeared some time between 2.6.24 and 2.6.25-rc1: at boot I get an infinite string of hdb: empty DMA table? I'm trying to bisect it right now. Argh, the first bisect point ended up with timeouts on hdb... Flagged as bad, to try to see when the problems started, but I suspect that there are several. Gabriel - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] enclosure: add support for enclosure services
--- On Tue, 2/12/08, Kristen Carlson Accardi [EMAIL PROTECTED] wrote: Hi, I apologize for taking so long to review this patch. I obviously agree wholeheartedly with Luben. The problem I ran into while trying to design an enclosure management interface for the SATA devices is that there is all this vendor defined stuff. For example, for the AHCI LED protocol, the only defined LED is 'activity'. For LED2 and LED3 it is up to hardware vendors to define these. For SGPIO there's all kinds of ways for hw vendors to customize. I felt that it was going to be a maintainance nightmare to have to keep track of various vendors enclosure implementations in the ahci driver, and that it'd be better to just have user space libraries take care of that. Plus, that way a vendor doesn't have to get a patch into the kernel to get their new spiffy wizzy bang blinky lights working (think of how long it takes something to even get into a vendor kernel, which is what these guys care about...). So I'm still not sold on having an enclosure abstraction in the kernel - at least for the SATA controllers. And I agree wholeheartedly with Kristen. Luben - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ide-floppy: rename end_request handler properly
On Tuesday 12 February 2008, Borislav Petkov wrote: commit 48f9b88d491aa478ffcf21e2f523e3665db0770b Author: Borislav Petkov [EMAIL PROTECTED] Date: Tue Feb 12 09:42:19 2008 +0100 ide-floppy: rename end_request handler properly mv idefloppy_do_end_request - idefloppy_end_request as is the case with ide-cd Signed-off-by: Borislav Petkov [EMAIL PROTECTED] applied - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
