[PATCH 2/3 v2] i2c: i2c-piix4: Use the common mutex

[Zoltan Boszormenyi]

Use the common mutex from driver/usb/host/pci-quirks.c in the
i2c-piix4 driver to synchronize access to the I/O port pair
0xcd6 / 0xcd7.

At the same time, remove the request_region() call to reserve
these I/O ports, so the sp5100_tco watchdog driver can also
load. The mutex is enough to protect the I/O port accesses.
This is an old regression in Linux 4.4-rc4, caused by:

v2: Explicit extern reference for sb800_mutex

commit 2fee61d22e606fc99ade9079fda15fdee83ec33e
Author: Christian Fetzer <fetzer...@gmail.com>
Date:   Thu Nov 19 20:13:48 2015 +0100

i2c: piix4: Add support for multiplexed main adapter in SB800

Signed-off-by: Zoltan Boszormenyi <zbos...@pr.hu>
---
 drivers/i2c/busses/i2c-piix4.c | 43 +-
 1 file changed, 13 insertions(+), 30 deletions(-)

diff --git a/drivers/i2c/busses/i2c-piix4.c b/drivers/i2c/busses/i2c-piix4.c
index c21ca7b..6c56e96 100644
--- a/drivers/i2c/busses/i2c-piix4.c
+++ b/drivers/i2c/busses/i2c-piix4.c
@@ -144,10 +144,10 @@ static const struct dmi_system_id piix4_dmi_ibm[] = {
 
 /*
  * SB800 globals
- * piix4_mutex_sb800 protects piix4_port_sel_sb800 and the pair
- * of I/O ports at SB800_PIIX4_SMB_IDX.
+ * sb800_mutex in drivers/usb/host/pci-quirks.c protects
+ * piix4_port_sel_sb800 and the pair of I/O ports at SB800_PIIX4_SMB_IDX.
  */
-static DEFINE_MUTEX(piix4_mutex_sb800);
+extern struct mutex sb800_mutex;
 static u8 piix4_port_sel_sb800;
 static const char *piix4_main_port_names_sb800[PIIX4_MAX_ADAPTERS] = {
" port 0", " port 2", " port 3", " port 4"
@@ -157,8 +157,6 @@ static const char *piix4_aux_port_name_sb800 = " port 1";
 struct i2c_piix4_adapdata {
unsigned short smba;
 
-   /* SB800 */
-   bool sb800_main;
u8 port;/* Port number, shifted */
 };
 
@@ -286,12 +284,12 @@ static int piix4_setup_sb800(struct pci_dev *PIIX4_dev,
else
smb_en = (aux) ? 0x28 : 0x2c;
 
-   mutex_lock(_mutex_sb800);
+   mutex_lock(_mutex);
outb_p(smb_en, SB800_PIIX4_SMB_IDX);
smba_en_lo = inb_p(SB800_PIIX4_SMB_IDX + 1);
outb_p(smb_en + 1, SB800_PIIX4_SMB_IDX);
smba_en_hi = inb_p(SB800_PIIX4_SMB_IDX + 1);
-   mutex_unlock(_mutex_sb800);
+   mutex_unlock(_mutex);
 
if (!smb_en) {
smb_en_status = smba_en_lo & 0x10;
@@ -349,13 +347,13 @@ static int piix4_setup_sb800(struct pci_dev *PIIX4_dev,
if (PIIX4_dev->vendor == PCI_VENDOR_ID_AMD) {
piix4_port_sel_sb800 = SB800_PIIX4_PORT_IDX_ALT;
} else {
-   mutex_lock(_mutex_sb800);
+   mutex_lock(_mutex);
outb_p(SB800_PIIX4_PORT_IDX_SEL, SB800_PIIX4_SMB_IDX);
port_sel = inb_p(SB800_PIIX4_SMB_IDX + 1);
piix4_port_sel_sb800 = (port_sel & 0x01) ?
   SB800_PIIX4_PORT_IDX_ALT :
   SB800_PIIX4_PORT_IDX;
-   mutex_unlock(_mutex_sb800);
+   mutex_unlock(_mutex);
}
 
dev_info(_dev->dev,
@@ -592,7 +590,7 @@ static s32 piix4_access_sb800(struct i2c_adapter *adap, u16 
addr,
u8 port;
int retval;
 
-   mutex_lock(_mutex_sb800);
+   mutex_lock(_mutex);
 
/* Request the SMBUS semaphore, avoid conflicts with the IMC */
smbslvcnt  = inb_p(SMBSLVCNT);
@@ -608,7 +606,7 @@ static s32 piix4_access_sb800(struct i2c_adapter *adap, u16 
addr,
} while (--retries);
/* SMBus is still owned by the IMC, we give up */
if (!retries) {
-   mutex_unlock(_mutex_sb800);
+   mutex_unlock(_mutex);
return -EBUSY;
}
 
@@ -628,7 +626,7 @@ static s32 piix4_access_sb800(struct i2c_adapter *adap, u16 
addr,
/* Release the semaphore */
outb_p(smbslvcnt | 0x20, SMBSLVCNT);
 
-   mutex_unlock(_mutex_sb800);
+   mutex_unlock(_mutex);
 
return retval;
 }
@@ -705,7 +703,6 @@ static int piix4_add_adapter(struct pci_dev *dev, unsigned 
short smba,
}
 
adapdata->smba = smba;
-   adapdata->sb800_main = sb800_main;
adapdata->port = port << 1;
 
/* set up the sysfs linkage to our parent device */
@@ -771,29 +768,18 @@ static int piix4_probe(struct pci_dev *dev, const struct 
pci_device_id *id)
dev->vendor == PCI_VENDOR_ID_AMD) {
is_sb800 = true;
 
-   if (!request_region(SB800_PIIX4_SMB_IDX, 2, "smba_idx")) {
-   dev_err(>dev,
-   "SMBus base address index region 0x%x already in 
use!\n",
-   SB800_PIIX4_SMB_IDX);
-   return -EBUSY;
-   }
-
/* base address location etc changed in SB800 */
retval = piix4_setup_sb800(dev, id, 0);
-  

[PATCH 2/3 v2] i2c: i2c-piix4: Use the common mutex

[Zoltan Boszormenyi]

Use the common mutex from driver/usb/host/pci-quirks.c in the
i2c-piix4 driver to synchronize access to the I/O port pair
0xcd6 / 0xcd7.

At the same time, remove the request_region() call to reserve
these I/O ports, so the sp5100_tco watchdog driver can also
load. The mutex is enough to protect the I/O port accesses.
This is an old regression in Linux 4.4-rc4, caused by:

v2: Explicit extern reference for sb800_mutex

commit 2fee61d22e606fc99ade9079fda15fdee83ec33e
Author: Christian Fetzer 
Date:   Thu Nov 19 20:13:48 2015 +0100

i2c: piix4: Add support for multiplexed main adapter in SB800

Signed-off-by: Zoltan Boszormenyi 
---
 drivers/i2c/busses/i2c-piix4.c | 43 +-
 1 file changed, 13 insertions(+), 30 deletions(-)

diff --git a/drivers/i2c/busses/i2c-piix4.c b/drivers/i2c/busses/i2c-piix4.c
index c21ca7b..6c56e96 100644
--- a/drivers/i2c/busses/i2c-piix4.c
+++ b/drivers/i2c/busses/i2c-piix4.c
@@ -144,10 +144,10 @@ static const struct dmi_system_id piix4_dmi_ibm[] = {
 
 /*
  * SB800 globals
- * piix4_mutex_sb800 protects piix4_port_sel_sb800 and the pair
- * of I/O ports at SB800_PIIX4_SMB_IDX.
+ * sb800_mutex in drivers/usb/host/pci-quirks.c protects
+ * piix4_port_sel_sb800 and the pair of I/O ports at SB800_PIIX4_SMB_IDX.
  */
-static DEFINE_MUTEX(piix4_mutex_sb800);
+extern struct mutex sb800_mutex;
 static u8 piix4_port_sel_sb800;
 static const char *piix4_main_port_names_sb800[PIIX4_MAX_ADAPTERS] = {
" port 0", " port 2", " port 3", " port 4"
@@ -157,8 +157,6 @@ static const char *piix4_aux_port_name_sb800 = " port 1";
 struct i2c_piix4_adapdata {
unsigned short smba;
 
-   /* SB800 */
-   bool sb800_main;
u8 port;/* Port number, shifted */
 };
 
@@ -286,12 +284,12 @@ static int piix4_setup_sb800(struct pci_dev *PIIX4_dev,
else
smb_en = (aux) ? 0x28 : 0x2c;
 
-   mutex_lock(_mutex_sb800);
+   mutex_lock(_mutex);
outb_p(smb_en, SB800_PIIX4_SMB_IDX);
smba_en_lo = inb_p(SB800_PIIX4_SMB_IDX + 1);
outb_p(smb_en + 1, SB800_PIIX4_SMB_IDX);
smba_en_hi = inb_p(SB800_PIIX4_SMB_IDX + 1);
-   mutex_unlock(_mutex_sb800);
+   mutex_unlock(_mutex);
 
if (!smb_en) {
smb_en_status = smba_en_lo & 0x10;
@@ -349,13 +347,13 @@ static int piix4_setup_sb800(struct pci_dev *PIIX4_dev,
if (PIIX4_dev->vendor == PCI_VENDOR_ID_AMD) {
piix4_port_sel_sb800 = SB800_PIIX4_PORT_IDX_ALT;
} else {
-   mutex_lock(_mutex_sb800);
+   mutex_lock(_mutex);
outb_p(SB800_PIIX4_PORT_IDX_SEL, SB800_PIIX4_SMB_IDX);
port_sel = inb_p(SB800_PIIX4_SMB_IDX + 1);
piix4_port_sel_sb800 = (port_sel & 0x01) ?
   SB800_PIIX4_PORT_IDX_ALT :
   SB800_PIIX4_PORT_IDX;
-   mutex_unlock(_mutex_sb800);
+   mutex_unlock(_mutex);
}
 
dev_info(_dev->dev,
@@ -592,7 +590,7 @@ static s32 piix4_access_sb800(struct i2c_adapter *adap, u16 
addr,
u8 port;
int retval;
 
-   mutex_lock(_mutex_sb800);
+   mutex_lock(_mutex);
 
/* Request the SMBUS semaphore, avoid conflicts with the IMC */
smbslvcnt  = inb_p(SMBSLVCNT);
@@ -608,7 +606,7 @@ static s32 piix4_access_sb800(struct i2c_adapter *adap, u16 
addr,
} while (--retries);
/* SMBus is still owned by the IMC, we give up */
if (!retries) {
-   mutex_unlock(_mutex_sb800);
+   mutex_unlock(_mutex);
return -EBUSY;
}
 
@@ -628,7 +626,7 @@ static s32 piix4_access_sb800(struct i2c_adapter *adap, u16 
addr,
/* Release the semaphore */
outb_p(smbslvcnt | 0x20, SMBSLVCNT);
 
-   mutex_unlock(_mutex_sb800);
+   mutex_unlock(_mutex);
 
return retval;
 }
@@ -705,7 +703,6 @@ static int piix4_add_adapter(struct pci_dev *dev, unsigned 
short smba,
}
 
adapdata->smba = smba;
-   adapdata->sb800_main = sb800_main;
adapdata->port = port << 1;
 
/* set up the sysfs linkage to our parent device */
@@ -771,29 +768,18 @@ static int piix4_probe(struct pci_dev *dev, const struct 
pci_device_id *id)
dev->vendor == PCI_VENDOR_ID_AMD) {
is_sb800 = true;
 
-   if (!request_region(SB800_PIIX4_SMB_IDX, 2, "smba_idx")) {
-   dev_err(>dev,
-   "SMBus base address index region 0x%x already in 
use!\n",
-   SB800_PIIX4_SMB_IDX);
-   return -EBUSY;
-   }
-
/* base address location etc changed in SB800 */
retval = piix4_setup_sb800(dev, id, 0);
-   if (retval < 0) {
-   r

[PATCH 3/3 v2] watchdog: sp5100_tco: Use the common mutex

[Zoltan Boszormenyi]

Use the common mutex from usb/host/pci-quirks.c to synchronize
accesses to the SB800 I/O port pair (0xcd6 / 0xcd7) with the
PCI quirk for isochronous USB transfers and with the i2c-piix4
driver.

At the same time, remove the request_region() call to reserve
these I/O ports, similarly to i2c-piix4 so the code is now uniform
across the three individual drivers.

v2: Explicit extern reference for sb800_mutex

Signed-off-by: Zoltan Boszormenyi <zbos...@pr.hu>
---
 drivers/watchdog/sp5100_tco.c | 31 ++-
 1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/drivers/watchdog/sp5100_tco.c b/drivers/watchdog/sp5100_tco.c
index 028618c..4dca9e89 100644
--- a/drivers/watchdog/sp5100_tco.c
+++ b/drivers/watchdog/sp5100_tco.c
@@ -36,9 +36,16 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "sp5100_tco.h"
 
+/*
+ * sb800_mutex in drivers/usb/host/pci-quirks.c protects
+ * parallel access to the I/O port pair 0xCD6 / 0xCD7.
+ */
+extern struct mutex sb800_mutex;
+
 /* Module and version information */
 #define TCO_VERSION "0.05"
 #define TCO_MODULE_NAME "SP5100 TCO timer"
@@ -48,7 +55,6 @@
 static u32 tcobase_phys;
 static u32 tco_wdt_fired;
 static void __iomem *tcobase;
-static unsigned int pm_iobase;
 static DEFINE_SPINLOCK(tco_lock);  /* Guards the hardware */
 static unsigned long timer_alive;
 static char tco_expect_close;
@@ -138,6 +144,8 @@ static void tco_timer_enable(void)
 
if (!tco_has_sp5100_reg_layout(sp5100_tco_pci)) {
/* For SB800 or later */
+   mutex_lock(_mutex);
+
/* Set the Watchdog timer resolution to 1 sec */
outb(SB800_PM_WATCHDOG_CONFIG, SB800_IO_PM_INDEX_REG);
val = inb(SB800_IO_PM_DATA_REG);
@@ -150,6 +158,8 @@ static void tco_timer_enable(void)
val |= SB800_PCI_WATCHDOG_DECODE_EN;
val &= ~SB800_PM_WATCHDOG_DISABLE;
outb(val, SB800_IO_PM_DATA_REG);
+
+   mutex_unlock(_mutex);
} else {
/* For SP5100 or SB7x0 */
/* Enable watchdog decode bit */
@@ -164,11 +174,13 @@ static void tco_timer_enable(void)
   val);
 
/* Enable Watchdog timer and set the resolution to 1 sec */
+   mutex_lock(_mutex);
outb(SP5100_PM_WATCHDOG_CONTROL, SP5100_IO_PM_INDEX_REG);
val = inb(SP5100_IO_PM_DATA_REG);
val |= SP5100_PM_WATCHDOG_SECOND_RES;
val &= ~SP5100_PM_WATCHDOG_DISABLE;
outb(val, SP5100_IO_PM_DATA_REG);
+   mutex_unlock(_mutex);
}
 }
 
@@ -361,16 +373,10 @@ static unsigned char sp5100_tco_setupdevice(void)
base_addr = SB800_PM_WATCHDOG_BASE;
}
 
-   /* Request the IO ports used by this driver */
-   pm_iobase = SP5100_IO_PM_INDEX_REG;
-   if (!request_region(pm_iobase, SP5100_PM_IOPORTS_SIZE, dev_name)) {
-   pr_err("I/O address 0x%04x already in use\n", pm_iobase);
-   goto exit;
-   }
-
/*
 * First, Find the watchdog timer MMIO address from indirect I/O.
 */
+   mutex_lock(_mutex);
outb(base_addr+3, index_reg);
val = inb(data_reg);
outb(base_addr+2, index_reg);
@@ -380,6 +386,7 @@ static unsigned char sp5100_tco_setupdevice(void)
outb(base_addr+0, index_reg);
/* Low three bits of BASE are reserved */
val = val << 8 | (inb(data_reg) & 0xf8);
+   mutex_unlock(_mutex);
 
pr_debug("Got 0x%04x from indirect I/O\n", val);
 
@@ -400,6 +407,7 @@ static unsigned char sp5100_tco_setupdevice(void)
  SP5100_SB_RESOURCE_MMIO_BASE, );
} else {
/* Read SBResource_MMIO from AcpiMmioEn(PM_Reg: 24h) */
+   mutex_lock(_mutex);
outb(SB800_PM_ACPI_MMIO_EN+3, SB800_IO_PM_INDEX_REG);
val = inb(SB800_IO_PM_DATA_REG);
outb(SB800_PM_ACPI_MMIO_EN+2, SB800_IO_PM_INDEX_REG);
@@ -408,6 +416,7 @@ static unsigned char sp5100_tco_setupdevice(void)
val = val << 8 | inb(SB800_IO_PM_DATA_REG);
outb(SB800_PM_ACPI_MMIO_EN+0, SB800_IO_PM_INDEX_REG);
val = val << 8 | inb(SB800_IO_PM_DATA_REG);
+   mutex_unlock(_mutex);
}
 
/* The SBResource_MMIO is enabled and mapped memory space? */
@@ -429,7 +438,7 @@ static unsigned char sp5100_tco_setupdevice(void)
pr_debug("SBResource_MMIO is disabled(0x%04x)\n", val);
 
pr_notice("failed to find MMIO address, giving up.\n");
-   goto  unreg_region;
+   goto  exit;
 
 setup_wdt:
tcobase_phys = val;
@@ -469,8 +478,6 @@ static unsigned char sp5100_tco_setupdevice(void)
 
 unreg_mem_region:
release_mem_region(tcobase_phys,

[PATCH 1/3 v2] usb: pci-quirks: Add a common mutex for the I/O port pair of SB800

[Zoltan Boszormenyi]

This patch adds a common mutex in the USB PCI quirks code and starts
using it to synchronize access to the I/O port pair 0xcd6 / 0xcd7 on
SB800.

These I/O ports are also used by i2c-piix4 and sp5100_tco, the next
two patches port these drivers to use this common mutex.

v2: No extra header and no wrapper for mutex_lock() / mutex_unlock()

Signed-off-by: Zoltan Boszormenyi <zbos...@pr.hu>
---
 drivers/usb/host/pci-quirks.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index a9a1e4c..1ef0ada 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -279,6 +279,9 @@ bool usb_amd_prefetch_quirk(void)
 }
 EXPORT_SYMBOL_GPL(usb_amd_prefetch_quirk);
 
+DEFINE_MUTEX(sb800_mutex);
+EXPORT_SYMBOL_GPL(sb800_mutex);
+
 /*
  * The hardware normally enables the A-link power management feature, which
  * lets the system lower the power consumption in idle states.
@@ -314,11 +317,13 @@ static void usb_amd_quirk_pll(int disable)
if (amd_chipset.sb_type.gen == AMD_CHIPSET_SB800 ||
amd_chipset.sb_type.gen == AMD_CHIPSET_HUDSON2 ||
amd_chipset.sb_type.gen == AMD_CHIPSET_BOLTON) {
+   mutex_lock(_mutex);
outb_p(AB_REG_BAR_LOW, 0xcd6);
addr_low = inb_p(0xcd7);
outb_p(AB_REG_BAR_HIGH, 0xcd6);
addr_high = inb_p(0xcd7);
addr = addr_high << 8 | addr_low;
+   mutex_unlock(_mutex);
 
outl_p(0x30, AB_INDX(addr));
outl_p(0x40, AB_DATA(addr));
-- 
2.9.3

[PATCH 3/3 v2] watchdog: sp5100_tco: Use the common mutex

[Zoltan Boszormenyi]

Use the common mutex from usb/host/pci-quirks.c to synchronize
accesses to the SB800 I/O port pair (0xcd6 / 0xcd7) with the
PCI quirk for isochronous USB transfers and with the i2c-piix4
driver.

At the same time, remove the request_region() call to reserve
these I/O ports, similarly to i2c-piix4 so the code is now uniform
across the three individual drivers.

v2: Explicit extern reference for sb800_mutex

Signed-off-by: Zoltan Boszormenyi 
---
 drivers/watchdog/sp5100_tco.c | 31 ++-
 1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/drivers/watchdog/sp5100_tco.c b/drivers/watchdog/sp5100_tco.c
index 028618c..4dca9e89 100644
--- a/drivers/watchdog/sp5100_tco.c
+++ b/drivers/watchdog/sp5100_tco.c
@@ -36,9 +36,16 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "sp5100_tco.h"
 
+/*
+ * sb800_mutex in drivers/usb/host/pci-quirks.c protects
+ * parallel access to the I/O port pair 0xCD6 / 0xCD7.
+ */
+extern struct mutex sb800_mutex;
+
 /* Module and version information */
 #define TCO_VERSION "0.05"
 #define TCO_MODULE_NAME "SP5100 TCO timer"
@@ -48,7 +55,6 @@
 static u32 tcobase_phys;
 static u32 tco_wdt_fired;
 static void __iomem *tcobase;
-static unsigned int pm_iobase;
 static DEFINE_SPINLOCK(tco_lock);  /* Guards the hardware */
 static unsigned long timer_alive;
 static char tco_expect_close;
@@ -138,6 +144,8 @@ static void tco_timer_enable(void)
 
if (!tco_has_sp5100_reg_layout(sp5100_tco_pci)) {
/* For SB800 or later */
+   mutex_lock(_mutex);
+
/* Set the Watchdog timer resolution to 1 sec */
outb(SB800_PM_WATCHDOG_CONFIG, SB800_IO_PM_INDEX_REG);
val = inb(SB800_IO_PM_DATA_REG);
@@ -150,6 +158,8 @@ static void tco_timer_enable(void)
val |= SB800_PCI_WATCHDOG_DECODE_EN;
val &= ~SB800_PM_WATCHDOG_DISABLE;
outb(val, SB800_IO_PM_DATA_REG);
+
+   mutex_unlock(_mutex);
} else {
/* For SP5100 or SB7x0 */
/* Enable watchdog decode bit */
@@ -164,11 +174,13 @@ static void tco_timer_enable(void)
   val);
 
/* Enable Watchdog timer and set the resolution to 1 sec */
+   mutex_lock(_mutex);
outb(SP5100_PM_WATCHDOG_CONTROL, SP5100_IO_PM_INDEX_REG);
val = inb(SP5100_IO_PM_DATA_REG);
val |= SP5100_PM_WATCHDOG_SECOND_RES;
val &= ~SP5100_PM_WATCHDOG_DISABLE;
outb(val, SP5100_IO_PM_DATA_REG);
+   mutex_unlock(_mutex);
}
 }
 
@@ -361,16 +373,10 @@ static unsigned char sp5100_tco_setupdevice(void)
base_addr = SB800_PM_WATCHDOG_BASE;
}
 
-   /* Request the IO ports used by this driver */
-   pm_iobase = SP5100_IO_PM_INDEX_REG;
-   if (!request_region(pm_iobase, SP5100_PM_IOPORTS_SIZE, dev_name)) {
-   pr_err("I/O address 0x%04x already in use\n", pm_iobase);
-   goto exit;
-   }
-
/*
 * First, Find the watchdog timer MMIO address from indirect I/O.
 */
+   mutex_lock(_mutex);
outb(base_addr+3, index_reg);
val = inb(data_reg);
outb(base_addr+2, index_reg);
@@ -380,6 +386,7 @@ static unsigned char sp5100_tco_setupdevice(void)
outb(base_addr+0, index_reg);
/* Low three bits of BASE are reserved */
val = val << 8 | (inb(data_reg) & 0xf8);
+   mutex_unlock(_mutex);
 
pr_debug("Got 0x%04x from indirect I/O\n", val);
 
@@ -400,6 +407,7 @@ static unsigned char sp5100_tco_setupdevice(void)
  SP5100_SB_RESOURCE_MMIO_BASE, );
} else {
/* Read SBResource_MMIO from AcpiMmioEn(PM_Reg: 24h) */
+   mutex_lock(_mutex);
outb(SB800_PM_ACPI_MMIO_EN+3, SB800_IO_PM_INDEX_REG);
val = inb(SB800_IO_PM_DATA_REG);
outb(SB800_PM_ACPI_MMIO_EN+2, SB800_IO_PM_INDEX_REG);
@@ -408,6 +416,7 @@ static unsigned char sp5100_tco_setupdevice(void)
val = val << 8 | inb(SB800_IO_PM_DATA_REG);
outb(SB800_PM_ACPI_MMIO_EN+0, SB800_IO_PM_INDEX_REG);
val = val << 8 | inb(SB800_IO_PM_DATA_REG);
+   mutex_unlock(_mutex);
}
 
/* The SBResource_MMIO is enabled and mapped memory space? */
@@ -429,7 +438,7 @@ static unsigned char sp5100_tco_setupdevice(void)
pr_debug("SBResource_MMIO is disabled(0x%04x)\n", val);
 
pr_notice("failed to find MMIO address, giving up.\n");
-   goto  unreg_region;
+   goto  exit;
 
 setup_wdt:
tcobase_phys = val;
@@ -469,8 +478,6 @@ static unsigned char sp5100_tco_setupdevice(void)
 
 unreg_mem_region:
release_mem_region(tcobase_phys, SP5100_WDT_MEM_MAP_SIZE

[PATCH 1/3 v2] usb: pci-quirks: Add a common mutex for the I/O port pair of SB800

[Zoltan Boszormenyi]

This patch adds a common mutex in the USB PCI quirks code and starts
using it to synchronize access to the I/O port pair 0xcd6 / 0xcd7 on
SB800.

These I/O ports are also used by i2c-piix4 and sp5100_tco, the next
two patches port these drivers to use this common mutex.

v2: No extra header and no wrapper for mutex_lock() / mutex_unlock()

Signed-off-by: Zoltan Boszormenyi 
---
 drivers/usb/host/pci-quirks.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index a9a1e4c..1ef0ada 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -279,6 +279,9 @@ bool usb_amd_prefetch_quirk(void)
 }
 EXPORT_SYMBOL_GPL(usb_amd_prefetch_quirk);
 
+DEFINE_MUTEX(sb800_mutex);
+EXPORT_SYMBOL_GPL(sb800_mutex);
+
 /*
  * The hardware normally enables the A-link power management feature, which
  * lets the system lower the power consumption in idle states.
@@ -314,11 +317,13 @@ static void usb_amd_quirk_pll(int disable)
if (amd_chipset.sb_type.gen == AMD_CHIPSET_SB800 ||
amd_chipset.sb_type.gen == AMD_CHIPSET_HUDSON2 ||
amd_chipset.sb_type.gen == AMD_CHIPSET_BOLTON) {
+   mutex_lock(_mutex);
outb_p(AB_REG_BAR_LOW, 0xcd6);
addr_low = inb_p(0xcd7);
outb_p(AB_REG_BAR_HIGH, 0xcd6);
addr_high = inb_p(0xcd7);
addr = addr_high << 8 | addr_low;
+   mutex_unlock(_mutex);
 
outl_p(0x30, AB_INDX(addr));
outl_p(0x40, AB_DATA(addr));
-- 
2.9.3

[PATCH 0/3 v2] Fix regression in the sp5100_tco driver

[Zoltan Boszormenyi]

Three drivers are accessing the same I/O ports (0xcd6 / 0xcd7) on
AMD SB800 based machines without synchronization or with excluding
each other out:
* the USB quirk for isochronous transfers on SB800 (no locking)
* sp5100_tco (request_region)
* i2c-piix4 (request_region)

Historically, the sp5100_tco watchdog driver used request_region()
for these I/O ports but an i2c-piix4 improvement for SB800 in
Linux 4.4-rc4 also added a request_region() call. Because of this
and the load order, this cause a regression and the watchdog function
became non-functional. The commit that caused the regression is:

commit 2fee61d22e606fc99ade9079fda15fdee83ec33e
Author: Christian Fetzer <fetzer...@gmail.com>
Date:   Thu Nov 19 20:13:48 2015 +0100

i2c: piix4: Add support for multiplexed main adapter in SB800

I was informed by Guenter Roeck <li...@roeck-us.net> that the
alternative, i.e. using request_muxed_region() can fail, either
because of a resource allocation failure, which is quite possible
with long uptimes, or because there are no guarantees that an as yet
unknown driver would also use request_muxed_region() consistently.

Because of this, a solution using a common mutex was chosen to
synchronize I/O port accesses and request_region() calls are removed
from both i2c-piix4 and sp5100_tco to make the code uniform.

This patch series implements this and restores the watchdog function.

v2: Don't introduce a new header, reference sb800_mutex explicitly

Signed-off-by: Zoltan Boszormenyi <zbos...@pr.hu>

 drivers/i2c/busses/i2c-piix4.c | 43 +--
 drivers/usb/host/pci-quirks.c  |  5 +
 drivers/watchdog/sp5100_tco.c  | 31 ++-
 3 files changed, 36 insertions(+), 43 deletions(-)

[PATCH 0/3 v2] Fix regression in the sp5100_tco driver

[Zoltan Boszormenyi]

Three drivers are accessing the same I/O ports (0xcd6 / 0xcd7) on
AMD SB800 based machines without synchronization or with excluding
each other out:
* the USB quirk for isochronous transfers on SB800 (no locking)
* sp5100_tco (request_region)
* i2c-piix4 (request_region)

Historically, the sp5100_tco watchdog driver used request_region()
for these I/O ports but an i2c-piix4 improvement for SB800 in
Linux 4.4-rc4 also added a request_region() call. Because of this
and the load order, this cause a regression and the watchdog function
became non-functional. The commit that caused the regression is:

commit 2fee61d22e606fc99ade9079fda15fdee83ec33e
Author: Christian Fetzer 
Date:   Thu Nov 19 20:13:48 2015 +0100

i2c: piix4: Add support for multiplexed main adapter in SB800

I was informed by Guenter Roeck  that the
alternative, i.e. using request_muxed_region() can fail, either
because of a resource allocation failure, which is quite possible
with long uptimes, or because there are no guarantees that an as yet
unknown driver would also use request_muxed_region() consistently.

Because of this, a solution using a common mutex was chosen to
synchronize I/O port accesses and request_region() calls are removed
from both i2c-piix4 and sp5100_tco to make the code uniform.

This patch series implements this and restores the watchdog function.

v2: Don't introduce a new header, reference sb800_mutex explicitly

Signed-off-by: Zoltan Boszormenyi 

 drivers/i2c/busses/i2c-piix4.c | 43 +--
 drivers/usb/host/pci-quirks.c  |  5 +
 drivers/watchdog/sp5100_tco.c  | 31 ++-
 3 files changed, 36 insertions(+), 43 deletions(-)

[PATCH 2/3] i2c: i2c-piix4: Synchronize I/O port accesses with the SB800 USB quirk

[Zoltan Boszormenyi]

Use the new header and the common mutex in the i2c-piix4 driver.

At the same time, remove the request_region() call to reserve
these I/O ports, so the sp5100_tco watchdog driver is fixed.
The mutex is enough to protect the I/O port accesses. This is
an old regression in Linux 4.4-rc4, caused by:

commit 2fee61d22e606fc99ade9079fda15fdee83ec33e
Author: Christian Fetzer <fetzer...@gmail.com>
Date:   Thu Nov 19 20:13:48 2015 +0100

i2c: piix4: Add support for multiplexed main adapter in SB800

Signed-off-by: Zoltan Boszormenyi <zbos...@pr.hu>
---
 drivers/i2c/busses/i2c-piix4.c | 59 ++
 1 file changed, 19 insertions(+), 40 deletions(-)

diff --git a/drivers/i2c/busses/i2c-piix4.c b/drivers/i2c/busses/i2c-piix4.c
index c21ca7b..a4549e5 100644
--- a/drivers/i2c/busses/i2c-piix4.c
+++ b/drivers/i2c/busses/i2c-piix4.c
@@ -40,7 +40,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 
 /* PIIX4 SMBus address offsets */
@@ -82,9 +82,6 @@
 /* Multi-port constants */
 #define PIIX4_MAX_ADAPTERS 4
 
-/* SB800 constants */
-#define SB800_PIIX4_SMB_IDX0xcd6
-
 /*
  * SB800 port is selected by bits 2:1 of the smb_en register (0x2c)
  * or the smb_sel register (0x2e), depending on bit 0 of register 0x2f.
@@ -144,10 +141,9 @@ static const struct dmi_system_id piix4_dmi_ibm[] = {
 
 /*
  * SB800 globals
- * piix4_mutex_sb800 protects piix4_port_sel_sb800 and the pair
- * of I/O ports at SB800_PIIX4_SMB_IDX.
+ * sb800_mutex in drivers/usb/host/pci-quirks.c protects
+ * piix4_port_sel_sb800 and the pair of I/O ports at SB800_PIIX4_SMB_IDX.
  */
-static DEFINE_MUTEX(piix4_mutex_sb800);
 static u8 piix4_port_sel_sb800;
 static const char *piix4_main_port_names_sb800[PIIX4_MAX_ADAPTERS] = {
" port 0", " port 2", " port 3", " port 4"
@@ -157,8 +153,6 @@ static const char *piix4_aux_port_name_sb800 = " port 1";
 struct i2c_piix4_adapdata {
unsigned short smba;
 
-   /* SB800 */
-   bool sb800_main;
u8 port;/* Port number, shifted */
 };
 
@@ -286,12 +280,12 @@ static int piix4_setup_sb800(struct pci_dev *PIIX4_dev,
else
smb_en = (aux) ? 0x28 : 0x2c;
 
-   mutex_lock(_mutex_sb800);
+   enter_sb800();
outb_p(smb_en, SB800_PIIX4_SMB_IDX);
-   smba_en_lo = inb_p(SB800_PIIX4_SMB_IDX + 1);
+   smba_en_lo = inb_p(SB800_PIIX4_SMB_DATA);
outb_p(smb_en + 1, SB800_PIIX4_SMB_IDX);
-   smba_en_hi = inb_p(SB800_PIIX4_SMB_IDX + 1);
-   mutex_unlock(_mutex_sb800);
+   smba_en_hi = inb_p(SB800_PIIX4_SMB_DATA);
+   leave_sb800();
 
if (!smb_en) {
smb_en_status = smba_en_lo & 0x10;
@@ -349,13 +343,13 @@ static int piix4_setup_sb800(struct pci_dev *PIIX4_dev,
if (PIIX4_dev->vendor == PCI_VENDOR_ID_AMD) {
piix4_port_sel_sb800 = SB800_PIIX4_PORT_IDX_ALT;
} else {
-   mutex_lock(_mutex_sb800);
+   enter_sb800();
outb_p(SB800_PIIX4_PORT_IDX_SEL, SB800_PIIX4_SMB_IDX);
-   port_sel = inb_p(SB800_PIIX4_SMB_IDX + 1);
+   port_sel = inb_p(SB800_PIIX4_SMB_DATA);
piix4_port_sel_sb800 = (port_sel & 0x01) ?
   SB800_PIIX4_PORT_IDX_ALT :
   SB800_PIIX4_PORT_IDX;
-   mutex_unlock(_mutex_sb800);
+   leave_sb800();
}
 
dev_info(_dev->dev,
@@ -592,7 +586,7 @@ static s32 piix4_access_sb800(struct i2c_adapter *adap, u16 
addr,
u8 port;
int retval;
 
-   mutex_lock(_mutex_sb800);
+   enter_sb800();
 
/* Request the SMBUS semaphore, avoid conflicts with the IMC */
smbslvcnt  = inb_p(SMBSLVCNT);
@@ -608,27 +602,27 @@ static s32 piix4_access_sb800(struct i2c_adapter *adap, 
u16 addr,
} while (--retries);
/* SMBus is still owned by the IMC, we give up */
if (!retries) {
-   mutex_unlock(_mutex_sb800);
+   leave_sb800();
return -EBUSY;
}
 
outb_p(piix4_port_sel_sb800, SB800_PIIX4_SMB_IDX);
-   smba_en_lo = inb_p(SB800_PIIX4_SMB_IDX + 1);
+   smba_en_lo = inb_p(SB800_PIIX4_SMB_DATA);
 
port = adapdata->port;
if ((smba_en_lo & SB800_PIIX4_PORT_IDX_MASK) != port)
outb_p((smba_en_lo & ~SB800_PIIX4_PORT_IDX_MASK) | port,
-  SB800_PIIX4_SMB_IDX + 1);
+  SB800_PIIX4_SMB_DATA);
 
retval = piix4_access(adap, addr, flags, read_write,
  command, size, data);
 
-   outb_p(smba_en_lo, SB800_PIIX4_SMB_IDX + 1);
+   outb_p(smba_en_lo, SB800_PIIX4_SMB_DATA);
 
/* Release the semaphore */
outb_p(smbslvcnt | 0x20, SMBSLVCNT);
 
-   mutex_unlock(_mutex_sb800);
+   leave_sb800();
 
return retval;
 }
@@ 

[PATCH 2/3] i2c: i2c-piix4: Synchronize I/O port accesses with the SB800 USB quirk

[Zoltan Boszormenyi]

Use the new header and the common mutex in the i2c-piix4 driver.

At the same time, remove the request_region() call to reserve
these I/O ports, so the sp5100_tco watchdog driver is fixed.
The mutex is enough to protect the I/O port accesses. This is
an old regression in Linux 4.4-rc4, caused by:

commit 2fee61d22e606fc99ade9079fda15fdee83ec33e
Author: Christian Fetzer 
Date:   Thu Nov 19 20:13:48 2015 +0100

i2c: piix4: Add support for multiplexed main adapter in SB800

Signed-off-by: Zoltan Boszormenyi 
---
 drivers/i2c/busses/i2c-piix4.c | 59 ++
 1 file changed, 19 insertions(+), 40 deletions(-)

diff --git a/drivers/i2c/busses/i2c-piix4.c b/drivers/i2c/busses/i2c-piix4.c
index c21ca7b..a4549e5 100644
--- a/drivers/i2c/busses/i2c-piix4.c
+++ b/drivers/i2c/busses/i2c-piix4.c
@@ -40,7 +40,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 
 /* PIIX4 SMBus address offsets */
@@ -82,9 +82,6 @@
 /* Multi-port constants */
 #define PIIX4_MAX_ADAPTERS 4
 
-/* SB800 constants */
-#define SB800_PIIX4_SMB_IDX0xcd6
-
 /*
  * SB800 port is selected by bits 2:1 of the smb_en register (0x2c)
  * or the smb_sel register (0x2e), depending on bit 0 of register 0x2f.
@@ -144,10 +141,9 @@ static const struct dmi_system_id piix4_dmi_ibm[] = {
 
 /*
  * SB800 globals
- * piix4_mutex_sb800 protects piix4_port_sel_sb800 and the pair
- * of I/O ports at SB800_PIIX4_SMB_IDX.
+ * sb800_mutex in drivers/usb/host/pci-quirks.c protects
+ * piix4_port_sel_sb800 and the pair of I/O ports at SB800_PIIX4_SMB_IDX.
  */
-static DEFINE_MUTEX(piix4_mutex_sb800);
 static u8 piix4_port_sel_sb800;
 static const char *piix4_main_port_names_sb800[PIIX4_MAX_ADAPTERS] = {
" port 0", " port 2", " port 3", " port 4"
@@ -157,8 +153,6 @@ static const char *piix4_aux_port_name_sb800 = " port 1";
 struct i2c_piix4_adapdata {
unsigned short smba;
 
-   /* SB800 */
-   bool sb800_main;
u8 port;/* Port number, shifted */
 };
 
@@ -286,12 +280,12 @@ static int piix4_setup_sb800(struct pci_dev *PIIX4_dev,
else
smb_en = (aux) ? 0x28 : 0x2c;
 
-   mutex_lock(_mutex_sb800);
+   enter_sb800();
outb_p(smb_en, SB800_PIIX4_SMB_IDX);
-   smba_en_lo = inb_p(SB800_PIIX4_SMB_IDX + 1);
+   smba_en_lo = inb_p(SB800_PIIX4_SMB_DATA);
outb_p(smb_en + 1, SB800_PIIX4_SMB_IDX);
-   smba_en_hi = inb_p(SB800_PIIX4_SMB_IDX + 1);
-   mutex_unlock(_mutex_sb800);
+   smba_en_hi = inb_p(SB800_PIIX4_SMB_DATA);
+   leave_sb800();
 
if (!smb_en) {
smb_en_status = smba_en_lo & 0x10;
@@ -349,13 +343,13 @@ static int piix4_setup_sb800(struct pci_dev *PIIX4_dev,
if (PIIX4_dev->vendor == PCI_VENDOR_ID_AMD) {
piix4_port_sel_sb800 = SB800_PIIX4_PORT_IDX_ALT;
} else {
-   mutex_lock(_mutex_sb800);
+   enter_sb800();
outb_p(SB800_PIIX4_PORT_IDX_SEL, SB800_PIIX4_SMB_IDX);
-   port_sel = inb_p(SB800_PIIX4_SMB_IDX + 1);
+   port_sel = inb_p(SB800_PIIX4_SMB_DATA);
piix4_port_sel_sb800 = (port_sel & 0x01) ?
   SB800_PIIX4_PORT_IDX_ALT :
   SB800_PIIX4_PORT_IDX;
-   mutex_unlock(_mutex_sb800);
+   leave_sb800();
}
 
dev_info(_dev->dev,
@@ -592,7 +586,7 @@ static s32 piix4_access_sb800(struct i2c_adapter *adap, u16 
addr,
u8 port;
int retval;
 
-   mutex_lock(_mutex_sb800);
+   enter_sb800();
 
/* Request the SMBUS semaphore, avoid conflicts with the IMC */
smbslvcnt  = inb_p(SMBSLVCNT);
@@ -608,27 +602,27 @@ static s32 piix4_access_sb800(struct i2c_adapter *adap, 
u16 addr,
} while (--retries);
/* SMBus is still owned by the IMC, we give up */
if (!retries) {
-   mutex_unlock(_mutex_sb800);
+   leave_sb800();
return -EBUSY;
}
 
outb_p(piix4_port_sel_sb800, SB800_PIIX4_SMB_IDX);
-   smba_en_lo = inb_p(SB800_PIIX4_SMB_IDX + 1);
+   smba_en_lo = inb_p(SB800_PIIX4_SMB_DATA);
 
port = adapdata->port;
if ((smba_en_lo & SB800_PIIX4_PORT_IDX_MASK) != port)
outb_p((smba_en_lo & ~SB800_PIIX4_PORT_IDX_MASK) | port,
-  SB800_PIIX4_SMB_IDX + 1);
+  SB800_PIIX4_SMB_DATA);
 
retval = piix4_access(adap, addr, flags, read_write,
  command, size, data);
 
-   outb_p(smba_en_lo, SB800_PIIX4_SMB_IDX + 1);
+   outb_p(smba_en_lo, SB800_PIIX4_SMB_DATA);
 
/* Release the semaphore */
outb_p(smbslvcnt | 0x20, SMBSLVCNT);
 
-   mutex_unlock(_mutex_sb800);
+   leave_sb800();
 
return retval;
 }
@@ -705,7 +699,6 @@ static int piix4_add_adapter(struct pc

[PATCH 3/3] watchdog: sp5100_tco: Synchronize I/O port accesses

[Zoltan Boszormenyi]

From: Böszörményi Zoltán <zbos...@pr.hu>

Use the new header and the mutex from usb/host/pci-quirks.c

This change will allow accesses to the SB800 I/O port pair
synchronized with the PCI quirk when isochronous USB transfers
are performed and with i2c-piix4.

At the same time, remove the request_region() call to reserve
these I/O ports, similarly to i2c-piix4 so the code is now uniform
across the three individual drivers.

Signed-off-by: Zoltan Boszormenyi <zbos...@pr.hu>
---
 drivers/watchdog/sp5100_tco.c | 24 +++-
 drivers/watchdog/sp5100_tco.h | 10 ++
 2 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/watchdog/sp5100_tco.c b/drivers/watchdog/sp5100_tco.c
index 028618c..dc125df 100644
--- a/drivers/watchdog/sp5100_tco.c
+++ b/drivers/watchdog/sp5100_tco.c
@@ -48,7 +48,6 @@
 static u32 tcobase_phys;
 static u32 tco_wdt_fired;
 static void __iomem *tcobase;
-static unsigned int pm_iobase;
 static DEFINE_SPINLOCK(tco_lock);  /* Guards the hardware */
 static unsigned long timer_alive;
 static char tco_expect_close;
@@ -138,6 +137,8 @@ static void tco_timer_enable(void)
 
if (!tco_has_sp5100_reg_layout(sp5100_tco_pci)) {
/* For SB800 or later */
+   enter_sb800();
+
/* Set the Watchdog timer resolution to 1 sec */
outb(SB800_PM_WATCHDOG_CONFIG, SB800_IO_PM_INDEX_REG);
val = inb(SB800_IO_PM_DATA_REG);
@@ -150,6 +151,8 @@ static void tco_timer_enable(void)
val |= SB800_PCI_WATCHDOG_DECODE_EN;
val &= ~SB800_PM_WATCHDOG_DISABLE;
outb(val, SB800_IO_PM_DATA_REG);
+
+   leave_sb800();
} else {
/* For SP5100 or SB7x0 */
/* Enable watchdog decode bit */
@@ -164,11 +167,13 @@ static void tco_timer_enable(void)
   val);
 
/* Enable Watchdog timer and set the resolution to 1 sec */
+   enter_sb800();
outb(SP5100_PM_WATCHDOG_CONTROL, SP5100_IO_PM_INDEX_REG);
val = inb(SP5100_IO_PM_DATA_REG);
val |= SP5100_PM_WATCHDOG_SECOND_RES;
val &= ~SP5100_PM_WATCHDOG_DISABLE;
outb(val, SP5100_IO_PM_DATA_REG);
+   leave_sb800();
}
 }
 
@@ -361,16 +366,10 @@ static unsigned char sp5100_tco_setupdevice(void)
base_addr = SB800_PM_WATCHDOG_BASE;
}
 
-   /* Request the IO ports used by this driver */
-   pm_iobase = SP5100_IO_PM_INDEX_REG;
-   if (!request_region(pm_iobase, SP5100_PM_IOPORTS_SIZE, dev_name)) {
-   pr_err("I/O address 0x%04x already in use\n", pm_iobase);
-   goto exit;
-   }
-
/*
 * First, Find the watchdog timer MMIO address from indirect I/O.
 */
+   enter_sb800();
outb(base_addr+3, index_reg);
val = inb(data_reg);
outb(base_addr+2, index_reg);
@@ -380,6 +379,7 @@ static unsigned char sp5100_tco_setupdevice(void)
outb(base_addr+0, index_reg);
/* Low three bits of BASE are reserved */
val = val << 8 | (inb(data_reg) & 0xf8);
+   leave_sb800();
 
pr_debug("Got 0x%04x from indirect I/O\n", val);
 
@@ -400,6 +400,7 @@ static unsigned char sp5100_tco_setupdevice(void)
  SP5100_SB_RESOURCE_MMIO_BASE, );
} else {
/* Read SBResource_MMIO from AcpiMmioEn(PM_Reg: 24h) */
+   enter_sb800();
outb(SB800_PM_ACPI_MMIO_EN+3, SB800_IO_PM_INDEX_REG);
val = inb(SB800_IO_PM_DATA_REG);
outb(SB800_PM_ACPI_MMIO_EN+2, SB800_IO_PM_INDEX_REG);
@@ -408,6 +409,7 @@ static unsigned char sp5100_tco_setupdevice(void)
val = val << 8 | inb(SB800_IO_PM_DATA_REG);
outb(SB800_PM_ACPI_MMIO_EN+0, SB800_IO_PM_INDEX_REG);
val = val << 8 | inb(SB800_IO_PM_DATA_REG);
+   leave_sb800();
}
 
/* The SBResource_MMIO is enabled and mapped memory space? */
@@ -429,7 +431,7 @@ static unsigned char sp5100_tco_setupdevice(void)
pr_debug("SBResource_MMIO is disabled(0x%04x)\n", val);
 
pr_notice("failed to find MMIO address, giving up.\n");
-   goto  unreg_region;
+   goto  exit;
 
 setup_wdt:
tcobase_phys = val;
@@ -469,8 +471,6 @@ static unsigned char sp5100_tco_setupdevice(void)
 
 unreg_mem_region:
release_mem_region(tcobase_phys, SP5100_WDT_MEM_MAP_SIZE);
-unreg_region:
-   release_region(pm_iobase, SP5100_PM_IOPORTS_SIZE);
 exit:
return 0;
 }
@@ -517,7 +517,6 @@ static int sp5100_tco_init(struct platform_device *dev)
 exit:
iounmap(tcobase);
release_mem_region(tcobase_phys, SP5100_WDT_MEM_MAP_SIZE);
-   release_region(pm_iobase, SP5100_PM_IOPORTS_SIZE)

[PATCH 1/3] usb: pci-quirks: Add a header for SB800 I/O ports and mutex for locking

[Zoltan Boszormenyi]

From: Böszörményi Zoltán <zbos...@pr.hu>

This patch adds:
* a mutex in the USB PCI quirks code for synchronizing access to
  the I/O ports on SB800
* a new header that contains symbols for the index and data I/O ports
  and wrappers for locking and unlocking the mutex.
* locking around the I/O port access for SB800

Signed-off-by: Zoltan Boszormenyi <zbos...@pr.hu>
---
 drivers/usb/host/pci-quirks.c | 14 ++
 include/linux/sb800.h | 15 +++
 2 files changed, 25 insertions(+), 4 deletions(-)
 create mode 100644 include/linux/sb800.h

diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index a9a1e4c..9b0445c 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "pci-quirks.h"
 #include "xhci-ext-caps.h"
 
@@ -279,6 +280,9 @@ bool usb_amd_prefetch_quirk(void)
 }
 EXPORT_SYMBOL_GPL(usb_amd_prefetch_quirk);
 
+DEFINE_MUTEX(sb800_mutex);
+EXPORT_SYMBOL_GPL(sb800_mutex);
+
 /*
  * The hardware normally enables the A-link power management feature, which
  * lets the system lower the power consumption in idle states.
@@ -314,11 +318,13 @@ static void usb_amd_quirk_pll(int disable)
if (amd_chipset.sb_type.gen == AMD_CHIPSET_SB800 ||
amd_chipset.sb_type.gen == AMD_CHIPSET_HUDSON2 ||
amd_chipset.sb_type.gen == AMD_CHIPSET_BOLTON) {
-   outb_p(AB_REG_BAR_LOW, 0xcd6);
-   addr_low = inb_p(0xcd7);
-   outb_p(AB_REG_BAR_HIGH, 0xcd6);
-   addr_high = inb_p(0xcd7);
+   enter_sb800();
+   outb_p(AB_REG_BAR_LOW, SB800_PIIX4_SMB_IDX);
+   addr_low = inb_p(SB800_PIIX4_SMB_DATA);
+   outb_p(AB_REG_BAR_HIGH, SB800_PIIX4_SMB_IDX);
+   addr_high = inb_p(SB800_PIIX4_SMB_DATA);
addr = addr_high << 8 | addr_low;
+   leave_sb800();
 
outl_p(0x30, AB_INDX(addr));
outl_p(0x40, AB_DATA(addr));
diff --git a/include/linux/sb800.h b/include/linux/sb800.h
new file mode 100644
index 000..5650b7d
--- /dev/null
+++ b/include/linux/sb800.h
@@ -0,0 +1,15 @@
+
+#ifndef SB800_H
+#define SB800_H
+
+#include 
+
+#define SB800_PIIX4_SMB_IDX0xcd6
+#define SB800_PIIX4_SMB_DATA   0xcd7
+
+extern struct mutex sb800_mutex;
+
+#define enter_sb800()  mutex_lock(_mutex)
+#define leave_sb800()  mutex_unlock(_mutex)
+
+#endif
-- 
2.9.3

[PATCH 3/3] watchdog: sp5100_tco: Synchronize I/O port accesses

[Zoltan Boszormenyi]

From: Böszörményi Zoltán 

Use the new header and the mutex from usb/host/pci-quirks.c

This change will allow accesses to the SB800 I/O port pair
synchronized with the PCI quirk when isochronous USB transfers
are performed and with i2c-piix4.

At the same time, remove the request_region() call to reserve
these I/O ports, similarly to i2c-piix4 so the code is now uniform
across the three individual drivers.

Signed-off-by: Zoltan Boszormenyi 
---
 drivers/watchdog/sp5100_tco.c | 24 +++-
 drivers/watchdog/sp5100_tco.h | 10 ++
 2 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/watchdog/sp5100_tco.c b/drivers/watchdog/sp5100_tco.c
index 028618c..dc125df 100644
--- a/drivers/watchdog/sp5100_tco.c
+++ b/drivers/watchdog/sp5100_tco.c
@@ -48,7 +48,6 @@
 static u32 tcobase_phys;
 static u32 tco_wdt_fired;
 static void __iomem *tcobase;
-static unsigned int pm_iobase;
 static DEFINE_SPINLOCK(tco_lock);  /* Guards the hardware */
 static unsigned long timer_alive;
 static char tco_expect_close;
@@ -138,6 +137,8 @@ static void tco_timer_enable(void)
 
if (!tco_has_sp5100_reg_layout(sp5100_tco_pci)) {
/* For SB800 or later */
+   enter_sb800();
+
/* Set the Watchdog timer resolution to 1 sec */
outb(SB800_PM_WATCHDOG_CONFIG, SB800_IO_PM_INDEX_REG);
val = inb(SB800_IO_PM_DATA_REG);
@@ -150,6 +151,8 @@ static void tco_timer_enable(void)
val |= SB800_PCI_WATCHDOG_DECODE_EN;
val &= ~SB800_PM_WATCHDOG_DISABLE;
outb(val, SB800_IO_PM_DATA_REG);
+
+   leave_sb800();
} else {
/* For SP5100 or SB7x0 */
/* Enable watchdog decode bit */
@@ -164,11 +167,13 @@ static void tco_timer_enable(void)
   val);
 
/* Enable Watchdog timer and set the resolution to 1 sec */
+   enter_sb800();
outb(SP5100_PM_WATCHDOG_CONTROL, SP5100_IO_PM_INDEX_REG);
val = inb(SP5100_IO_PM_DATA_REG);
val |= SP5100_PM_WATCHDOG_SECOND_RES;
val &= ~SP5100_PM_WATCHDOG_DISABLE;
outb(val, SP5100_IO_PM_DATA_REG);
+   leave_sb800();
}
 }
 
@@ -361,16 +366,10 @@ static unsigned char sp5100_tco_setupdevice(void)
base_addr = SB800_PM_WATCHDOG_BASE;
}
 
-   /* Request the IO ports used by this driver */
-   pm_iobase = SP5100_IO_PM_INDEX_REG;
-   if (!request_region(pm_iobase, SP5100_PM_IOPORTS_SIZE, dev_name)) {
-   pr_err("I/O address 0x%04x already in use\n", pm_iobase);
-   goto exit;
-   }
-
/*
 * First, Find the watchdog timer MMIO address from indirect I/O.
 */
+   enter_sb800();
outb(base_addr+3, index_reg);
val = inb(data_reg);
outb(base_addr+2, index_reg);
@@ -380,6 +379,7 @@ static unsigned char sp5100_tco_setupdevice(void)
outb(base_addr+0, index_reg);
/* Low three bits of BASE are reserved */
val = val << 8 | (inb(data_reg) & 0xf8);
+   leave_sb800();
 
pr_debug("Got 0x%04x from indirect I/O\n", val);
 
@@ -400,6 +400,7 @@ static unsigned char sp5100_tco_setupdevice(void)
  SP5100_SB_RESOURCE_MMIO_BASE, );
} else {
/* Read SBResource_MMIO from AcpiMmioEn(PM_Reg: 24h) */
+   enter_sb800();
outb(SB800_PM_ACPI_MMIO_EN+3, SB800_IO_PM_INDEX_REG);
val = inb(SB800_IO_PM_DATA_REG);
outb(SB800_PM_ACPI_MMIO_EN+2, SB800_IO_PM_INDEX_REG);
@@ -408,6 +409,7 @@ static unsigned char sp5100_tco_setupdevice(void)
val = val << 8 | inb(SB800_IO_PM_DATA_REG);
outb(SB800_PM_ACPI_MMIO_EN+0, SB800_IO_PM_INDEX_REG);
val = val << 8 | inb(SB800_IO_PM_DATA_REG);
+   leave_sb800();
}
 
/* The SBResource_MMIO is enabled and mapped memory space? */
@@ -429,7 +431,7 @@ static unsigned char sp5100_tco_setupdevice(void)
pr_debug("SBResource_MMIO is disabled(0x%04x)\n", val);
 
pr_notice("failed to find MMIO address, giving up.\n");
-   goto  unreg_region;
+   goto  exit;
 
 setup_wdt:
tcobase_phys = val;
@@ -469,8 +471,6 @@ static unsigned char sp5100_tco_setupdevice(void)
 
 unreg_mem_region:
release_mem_region(tcobase_phys, SP5100_WDT_MEM_MAP_SIZE);
-unreg_region:
-   release_region(pm_iobase, SP5100_PM_IOPORTS_SIZE);
 exit:
return 0;
 }
@@ -517,7 +517,6 @@ static int sp5100_tco_init(struct platform_device *dev)
 exit:
iounmap(tcobase);
release_mem_region(tcobase_phys, SP5100_WDT_MEM_MAP_SIZE);
-   release_region(pm_iobase, SP5100_PM_IOPORTS_SIZE);
return ret;
 }
 
@@ -531,7 +530,6 @@ sta

[PATCH 1/3] usb: pci-quirks: Add a header for SB800 I/O ports and mutex for locking

[Zoltan Boszormenyi]

From: Böszörményi Zoltán 

This patch adds:
* a mutex in the USB PCI quirks code for synchronizing access to
  the I/O ports on SB800
* a new header that contains symbols for the index and data I/O ports
  and wrappers for locking and unlocking the mutex.
* locking around the I/O port access for SB800

Signed-off-by: Zoltan Boszormenyi 
---
 drivers/usb/host/pci-quirks.c | 14 ++
 include/linux/sb800.h | 15 +++
 2 files changed, 25 insertions(+), 4 deletions(-)
 create mode 100644 include/linux/sb800.h

diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index a9a1e4c..9b0445c 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "pci-quirks.h"
 #include "xhci-ext-caps.h"
 
@@ -279,6 +280,9 @@ bool usb_amd_prefetch_quirk(void)
 }
 EXPORT_SYMBOL_GPL(usb_amd_prefetch_quirk);
 
+DEFINE_MUTEX(sb800_mutex);
+EXPORT_SYMBOL_GPL(sb800_mutex);
+
 /*
  * The hardware normally enables the A-link power management feature, which
  * lets the system lower the power consumption in idle states.
@@ -314,11 +318,13 @@ static void usb_amd_quirk_pll(int disable)
if (amd_chipset.sb_type.gen == AMD_CHIPSET_SB800 ||
amd_chipset.sb_type.gen == AMD_CHIPSET_HUDSON2 ||
amd_chipset.sb_type.gen == AMD_CHIPSET_BOLTON) {
-   outb_p(AB_REG_BAR_LOW, 0xcd6);
-   addr_low = inb_p(0xcd7);
-   outb_p(AB_REG_BAR_HIGH, 0xcd6);
-   addr_high = inb_p(0xcd7);
+   enter_sb800();
+   outb_p(AB_REG_BAR_LOW, SB800_PIIX4_SMB_IDX);
+   addr_low = inb_p(SB800_PIIX4_SMB_DATA);
+   outb_p(AB_REG_BAR_HIGH, SB800_PIIX4_SMB_IDX);
+   addr_high = inb_p(SB800_PIIX4_SMB_DATA);
addr = addr_high << 8 | addr_low;
+   leave_sb800();
 
outl_p(0x30, AB_INDX(addr));
outl_p(0x40, AB_DATA(addr));
diff --git a/include/linux/sb800.h b/include/linux/sb800.h
new file mode 100644
index 000..5650b7d
--- /dev/null
+++ b/include/linux/sb800.h
@@ -0,0 +1,15 @@
+
+#ifndef SB800_H
+#define SB800_H
+
+#include 
+
+#define SB800_PIIX4_SMB_IDX0xcd6
+#define SB800_PIIX4_SMB_DATA   0xcd7
+
+extern struct mutex sb800_mutex;
+
+#define enter_sb800()  mutex_lock(_mutex)
+#define leave_sb800()  mutex_unlock(_mutex)
+
+#endif
-- 
2.9.3

[PATCH 0/3, resend] Fix sp5100_tco watchdog driver regression

[Zoltan Boszormenyi]

My name with Hungarian accented characters from the Signed-off-by line
is also used in cc: by git send-email but it gets rejected by
mailer damons. Why only patch 2/3 was rejected is a mystery.
Resending with my name in 7-bit ASCII.

Three drivers are accessing the same I/O ports (0xcd6 / 0xcd7) on
AMD SB800 based machines without synchronization or with excluding
each other out:
* the USB quirk for isochronous transfers on SB800 (no locking)
* sp5100_tco (request_region)
* i2c-piix4 (request_region)

Historically, the sp5100_tco watchdog driver used request_region()
for these I/O ports but an i2c-piix4 improvement for SB800 in
Linux 4.4-rc4 also added a request_region() call. Because of this
and the load order, this cause a regression and the watchdog function
became non-functional. The commit that caused the regression is:

commit 2fee61d22e606fc99ade9079fda15fdee83ec33e
Author: Christian Fetzer <fetzer...@gmail.com>
Date:   Thu Nov 19 20:13:48 2015 +0100

i2c: piix4: Add support for multiplexed main adapter in SB800

I was informed by Guenter Roeck <li...@roeck-us.net> that the
alternative, i.e. using request_muxed_region() can fail, either
because of a resource allocation failure, which is quite possible
with long uptimes, or because there are no guarantees that an as yet
unknown driver would also use request_muxed_region() consistently.

Because of this, a solution using a common mutex was chosen to
synchronize I/O port accesses and request_region() calls are removed
from both i2c-piix4 and sp5100_tco to make the code uniform.

This patch series implements this and restores the watchdog function.

Signed-off-by: Zoltan Boszormenyi <zbos...@pr.hu>

 drivers/i2c/busses/i2c-piix4.c | 59 --
 drivers/usb/host/pci-quirks.c  | 14 ++---
 drivers/watchdog/sp5100_tco.c  | 24 +++-
 drivers/watchdog/sp5100_tco.h  | 10 ---
 include/linux/sb800.h  | 15 ++
 5 files changed, 61 insertions(+), 61 deletions(-)

[PATCH 0/3, resend] Fix sp5100_tco watchdog driver regression

[Zoltan Boszormenyi]

My name with Hungarian accented characters from the Signed-off-by line
is also used in cc: by git send-email but it gets rejected by
mailer damons. Why only patch 2/3 was rejected is a mystery.
Resending with my name in 7-bit ASCII.

Three drivers are accessing the same I/O ports (0xcd6 / 0xcd7) on
AMD SB800 based machines without synchronization or with excluding
each other out:
* the USB quirk for isochronous transfers on SB800 (no locking)
* sp5100_tco (request_region)
* i2c-piix4 (request_region)

Historically, the sp5100_tco watchdog driver used request_region()
for these I/O ports but an i2c-piix4 improvement for SB800 in
Linux 4.4-rc4 also added a request_region() call. Because of this
and the load order, this cause a regression and the watchdog function
became non-functional. The commit that caused the regression is:

commit 2fee61d22e606fc99ade9079fda15fdee83ec33e
Author: Christian Fetzer 
Date:   Thu Nov 19 20:13:48 2015 +0100

i2c: piix4: Add support for multiplexed main adapter in SB800

I was informed by Guenter Roeck  that the
alternative, i.e. using request_muxed_region() can fail, either
because of a resource allocation failure, which is quite possible
with long uptimes, or because there are no guarantees that an as yet
unknown driver would also use request_muxed_region() consistently.

Because of this, a solution using a common mutex was chosen to
synchronize I/O port accesses and request_region() calls are removed
from both i2c-piix4 and sp5100_tco to make the code uniform.

This patch series implements this and restores the watchdog function.

Signed-off-by: Zoltan Boszormenyi 

 drivers/i2c/busses/i2c-piix4.c | 59 --
 drivers/usb/host/pci-quirks.c  | 14 ++---
 drivers/watchdog/sp5100_tco.c  | 24 +++-
 drivers/watchdog/sp5100_tco.h  | 10 ---
 include/linux/sb800.h  | 15 ++
 5 files changed, 61 insertions(+), 61 deletions(-)

[PATCH] Re: Forcing modes in libata (was: SATA buffered read VERY

[Zoltan Boszormenyi]

Hi,

Once upon a time FD Cami wrote:

On Sun, 6 Jan 2008 13:36:09 +
Alan Cox <[EMAIL PROTECTED]> wrote:

> On Sun, 6 Jan 2008 08:03:31 +0300
> > > For now you can boot with libata.dma=1 to select DMA on disks but
> > > not CD
> > 
> > Great, but why isn't this in the documentation?
> 
> Send patches


patch attached.

Description : Add libata.dma= to Documentation/kernel-parameters.txt

Found documentation in :
http://www.mail-archive.com/linux-ide%40vger.kernel.org/msg09849.html
http://www.redhat.com/archives/fedora-extras-commits/2007-October/msg04568.html

Signed-off-by: François Cami <[EMAIL PROTECTED]>

*["libata-doc-patch.txt" (text/plain)]* 


diff -rU2 linux-2.6.24-rc6/Documentation/kernel-parameters.txt \
linux-2.6.24-rc6-mine/Documentation/kernel-parameters.txt
--- linux-2.6.24-rc6/Documentation/kernel-parameters.txt2008-01-06 \
15:58:54.0 +0100
+++ linux-2.6.24-rc6-mine/Documentation/kernel-parameters.txt   2008-01-06 \
16:11:20.0 +0100 @@ -883,4 +883,11 @@
C2 power state.
 
+	libata.dma=	[LIBATA] DMA control

+   libata.dma=0  Disable all PATA DMA like old IDE
+   libata.dma=1  Disk DMA only
+   libata.dma=2  ATAPI DMA only
+			libata.dma=3	  CF DMA only 
+			libata.dma=0,1,3  Combinations also work.

+
  


The code patch you are looking at has little different semantics.
(1 << 2) is 4 not 3... Values for different devices are:

1  - ATA
2 - ATAPI
4 - CF

The parameter is a bitmask of 1, 2, 4. Default is 7.
2.6.24-rc3 also has this in libata-core.c which confirms
the acceptance of a bitmask :

static int libata_dma_mask = 
ATA_DMA_MASK_ATA|ATA_DMA_MASK_ATAPI|ATA_DMA_MASK_CFA;

module_param_named(dma, libata_dma_mask, int, 0444);
MODULE_PARM_DESC(dma, "DMA enable/disable (0x1==ATA, 0x2==ATAPI, 0x4==CF)");

Best regards,
Zoltán Böszörményi


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

[PATCH] Re: Forcing modes in libata (was: SATA buffered read VERY

[Zoltan Boszormenyi]

Hi,

Once upon a time FD Cami wrote:

On Sun, 6 Jan 2008 13:36:09 +
Alan Cox [EMAIL PROTECTED] wrote:

 On Sun, 6 Jan 2008 08:03:31 +0300
   For now you can boot with libata.dma=1 to select DMA on disks but
   not CD
  
  Great, but why isn't this in the documentation?
 
 Send patches


patch attached.

Description : Add libata.dma= to Documentation/kernel-parameters.txt

Found documentation in :
http://www.mail-archive.com/linux-ide%40vger.kernel.org/msg09849.html
http://www.redhat.com/archives/fedora-extras-commits/2007-October/msg04568.html

Signed-off-by: François Cami [EMAIL PROTECTED]

*[libata-doc-patch.txt (text/plain)]* 
http://marc.info/?l=linux-kernelm=119963307018562q=p3

diff -rU2 linux-2.6.24-rc6/Documentation/kernel-parameters.txt \
linux-2.6.24-rc6-mine/Documentation/kernel-parameters.txt
--- linux-2.6.24-rc6/Documentation/kernel-parameters.txt2008-01-06 \
15:58:54.0 +0100
+++ linux-2.6.24-rc6-mine/Documentation/kernel-parameters.txt   2008-01-06 \
16:11:20.0 +0100 @@ -883,4 +883,11 @@
C2 power state.
 
+	libata.dma=	[LIBATA] DMA control

+   libata.dma=0  Disable all PATA DMA like old IDE
+   libata.dma=1  Disk DMA only
+   libata.dma=2  ATAPI DMA only
+			libata.dma=3	  CF DMA only 
+			libata.dma=0,1,3  Combinations also work.

+
  


The code patch you are looking at has little different semantics.
(1  2) is 4 not 3... Values for different devices are:

1  - ATA
2 - ATAPI
4 - CF

The parameter is a bitmask of 1, 2, 4. Default is 7.
2.6.24-rc3 also has this in libata-core.c which confirms
the acceptance of a bitmask :

static int libata_dma_mask = 
ATA_DMA_MASK_ATA|ATA_DMA_MASK_ATAPI|ATA_DMA_MASK_CFA;

module_param_named(dma, libata_dma_mask, int, 0444);
MODULE_PARM_DESC(dma, DMA enable/disable (0x1==ATA, 0x2==ATAPI, 0x4==CF));

Best regards,
Zoltán Böszörményi


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

Re: Bad CD disk disables IDE DMA

[Zoltan Boszormenyi]

Zoltan Boszormenyi írta:

Bodo Eggert írta:

Michal Piotrowski <[EMAIL PROTECTED]> wrote:
 

On 15/08/07, Zoltan Boszormenyi <[EMAIL PROTECTED]> wrote:



 

I noticed that a bad CD of mine makes DMA disabled:
  


[...]
 

hda: cdrom_decode_status: error=0x40 { LastFailedSense=0x04 }
ide: failed opcode was: unknown
hda: DMA disabled
hda: ide_intr: huh? expected NULL handler on exit
hda: ATAPI reset complete

Every time I put the said CD into to drive and DMA is on, I get the
above messages.
  

This might be intended.



Maybe, and maybe only a certain effect might be intended. And maybe I 
can

help by asking these questions:

1) Does disabling DMA fix the seek errors, or does it hide them by 
the PIO

   interfce not printing them?
  


With DMA off no seek error occurs. When the transfer rate is
limited to UDMA3 I get this:

hda: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
hda: drive_cmd: error=0x04 { AbortedCommand }
ide: failed opcode was: 0xec

Note the difference: the error code is different and
it knows the failed opcode as well. But DMA remains on.
Can it be a bad 80w cable? I don't think so, considering that
it doesn't occur for DVDs when using UDMA4...

2) If it does hide them, would filtering for seek errors be a sane 
thing to

   do, or does the DMA engine (or HDD) behave badly on these errors, or
   do bad-DMA devices report seek errors, too?

3) If it does not hide them, would re-enabling DMA on disk change be a
   feasable workaround?
   (proposed interface: use hdparm -d $num where $num =
 0, 1: as before
 3: DMA on, if switched off automatically, will be set to 2
 2: DMA off, will be turned on (set to 3) on disk change)
  


The automatic DMA re-enabling would be a good solution.


4) Does libata work well enough for making all effort put into that old
   IDE layer be a waste of time?
  


Unfortunately libata (or pata_amd) doesn't work very well on this 
machine,
I tried to switch to libata for the CD drive but it lost the 
DVD-playing capability.
It seems the error was that libdvdcss couldn't get the keys via the 
scd device.

This is the main obstacle that stops me switching to Fedora 7 from FC6.
I reported it some time ago but got no answer. Look for subject
"DVD-playing, ide-cd vs scsi-cd drivers".


Forget about this last comment. I just installed F7 on a similar machine,
motherboard is ABit KN9S instead of KN9SLI (mine), both have the same
MCP55 IDE rev a1 and MCP55 SATA rev a2. This new machine
plays DVDs nicely, so the difference is in the userspace. Although
both my FC6 and F7 has the same libdvdcss-1.2.9-4.lvn6. Its src.rpm
doesn't have any patches, just the mainstream libdvdcss sources.
Now explain that. :-)


Best regards,
Zoltán Böszörményi



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

Re: Bad CD disk disables IDE DMA

[Zoltan Boszormenyi]

Zoltan Boszormenyi írta:

Bodo Eggert írta:

Michal Piotrowski [EMAIL PROTECTED] wrote:
 

On 15/08/07, Zoltan Boszormenyi [EMAIL PROTECTED] wrote:



 

I noticed that a bad CD of mine makes DMA disabled:
  


[...]
 

hda: cdrom_decode_status: error=0x40 { LastFailedSense=0x04 }
ide: failed opcode was: unknown
hda: DMA disabled
hda: ide_intr: huh? expected NULL handler on exit
hda: ATAPI reset complete

Every time I put the said CD into to drive and DMA is on, I get the
above messages.
  

This might be intended.



Maybe, and maybe only a certain effect might be intended. And maybe I 
can

help by asking these questions:

1) Does disabling DMA fix the seek errors, or does it hide them by 
the PIO

   interfce not printing them?
  


With DMA off no seek error occurs. When the transfer rate is
limited to UDMA3 I get this:

hda: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
hda: drive_cmd: error=0x04 { AbortedCommand }
ide: failed opcode was: 0xec

Note the difference: the error code is different and
it knows the failed opcode as well. But DMA remains on.
Can it be a bad 80w cable? I don't think so, considering that
it doesn't occur for DVDs when using UDMA4...

2) If it does hide them, would filtering for seek errors be a sane 
thing to

   do, or does the DMA engine (or HDD) behave badly on these errors, or
   do bad-DMA devices report seek errors, too?

3) If it does not hide them, would re-enabling DMA on disk change be a
   feasable workaround?
   (proposed interface: use hdparm -d $num where $num =
 0, 1: as before
 3: DMA on, if switched off automatically, will be set to 2
 2: DMA off, will be turned on (set to 3) on disk change)
  


The automatic DMA re-enabling would be a good solution.


4) Does libata work well enough for making all effort put into that old
   IDE layer be a waste of time?
  


Unfortunately libata (or pata_amd) doesn't work very well on this 
machine,
I tried to switch to libata for the CD drive but it lost the 
DVD-playing capability.
It seems the error was that libdvdcss couldn't get the keys via the 
scd device.

This is the main obstacle that stops me switching to Fedora 7 from FC6.
I reported it some time ago but got no answer. Look for subject
DVD-playing, ide-cd vs scsi-cd drivers.


Forget about this last comment. I just installed F7 on a similar machine,
motherboard is ABit KN9S instead of KN9SLI (mine), both have the same
MCP55 IDE rev a1 and MCP55 SATA rev a2. This new machine
plays DVDs nicely, so the difference is in the userspace. Although
both my FC6 and F7 has the same libdvdcss-1.2.9-4.lvn6. Its src.rpm
doesn't have any patches, just the mainstream libdvdcss sources.
Now explain that. :-)


Best regards,
Zoltán Böszörményi



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

Re: Bad CD disk disables IDE DMA

[Zoltan Boszormenyi]

Bodo Eggert írta:

Michal Piotrowski <[EMAIL PROTECTED]> wrote:
  

On 15/08/07, Zoltan Boszormenyi <[EMAIL PROTECTED]> wrote:



  

I noticed that a bad CD of mine makes DMA disabled:
  


[...]
  

hda: cdrom_decode_status: error=0x40 { LastFailedSense=0x04 }
ide: failed opcode was: unknown
hda: DMA disabled
hda: ide_intr: huh? expected NULL handler on exit
hda: ATAPI reset complete

Every time I put the said CD into to drive and DMA is on, I get the
above messages.
  

This might be intended.



Maybe, and maybe only a certain effect might be intended. And maybe I can
help by asking these questions:

1) Does disabling DMA fix the seek errors, or does it hide them by the PIO
   interfce not printing them?
  


With DMA off no seek error occurs. When the transfer rate is
limited to UDMA3 I get this:

hda: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
hda: drive_cmd: error=0x04 { AbortedCommand }
ide: failed opcode was: 0xec

Note the difference: the error code is different and
it knows the failed opcode as well. But DMA remains on.
Can it be a bad 80w cable? I don't think so, considering that
it doesn't occur for DVDs when using UDMA4...


2) If it does hide them, would filtering for seek errors be a sane thing to
   do, or does the DMA engine (or HDD) behave badly on these errors, or
   do bad-DMA devices report seek errors, too?

3) If it does not hide them, would re-enabling DMA on disk change be a
   feasable workaround?
   (proposed interface: use hdparm -d $num where $num =
 0, 1: as before
 3: DMA on, if switched off automatically, will be set to 2
 2: DMA off, will be turned on (set to 3) on disk change)
  


The automatic DMA re-enabling would be a good solution.


4) Does libata work well enough for making all effort put into that old
   IDE layer be a waste of time?
  


Unfortunately libata (or pata_amd) doesn't work very well on this machine,
I tried to switch to libata for the CD drive but it lost the DVD-playing 
capability.
It seems the error was that libdvdcss couldn't get the keys via the scd 
device.

This is the main obstacle that stops me switching to Fedora 7 from FC6.
I reported it some time ago but got no answer. Look for subject
"DVD-playing, ide-cd vs scsi-cd drivers".

Best regards,
Zoltán Böszörményi


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

Re: Bad CD disk disables IDE DMA

[Zoltan Boszormenyi]

Zoltan Boszormenyi írta:

Michal Piotrowski írta:

Hi Zoltan,

On 15/08/07, Zoltan Boszormenyi <[EMAIL PROTECTED]> wrote:
 

Hi,

I noticed that a bad CD of mine makes DMA disabled:

hda: selected mode 0x44
hda: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error }
hda: cdrom_decode_status: error=0x40 { LastFailedSense=0x04 }
ide: failed opcode was: unknown
hda: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error }
hda: cdrom_decode_status: error=0x40 { LastFailedSense=0x04 }
ide: failed opcode was: unknown
hda: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error }
hda: cdrom_decode_status: error=0x40 { LastFailedSense=0x04 }
ide: failed opcode was: unknown
hda: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error }
hda: cdrom_decode_status: error=0x40 { LastFailedSense=0x04 }
ide: failed opcode was: unknown
hda: DMA disabled
hda: ide_intr: huh? expected NULL handler on exit
hda: ATAPI reset complete

Every time I put the said CD into to drive and DMA is on, I get the
above messages.



This might be intended.
  


Might be. Note however, that there are no "cdrom_decode_status: " lines
when the drive is not using DMA. The disk is the same in both cases.
I don't know too much about ATAPI, but shouldn't it report the same
errors no matter how the commands are passed to the drive?
I tried to make it using DMA after mounting the "faulty" disk and 
copying it.
The same errors occured in the logs when dd started reading but it 
actually

finished reading:

$ LANG=C dd if=/dev/hda of=image.iso bs=2048
dd: reading `/dev/hda': Input/output error
298106+0 records in
298106+0 records out
610521088 bytes (611 MB) copied, 144.349 seconds, 4.2 MB/s

The file is a bit larger than what isosize reports about it but IIRC 
it's expected.
So, if the disk is actually faulty dd would drop dead and not able to 
read the disk.
Or something is not quite right in the ide-cd driver. The "DMA 
disabled" message
comes when the drive should spin up the disk. Isn't there a timeout 
error somewhere?
Hm. Thinking about it a bit more upon mount the same is happening - 
before
the disk is spun up the error shows up in the logs and it switches to 
PIO.

Does it ring a bell to someone?


Another data point: the other disks I tried up to now were DVDs
and DMA remains turned on for those. It's even true for empty
DVDs and the label side of a Labelflash disk. On the other hand,
another CD and two other CDRW disks (no visible faults, scratches
on either btw) give me the same error when they are mounted,
DMA gets disabled.

... some more tests and researching ...

TADA! The solution was to tune down the drive to only use UDMA3
with "hdparm -X67". Now although dd didn't get any faster, DMA
remained enabled. Actually the drive is originally a Pioneer 111D
that was reflashed to 111L to get the Labelflash feature.
Can it be a firmware bug? BTW the drive has a 80w cable.


Two things are interesting: first, it gets mounted correctly and
readable and
second, when DMA was already disabled no such messages occur in the 
logs.

Anyhow, I would need DMA to correctly burn CDs/DVDs...
What can I do besides manually re-enable DMA?
All other disks I have tried behave perfectly.
This happened on 2.6.22[-rcX], 2.6.23-rc3-git1 and 2.6.20-1.2962.fc6.
This is on a Fedora Core 6 system. CD/DVD is using the old IDE drivers:

Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with 
idebus=xx

NFORCE-MCP55: IDE controller at PCI slot :00:04.0
NFORCE-MCP55: chipset revision 161
NFORCE-MCP55: not 100% native mode: will probe irqs later
NFORCE-MCP55: BIOS didn't set cable bits correctly. Enabling 
workaround.

NFORCE-MCP55: :00:04.0 (rev a1) UDMA133 controller
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
Probing IDE interface ide0...
hda: PIONEER DVD-RW DVR-111L, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
ide-floppy driver 0.99.newide

$ cat /proc/ide/amd74xx
--AMD BusMastering IDE Configuration
Driver Version: 2.13
South Bridge:   :00:04.0
Revision:   IDE 0xa1
Highest DMA rate:   UDMA133
BM-DMA base:0xf000
PCI clock:  33.3MHz
---Primary IDE---Secondary IDE--
Prefetch Buffer:  yes yes
Post Write Buffer:yes yes
Enabled:  yes  no
Simplex only:  no yes
Cable Type:   80w 80w
---drive0drive1drive2drive3-
Transfer Mode:PIO   DMA   DMA   DMA
Address Setup:   30ns  90ns  90ns  90ns
Cmd Active:  90ns  90ns 300ns 300ns

Re: Bad CD disk disables IDE DMA

[Zoltan Boszormenyi]

Michal Piotrowski írta:

Hi Zoltan,

On 15/08/07, Zoltan Boszormenyi <[EMAIL PROTECTED]> wrote:
  

Hi,

I noticed that a bad CD of mine makes DMA disabled:

hda: selected mode 0x44
hda: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error }
hda: cdrom_decode_status: error=0x40 { LastFailedSense=0x04 }
ide: failed opcode was: unknown
hda: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error }
hda: cdrom_decode_status: error=0x40 { LastFailedSense=0x04 }
ide: failed opcode was: unknown
hda: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error }
hda: cdrom_decode_status: error=0x40 { LastFailedSense=0x04 }
ide: failed opcode was: unknown
hda: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error }
hda: cdrom_decode_status: error=0x40 { LastFailedSense=0x04 }
ide: failed opcode was: unknown
hda: DMA disabled
hda: ide_intr: huh? expected NULL handler on exit
hda: ATAPI reset complete

Every time I put the said CD into to drive and DMA is on, I get the
above messages.



This might be intended.
  


Might be. Note however, that there are no "cdrom_decode_status: " lines
when the drive is not using DMA. The disk is the same in both cases.
I don't know too much about ATAPI, but shouldn't it report the same
errors no matter how the commands are passed to the drive?
I tried to make it using DMA after mounting the "faulty" disk and 
copying it.

The same errors occured in the logs when dd started reading but it actually
finished reading:

$ LANG=C dd if=/dev/hda of=image.iso bs=2048
dd: reading `/dev/hda': Input/output error
298106+0 records in
298106+0 records out
610521088 bytes (611 MB) copied, 144.349 seconds, 4.2 MB/s

The file is a bit larger than what isosize reports about it but IIRC 
it's expected.
So, if the disk is actually faulty dd would drop dead and not able to 
read the disk.
Or something is not quite right in the ide-cd driver. The "DMA disabled" 
message
comes when the drive should spin up the disk. Isn't there a timeout 
error somewhere?

Hm. Thinking about it a bit more upon mount the same is happening - before
the disk is spun up the error shows up in the logs and it switches to PIO.
Does it ring a bell to someone?


Two things are interesting: first, it gets mounted correctly and
readable and
second, when DMA was already disabled no such messages occur in the logs.
Anyhow, I would need DMA to correctly burn CDs/DVDs...
What can I do besides manually re-enable DMA?
All other disks I have tried behave perfectly.
This happened on 2.6.22[-rcX], 2.6.23-rc3-git1 and 2.6.20-1.2962.fc6.
This is on a Fedora Core 6 system. CD/DVD is using the old IDE drivers:

Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
NFORCE-MCP55: IDE controller at PCI slot :00:04.0
NFORCE-MCP55: chipset revision 161
NFORCE-MCP55: not 100% native mode: will probe irqs later
NFORCE-MCP55: BIOS didn't set cable bits correctly. Enabling workaround.
NFORCE-MCP55: :00:04.0 (rev a1) UDMA133 controller
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
Probing IDE interface ide0...
hda: PIONEER DVD-RW DVR-111L, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
ide-floppy driver 0.99.newide

$ cat /proc/ide/amd74xx
--AMD BusMastering IDE Configuration
Driver Version: 2.13
South Bridge:   :00:04.0
Revision:   IDE 0xa1
Highest DMA rate:   UDMA133
BM-DMA base:0xf000
PCI clock:  33.3MHz
---Primary IDE---Secondary IDE--
Prefetch Buffer:  yes yes
Post Write Buffer:yes yes
Enabled:  yes  no
Simplex only:  no yes
Cable Type:   80w 80w
---drive0drive1drive2drive3-
Transfer Mode:PIO   DMA   DMA   DMA
Address Setup:   30ns  90ns  90ns  90ns
Cmd Active:  90ns  90ns 300ns 300ns
Cmd Recovery:30ns  30ns 300ns 300ns
Data Active: 90ns 330ns 330ns 330ns
Data Recovery:   30ns 270ns 270ns 270ns
Cycle Time: 120ns 600ns 600ns 600ns
Transfer Rate:   16.6MB/s   3.3MB/s   3.3MB/s   3.3MB/s

Best regards,
Zoltán Böszörményi



Regards,
Michal

  


Best regards,
Zoltán


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

Re: Bad CD disk disables IDE DMA

[Zoltan Boszormenyi]

Michal Piotrowski írta:

Hi Zoltan,

On 15/08/07, Zoltan Boszormenyi [EMAIL PROTECTED] wrote:
  

Hi,

I noticed that a bad CD of mine makes DMA disabled:

hda: selected mode 0x44
hda: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error }
hda: cdrom_decode_status: error=0x40 { LastFailedSense=0x04 }
ide: failed opcode was: unknown
hda: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error }
hda: cdrom_decode_status: error=0x40 { LastFailedSense=0x04 }
ide: failed opcode was: unknown
hda: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error }
hda: cdrom_decode_status: error=0x40 { LastFailedSense=0x04 }
ide: failed opcode was: unknown
hda: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error }
hda: cdrom_decode_status: error=0x40 { LastFailedSense=0x04 }
ide: failed opcode was: unknown
hda: DMA disabled
hda: ide_intr: huh? expected NULL handler on exit
hda: ATAPI reset complete

Every time I put the said CD into to drive and DMA is on, I get the
above messages.



This might be intended.
  


Might be. Note however, that there are no cdrom_decode_status:  lines
when the drive is not using DMA. The disk is the same in both cases.
I don't know too much about ATAPI, but shouldn't it report the same
errors no matter how the commands are passed to the drive?
I tried to make it using DMA after mounting the faulty disk and 
copying it.

The same errors occured in the logs when dd started reading but it actually
finished reading:

$ LANG=C dd if=/dev/hda of=image.iso bs=2048
dd: reading `/dev/hda': Input/output error
298106+0 records in
298106+0 records out
610521088 bytes (611 MB) copied, 144.349 seconds, 4.2 MB/s

The file is a bit larger than what isosize reports about it but IIRC 
it's expected.
So, if the disk is actually faulty dd would drop dead and not able to 
read the disk.
Or something is not quite right in the ide-cd driver. The DMA disabled 
message
comes when the drive should spin up the disk. Isn't there a timeout 
error somewhere?

Hm. Thinking about it a bit more upon mount the same is happening - before
the disk is spun up the error shows up in the logs and it switches to PIO.
Does it ring a bell to someone?


Two things are interesting: first, it gets mounted correctly and
readable and
second, when DMA was already disabled no such messages occur in the logs.
Anyhow, I would need DMA to correctly burn CDs/DVDs...
What can I do besides manually re-enable DMA?
All other disks I have tried behave perfectly.
This happened on 2.6.22[-rcX], 2.6.23-rc3-git1 and 2.6.20-1.2962.fc6.
This is on a Fedora Core 6 system. CD/DVD is using the old IDE drivers:

Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
NFORCE-MCP55: IDE controller at PCI slot :00:04.0
NFORCE-MCP55: chipset revision 161
NFORCE-MCP55: not 100% native mode: will probe irqs later
NFORCE-MCP55: BIOS didn't set cable bits correctly. Enabling workaround.
NFORCE-MCP55: :00:04.0 (rev a1) UDMA133 controller
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
Probing IDE interface ide0...
hda: PIONEER DVD-RW DVR-111L, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
ide-floppy driver 0.99.newide

$ cat /proc/ide/amd74xx
--AMD BusMastering IDE Configuration
Driver Version: 2.13
South Bridge:   :00:04.0
Revision:   IDE 0xa1
Highest DMA rate:   UDMA133
BM-DMA base:0xf000
PCI clock:  33.3MHz
---Primary IDE---Secondary IDE--
Prefetch Buffer:  yes yes
Post Write Buffer:yes yes
Enabled:  yes  no
Simplex only:  no yes
Cable Type:   80w 80w
---drive0drive1drive2drive3-
Transfer Mode:PIO   DMA   DMA   DMA
Address Setup:   30ns  90ns  90ns  90ns
Cmd Active:  90ns  90ns 300ns 300ns
Cmd Recovery:30ns  30ns 300ns 300ns
Data Active: 90ns 330ns 330ns 330ns
Data Recovery:   30ns 270ns 270ns 270ns
Cycle Time: 120ns 600ns 600ns 600ns
Transfer Rate:   16.6MB/s   3.3MB/s   3.3MB/s   3.3MB/s

Best regards,
Zoltán Böszörményi



Regards,
Michal

  


Best regards,
Zoltán


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

Re: Bad CD disk disables IDE DMA

[Zoltan Boszormenyi]

Zoltan Boszormenyi írta:

Michal Piotrowski írta:

Hi Zoltan,

On 15/08/07, Zoltan Boszormenyi [EMAIL PROTECTED] wrote:
 

Hi,

I noticed that a bad CD of mine makes DMA disabled:

hda: selected mode 0x44
hda: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error }
hda: cdrom_decode_status: error=0x40 { LastFailedSense=0x04 }
ide: failed opcode was: unknown
hda: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error }
hda: cdrom_decode_status: error=0x40 { LastFailedSense=0x04 }
ide: failed opcode was: unknown
hda: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error }
hda: cdrom_decode_status: error=0x40 { LastFailedSense=0x04 }
ide: failed opcode was: unknown
hda: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error }
hda: cdrom_decode_status: error=0x40 { LastFailedSense=0x04 }
ide: failed opcode was: unknown
hda: DMA disabled
hda: ide_intr: huh? expected NULL handler on exit
hda: ATAPI reset complete

Every time I put the said CD into to drive and DMA is on, I get the
above messages.



This might be intended.
  


Might be. Note however, that there are no cdrom_decode_status:  lines
when the drive is not using DMA. The disk is the same in both cases.
I don't know too much about ATAPI, but shouldn't it report the same
errors no matter how the commands are passed to the drive?
I tried to make it using DMA after mounting the faulty disk and 
copying it.
The same errors occured in the logs when dd started reading but it 
actually

finished reading:

$ LANG=C dd if=/dev/hda of=image.iso bs=2048
dd: reading `/dev/hda': Input/output error
298106+0 records in
298106+0 records out
610521088 bytes (611 MB) copied, 144.349 seconds, 4.2 MB/s

The file is a bit larger than what isosize reports about it but IIRC 
it's expected.
So, if the disk is actually faulty dd would drop dead and not able to 
read the disk.
Or something is not quite right in the ide-cd driver. The DMA 
disabled message
comes when the drive should spin up the disk. Isn't there a timeout 
error somewhere?
Hm. Thinking about it a bit more upon mount the same is happening - 
before
the disk is spun up the error shows up in the logs and it switches to 
PIO.

Does it ring a bell to someone?


Another data point: the other disks I tried up to now were DVDs
and DMA remains turned on for those. It's even true for empty
DVDs and the label side of a Labelflash disk. On the other hand,
another CD and two other CDRW disks (no visible faults, scratches
on either btw) give me the same error when they are mounted,
DMA gets disabled.

... some more tests and researching ...

TADA! The solution was to tune down the drive to only use UDMA3
with hdparm -X67. Now although dd didn't get any faster, DMA
remained enabled. Actually the drive is originally a Pioneer 111D
that was reflashed to 111L to get the Labelflash feature.
Can it be a firmware bug? BTW the drive has a 80w cable.


Two things are interesting: first, it gets mounted correctly and
readable and
second, when DMA was already disabled no such messages occur in the 
logs.

Anyhow, I would need DMA to correctly burn CDs/DVDs...
What can I do besides manually re-enable DMA?
All other disks I have tried behave perfectly.
This happened on 2.6.22[-rcX], 2.6.23-rc3-git1 and 2.6.20-1.2962.fc6.
This is on a Fedora Core 6 system. CD/DVD is using the old IDE drivers:

Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with 
idebus=xx

NFORCE-MCP55: IDE controller at PCI slot :00:04.0
NFORCE-MCP55: chipset revision 161
NFORCE-MCP55: not 100% native mode: will probe irqs later
NFORCE-MCP55: BIOS didn't set cable bits correctly. Enabling 
workaround.

NFORCE-MCP55: :00:04.0 (rev a1) UDMA133 controller
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
Probing IDE interface ide0...
hda: PIONEER DVD-RW DVR-111L, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
ide-floppy driver 0.99.newide

$ cat /proc/ide/amd74xx
--AMD BusMastering IDE Configuration
Driver Version: 2.13
South Bridge:   :00:04.0
Revision:   IDE 0xa1
Highest DMA rate:   UDMA133
BM-DMA base:0xf000
PCI clock:  33.3MHz
---Primary IDE---Secondary IDE--
Prefetch Buffer:  yes yes
Post Write Buffer:yes yes
Enabled:  yes  no
Simplex only:  no yes
Cable Type:   80w 80w
---drive0drive1drive2drive3-
Transfer Mode:PIO   DMA   DMA   DMA
Address Setup:   30ns  90ns  90ns  90ns
Cmd Active:  90ns  90ns 300ns 300ns
Cmd Recovery:30ns  30ns 300ns 300ns

Re: Bad CD disk disables IDE DMA

[Zoltan Boszormenyi]

Bodo Eggert írta:

Michal Piotrowski [EMAIL PROTECTED] wrote:
  

On 15/08/07, Zoltan Boszormenyi [EMAIL PROTECTED] wrote:



  

I noticed that a bad CD of mine makes DMA disabled:
  


[...]
  

hda: cdrom_decode_status: error=0x40 { LastFailedSense=0x04 }
ide: failed opcode was: unknown
hda: DMA disabled
hda: ide_intr: huh? expected NULL handler on exit
hda: ATAPI reset complete

Every time I put the said CD into to drive and DMA is on, I get the
above messages.
  

This might be intended.



Maybe, and maybe only a certain effect might be intended. And maybe I can
help by asking these questions:

1) Does disabling DMA fix the seek errors, or does it hide them by the PIO
   interfce not printing them?
  


With DMA off no seek error occurs. When the transfer rate is
limited to UDMA3 I get this:

hda: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
hda: drive_cmd: error=0x04 { AbortedCommand }
ide: failed opcode was: 0xec

Note the difference: the error code is different and
it knows the failed opcode as well. But DMA remains on.
Can it be a bad 80w cable? I don't think so, considering that
it doesn't occur for DVDs when using UDMA4...


2) If it does hide them, would filtering for seek errors be a sane thing to
   do, or does the DMA engine (or HDD) behave badly on these errors, or
   do bad-DMA devices report seek errors, too?

3) If it does not hide them, would re-enabling DMA on disk change be a
   feasable workaround?
   (proposed interface: use hdparm -d $num where $num =
 0, 1: as before
 3: DMA on, if switched off automatically, will be set to 2
 2: DMA off, will be turned on (set to 3) on disk change)
  


The automatic DMA re-enabling would be a good solution.


4) Does libata work well enough for making all effort put into that old
   IDE layer be a waste of time?
  


Unfortunately libata (or pata_amd) doesn't work very well on this machine,
I tried to switch to libata for the CD drive but it lost the DVD-playing 
capability.
It seems the error was that libdvdcss couldn't get the keys via the scd 
device.

This is the main obstacle that stops me switching to Fedora 7 from FC6.
I reported it some time ago but got no answer. Look for subject
DVD-playing, ide-cd vs scsi-cd drivers.

Best regards,
Zoltán Böszörményi


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

Bad CD disk disables IDE DMA

[Zoltan Boszormenyi]

Hi,

I noticed that a bad CD of mine makes DMA disabled:

hda: selected mode 0x44
hda: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error }
hda: cdrom_decode_status: error=0x40 { LastFailedSense=0x04 }
ide: failed opcode was: unknown
hda: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error }
hda: cdrom_decode_status: error=0x40 { LastFailedSense=0x04 }
ide: failed opcode was: unknown
hda: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error }
hda: cdrom_decode_status: error=0x40 { LastFailedSense=0x04 }
ide: failed opcode was: unknown
hda: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error }
hda: cdrom_decode_status: error=0x40 { LastFailedSense=0x04 }
ide: failed opcode was: unknown
hda: DMA disabled
hda: ide_intr: huh? expected NULL handler on exit
hda: ATAPI reset complete

Every time I put the said CD into to drive and DMA is on, I get the 
above messages.
Two things are interesting: first, it gets mounted correctly and 
readable and

second, when DMA was already disabled no such messages occur in the logs.
Anyhow, I would need DMA to correctly burn CDs/DVDs...
What can I do besides manually re-enable DMA?
All other disks I have tried behave perfectly.
This happened on 2.6.22[-rcX], 2.6.23-rc3-git1 and 2.6.20-1.2962.fc6.
This is on a Fedora Core 6 system. CD/DVD is using the old IDE drivers:

Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
NFORCE-MCP55: IDE controller at PCI slot :00:04.0
NFORCE-MCP55: chipset revision 161
NFORCE-MCP55: not 100% native mode: will probe irqs later
NFORCE-MCP55: BIOS didn't set cable bits correctly. Enabling workaround.
NFORCE-MCP55: :00:04.0 (rev a1) UDMA133 controller
   ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
Probing IDE interface ide0...
hda: PIONEER DVD-RW DVR-111L, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
ide-floppy driver 0.99.newide

$ cat /proc/ide/amd74xx
--AMD BusMastering IDE Configuration
Driver Version: 2.13
South Bridge:   :00:04.0
Revision:   IDE 0xa1
Highest DMA rate:   UDMA133
BM-DMA base:0xf000
PCI clock:  33.3MHz
---Primary IDE---Secondary IDE--
Prefetch Buffer:  yes yes
Post Write Buffer:yes yes
Enabled:  yes  no
Simplex only:  no yes
Cable Type:   80w 80w
---drive0drive1drive2drive3-
Transfer Mode:PIO   DMA   DMA   DMA
Address Setup:   30ns  90ns  90ns  90ns
Cmd Active:  90ns  90ns 300ns 300ns
Cmd Recovery:30ns  30ns 300ns 300ns
Data Active: 90ns 330ns 330ns 330ns
Data Recovery:   30ns 270ns 270ns 270ns
Cycle Time: 120ns 600ns 600ns 600ns
Transfer Rate:   16.6MB/s   3.3MB/s   3.3MB/s   3.3MB/s

Best regards,
Zoltán Böszörményi


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

Bad CD disk disables IDE DMA

[Zoltan Boszormenyi]

Hi,

I noticed that a bad CD of mine makes DMA disabled:

hda: selected mode 0x44
hda: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error }
hda: cdrom_decode_status: error=0x40 { LastFailedSense=0x04 }
ide: failed opcode was: unknown
hda: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error }
hda: cdrom_decode_status: error=0x40 { LastFailedSense=0x04 }
ide: failed opcode was: unknown
hda: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error }
hda: cdrom_decode_status: error=0x40 { LastFailedSense=0x04 }
ide: failed opcode was: unknown
hda: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error }
hda: cdrom_decode_status: error=0x40 { LastFailedSense=0x04 }
ide: failed opcode was: unknown
hda: DMA disabled
hda: ide_intr: huh? expected NULL handler on exit
hda: ATAPI reset complete

Every time I put the said CD into to drive and DMA is on, I get the 
above messages.
Two things are interesting: first, it gets mounted correctly and 
readable and

second, when DMA was already disabled no such messages occur in the logs.
Anyhow, I would need DMA to correctly burn CDs/DVDs...
What can I do besides manually re-enable DMA?
All other disks I have tried behave perfectly.
This happened on 2.6.22[-rcX], 2.6.23-rc3-git1 and 2.6.20-1.2962.fc6.
This is on a Fedora Core 6 system. CD/DVD is using the old IDE drivers:

Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
NFORCE-MCP55: IDE controller at PCI slot :00:04.0
NFORCE-MCP55: chipset revision 161
NFORCE-MCP55: not 100% native mode: will probe irqs later
NFORCE-MCP55: BIOS didn't set cable bits correctly. Enabling workaround.
NFORCE-MCP55: :00:04.0 (rev a1) UDMA133 controller
   ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
Probing IDE interface ide0...
hda: PIONEER DVD-RW DVR-111L, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
ide-floppy driver 0.99.newide

$ cat /proc/ide/amd74xx
--AMD BusMastering IDE Configuration
Driver Version: 2.13
South Bridge:   :00:04.0
Revision:   IDE 0xa1
Highest DMA rate:   UDMA133
BM-DMA base:0xf000
PCI clock:  33.3MHz
---Primary IDE---Secondary IDE--
Prefetch Buffer:  yes yes
Post Write Buffer:yes yes
Enabled:  yes  no
Simplex only:  no yes
Cable Type:   80w 80w
---drive0drive1drive2drive3-
Transfer Mode:PIO   DMA   DMA   DMA
Address Setup:   30ns  90ns  90ns  90ns
Cmd Active:  90ns  90ns 300ns 300ns
Cmd Recovery:30ns  30ns 300ns 300ns
Data Active: 90ns 330ns 330ns 330ns
Data Recovery:   30ns 270ns 270ns 270ns
Cycle Time: 120ns 600ns 600ns 600ns
Transfer Rate:   16.6MB/s   3.3MB/s   3.3MB/s   3.3MB/s

Best regards,
Zoltán Böszörményi


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

NVIDIA libata status outdated

[Zoltan Boszormenyi]

Hi,

it seems your "Libata status" page needs some update.

"


 NVIDIA

Driver name: *sata_nv*

Summary: No TCQ/NCQ in early chipsets. NCQ support added in later 
chipsets. Looks like a PATA controller, but with full SATA control 
including hotplug and PM.


*Update:* NVIDIA has provided information (under NDA) that permits 
implementation of NCQ support, and a sample Linux implementation 
 
(patch) as well. Unfortunately, the patch needs debugging, and no one 
seems to have the time or motivation.


*NOTE:* Newer NVIDIA chipsets are AHCI 
, and use the ahci driver 
rather than the sata_nv driver.

"

There have been changes since you wrote the above.
ADMA has been incorporated mainstream for a while now
and SWNCQ is now in -mm. AHCI support is obvious.

Best regards,
Zoltán Böszörményi


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

NVIDIA libata status outdated

[Zoltan Boszormenyi]

Hi,

it seems your Libata status page needs some update.




 NVIDIA

Driver name: *sata_nv*

Summary: No TCQ/NCQ in early chipsets. NCQ support added in later 
chipsets. Looks like a PATA controller, but with full SATA control 
including hotplug and PM.


*Update:* NVIDIA has provided information (under NDA) that permits 
implementation of NCQ support, and a sample Linux implementation 
http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/archive/2.6.17-nv-adma.patch.bz2 
(patch) as well. Unfortunately, the patch needs debugging, and no one 
seems to have the time or motivation.


*NOTE:* Newer NVIDIA chipsets are AHCI 
http://linux-ata.org/driver-status.html#ahci, and use the ahci driver 
rather than the sata_nv driver.



There have been changes since you wrote the above.
ADMA has been incorporated mainstream for a while now
and SWNCQ is now in -mm. AHCI support is obvious.

Best regards,
Zoltán Böszörményi


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

DVD-playing, ide-cd vs scsi-cd drivers

[Zoltan Boszormenyi]

Hi,

I have an FC6 machine with a Pioneer DVD-RW and
I occasionally watch DVDs on it. (Xine+libdvdcss
from Livna works just fine.) I compiled 2.6.22-rc7-git5
before with ide-cd but now I changed the driver to
pata_amd to see it works before I upgrade to FC7.
Now DVD-playing doesn't work, I got this in the log
when I tried to play a DVD in Xine.

UDF-fs: Partition marked readonly; forcing readonly mount
UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'TW10Y', timestamp 
2004/12/16 14:30 (1078)

SELinux: initialized (dev sr0, type udf), uses genfs_contexts
sr 6:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
sr 6:0:0:0: [sr0] Sense Key : Hardware Error [current]
sr 6:0:0:0: [sr0] Add. Sense: Logical unit communication CRC error 
(Ultra-DMA/32)

end_request: I/O error, dev sr0, sector 1476
Buffer I/O error on device sr0, logical block 369
Buffer I/O error on device sr0, logical block 370
Buffer I/O error on device sr0, logical block 371
Buffer I/O error on device sr0, logical block 372
Buffer I/O error on device sr0, logical block 373
Buffer I/O error on device sr0, logical block 374
Buffer I/O error on device sr0, logical block 375
Buffer I/O error on device sr0, logical block 376
Buffer I/O error on device sr0, logical block 377
Buffer I/O error on device sr0, logical block 378
sr 6:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
sr 6:0:0:0: [sr0] Sense Key : Hardware Error [current]
sr 6:0:0:0: [sr0] Add. Sense: Logical unit communication CRC error 
(Ultra-DMA/32)

end_request: I/O error, dev sr0, sector 9126328
printk: 5 messages suppressed.
Buffer I/O error on device sr0, logical block 2281582
Buffer I/O error on device sr0, logical block 2281583
Buffer I/O error on device sr0, logical block 2281584
Buffer I/O error on device sr0, logical block 2281585
Buffer I/O error on device sr0, logical block 2281586
Buffer I/O error on device sr0, logical block 2281587
Buffer I/O error on device sr0, logical block 2281588
Buffer I/O error on device sr0, logical block 2281589
Buffer I/O error on device sr0, logical block 2281590
Buffer I/O error on device sr0, logical block 2281591
sr 6:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
sr 6:0:0:0: [sr0] Sense Key : Hardware Error [current]
sr 6:0:0:0: [sr0] Add. Sense: Logical unit communication CRC error 
(Ultra-DMA/32)

end_request: I/O error, dev sr0, sector 1464
sr 6:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
sr 6:0:0:0: [sr0] Sense Key : Hardware Error [current]
sr 6:0:0:0: [sr0] Add. Sense: Logical unit communication CRC error 
(Ultra-DMA/32)

end_request: I/O error, dev sr0, sector 1820
sr 6:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
sr 6:0:0:0: [sr0] Sense Key : Hardware Error [current]
sr 6:0:0:0: [sr0] Add. Sense: Logical unit communication CRC error 
(Ultra-DMA/32)

end_request: I/O error, dev sr0, sector 64420
sr 6:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
sr 6:0:0:0: [sr0] Sense Key : Hardware Error [current]
sr 6:0:0:0: [sr0] Add. Sense: Logical unit communication CRC error 
(Ultra-DMA/32)

end_request: I/O error, dev sr0, sector 2163840
sr 6:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
sr 6:0:0:0: [sr0] Sense Key : Hardware Error [current]
sr 6:0:0:0: [sr0] Add. Sense: Logical unit communication CRC error 
(Ultra-DMA/32)

end_request: I/O error, dev sr0, sector 2163840
sr 6:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
sr 6:0:0:0: [sr0] Sense Key : Hardware Error [current]
sr 6:0:0:0: [sr0] Add. Sense: Logical unit communication CRC error 
(Ultra-DMA/32)

end_request: I/O error, dev sr0, sector 4258944
sr 6:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
sr 6:0:0:0: [sr0] Sense Key : Hardware Error [current]
sr 6:0:0:0: [sr0] Add. Sense: Logical unit communication CRC error 
(Ultra-DMA/32)

end_request: I/O error, dev sr0, sector 6356860
sr 6:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
sr 6:0:0:0: [sr0] Sense Key : Hardware Error [current]
sr 6:0:0:0: [sr0] Add. Sense: Logical unit communication CRC error 
(Ultra-DMA/32)

end_request: I/O error, dev sr0, sector 8453752
sr 6:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
sr 6:0:0:0: [sr0] Sense Key : Hardware Error [current]
sr 6:0:0:0: [sr0] Add. Sense: Logical unit communication CRC error 
(Ultra-DMA/32)

end_request: I/O error, dev sr0, sector 9127460

I changed the driver back to old IDE and DVD-playing works again
so it's not a hardware error. Is there something I forgot to compile in
or is it a handicap in the SCSI CD drivers?

Best regards,
Zoltán Böszörményi


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

DVD-playing, ide-cd vs scsi-cd drivers

[Zoltan Boszormenyi]

Hi,

I have an FC6 machine with a Pioneer DVD-RW and
I occasionally watch DVDs on it. (Xine+libdvdcss
from Livna works just fine.) I compiled 2.6.22-rc7-git5
before with ide-cd but now I changed the driver to
pata_amd to see it works before I upgrade to FC7.
Now DVD-playing doesn't work, I got this in the log
when I tried to play a DVD in Xine.

UDF-fs: Partition marked readonly; forcing readonly mount
UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'TW10Y', timestamp 
2004/12/16 14:30 (1078)

SELinux: initialized (dev sr0, type udf), uses genfs_contexts
sr 6:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
sr 6:0:0:0: [sr0] Sense Key : Hardware Error [current]
sr 6:0:0:0: [sr0] Add. Sense: Logical unit communication CRC error 
(Ultra-DMA/32)

end_request: I/O error, dev sr0, sector 1476
Buffer I/O error on device sr0, logical block 369
Buffer I/O error on device sr0, logical block 370
Buffer I/O error on device sr0, logical block 371
Buffer I/O error on device sr0, logical block 372
Buffer I/O error on device sr0, logical block 373
Buffer I/O error on device sr0, logical block 374
Buffer I/O error on device sr0, logical block 375
Buffer I/O error on device sr0, logical block 376
Buffer I/O error on device sr0, logical block 377
Buffer I/O error on device sr0, logical block 378
sr 6:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
sr 6:0:0:0: [sr0] Sense Key : Hardware Error [current]
sr 6:0:0:0: [sr0] Add. Sense: Logical unit communication CRC error 
(Ultra-DMA/32)

end_request: I/O error, dev sr0, sector 9126328
printk: 5 messages suppressed.
Buffer I/O error on device sr0, logical block 2281582
Buffer I/O error on device sr0, logical block 2281583
Buffer I/O error on device sr0, logical block 2281584
Buffer I/O error on device sr0, logical block 2281585
Buffer I/O error on device sr0, logical block 2281586
Buffer I/O error on device sr0, logical block 2281587
Buffer I/O error on device sr0, logical block 2281588
Buffer I/O error on device sr0, logical block 2281589
Buffer I/O error on device sr0, logical block 2281590
Buffer I/O error on device sr0, logical block 2281591
sr 6:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
sr 6:0:0:0: [sr0] Sense Key : Hardware Error [current]
sr 6:0:0:0: [sr0] Add. Sense: Logical unit communication CRC error 
(Ultra-DMA/32)

end_request: I/O error, dev sr0, sector 1464
sr 6:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
sr 6:0:0:0: [sr0] Sense Key : Hardware Error [current]
sr 6:0:0:0: [sr0] Add. Sense: Logical unit communication CRC error 
(Ultra-DMA/32)

end_request: I/O error, dev sr0, sector 1820
sr 6:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
sr 6:0:0:0: [sr0] Sense Key : Hardware Error [current]
sr 6:0:0:0: [sr0] Add. Sense: Logical unit communication CRC error 
(Ultra-DMA/32)

end_request: I/O error, dev sr0, sector 64420
sr 6:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
sr 6:0:0:0: [sr0] Sense Key : Hardware Error [current]
sr 6:0:0:0: [sr0] Add. Sense: Logical unit communication CRC error 
(Ultra-DMA/32)

end_request: I/O error, dev sr0, sector 2163840
sr 6:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
sr 6:0:0:0: [sr0] Sense Key : Hardware Error [current]
sr 6:0:0:0: [sr0] Add. Sense: Logical unit communication CRC error 
(Ultra-DMA/32)

end_request: I/O error, dev sr0, sector 2163840
sr 6:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
sr 6:0:0:0: [sr0] Sense Key : Hardware Error [current]
sr 6:0:0:0: [sr0] Add. Sense: Logical unit communication CRC error 
(Ultra-DMA/32)

end_request: I/O error, dev sr0, sector 4258944
sr 6:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
sr 6:0:0:0: [sr0] Sense Key : Hardware Error [current]
sr 6:0:0:0: [sr0] Add. Sense: Logical unit communication CRC error 
(Ultra-DMA/32)

end_request: I/O error, dev sr0, sector 6356860
sr 6:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
sr 6:0:0:0: [sr0] Sense Key : Hardware Error [current]
sr 6:0:0:0: [sr0] Add. Sense: Logical unit communication CRC error 
(Ultra-DMA/32)

end_request: I/O error, dev sr0, sector 8453752
sr 6:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
sr 6:0:0:0: [sr0] Sense Key : Hardware Error [current]
sr 6:0:0:0: [sr0] Add. Sense: Logical unit communication CRC error 
(Ultra-DMA/32)

end_request: I/O error, dev sr0, sector 9127460

I changed the driver back to old IDE and DVD-playing works again
so it's not a hardware error. Is there something I forgot to compile in
or is it a handicap in the SCSI CD drivers?

Best regards,
Zoltán Böszörményi


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

Re: [PATCH] ata: Add the SW NCQ support to sata_nv for MCP51/MCP55/MCP61

[Zoltan Boszormenyi]

kuan luo írta:

From: Kuan Luo <[EMAIL PROTECTED]>

Add the Software NCQ support to sata_nv.c for MCP51/MCP55/MCP61 SATA
controller.  NCQ function is disable by default, you can enable it with
'swncq=1'. NCQ will be turned off if the drive is Maxtor on MCP51 or
MCP55 rev 0xa2  platform.

Signed-off-by: Kuan Luo <[EMAIL PROTECTED]>
Signed-off-by: Peer Chen <[EMAIL PROTECTED]>
---


Thanks, I am using it on 2.6.22-rc7-git5, have run a stress test 
yesterday night.
It seems to be as stable as the previous version. I guess it's safe to 
turn it on

by default when it gets into Linus' kernels.

I have a question though. Why is the blanket needed for Maxtor drives?
Can't it be narrowed down to certain models? Maybe those models
should be put into libata blacklist...
Not that my current machine is affected, I am just curious.

Best regards,
Zoltán Böszörményi


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

Re: [PATCH] ata: Add the SW NCQ support to sata_nv for MCP51/MCP55/MCP61

[Zoltan Boszormenyi]

kuan luo írta:

From: Kuan Luo [EMAIL PROTECTED]

Add the Software NCQ support to sata_nv.c for MCP51/MCP55/MCP61 SATA
controller.  NCQ function is disable by default, you can enable it with
'swncq=1'. NCQ will be turned off if the drive is Maxtor on MCP51 or
MCP55 rev 0xa2  platform.

Signed-off-by: Kuan Luo [EMAIL PROTECTED]
Signed-off-by: Peer Chen [EMAIL PROTECTED]
---


Thanks, I am using it on 2.6.22-rc7-git5, have run a stress test 
yesterday night.
It seems to be as stable as the previous version. I guess it's safe to 
turn it on

by default when it gets into Linus' kernels.

I have a question though. Why is the blanket needed for Maxtor drives?
Can't it be narrowed down to certain models? Maybe those models
should be put into libata blacklist...
Not that my current machine is affected, I am just curious.

Best regards,
Zoltán Böszörményi


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

Re: [PATCH] ata: Add the SW NCQ support to sata_nv for MCP51/MCP55/MCP61

[Zoltan Boszormenyi]

Hi,

Zoltan Boszormenyi írta:

Hi,

I am testing your current code with akpm's beautifying patches
for about an hour now. I have seen no problems with it so far.


Still using the patch on 2.6.22-rc6 and no problems so far.
It's really stable. I am looking forward to the next version and
the inclusion into mainstream kernels. Thanks!

Best regards,
Zoltán Böszörményi


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

Re: [PATCH] ata: Add the SW NCQ support to sata_nv for MCP51/MCP55/MCP61

[Zoltan Boszormenyi]

Hi,

Zoltan Boszormenyi írta:

Hi,

I am testing your current code with akpm's beautifying patches
for about an hour now. I have seen no problems with it so far.


Still using the patch on 2.6.22-rc6 and no problems so far.
It's really stable. I am looking forward to the next version and
the inclusion into mainstream kernels. Thanks!

Best regards,
Zoltán Böszörményi


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

RE: [PATCH] ata: Add the SW NCQ support to sata_nv for MCP51/MCP55/MCP61

[Zoltan Boszormenyi]

Hi,

I am testing your current code with akpm's beautifying patches
for about an hour now. I have seen no problems with it so far.


**A pretty good way.  I will modify my code.
  


Please, cc me when sending your next patch to LKML, thanks.

Best regards,
Zoltán Böszörményi


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

RE: [PATCH] ata: Add the SW NCQ support to sata_nv for MCP51/MCP55/MCP61

[Zoltan Boszormenyi]

Hi,

I am testing your current code with akpm's beautifying patches
for about an hour now. I have seen no problems with it so far.


**A pretty good way.  I will modify my code.
  


Please, cc me when sending your next patch to LKML, thanks.

Best regards,
Zoltán Böszörményi


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

Re: MCP55 NCQ problem?

[Zoltan Boszormenyi]

Zoltan Boszormenyi írta:

Hi,

Peer Chen írta:

Zoltan,
What's your board's model number? Could you post the pci dump using 
'lspci -xxx'? Thanks.



BRs
Peer Chen

-Original Message-
From: Robert Hancock [mailto:[EMAIL PROTECTED] Sent: Thursday, May 
31, 2007 10:31 PM

To: Zoltan Boszormenyi
Cc: linux-kernel; Peer Chen; Kuan Luo
Subject: Re: MCP55 NCQ problem?

CCing Peer Chen and Kuan Luo from NVIDIA..

Looks like there were some unrecognized FIS errors from the 
controller in there?


Zoltan Boszormenyi wrote:
 

Hi,

I just got this with 2.6.22-rc2 + cfs-v13 + swncq patch:

ata2.00: exception Emask 0x0 SAct 0x6 SErr 0x0 action 0x2 frozen
ata2.00: cmd 61/18:08:0f:b7:68/00:00:16:00:00/40 tag 1 cdb 0x0 data 
12288 out

res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata2.00: cmd 61/18:10:7f:b7:68/00:00:16:00:00/40 tag 2 cdb 0x0 data 
12288 out

res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata2: hard resetting port
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata2.00: ata_hpa_resize 1: sectors = 625142448, hpa_sectors = 625142448
ata2.00: ata_hpa_resize 1: sectors = 625142448, hpa_sectors = 625142448
ata2.00: configured for UDMA/133
ata2: EH pending after completion, repeating EH (cnt=4)
ata2: EH complete
sd 1:0:0:0: [sdb] 625142448 512-byte hardware sectors (320073 MB)
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't 
support DPO or FUA


At the time I was creating a DVD ISO image (reads and writes went to 
the disk
that was resetted), browsing mail in thunderbird which also 
exercised the same

disk and I was downloading another ISO with about 400-450 kB/sec to
another disk. Here are the disks in question:

scsi 0:0:0:0: Direct-Access ATA  SAMSUNG HD160JJ  WU10 PQ: 0 
ANSI: 5
scsi 1:0:0:0: Direct-Access ATA  ST3320620AS  3.AA PQ: 0 
ANSI: 5


I got almost the same yesterday with 2.6.22-rc2-mm1:

May 29 12:44:20 localhost kernel: ata2.00: exception Emask 0x0 SAct 
0x6 SErr 0x0 action 0x2 frozen
May 29 12:44:20 localhost kernel: ata2.00: cmd 
61/10:08:2f:41:e9/00:00:07:00:00/40 tag 1 cdb 0x0 data 8192 out
May 29 12:44:20 localhost kernel:  res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

May 29 12:44:20 localhost kernel: ata2.00: status: {DRDY }
May 29 12:44:20 localhost kernel: ata2.00: cmd 
61/30:10:8f:42:e9/00:00:07:00:00/40 tag 2 cdb 0x0 data 24576 out
May 29 12:44:20 localhost kernel:  res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

May 29 12:44:20 localhost kernel: ata2.00: status: {DRDY }
May 29 12:44:20 localhost kernel: ata2: hard resetting port
May 29 12:44:21 localhost kernel: ata2: SATA link up 1.5 Gbps 
(SStatus 113 SControl 300)
May 29 12:44:21 localhost kernel: ata2.00: ata_hpa_resize: sectors = 
625142448, hpa_sectors = 625142448
May 29 12:44:21 localhost kernel: ata2.00: ata_hpa_resize: sectors = 
625142448, hpa_sectors = 625142448

May 29 12:44:21 localhost kernel: ata2.00: configured for UDMA/133
May 29 12:44:21 localhost kernel: ata2: EH pending after completion, 
repeating EH (cnt=4)

May 29 12:44:21 localhost kernel: ata2: EH complete
May 29 12:44:21 localhost kernel: sd 1:0:0:0: [sdb] 625142448 
512-byte hardware sectors (320073 MB)
May 29 12:44:21 localhost kernel: sd 1:0:0:0: [sdb] Write Protect is 
off
May 29 12:44:21 localhost kernel: sd 1:0:0:0: [sdb] Write cache: 
enabled, read cache: enabled, doesn't support DPO or FUA

..
May 29 12:47:46 localhost kernel: ata2.00: exception Emask 0x0 SAct 
0x7 SErr 0x0 action 0x2 frozen
May 29 12:47:46 localhost kernel: ata2.00: cmd 
61/08:00:27:5a:eb/00:00:07:00:00/40 tag 0 cdb 0x0 data 4096 out
May 29 12:47:46 localhost kernel:  res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

May 29 12:47:46 localhost kernel: ata2.00: status: {DRDY }
May 29 12:47:46 localhost kernel: ata2.00: cmd 
61/08:08:bf:61:9e/00:00:0f:00:00/40 tag 1 cdb 0x0 data 4096 out
May 29 12:47:46 localhost kernel:  res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

May 29 12:47:46 localhost kernel: ata2.00: status: {DRDY }
May 29 12:47:46 localhost kernel: ata2.00: cmd 
61/20:10:97:5a:eb/00:00:07:00:00/40 tag 2 cdb 0x0 data 16384 out
May 29 12:47:46 localhost kernel:  res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

May 29 12:47:46 localhost kernel: ata2.00: status: {DRDY }
May 29 12:47:46 localhost kernel: ata2: hard resetting port
May 29 12:47:46 localhost kernel: ata2: SATA link up 1.5 Gbps 
(SStatus 113 SControl 300)
May 29 12:47:46 localhost kernel: ata2.00: ata_hpa_resize: sectors = 
625142448, hpa_sectors = 625142448
May 29 12:47:46 localhost kernel: ata2.00: ata_hpa_resize: sectors = 
625142448, hpa_sectors = 625142448

May 29 12:47:47 localhost kernel: ata2.00: configured for UDMA/133
May 29 12:47:47 localhost kernel: ata2: EH pending after completion, 
repeating EH (cnt=4)

May 29 12

Re: MCP55 NCQ problem?

[Zoltan Boszormenyi]

Zoltan Boszormenyi írta:

Hi,

Peer Chen írta:

Zoltan,
What's your board's model number? Could you post the pci dump using 
'lspci -xxx'? Thanks.



BRs
Peer Chen

-Original Message-
From: Robert Hancock [mailto:[EMAIL PROTECTED] Sent: Thursday, May 
31, 2007 10:31 PM

To: Zoltan Boszormenyi
Cc: linux-kernel; Peer Chen; Kuan Luo
Subject: Re: MCP55 NCQ problem?

CCing Peer Chen and Kuan Luo from NVIDIA..

Looks like there were some unrecognized FIS errors from the 
controller in there?


Zoltan Boszormenyi wrote:
 

Hi,

I just got this with 2.6.22-rc2 + cfs-v13 + swncq patch:

ata2.00: exception Emask 0x0 SAct 0x6 SErr 0x0 action 0x2 frozen
ata2.00: cmd 61/18:08:0f:b7:68/00:00:16:00:00/40 tag 1 cdb 0x0 data 
12288 out

res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata2.00: cmd 61/18:10:7f:b7:68/00:00:16:00:00/40 tag 2 cdb 0x0 data 
12288 out

res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata2: hard resetting port
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata2.00: ata_hpa_resize 1: sectors = 625142448, hpa_sectors = 625142448
ata2.00: ata_hpa_resize 1: sectors = 625142448, hpa_sectors = 625142448
ata2.00: configured for UDMA/133
ata2: EH pending after completion, repeating EH (cnt=4)
ata2: EH complete
sd 1:0:0:0: [sdb] 625142448 512-byte hardware sectors (320073 MB)
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't 
support DPO or FUA


At the time I was creating a DVD ISO image (reads and writes went to 
the disk
that was resetted), browsing mail in thunderbird which also 
exercised the same

disk and I was downloading another ISO with about 400-450 kB/sec to
another disk. Here are the disks in question:

scsi 0:0:0:0: Direct-Access ATA  SAMSUNG HD160JJ  WU10 PQ: 0 
ANSI: 5
scsi 1:0:0:0: Direct-Access ATA  ST3320620AS  3.AA PQ: 0 
ANSI: 5


I got almost the same yesterday with 2.6.22-rc2-mm1:

May 29 12:44:20 localhost kernel: ata2.00: exception Emask 0x0 SAct 
0x6 SErr 0x0 action 0x2 frozen
May 29 12:44:20 localhost kernel: ata2.00: cmd 
61/10:08:2f:41:e9/00:00:07:00:00/40 tag 1 cdb 0x0 data 8192 out
May 29 12:44:20 localhost kernel:  res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

May 29 12:44:20 localhost kernel: ata2.00: status: {DRDY }
May 29 12:44:20 localhost kernel: ata2.00: cmd 
61/30:10:8f:42:e9/00:00:07:00:00/40 tag 2 cdb 0x0 data 24576 out
May 29 12:44:20 localhost kernel:  res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

May 29 12:44:20 localhost kernel: ata2.00: status: {DRDY }
May 29 12:44:20 localhost kernel: ata2: hard resetting port
May 29 12:44:21 localhost kernel: ata2: SATA link up 1.5 Gbps 
(SStatus 113 SControl 300)
May 29 12:44:21 localhost kernel: ata2.00: ata_hpa_resize: sectors = 
625142448, hpa_sectors = 625142448
May 29 12:44:21 localhost kernel: ata2.00: ata_hpa_resize: sectors = 
625142448, hpa_sectors = 625142448

May 29 12:44:21 localhost kernel: ata2.00: configured for UDMA/133
May 29 12:44:21 localhost kernel: ata2: EH pending after completion, 
repeating EH (cnt=4)

May 29 12:44:21 localhost kernel: ata2: EH complete
May 29 12:44:21 localhost kernel: sd 1:0:0:0: [sdb] 625142448 
512-byte hardware sectors (320073 MB)
May 29 12:44:21 localhost kernel: sd 1:0:0:0: [sdb] Write Protect is 
off
May 29 12:44:21 localhost kernel: sd 1:0:0:0: [sdb] Write cache: 
enabled, read cache: enabled, doesn't support DPO or FUA

..
May 29 12:47:46 localhost kernel: ata2.00: exception Emask 0x0 SAct 
0x7 SErr 0x0 action 0x2 frozen
May 29 12:47:46 localhost kernel: ata2.00: cmd 
61/08:00:27:5a:eb/00:00:07:00:00/40 tag 0 cdb 0x0 data 4096 out
May 29 12:47:46 localhost kernel:  res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

May 29 12:47:46 localhost kernel: ata2.00: status: {DRDY }
May 29 12:47:46 localhost kernel: ata2.00: cmd 
61/08:08:bf:61:9e/00:00:0f:00:00/40 tag 1 cdb 0x0 data 4096 out
May 29 12:47:46 localhost kernel:  res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

May 29 12:47:46 localhost kernel: ata2.00: status: {DRDY }
May 29 12:47:46 localhost kernel: ata2.00: cmd 
61/20:10:97:5a:eb/00:00:07:00:00/40 tag 2 cdb 0x0 data 16384 out
May 29 12:47:46 localhost kernel:  res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

May 29 12:47:46 localhost kernel: ata2.00: status: {DRDY }
May 29 12:47:46 localhost kernel: ata2: hard resetting port
May 29 12:47:46 localhost kernel: ata2: SATA link up 1.5 Gbps 
(SStatus 113 SControl 300)
May 29 12:47:46 localhost kernel: ata2.00: ata_hpa_resize: sectors = 
625142448, hpa_sectors = 625142448
May 29 12:47:46 localhost kernel: ata2.00: ata_hpa_resize: sectors = 
625142448, hpa_sectors = 625142448

May 29 12:47:47 localhost kernel: ata2.00: configured for UDMA/133
May 29 12:47:47 localhost kernel: ata2: EH pending after completion, 
repeating EH (cnt=4)

May 29 12

Re: 2.6.22-rc3-mm1

[Zoltan Boszormenyi]

Hi!


-drivers-ata-add-sw-ncq-support-to-sata_nv-for-mcp51-mcp55-mcp61.patch
-drivers-ata-add-sw-ncq-support-to-sata_nv-for-mcp51-mcp55-mcp61-fix.patch
-drivers-ata-add-sw-ncq-support-to-sata_nv-for-mcp51-mcp55-mcp61-fix-tidy.patch

 Merged into mainline or a subsystem tree


They aren't. They are in neither 2.6.22-rc3 nor 2.6.22-rc3-mm1.bz2,
or in any of the broken-out patches, git-* or other.

Best regards,
Zoltán Böszörményi


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

Re: 2.6.22-rc3-mm1

[Zoltan Boszormenyi]

Hi!


-drivers-ata-add-sw-ncq-support-to-sata_nv-for-mcp51-mcp55-mcp61.patch
-drivers-ata-add-sw-ncq-support-to-sata_nv-for-mcp51-mcp55-mcp61-fix.patch
-drivers-ata-add-sw-ncq-support-to-sata_nv-for-mcp51-mcp55-mcp61-fix-tidy.patch

 Merged into mainline or a subsystem tree


They aren't. They are in neither 2.6.22-rc3 nor 2.6.22-rc3-mm1.bz2,
or in any of the broken-out patches, git-* or other.

Best regards,
Zoltán Böszörményi


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

Re: MCP55 NCQ problem?

[Zoltan Boszormenyi]

Hi,

Peer Chen írta:

Zoltan,
What's your board's model number? Could you post the pci dump using 'lspci 
-xxx'? Thanks.


BRs
Peer Chen

-Original Message-
From: Robert Hancock [mailto:[EMAIL PROTECTED] 
Sent: Thursday, May 31, 2007 10:31 PM

To: Zoltan Boszormenyi
Cc: linux-kernel; Peer Chen; Kuan Luo
Subject: Re: MCP55 NCQ problem?

CCing Peer Chen and Kuan Luo from NVIDIA..

Looks like there were some unrecognized FIS errors from the controller 
in there?


Zoltan Boszormenyi wrote:
  

Hi,

I just got this with 2.6.22-rc2 + cfs-v13 + swncq patch:

ata2.00: exception Emask 0x0 SAct 0x6 SErr 0x0 action 0x2 frozen
ata2.00: cmd 61/18:08:0f:b7:68/00:00:16:00:00/40 tag 1 cdb 0x0 data 
12288 out

res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata2.00: cmd 61/18:10:7f:b7:68/00:00:16:00:00/40 tag 2 cdb 0x0 data 
12288 out

res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata2: hard resetting port
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata2.00: ata_hpa_resize 1: sectors = 625142448, hpa_sectors = 625142448
ata2.00: ata_hpa_resize 1: sectors = 625142448, hpa_sectors = 625142448
ata2.00: configured for UDMA/133
ata2: EH pending after completion, repeating EH (cnt=4)
ata2: EH complete
sd 1:0:0:0: [sdb] 625142448 512-byte hardware sectors (320073 MB)
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't 
support DPO or FUA


At the time I was creating a DVD ISO image (reads and writes went to the 
disk
that was resetted), browsing mail in thunderbird which also exercised 
the same

disk and I was downloading another ISO with about 400-450 kB/sec to
another disk. Here are the disks in question:

scsi 0:0:0:0: Direct-Access ATA  SAMSUNG HD160JJ  WU10 PQ: 0 
ANSI: 5
scsi 1:0:0:0: Direct-Access ATA  ST3320620AS  3.AA PQ: 0 
ANSI: 5


I got almost the same yesterday with 2.6.22-rc2-mm1:

May 29 12:44:20 localhost kernel: ata2.00: exception Emask 0x0 SAct 0x6 
SErr 0x0 action 0x2 frozen
May 29 12:44:20 localhost kernel: ata2.00: cmd 
61/10:08:2f:41:e9/00:00:07:00:00/40 tag 1 cdb 0x0 data 8192 out
May 29 12:44:20 localhost kernel:  res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

May 29 12:44:20 localhost kernel: ata2.00: status: {DRDY }
May 29 12:44:20 localhost kernel: ata2.00: cmd 
61/30:10:8f:42:e9/00:00:07:00:00/40 tag 2 cdb 0x0 data 24576 out
May 29 12:44:20 localhost kernel:  res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

May 29 12:44:20 localhost kernel: ata2.00: status: {DRDY }
May 29 12:44:20 localhost kernel: ata2: hard resetting port
May 29 12:44:21 localhost kernel: ata2: SATA link up 1.5 Gbps (SStatus 
113 SControl 300)
May 29 12:44:21 localhost kernel: ata2.00: ata_hpa_resize: sectors = 
625142448, hpa_sectors = 625142448
May 29 12:44:21 localhost kernel: ata2.00: ata_hpa_resize: sectors = 
625142448, hpa_sectors = 625142448

May 29 12:44:21 localhost kernel: ata2.00: configured for UDMA/133
May 29 12:44:21 localhost kernel: ata2: EH pending after completion, 
repeating EH (cnt=4)

May 29 12:44:21 localhost kernel: ata2: EH complete
May 29 12:44:21 localhost kernel: sd 1:0:0:0: [sdb] 625142448 512-byte 
hardware sectors (320073 MB)

May 29 12:44:21 localhost kernel: sd 1:0:0:0: [sdb] Write Protect is off
May 29 12:44:21 localhost kernel: sd 1:0:0:0: [sdb] Write cache: 
enabled, read cache: enabled, doesn't support DPO or FUA

..
May 29 12:47:46 localhost kernel: ata2.00: exception Emask 0x0 SAct 0x7 
SErr 0x0 action 0x2 frozen
May 29 12:47:46 localhost kernel: ata2.00: cmd 
61/08:00:27:5a:eb/00:00:07:00:00/40 tag 0 cdb 0x0 data 4096 out
May 29 12:47:46 localhost kernel:  res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

May 29 12:47:46 localhost kernel: ata2.00: status: {DRDY }
May 29 12:47:46 localhost kernel: ata2.00: cmd 
61/08:08:bf:61:9e/00:00:0f:00:00/40 tag 1 cdb 0x0 data 4096 out
May 29 12:47:46 localhost kernel:  res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

May 29 12:47:46 localhost kernel: ata2.00: status: {DRDY }
May 29 12:47:46 localhost kernel: ata2.00: cmd 
61/20:10:97:5a:eb/00:00:07:00:00/40 tag 2 cdb 0x0 data 16384 out
May 29 12:47:46 localhost kernel:  res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

May 29 12:47:46 localhost kernel: ata2.00: status: {DRDY }
May 29 12:47:46 localhost kernel: ata2: hard resetting port
May 29 12:47:46 localhost kernel: ata2: SATA link up 1.5 Gbps (SStatus 
113 SControl 300)
May 29 12:47:46 localhost kernel: ata2.00: ata_hpa_resize: sectors = 
625142448, hpa_sectors = 625142448
May 29 12:47:46 localhost kernel: ata2.00: ata_hpa_resize: sectors = 
625142448, hpa_sectors = 625142448

May 29 12:47:47 localhost kernel: ata2.00: configured for UDMA/133
May 29 12:47:47 localhost kernel: ata2: EH pending after completion, 
repeating EH (cnt=4)

May 29 12:47:47 localhost kernel

Re: MCP55 NCQ problem?

[Zoltan Boszormenyi]

Hi,

Peer Chen írta:

Zoltan,
What's your board's model number? Could you post the pci dump using 'lspci 
-xxx'? Thanks.


BRs
Peer Chen

-Original Message-
From: Robert Hancock [mailto:[EMAIL PROTECTED] 
Sent: Thursday, May 31, 2007 10:31 PM

To: Zoltan Boszormenyi
Cc: linux-kernel; Peer Chen; Kuan Luo
Subject: Re: MCP55 NCQ problem?

CCing Peer Chen and Kuan Luo from NVIDIA..

Looks like there were some unrecognized FIS errors from the controller 
in there?


Zoltan Boszormenyi wrote:
  

Hi,

I just got this with 2.6.22-rc2 + cfs-v13 + swncq patch:

ata2.00: exception Emask 0x0 SAct 0x6 SErr 0x0 action 0x2 frozen
ata2.00: cmd 61/18:08:0f:b7:68/00:00:16:00:00/40 tag 1 cdb 0x0 data 
12288 out

res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata2.00: cmd 61/18:10:7f:b7:68/00:00:16:00:00/40 tag 2 cdb 0x0 data 
12288 out

res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata2: hard resetting port
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata2.00: ata_hpa_resize 1: sectors = 625142448, hpa_sectors = 625142448
ata2.00: ata_hpa_resize 1: sectors = 625142448, hpa_sectors = 625142448
ata2.00: configured for UDMA/133
ata2: EH pending after completion, repeating EH (cnt=4)
ata2: EH complete
sd 1:0:0:0: [sdb] 625142448 512-byte hardware sectors (320073 MB)
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't 
support DPO or FUA


At the time I was creating a DVD ISO image (reads and writes went to the 
disk
that was resetted), browsing mail in thunderbird which also exercised 
the same

disk and I was downloading another ISO with about 400-450 kB/sec to
another disk. Here are the disks in question:

scsi 0:0:0:0: Direct-Access ATA  SAMSUNG HD160JJ  WU10 PQ: 0 
ANSI: 5
scsi 1:0:0:0: Direct-Access ATA  ST3320620AS  3.AA PQ: 0 
ANSI: 5


I got almost the same yesterday with 2.6.22-rc2-mm1:

May 29 12:44:20 localhost kernel: ata2.00: exception Emask 0x0 SAct 0x6 
SErr 0x0 action 0x2 frozen
May 29 12:44:20 localhost kernel: ata2.00: cmd 
61/10:08:2f:41:e9/00:00:07:00:00/40 tag 1 cdb 0x0 data 8192 out
May 29 12:44:20 localhost kernel:  res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

May 29 12:44:20 localhost kernel: ata2.00: status: {DRDY }
May 29 12:44:20 localhost kernel: ata2.00: cmd 
61/30:10:8f:42:e9/00:00:07:00:00/40 tag 2 cdb 0x0 data 24576 out
May 29 12:44:20 localhost kernel:  res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

May 29 12:44:20 localhost kernel: ata2.00: status: {DRDY }
May 29 12:44:20 localhost kernel: ata2: hard resetting port
May 29 12:44:21 localhost kernel: ata2: SATA link up 1.5 Gbps (SStatus 
113 SControl 300)
May 29 12:44:21 localhost kernel: ata2.00: ata_hpa_resize: sectors = 
625142448, hpa_sectors = 625142448
May 29 12:44:21 localhost kernel: ata2.00: ata_hpa_resize: sectors = 
625142448, hpa_sectors = 625142448

May 29 12:44:21 localhost kernel: ata2.00: configured for UDMA/133
May 29 12:44:21 localhost kernel: ata2: EH pending after completion, 
repeating EH (cnt=4)

May 29 12:44:21 localhost kernel: ata2: EH complete
May 29 12:44:21 localhost kernel: sd 1:0:0:0: [sdb] 625142448 512-byte 
hardware sectors (320073 MB)

May 29 12:44:21 localhost kernel: sd 1:0:0:0: [sdb] Write Protect is off
May 29 12:44:21 localhost kernel: sd 1:0:0:0: [sdb] Write cache: 
enabled, read cache: enabled, doesn't support DPO or FUA

..
May 29 12:47:46 localhost kernel: ata2.00: exception Emask 0x0 SAct 0x7 
SErr 0x0 action 0x2 frozen
May 29 12:47:46 localhost kernel: ata2.00: cmd 
61/08:00:27:5a:eb/00:00:07:00:00/40 tag 0 cdb 0x0 data 4096 out
May 29 12:47:46 localhost kernel:  res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

May 29 12:47:46 localhost kernel: ata2.00: status: {DRDY }
May 29 12:47:46 localhost kernel: ata2.00: cmd 
61/08:08:bf:61:9e/00:00:0f:00:00/40 tag 1 cdb 0x0 data 4096 out
May 29 12:47:46 localhost kernel:  res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

May 29 12:47:46 localhost kernel: ata2.00: status: {DRDY }
May 29 12:47:46 localhost kernel: ata2.00: cmd 
61/20:10:97:5a:eb/00:00:07:00:00/40 tag 2 cdb 0x0 data 16384 out
May 29 12:47:46 localhost kernel:  res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

May 29 12:47:46 localhost kernel: ata2.00: status: {DRDY }
May 29 12:47:46 localhost kernel: ata2: hard resetting port
May 29 12:47:46 localhost kernel: ata2: SATA link up 1.5 Gbps (SStatus 
113 SControl 300)
May 29 12:47:46 localhost kernel: ata2.00: ata_hpa_resize: sectors = 
625142448, hpa_sectors = 625142448
May 29 12:47:46 localhost kernel: ata2.00: ata_hpa_resize: sectors = 
625142448, hpa_sectors = 625142448

May 29 12:47:47 localhost kernel: ata2.00: configured for UDMA/133
May 29 12:47:47 localhost kernel: ata2: EH pending after completion, 
repeating EH (cnt=4)

May 29 12:47:47 localhost kernel

Re: Kernel 2.6.21.3 does not work with 8GB of RAM on Intel 965WH

[Zoltan Boszormenyi]

Justin Piszcz írta:



On Wed, 30 May 2007, Zoltan Boszormenyi wrote:


Hi,


Look at how slow the raid benchmarks are in dmesg with 8GB of memory!

[   59.592560] raid6: using algorithm sse2x4 (476 MB/s)
[   59.597558] raid5: using function: generic_sse (56.000 MB/sec)

Yikes!

With mem=4096M:
[   60.336352] raid6: using algorithm sse2x4 (6804 MB/s)
[   60.341345] raid5: using function: generic_sse (8552.000 MB/sec)

What is going on here?

Justin.


I saw a similar effect on a P5 board that could
only cache 64MB of memory a long time ago.
Putting more memory into it made the machine slower
and e.g. made the sym2 driver giving up at initialization.
Maybe it's a modern reincarnation of the problem?

Best regards,
Zoltán Böszörményi



I see, so Intel 965 motherboards do not work with 8GB of memory?  Or 
is this a Linux issue?


It was certainly a mainboard problem, the same system worked well
on another board with a more capable L2 cache controller.
Or on PPro/P-II boards.

I have an Intel Case ID open 225446 but so far we have not gotten 
anywhere with this problem.  Currently I have 8GB in the machine and 
boot with mem=4096M.  Was there any type of fix?  Any recommendations 
as to what I can do?  Continue to speak with Intel?  Or perhaps 
someone with more knowledge of the kernel and chime in as to what 
exactly is happening here?


Justin.


I think continue to talk Intel and with the kernel guys,
I don't have experience with machines with so much memory (yet).

Best regards,
Zoltán Böszörményi

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

Re: Kernel 2.6.21.3 does not work with 8GB of RAM on Intel 965WH

[Zoltan Boszormenyi]

Hi,


Look at how slow the raid benchmarks are in dmesg with 8GB of memory!

[   59.592560] raid6: using algorithm sse2x4 (476 MB/s)
[   59.597558] raid5: using function: generic_sse (56.000 MB/sec)

Yikes!

With mem=4096M:
[   60.336352] raid6: using algorithm sse2x4 (6804 MB/s)
[   60.341345] raid5: using function: generic_sse (8552.000 MB/sec)

What is going on here?

Justin.


I saw a similar effect on a P5 board that could
only cache 64MB of memory a long time ago.
Putting more memory into it made the machine slower
and e.g. made the sym2 driver giving up at initialization.
Maybe it's a modern reincarnation of the problem?

Best regards,
Zoltán Böszörményi

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

MCP55 NCQ problem?

[Zoltan Boszormenyi]

Hi,

I just got this with 2.6.22-rc2 + cfs-v13 + swncq patch:

ata2.00: exception Emask 0x0 SAct 0x6 SErr 0x0 action 0x2 frozen
ata2.00: cmd 61/18:08:0f:b7:68/00:00:16:00:00/40 tag 1 cdb 0x0 data 
12288 out

res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata2.00: cmd 61/18:10:7f:b7:68/00:00:16:00:00/40 tag 2 cdb 0x0 data 
12288 out

res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata2: hard resetting port
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata2.00: ata_hpa_resize 1: sectors = 625142448, hpa_sectors = 625142448
ata2.00: ata_hpa_resize 1: sectors = 625142448, hpa_sectors = 625142448
ata2.00: configured for UDMA/133
ata2: EH pending after completion, repeating EH (cnt=4)
ata2: EH complete
sd 1:0:0:0: [sdb] 625142448 512-byte hardware sectors (320073 MB)
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't 
support DPO or FUA


At the time I was creating a DVD ISO image (reads and writes went to the 
disk
that was resetted), browsing mail in thunderbird which also exercised 
the same

disk and I was downloading another ISO with about 400-450 kB/sec to
another disk. Here are the disks in question:

scsi 0:0:0:0: Direct-Access ATA  SAMSUNG HD160JJ  WU10 PQ: 0 ANSI: 5
scsi 1:0:0:0: Direct-Access ATA  ST3320620AS  3.AA PQ: 0 ANSI: 5

I got almost the same yesterday with 2.6.22-rc2-mm1:

May 29 12:44:20 localhost kernel: ata2.00: exception Emask 0x0 SAct 0x6 
SErr 0x0 action 0x2 frozen
May 29 12:44:20 localhost kernel: ata2.00: cmd 
61/10:08:2f:41:e9/00:00:07:00:00/40 tag 1 cdb 0x0 data 8192 out
May 29 12:44:20 localhost kernel:  res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

May 29 12:44:20 localhost kernel: ata2.00: status: {DRDY }
May 29 12:44:20 localhost kernel: ata2.00: cmd 
61/30:10:8f:42:e9/00:00:07:00:00/40 tag 2 cdb 0x0 data 24576 out
May 29 12:44:20 localhost kernel:  res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

May 29 12:44:20 localhost kernel: ata2.00: status: {DRDY }
May 29 12:44:20 localhost kernel: ata2: hard resetting port
May 29 12:44:21 localhost kernel: ata2: SATA link up 1.5 Gbps (SStatus 
113 SControl 300)
May 29 12:44:21 localhost kernel: ata2.00: ata_hpa_resize: sectors = 
625142448, hpa_sectors = 625142448
May 29 12:44:21 localhost kernel: ata2.00: ata_hpa_resize: sectors = 
625142448, hpa_sectors = 625142448

May 29 12:44:21 localhost kernel: ata2.00: configured for UDMA/133
May 29 12:44:21 localhost kernel: ata2: EH pending after completion, 
repeating EH (cnt=4)

May 29 12:44:21 localhost kernel: ata2: EH complete
May 29 12:44:21 localhost kernel: sd 1:0:0:0: [sdb] 625142448 512-byte 
hardware sectors (320073 MB)

May 29 12:44:21 localhost kernel: sd 1:0:0:0: [sdb] Write Protect is off
May 29 12:44:21 localhost kernel: sd 1:0:0:0: [sdb] Write cache: 
enabled, read cache: enabled, doesn't support DPO or FUA

...
May 29 12:47:46 localhost kernel: ata2.00: exception Emask 0x0 SAct 0x7 
SErr 0x0 action 0x2 frozen
May 29 12:47:46 localhost kernel: ata2.00: cmd 
61/08:00:27:5a:eb/00:00:07:00:00/40 tag 0 cdb 0x0 data 4096 out
May 29 12:47:46 localhost kernel:  res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

May 29 12:47:46 localhost kernel: ata2.00: status: {DRDY }
May 29 12:47:46 localhost kernel: ata2.00: cmd 
61/08:08:bf:61:9e/00:00:0f:00:00/40 tag 1 cdb 0x0 data 4096 out
May 29 12:47:46 localhost kernel:  res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

May 29 12:47:46 localhost kernel: ata2.00: status: {DRDY }
May 29 12:47:46 localhost kernel: ata2.00: cmd 
61/20:10:97:5a:eb/00:00:07:00:00/40 tag 2 cdb 0x0 data 16384 out
May 29 12:47:46 localhost kernel:  res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

May 29 12:47:46 localhost kernel: ata2.00: status: {DRDY }
May 29 12:47:46 localhost kernel: ata2: hard resetting port
May 29 12:47:46 localhost kernel: ata2: SATA link up 1.5 Gbps (SStatus 
113 SControl 300)
May 29 12:47:46 localhost kernel: ata2.00: ata_hpa_resize: sectors = 
625142448, hpa_sectors = 625142448
May 29 12:47:46 localhost kernel: ata2.00: ata_hpa_resize: sectors = 
625142448, hpa_sectors = 625142448

May 29 12:47:47 localhost kernel: ata2.00: configured for UDMA/133
May 29 12:47:47 localhost kernel: ata2: EH pending after completion, 
repeating EH (cnt=4)

May 29 12:47:47 localhost kernel: ata2: EH complete
May 29 12:47:47 localhost kernel: sd 1:0:0:0: [sdb] 625142448 512-byte 
hardware sectors (320073 MB)

May 29 12:47:47 localhost kernel: sd 1:0:0:0: [sdb] Write Protect is off
May 29 12:47:47 localhost kernel: sd 1:0:0:0: [sdb] Write cache: 
enabled, read cache: enabled, doesn't support DPO or FUA
May 29 12:49:23 localhost kernel: ata2.00: exception Emask 0x0 SAct 0x6 
SErr 0x200 action 0x2 frozen

May 29 12:49:23 localhost kernel: ata2: SError: {UnrecFIS }
May 29 12:49:23 localhost 

MCP55 NCQ problem?

[Zoltan Boszormenyi]

Hi,

I just got this with 2.6.22-rc2 + cfs-v13 + swncq patch:

ata2.00: exception Emask 0x0 SAct 0x6 SErr 0x0 action 0x2 frozen
ata2.00: cmd 61/18:08:0f:b7:68/00:00:16:00:00/40 tag 1 cdb 0x0 data 
12288 out

res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata2.00: cmd 61/18:10:7f:b7:68/00:00:16:00:00/40 tag 2 cdb 0x0 data 
12288 out

res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata2: hard resetting port
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata2.00: ata_hpa_resize 1: sectors = 625142448, hpa_sectors = 625142448
ata2.00: ata_hpa_resize 1: sectors = 625142448, hpa_sectors = 625142448
ata2.00: configured for UDMA/133
ata2: EH pending after completion, repeating EH (cnt=4)
ata2: EH complete
sd 1:0:0:0: [sdb] 625142448 512-byte hardware sectors (320073 MB)
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't 
support DPO or FUA


At the time I was creating a DVD ISO image (reads and writes went to the 
disk
that was resetted), browsing mail in thunderbird which also exercised 
the same

disk and I was downloading another ISO with about 400-450 kB/sec to
another disk. Here are the disks in question:

scsi 0:0:0:0: Direct-Access ATA  SAMSUNG HD160JJ  WU10 PQ: 0 ANSI: 5
scsi 1:0:0:0: Direct-Access ATA  ST3320620AS  3.AA PQ: 0 ANSI: 5

I got almost the same yesterday with 2.6.22-rc2-mm1:

May 29 12:44:20 localhost kernel: ata2.00: exception Emask 0x0 SAct 0x6 
SErr 0x0 action 0x2 frozen
May 29 12:44:20 localhost kernel: ata2.00: cmd 
61/10:08:2f:41:e9/00:00:07:00:00/40 tag 1 cdb 0x0 data 8192 out
May 29 12:44:20 localhost kernel:  res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

May 29 12:44:20 localhost kernel: ata2.00: status: {DRDY }
May 29 12:44:20 localhost kernel: ata2.00: cmd 
61/30:10:8f:42:e9/00:00:07:00:00/40 tag 2 cdb 0x0 data 24576 out
May 29 12:44:20 localhost kernel:  res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

May 29 12:44:20 localhost kernel: ata2.00: status: {DRDY }
May 29 12:44:20 localhost kernel: ata2: hard resetting port
May 29 12:44:21 localhost kernel: ata2: SATA link up 1.5 Gbps (SStatus 
113 SControl 300)
May 29 12:44:21 localhost kernel: ata2.00: ata_hpa_resize: sectors = 
625142448, hpa_sectors = 625142448
May 29 12:44:21 localhost kernel: ata2.00: ata_hpa_resize: sectors = 
625142448, hpa_sectors = 625142448

May 29 12:44:21 localhost kernel: ata2.00: configured for UDMA/133
May 29 12:44:21 localhost kernel: ata2: EH pending after completion, 
repeating EH (cnt=4)

May 29 12:44:21 localhost kernel: ata2: EH complete
May 29 12:44:21 localhost kernel: sd 1:0:0:0: [sdb] 625142448 512-byte 
hardware sectors (320073 MB)

May 29 12:44:21 localhost kernel: sd 1:0:0:0: [sdb] Write Protect is off
May 29 12:44:21 localhost kernel: sd 1:0:0:0: [sdb] Write cache: 
enabled, read cache: enabled, doesn't support DPO or FUA

...
May 29 12:47:46 localhost kernel: ata2.00: exception Emask 0x0 SAct 0x7 
SErr 0x0 action 0x2 frozen
May 29 12:47:46 localhost kernel: ata2.00: cmd 
61/08:00:27:5a:eb/00:00:07:00:00/40 tag 0 cdb 0x0 data 4096 out
May 29 12:47:46 localhost kernel:  res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

May 29 12:47:46 localhost kernel: ata2.00: status: {DRDY }
May 29 12:47:46 localhost kernel: ata2.00: cmd 
61/08:08:bf:61:9e/00:00:0f:00:00/40 tag 1 cdb 0x0 data 4096 out
May 29 12:47:46 localhost kernel:  res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

May 29 12:47:46 localhost kernel: ata2.00: status: {DRDY }
May 29 12:47:46 localhost kernel: ata2.00: cmd 
61/20:10:97:5a:eb/00:00:07:00:00/40 tag 2 cdb 0x0 data 16384 out
May 29 12:47:46 localhost kernel:  res 
40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

May 29 12:47:46 localhost kernel: ata2.00: status: {DRDY }
May 29 12:47:46 localhost kernel: ata2: hard resetting port
May 29 12:47:46 localhost kernel: ata2: SATA link up 1.5 Gbps (SStatus 
113 SControl 300)
May 29 12:47:46 localhost kernel: ata2.00: ata_hpa_resize: sectors = 
625142448, hpa_sectors = 625142448
May 29 12:47:46 localhost kernel: ata2.00: ata_hpa_resize: sectors = 
625142448, hpa_sectors = 625142448

May 29 12:47:47 localhost kernel: ata2.00: configured for UDMA/133
May 29 12:47:47 localhost kernel: ata2: EH pending after completion, 
repeating EH (cnt=4)

May 29 12:47:47 localhost kernel: ata2: EH complete
May 29 12:47:47 localhost kernel: sd 1:0:0:0: [sdb] 625142448 512-byte 
hardware sectors (320073 MB)

May 29 12:47:47 localhost kernel: sd 1:0:0:0: [sdb] Write Protect is off
May 29 12:47:47 localhost kernel: sd 1:0:0:0: [sdb] Write cache: 
enabled, read cache: enabled, doesn't support DPO or FUA
May 29 12:49:23 localhost kernel: ata2.00: exception Emask 0x0 SAct 0x6 
SErr 0x200 action 0x2 frozen

May 29 12:49:23 localhost kernel: ata2: SError: {UnrecFIS }
May 29 12:49:23 localhost 

Re: Kernel 2.6.21.3 does not work with 8GB of RAM on Intel 965WH

[Zoltan Boszormenyi]

Hi,


Look at how slow the raid benchmarks are in dmesg with 8GB of memory!

[   59.592560] raid6: using algorithm sse2x4 (476 MB/s)
[   59.597558] raid5: using function: generic_sse (56.000 MB/sec)

Yikes!

With mem=4096M:
[   60.336352] raid6: using algorithm sse2x4 (6804 MB/s)
[   60.341345] raid5: using function: generic_sse (8552.000 MB/sec)

What is going on here?

Justin.


I saw a similar effect on a P5 board that could
only cache 64MB of memory a long time ago.
Putting more memory into it made the machine slower
and e.g. made the sym2 driver giving up at initialization.
Maybe it's a modern reincarnation of the problem?

Best regards,
Zoltán Böszörményi

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

Re: Kernel 2.6.21.3 does not work with 8GB of RAM on Intel 965WH

[Zoltan Boszormenyi]

Justin Piszcz írta:



On Wed, 30 May 2007, Zoltan Boszormenyi wrote:


Hi,


Look at how slow the raid benchmarks are in dmesg with 8GB of memory!

[   59.592560] raid6: using algorithm sse2x4 (476 MB/s)
[   59.597558] raid5: using function: generic_sse (56.000 MB/sec)

Yikes!

With mem=4096M:
[   60.336352] raid6: using algorithm sse2x4 (6804 MB/s)
[   60.341345] raid5: using function: generic_sse (8552.000 MB/sec)

What is going on here?

Justin.


I saw a similar effect on a P5 board that could
only cache 64MB of memory a long time ago.
Putting more memory into it made the machine slower
and e.g. made the sym2 driver giving up at initialization.
Maybe it's a modern reincarnation of the problem?

Best regards,
Zoltán Böszörményi



I see, so Intel 965 motherboards do not work with 8GB of memory?  Or 
is this a Linux issue?


It was certainly a mainboard problem, the same system worked well
on another board with a more capable L2 cache controller.
Or on PPro/P-II boards.

I have an Intel Case ID open 225446 but so far we have not gotten 
anywhere with this problem.  Currently I have 8GB in the machine and 
boot with mem=4096M.  Was there any type of fix?  Any recommendations 
as to what I can do?  Continue to speak with Intel?  Or perhaps 
someone with more knowledge of the kernel and chime in as to what 
exactly is happening here?


Justin.


I think continue to talk Intel and with the kernel guys,
I don't have experience with machines with so much memory (yet).

Best regards,
Zoltán Böszörményi

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

Re: [PATCH] drivers/ata: Add the SW NCQ support to sata_nv for MCP51/MCP55/MCP61

[Zoltan Boszormenyi]

Hi,

Jeff Garzik írta:

Alan Cox wrote:
That shouldn't be a problem, libata default DMA mask is 32 bits 
(which isn't overridden with this controller) and so the block layer 
will bounce any data being read/written above that point with IOMMU 
or swiotlb. The comment is a bit unnecessarily scary.


Adding a BUG_ON for this would be wise. Its trivial to check and a BUG
rather than corruption if this assumption ever changes would be far
preferable


The default DMA mask -everywhere- is 32 bits.

A lot of code will break if this assumption ever changes, not just 
libata.


Jeff


thanks for clarifying this.

I tested the effect of this patch on 2.6.22-rc2 + CFS-v13
with the current CVS version of PostgreSQL 8.3devel.
pgbench with 25 clients and some large number of
transactions to make the result stable showed substantial
increase in throughput. Without NCQ, I got around 446 tps,
with NCQ I got around 680 via local TCP connection.
Previously, I got this level of performance only over
local unix socket and smaller number of simultaneous clients.
The disk is Seagate 320GB (ST3320620AS).

Again, thanks for this patch.

Best regards,
Zoltán Böszörményi

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

Re: [PATCH] drivers/ata: Add the SW NCQ support to sata_nv for MCP51/MCP55/MCP61

[Zoltan Boszormenyi]

Hi,

Jeff Garzik írta:

Alan Cox wrote:
That shouldn't be a problem, libata default DMA mask is 32 bits 
(which isn't overridden with this controller) and so the block layer 
will bounce any data being read/written above that point with IOMMU 
or swiotlb. The comment is a bit unnecessarily scary.


Adding a BUG_ON for this would be wise. Its trivial to check and a BUG
rather than corruption if this assumption ever changes would be far
preferable


The default DMA mask -everywhere- is 32 bits.

A lot of code will break if this assumption ever changes, not just 
libata.


Jeff


thanks for clarifying this.

I tested the effect of this patch on 2.6.22-rc2 + CFS-v13
with the current CVS version of PostgreSQL 8.3devel.
pgbench with 25 clients and some large number of
transactions to make the result stable showed substantial
increase in throughput. Without NCQ, I got around 446 tps,
with NCQ I got around 680 via local TCP connection.
Previously, I got this level of performance only over
local unix socket and smaller number of simultaneous clients.
The disk is Seagate 320GB (ST3320620AS).

Again, thanks for this patch.

Best regards,
Zoltán Böszörményi

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

Re: [PATCH] drivers/ata: Add the SW NCQ support to sata_nv for MCP51/MCP55/MCP61

[Zoltan Boszormenyi]

Hi,

thanks for publishing this.


Add the Software NCQ support to sata_nv.c for MCP51/MCP55/MCP61 SATA
controller.

This patch base on sata_nv.c file from kernel 2.6.22-rc1

See attachment for the patch.

Signed-off-by: Kuan Luo <[EMAIL PROTECTED]>
Signed-off-by: Peer Chen <[EMAIL PROTECTED]>
==
See attached file.
==
  


However, I saw this in the patch:

+   /* determine if physical DMA addr spans 64K boundary.
+* Note h/w doesn't support 64-bit, so we unconditionally
+* truncate dma_addr_t to u32.
+*/
+   addr = (u32) sg_dma_address(sg);

Does it mean that I can't upgrade my machine to 4 GB or more
without losing NCQ or risking data corruption?
Can the code be made IOMMU-aware?

Best regards,
Zoltán Böszörményi

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

Re: [PATCH] drivers/ata: Add the SW NCQ support to sata_nv for MCP51/MCP55/MCP61

[Zoltan Boszormenyi]

Hi,

thanks for publishing this.


Add the Software NCQ support to sata_nv.c for MCP51/MCP55/MCP61 SATA
controller.

This patch base on sata_nv.c file from kernel 2.6.22-rc1

See attachment for the patch.

Signed-off-by: Kuan Luo [EMAIL PROTECTED]
Signed-off-by: Peer Chen [EMAIL PROTECTED]
==
See attached file.
==
  


However, I saw this in the patch:

+   /* determine if physical DMA addr spans 64K boundary.
+* Note h/w doesn't support 64-bit, so we unconditionally
+* truncate dma_addr_t to u32.
+*/
+   addr = (u32) sg_dma_address(sg);

Does it mean that I can't upgrade my machine to 4 GB or more
without losing NCQ or risking data corruption?
Can the code be made IOMMU-aware?

Best regards,
Zoltán Böszörményi

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

Re: [patch] CFS scheduler, -v8

[Zoltan Boszormenyi]

Hi!


*** Balbir Singh <[EMAIL PROTECTED]> wrote:

> The problem is with comparing a s64 values with (s64)ULONG_MAX, which 
> evaluates to -1. Then we check if exec_delta64 and fair_delta64 are 
> greater than (s64)ULONG_MAX (-1), if so we assign (s64)ULONG_MAX to 
> the respective values.


ah, indeed ...

> The fix is to compare these values against (s64)LONG_MAX and assign 
> (s64)LONG_MAX to exec_delta64 and fair_delta64 if they are greater 
> than (s64)LONG_MAX.
> 
> Tested on PowerPC, the regression is gone, tasks are load balanced as 
> they were in v7.


thanks, applied!

Ingo


I started up 12 glxgears to see the effect of CFS v8
on my Athlon64 X2 4200.

Without this patch all the GL load was handled by the second core,
the system only stressed the first core if other processes were also
started, i.e. a kernel compilation. With this patch  the load is evenly
balanced across the two cores all the time. And while doing make -j4
on the kernel, the 12 gears are still spinning about 185+ FPS and
there are only slightly visible hiccups. Switching between workspaces,
i.e. refreshing the large windows of Thunderbird and Firefox are
done very quickly, the whole system is exceptionally responsive.

Thanks for this great work!

Best regards,
Zoltán Böszörményi

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

Re: [patch] CFS scheduler, -v8

[Zoltan Boszormenyi]

Hi!


*** Balbir Singh [EMAIL PROTECTED] wrote:

 The problem is with comparing a s64 values with (s64)ULONG_MAX, which 
 evaluates to -1. Then we check if exec_delta64 and fair_delta64 are 
 greater than (s64)ULONG_MAX (-1), if so we assign (s64)ULONG_MAX to 
 the respective values.


ah, indeed ...

 The fix is to compare these values against (s64)LONG_MAX and assign 
 (s64)LONG_MAX to exec_delta64 and fair_delta64 if they are greater 
 than (s64)LONG_MAX.
 
 Tested on PowerPC, the regression is gone, tasks are load balanced as 
 they were in v7.


thanks, applied!

Ingo


I started up 12 glxgears to see the effect of CFS v8
on my Athlon64 X2 4200.

Without this patch all the GL load was handled by the second core,
the system only stressed the first core if other processes were also
started, i.e. a kernel compilation. With this patch  the load is evenly
balanced across the two cores all the time. And while doing make -j4
on the kernel, the 12 gears are still spinning about 185+ FPS and
there are only slightly visible hiccups. Switching between workspaces,
i.e. refreshing the large windows of Thunderbird and Firefox are
done very quickly, the whole system is exceptionally responsive.

Thanks for this great work!

Best regards,
Zoltán Böszörményi

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

Re: Nvidia nForce5 NCQ support status?

[Zoltan Boszormenyi]

Hi,


Hello list,

I was wondering what has happened with the NCQ support for nForce5 chipsets? 
I've got one (on an Abit KN9-SLI), and I've found no further mentions about 
it for a while.


Kind regards,

Jan
  


I asked about it almost two months ago on this list, a month before that
in private, never got an answer. The promise we got from Allen Martin
from NVidia will be 7 months old on 10th May:
http://marc.theaimsgroup.com/?l=linux-kernel=116046278930988=2

BTW I have the same motherboard, I had to upgrade the BIOS
to v18 to have a stable forcedeth and USB keyboard.

Best regards,
Zoltán Böszörményi

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

Re: Nvidia nForce5 NCQ support status?

[Zoltan Boszormenyi]

Hi,


Hello list,

I was wondering what has happened with the NCQ support for nForce5 chipsets? 
I've got one (on an Abit KN9-SLI), and I've found no further mentions about 
it for a while.


Kind regards,

Jan
  


I asked about it almost two months ago on this list, a month before that
in private, never got an answer. The promise we got from Allen Martin
from NVidia will be 7 months old on 10th May:
http://marc.theaimsgroup.com/?l=linux-kernelm=116046278930988w=2

BTW I have the same motherboard, I had to upgrade the BIOS
to v18 to have a stable forcedeth and USB keyboard.

Best regards,
Zoltán Böszörményi

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

How soon is soon? MCP55 NCQ support on Linux...

[Zoltan Boszormenyi]

Hi,

I have seen your message in LKML archive:
http://marc.theaimsgroup.com/?l=linux-kernel=116046278930988=2
It's dated 2006.10.10 and states that a patch
to support NCQ on MCP55/MCP61 under Linux
is coming "soon". Now it's five months later
and I would like to ask when will it be supported?
Especially when this seems to be the last NVidia chipset
that has NCQ but isn't supported under Linux.

Thanks in advance,
Zoltán Böszörményi

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

How soon is soon? MCP55 NCQ support on Linux...

[Zoltan Boszormenyi]

Hi,

I have seen your message in LKML archive:
http://marc.theaimsgroup.com/?l=linux-kernelm=116046278930988w=2
It's dated 2006.10.10 and states that a patch
to support NCQ on MCP55/MCP61 under Linux
is coming soon. Now it's five months later
and I would like to ask when will it be supported?
Especially when this seems to be the last NVidia chipset
that has NCQ but isn't supported under Linux.

Thanks in advance,
Zoltán Böszörményi

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

BUG in kernel-rt 2.6.20-0119.rt8

[Zoltan Boszormenyi]

Hi,

I am using kernel-rt on my FC6/x86-64 system,
the CPU is an Athlon64 X2.

It locks up very rarely (I haven't found any sign in the logs for that)
but I always get this on shutdown, I wonder if it might be related
to the lockup:

Mar  5 23:53:52 static-81-17-177-202 kernel: BUG: using 
smp_processor_id() in preemptible [] code: nfsd/3939
Mar  5 23:53:52 static-81-17-177-202 kernel: caller is 
drain_array+0x25/0x132

Mar  5 23:53:52 static-81-17-177-202 kernel:
Mar  5 23:53:52 static-81-17-177-202 kernel: Call Trace:
Mar  5 23:53:52 static-81-17-177-202 kernel:  [] 
dump_trace+0xbd/0x3d8
Mar  5 23:53:52 static-81-17-177-202 kernel:  [] 
show_trace+0x44/0x6d
Mar  5 23:53:52 static-81-17-177-202 kernel:  [] 
dump_stack+0x13/0x15
Mar  5 23:53:52 static-81-17-177-202 kernel:  [] 
debug_smp_processor_id+0xe3/0xf1
Mar  5 23:53:52 static-81-17-177-202 kernel:  [] 
drain_array+0x25/0x132
Mar  5 23:53:52 static-81-17-177-202 kernel:  [] 
__cache_shrink+0xd5/0x1a6
Mar  5 23:53:52 static-81-17-177-202 kernel:  [] 
kmem_cache_destroy+0x6c/0xe3
Mar  5 23:53:52 static-81-17-177-202 kernel:  [] 
:nfsd:nfsd4_free_slab+0x16/0x21
Mar  5 23:53:52 static-81-17-177-202 kernel:  [] 
:nfsd:nfsd4_free_slabs+0x10/0x36
Mar  5 23:53:52 static-81-17-177-202 kernel:  [] 
:nfsd:nfs4_state_shutdown+0x1a2/0x1ae
Mar  5 23:53:52 static-81-17-177-202 kernel:  [] 
:nfsd:nfsd_last_thread+0x47/0x76
Mar  5 23:53:52 static-81-17-177-202 kernel:  [] 
:sunrpc:svc_destroy+0x8d/0xd1
Mar  5 23:53:52 static-81-17-177-202 kernel:  [] 
:sunrpc:svc_exit_thread+0xba/0xc6
Mar  5 23:53:52 static-81-17-177-202 kernel:  [] 
:nfsd:nfsd+0x2a3/0x2b8
Mar  5 23:53:52 static-81-17-177-202 kernel:  [] 
child_rip+0xa/0x12

Mar  5 23:53:52 static-81-17-177-202 kernel:
Mar  5 23:53:52 static-81-17-177-202 kernel: ---
Mar  5 23:53:52 static-81-17-177-202 kernel: | preempt count: 0001 ]
Mar  5 23:53:52 static-81-17-177-202 kernel: | 1-level deep critical 
section nesting:
Mar  5 23:53:52 static-81-17-177-202 kernel: 

Mar  5 23:53:52 static-81-17-177-202 kernel: .. [] 
 debug_smp_processor_id+0x90/0xf1
Mar  5 23:53:52 static-81-17-177-202 kernel: .[] 
..   ( <= drain_array+0x25/0x132)

Mar  5 23:53:52 static-81-17-177-202 kernel:
Mar  5 23:53:52 static-81-17-177-202 kernel: BUG: nfsd:3939 task might 
have lost a preemption check!

Mar  5 23:53:52 static-81-17-177-202 kernel:
Mar  5 23:53:52 static-81-17-177-202 kernel: Call Trace:
Mar  5 23:53:52 static-81-17-177-202 kernel:  [] 
dump_trace+0xbd/0x3d8
Mar  5 23:53:52 static-81-17-177-202 kernel:  [] 
show_trace+0x44/0x6d
Mar  5 23:53:52 static-81-17-177-202 kernel:  [] 
dump_stack+0x13/0x15
Mar  5 23:53:52 static-81-17-177-202 kernel:  [] 
preempt_enable_no_resched+0x5c/0x5e
Mar  5 23:53:52 static-81-17-177-202 kernel:  [] 
debug_smp_processor_id+0xe8/0xf1
Mar  5 23:53:52 static-81-17-177-202 kernel:  [] 
drain_array+0x25/0x132
Mar  5 23:53:52 static-81-17-177-202 kernel:  [] 
__cache_shrink+0xd5/0x1a6
Mar  5 23:53:52 static-81-17-177-202 kernel:  [] 
kmem_cache_destroy+0x6c/0xe3
Mar  5 23:53:52 static-81-17-177-202 kernel:  [] 
:nfsd:nfsd4_free_slab+0x16/0x21
Mar  5 23:53:52 static-81-17-177-202 kernel:  [] 
:nfsd:nfsd4_free_slabs+0x10/0x36
Mar  5 23:53:52 static-81-17-177-202 kernel:  [] 
:nfsd:nfs4_state_shutdown+0x1a2/0x1ae
Mar  5 23:53:52 static-81-17-177-202 kernel:  [] 
:nfsd:nfsd_last_thread+0x47/0x76
Mar  5 23:53:52 static-81-17-177-202 kernel:  [] 
:sunrpc:svc_destroy+0x8d/0xd1
Mar  5 23:53:52 static-81-17-177-202 kernel:  [] 
:sunrpc:svc_exit_thread+0xba/0xc6
Mar  5 23:53:52 static-81-17-177-202 kernel:  [] 
:nfsd:nfsd+0x2a3/0x2b8
Mar  5 23:53:52 static-81-17-177-202 kernel:  [] 
child_rip+0xa/0x12

Mar  5 23:53:52 static-81-17-177-202 kernel:
Mar  5 23:53:52 static-81-17-177-202 kernel: ---
Mar  5 23:53:52 static-81-17-177-202 kernel: | preempt count:  ]
Mar  5 23:53:52 static-81-17-177-202 kernel: | 0-level deep critical 
section nesting:
Mar  5 23:53:52 static-81-17-177-202 kernel: 


Mar  5 23:53:52 static-81-17-177-202 kernel:
Mar  5 23:53:52 static-81-17-177-202 kernel: BUG: using 
smp_processor_id() in preemptible [] code: nfsd/3939
Mar  5 23:53:52 static-81-17-177-202 kernel: caller is 
drain_array+0x25/0x132

Mar  5 23:53:52 static-81-17-177-202 kernel:
Mar  5 23:53:52 static-81-17-177-202 kernel: Call Trace:
Mar  5 23:53:52 static-81-17-177-202 kernel:  [] 
dump_trace+0xbd/0x3d8
Mar  5 23:53:52 static-81-17-177-202 kernel:  [] 
show_trace+0x44/0x6d
Mar  5 23:53:52 static-81-17-177-202 kernel:  [] 
dump_stack+0x13/0x15
Mar  5 23:53:52 static-81-17-177-202 kernel:  [] 
debug_smp_processor_id+0xe3/0xf1
Mar  5 23:53:52 static-81-17-177-202 kernel:  [] 
drain_array+0x25/0x132
Mar  5 23:53:52 static-81-17-177-202 kernel:  [] 
__cache_shrink+0xd5/0x1a6
Mar  5 23:53:52 static-81-17-177-202 kernel:  [] 
kmem_cache_destroy+0x6c/0xe3
Mar  5 

BUG in kernel-rt 2.6.20-0119.rt8

[Zoltan Boszormenyi]

Hi,

I am using kernel-rt on my FC6/x86-64 system,
the CPU is an Athlon64 X2.

It locks up very rarely (I haven't found any sign in the logs for that)
but I always get this on shutdown, I wonder if it might be related
to the lockup:

Mar  5 23:53:52 static-81-17-177-202 kernel: BUG: using 
smp_processor_id() in preemptible [] code: nfsd/3939
Mar  5 23:53:52 static-81-17-177-202 kernel: caller is 
drain_array+0x25/0x132

Mar  5 23:53:52 static-81-17-177-202 kernel:
Mar  5 23:53:52 static-81-17-177-202 kernel: Call Trace:
Mar  5 23:53:52 static-81-17-177-202 kernel:  [8026d828] 
dump_trace+0xbd/0x3d8
Mar  5 23:53:52 static-81-17-177-202 kernel:  [8026db87] 
show_trace+0x44/0x6d
Mar  5 23:53:52 static-81-17-177-202 kernel:  [8026ddc8] 
dump_stack+0x13/0x15
Mar  5 23:53:52 static-81-17-177-202 kernel:  [80355e2e] 
debug_smp_processor_id+0xe3/0xf1
Mar  5 23:53:52 static-81-17-177-202 kernel:  [802e01b5] 
drain_array+0x25/0x132
Mar  5 23:53:52 static-81-17-177-202 kernel:  [802e07ac] 
__cache_shrink+0xd5/0x1a6
Mar  5 23:53:52 static-81-17-177-202 kernel:  [802e0a47] 
kmem_cache_destroy+0x6c/0xe3
Mar  5 23:53:52 static-81-17-177-202 kernel:  [8878a809] 
:nfsd:nfsd4_free_slab+0x16/0x21
Mar  5 23:53:52 static-81-17-177-202 kernel:  [8878a824] 
:nfsd:nfsd4_free_slabs+0x10/0x36
Mar  5 23:53:52 static-81-17-177-202 kernel:  [8878baf9] 
:nfsd:nfs4_state_shutdown+0x1a2/0x1ae
Mar  5 23:53:52 static-81-17-177-202 kernel:  [887750f8] 
:nfsd:nfsd_last_thread+0x47/0x76
Mar  5 23:53:52 static-81-17-177-202 kernel:  [8867f63a] 
:sunrpc:svc_destroy+0x8d/0xd1
Mar  5 23:53:52 static-81-17-177-202 kernel:  [8867f738] 
:sunrpc:svc_exit_thread+0xba/0xc6
Mar  5 23:53:52 static-81-17-177-202 kernel:  [8877595f] 
:nfsd:nfsd+0x2a3/0x2b8
Mar  5 23:53:52 static-81-17-177-202 kernel:  [802600f8] 
child_rip+0xa/0x12

Mar  5 23:53:52 static-81-17-177-202 kernel:
Mar  5 23:53:52 static-81-17-177-202 kernel: ---
Mar  5 23:53:52 static-81-17-177-202 kernel: | preempt count: 0001 ]
Mar  5 23:53:52 static-81-17-177-202 kernel: | 1-level deep critical 
section nesting:
Mar  5 23:53:52 static-81-17-177-202 kernel: 

Mar  5 23:53:52 static-81-17-177-202 kernel: .. [80355ddb] 
 debug_smp_processor_id+0x90/0xf1
Mar  5 23:53:52 static-81-17-177-202 kernel: .[802e01b5] 
..   ( = drain_array+0x25/0x132)

Mar  5 23:53:52 static-81-17-177-202 kernel:
Mar  5 23:53:52 static-81-17-177-202 kernel: BUG: nfsd:3939 task might 
have lost a preemption check!

Mar  5 23:53:52 static-81-17-177-202 kernel:
Mar  5 23:53:52 static-81-17-177-202 kernel: Call Trace:
Mar  5 23:53:52 static-81-17-177-202 kernel:  [8026d828] 
dump_trace+0xbd/0x3d8
Mar  5 23:53:52 static-81-17-177-202 kernel:  [8026db87] 
show_trace+0x44/0x6d
Mar  5 23:53:52 static-81-17-177-202 kernel:  [8026ddc8] 
dump_stack+0x13/0x15
Mar  5 23:53:52 static-81-17-177-202 kernel:  [8028be9b] 
preempt_enable_no_resched+0x5c/0x5e
Mar  5 23:53:52 static-81-17-177-202 kernel:  [80355e33] 
debug_smp_processor_id+0xe8/0xf1
Mar  5 23:53:52 static-81-17-177-202 kernel:  [802e01b5] 
drain_array+0x25/0x132
Mar  5 23:53:52 static-81-17-177-202 kernel:  [802e07ac] 
__cache_shrink+0xd5/0x1a6
Mar  5 23:53:52 static-81-17-177-202 kernel:  [802e0a47] 
kmem_cache_destroy+0x6c/0xe3
Mar  5 23:53:52 static-81-17-177-202 kernel:  [8878a809] 
:nfsd:nfsd4_free_slab+0x16/0x21
Mar  5 23:53:52 static-81-17-177-202 kernel:  [8878a824] 
:nfsd:nfsd4_free_slabs+0x10/0x36
Mar  5 23:53:52 static-81-17-177-202 kernel:  [8878baf9] 
:nfsd:nfs4_state_shutdown+0x1a2/0x1ae
Mar  5 23:53:52 static-81-17-177-202 kernel:  [887750f8] 
:nfsd:nfsd_last_thread+0x47/0x76
Mar  5 23:53:52 static-81-17-177-202 kernel:  [8867f63a] 
:sunrpc:svc_destroy+0x8d/0xd1
Mar  5 23:53:52 static-81-17-177-202 kernel:  [8867f738] 
:sunrpc:svc_exit_thread+0xba/0xc6
Mar  5 23:53:52 static-81-17-177-202 kernel:  [8877595f] 
:nfsd:nfsd+0x2a3/0x2b8
Mar  5 23:53:52 static-81-17-177-202 kernel:  [802600f8] 
child_rip+0xa/0x12

Mar  5 23:53:52 static-81-17-177-202 kernel:
Mar  5 23:53:52 static-81-17-177-202 kernel: ---
Mar  5 23:53:52 static-81-17-177-202 kernel: | preempt count:  ]
Mar  5 23:53:52 static-81-17-177-202 kernel: | 0-level deep critical 
section nesting:
Mar  5 23:53:52 static-81-17-177-202 kernel: 


Mar  5 23:53:52 static-81-17-177-202 kernel:
Mar  5 23:53:52 static-81-17-177-202 kernel: BUG: using 
smp_processor_id() in preemptible [] code: nfsd/3939
Mar  5 23:53:52 static-81-17-177-202 kernel: caller is 
drain_array+0x25/0x132

Mar  5 23:53:52 static-81-17-177-202 kernel:
Mar  5 23:53:52 static-81-17-177-202 kernel: Call Trace:
Mar  5 

How mature is forcedeth?

[Zoltan Boszormenyi]

Hi,

I replaced my "aging" (means: no SVM) first generation
Athlon64 3200+ and mainboard with a new AM2 X2 4200+
and ABit KN9 SLI which has dual GbE. Both channels are
claimed by forcedeth. I have another machine that is used
mostly as a thin client, it's connected to the main machine
with a crossover cable. The problem is that if I use the
forcedeth ports on the main machine, the thin client doesn't
work correctly. Sometimes it fails to get the IP via DHCP.
Sometimes it doesn't finish booting, either during the TFTP
or NFS mount/transaction. Sometimes it boots up but
X "locks up", e.g. during a window dragging, the window
gets stuck and the pointer doesn't change back to the
regular arrow. With the previous mainboard that used
the r8169 driver everything was OK. I put an 3com card
into the new machine and the thin client works again
via that connection. The system is a fully uptodate FC6,
kernel 2.6.19-1.2895.fc6.

Best regards,
Zoltán Böszörményip
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

How mature is forcedeth?

[Zoltan Boszormenyi]

Hi,

I replaced my aging (means: no SVM) first generation
Athlon64 3200+ and mainboard with a new AM2 X2 4200+
and ABit KN9 SLI which has dual GbE. Both channels are
claimed by forcedeth. I have another machine that is used
mostly as a thin client, it's connected to the main machine
with a crossover cable. The problem is that if I use the
forcedeth ports on the main machine, the thin client doesn't
work correctly. Sometimes it fails to get the IP via DHCP.
Sometimes it doesn't finish booting, either during the TFTP
or NFS mount/transaction. Sometimes it boots up but
X locks up, e.g. during a window dragging, the window
gets stuck and the pointer doesn't change back to the
regular arrow. With the previous mainboard that used
the r8169 driver everything was OK. I put an 3com card
into the new machine and the thin client works again
via that connection. The system is a fully uptodate FC6,
kernel 2.6.19-1.2895.fc6.

Best regards,
Zoltán Böszörményip
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] x86: fix ESP corruption CPU bug

[Zoltan Boszormenyi]

Stas Sergeev <[EMAIL PROTECTED]> writes:

Another way of saying the same thing: I absolutely hate seeing
patches that fix some theoretical issue that no Linux apps will ever
care about.
No, it is not theoretical, but it is mainly
about a DOS games and an MS linker, as for
me. The things I'd like to get working, but
the ones you may not care too much about:)
The particular game I want to get working,
is "Master of Orion 2" for DOS.
How about you just run it in dosbox instead of dosemu ?
-Andi
Nah, don't insult a DOSemu developer. ;-) Stas is one of them...
Best regards,
Zoltán Böszörményi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] x86: fix ESP corruption CPU bug

[Zoltan Boszormenyi]

Stas Sergeev [EMAIL PROTECTED] writes:

Another way of saying the same thing: I absolutely hate seeing
patches that fix some theoretical issue that no Linux apps will ever
care about.
No, it is not theoretical, but it is mainly
about a DOS games and an MS linker, as for
me. The things I'd like to get working, but
the ones you may not care too much about:)
The particular game I want to get working,
is Master of Orion 2 for DOS.
How about you just run it in dosbox instead of dosemu ?
-Andi
Nah, don't insult a DOSemu developer. ;-) Stas is one of them...
Best regards,
Zoltn Bszrmnyi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.10 dies when X uses PCI radeon 9200 SE, further binary search result

[Zoltan Boszormenyi]

On Sun, Jan 30, 2005 at 10:05:16AM -0500, Jon Smirl wrote:
I just checked out on current Linus BK with my AGP Radeon 9000 which
is pretty close to a 9200. Everything is working fine.
I notice from his logs that he is running a PCI radeon, not an AGP
one. Didn't someone make some changes to the PCI radeon memory
management code recently? I run a PCI R128 and that is still working.
DRM debug output might give more clues.
Yes, it is a PCI radeon.  And the machine has an AGP slot
too, which is used by a matrox G550.  This AGP card was not
used in the test, (other than being the VGA console).
Note that there is no crash if I don't compile 
AGP support, so the crash is related to AGP somehow even though
AGP is not supposed to be used in this case.

As I start X (on the radeon) I notice that the VGA console 
I'm using (on the G550 AGP) goes black.  I see no need for that either,
the radeon display is a _different_ device so why black out 
the vgacon?  Could the problem lurk there somehow?

Helge Hafting
I suspect it's the X server that makes your G550 go black.
XOrg-X11-6.8.2 RC1 or RC2 fixes that by introducing a VGAAccess
option for its radeon driver. I recompiled xorg-x11-6.8.1 with this
fix on my FC3 system. It made the only thing that annoyed me
using the linuxconsole.sf.net ruby patch go away.
I have a Radeon 7000VE PCI and a Radeon 9200SE AGP8x.
Every time I logged out on the first X ( localhost:0 ),
it made the other one (localhost:1) go blank.
With the above mentioned fix (that I collected from the XOrg devel
mailing list and was made by Ben Herrenschmidt) applied to XOrg
and using
Option "VGAAccess" "on"
on the card that is set up for VGA by the BIOS and
Option "VGAAccess" "off"
on the other, this problem went away. This modification disables
using the "vgahw" module in XOrg and unfortunately only applicable
to the radeon driver. BTW this patch was made for specifically
for systems that don't use vgacon, like PPC that don't even have
legacy VGA and for others that use radeonfb.
I guess the VGA routing patch and X cooperation will also
solve "the other VGA(s) in the system go blank when I fire up X"
in a generic way, not only for Radeons.
Best regards,
Zoltán Böszörményi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/