Re: [patch 2/4] Expose Power Management Policy option to users
Jeff Garzik wrote: Any chance the SCSI peeps could ACK this, and then let me include it in the ALPM patchset in the libata tree? ATA link PS is pretty complex with HIPM, DIPM and AHCI ALPM. I'm not sure whether this three level knob would be sufficient. It might be good enough if we're gonna develop extensive in-kernel black/white list specifying which method works on which combination but my gut tells me that it's best left to userland (probably in the form of per-notebook PS profile). Adding to the fun, there are quite a few broken devices out there which act weirdly when link PS actions are taken. Also, I generally don't think AHCI ALPM is a good idea. It doesn't have 'cool down' period before entering PS state which unnecessarily hampers performance and might increase chance of device malfunction. So, mild NACK from me. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH libata-dev#upstream 1/2] libata: don't skip EH report if action is pending
Don't skip EH report if action is pending. Signed-off-by: Tejun Heo [EMAIL PROTECTED] --- drivers/ata/libata-eh.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: work/drivers/ata/libata-eh.c === --- work.orig/drivers/ata/libata-eh.c +++ work/drivers/ata/libata-eh.c @@ -1675,7 +1675,7 @@ static void ata_eh_report(struct ata_por nr_failed++; } - if (!nr_failed !ehc-i.err_mask) + if (!nr_failed !ehc-i.err_mask !ehc-i.action) return; frozen = ; - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH libata-dev#upstream 2/2] libata: move EH repeat reporting into ata_eh_report()
EH is sometimes repeated without any error or action. For example,
this happens when probing IDENTIFY fails because of a phantom device.
In these cases, all the repeated EH does is making sure there is no
unhandled error or pending action and return. This repeation is
necessary to avoid losing any event which occurred while EH was in
progress.
Unfortunately, this dry run causes annonying EH pending after
completion message. This patch moves the repeat reporting into
ata_eh_report() such that it's more compact and skipped on dry runs.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
Cc: Mikael Pettersson [EMAIL PROTECTED]
---
Mikael, please verify this removes the annonying message you're
seeing.
Thanks.
drivers/ata/libata-eh.c | 26 --
include/linux/libata.h |5 +++--
2 files changed, 19 insertions(+), 12 deletions(-)
Index: work/drivers/ata/libata-eh.c
===
--- work.orig/drivers/ata/libata-eh.c
+++ work/drivers/ata/libata-eh.c
@@ -290,7 +290,7 @@ enum scsi_eh_timer_return ata_scsi_timed
void ata_scsi_error(struct Scsi_Host *host)
{
struct ata_port *ap = ata_shost_to_port(host);
- int i, repeat_cnt = ATA_EH_MAX_REPEAT;
+ int i;
unsigned long flags;
DPRINTK(ENTER\n);
@@ -356,6 +356,9 @@ void ata_scsi_error(struct Scsi_Host *ho
__ata_port_freeze(ap);
spin_unlock_irqrestore(ap-lock, flags);
+
+ /* initialize eh_tries */
+ ap-eh_tries = ATA_EH_MAX_TRIES;
} else
spin_unlock_wait(ap-lock);
@@ -396,15 +399,12 @@ void ata_scsi_error(struct Scsi_Host *ho
spin_lock_irqsave(ap-lock, flags);
if (ap-pflags ATA_PFLAG_EH_PENDING) {
- if (--repeat_cnt) {
- ata_port_printk(ap, KERN_INFO,
- EH pending after completion,
- repeating EH (cnt=%d)\n, repeat_cnt);
+ if (--ap-eh_tries) {
spin_unlock_irqrestore(ap-lock, flags);
goto repeat;
}
ata_port_printk(ap, KERN_ERR, EH pending after %d
- tries, giving up\n,
ATA_EH_MAX_REPEAT);
+ tries, giving up\n, ATA_EH_MAX_TRIES);
ap-pflags = ~ATA_PFLAG_EH_PENDING;
}
@@ -1658,6 +1658,7 @@ static void ata_eh_report(struct ata_por
{
struct ata_eh_context *ehc = ap-eh_context;
const char *frozen, *desc;
+ char tries_buf[6];
int tag, nr_failed = 0;
desc = NULL;
@@ -1682,18 +1683,23 @@ static void ata_eh_report(struct ata_por
if (ap-pflags ATA_PFLAG_FROZEN)
frozen = frozen;
+ memset(tries_buf, 0, sizeof(tries_buf));
+ if (ap-eh_tries ATA_EH_MAX_TRIES)
+ snprintf(tries_buf, sizeof(tries_buf) - 1, t%d,
+ap-eh_tries);
+
if (ehc-i.dev) {
ata_dev_printk(ehc-i.dev, KERN_ERR, exception Emask 0x%x
- SAct 0x%x SErr 0x%x action 0x%x%s\n,
+ SAct 0x%x SErr 0x%x action 0x%x%s%s\n,
ehc-i.err_mask, ap-sactive, ehc-i.serror,
- ehc-i.action, frozen);
+ ehc-i.action, frozen, tries_buf);
if (desc)
ata_dev_printk(ehc-i.dev, KERN_ERR, %s\n, desc);
} else {
ata_port_printk(ap, KERN_ERR, exception Emask 0x%x
- SAct 0x%x SErr 0x%x action 0x%x%s\n,
+ SAct 0x%x SErr 0x%x action 0x%x%s%s\n,
ehc-i.err_mask, ap-sactive, ehc-i.serror,
- ehc-i.action, frozen);
+ ehc-i.action, frozen, tries_buf);
if (desc)
ata_port_printk(ap, KERN_ERR, %s\n, desc);
}
Index: work/include/linux/libata.h
===
--- work.orig/include/linux/libata.h
+++ work/include/linux/libata.h
@@ -287,8 +287,8 @@ enum {
ATA_EHI_DID_RESET = ATA_EHI_DID_SOFTRESET | ATA_EHI_DID_HARDRESET,
ATA_EHI_RESET_MODIFIER_MASK = ATA_EHI_RESUME_LINK,
- /* max repeat if error condition is still set after -error_handler */
- ATA_EH_MAX_REPEAT = 5,
+ /* max tries if error condition is still set after -error_handler */
+ ATA_EH_MAX_TRIES= 5,
/* how hard are we gonna try to probe/recover devices */
ATA_PROBE_MAX_TRIES = 3,
@@ -537,6 +537,7 @@ struct ata_port {
struct ata_eh_info eh_info;
/* EH context owned by EH */
struct
Re: errors on shutdown with PMP
Tejun Heo wrote: Marc Bejarano wrote: At 03:33 7/28/2007, Tejun Heo wrote: Device times out write. odd that it would be able to be part of an lv's filesystem that had hundreds of gigabytes recently written to it and then choke on flushing during shutdown. And then never comes back. asleep at the wheel ;) Please post the result of 'smartctl -a /dev/sdX' where sdX is the device which went offline. i suppose i should have seen that coming. here you go: === [EMAIL PROTECTED] ~]# /usr/local/sbin/smartctl -a /dev/sdc smartctl version 5.37 [x86_64-unknown-linux-gnu] Copyright (C) 2002-6 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Model Family: Seagate Barracuda 7200.10 family Device Model: ST3750640AS [--snip--] ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 090 079 006Pre-fail Always - 66902364 5 Reallocated_Sector_Ct 0x0033 100 100 036Pre-fail Always - 31 7 Seek_Error_Rate 0x000f 081 060 030Pre-fail Always - 146651228 195 Hardware_ECC_Recovered 0x001a 056 049 000Old_age Always - 102514302 198 Offline_Uncorrectable 0x0010 099 099 000Old_age Offline - 40 Counters don't look too friendly. Do you happen to have another drive of the same model? If so, can you post smartctl -a of the drive? Offline_Uncorrectable looks bad, as well as Reallocated_Sector_Ct... For Raw_Read_Error_Rate/Seek_Error_Rate/Hardware_ECC_Recovered it is how Seagates work: gwy:~# for a in /dev/sd[a-f]; do smartctl -a $a; done | grep '\(Raw_Read\|Seek_Error\|Hardware_ECC\|Offline_Uncorr\|Reallocated\|^Device M\|^Firmware\)' Device Model: Hitachi HDT725032VLA380 Firmware Version: V54OA52A 1 Raw_Read_Error_Rate 0x000b 100 100 016Pre-fail Always - 0 5 Reallocated_Sector_Ct 0x0033 100 100 005Pre-fail Always - 0 7 Seek_Error_Rate 0x000b 100 100 067Pre-fail Always - 0 196 Reallocated_Event_Count 0x0032 100 100 000Old_age Always - 0 198 Offline_Uncorrectable 0x0008 100 100 000Old_age Offline - 0 Device Model: Hitachi HDS721010KLA330 Firmware Version: GKAOA70F 1 Raw_Read_Error_Rate 0x000b 100 100 016Pre-fail Always - 0 5 Reallocated_Sector_Ct 0x0033 100 100 005Pre-fail Always - 0 7 Seek_Error_Rate 0x000b 100 100 067Pre-fail Always - 0 196 Reallocated_Event_Count 0x0032 100 100 000Old_age Always - 0 198 Offline_Uncorrectable 0x0008 100 100 000Old_age Offline - 0 Device Model: ST3750640AS Firmware Version: 3.AAE 1 Raw_Read_Error_Rate 0x000f 110 087 006Pre-fail Always - 201790283 5 Reallocated_Sector_Ct 0x0033 100 100 036Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 076 060 030Pre-fail Always - 43520234 195 Hardware_ECC_Recovered 0x001a 059 050 000Old_age Always - 40212951 198 Offline_Uncorrectable 0x0010 100 100 000Old_age Offline - 0 Device Model: Hitachi HDS721010KLA330 Firmware Version: GKAOA70F 1 Raw_Read_Error_Rate 0x000b 100 100 016Pre-fail Always - 0 5 Reallocated_Sector_Ct 0x0033 100 100 005Pre-fail Always - 0 7 Seek_Error_Rate 0x000b 100 100 067Pre-fail Always - 0 196 Reallocated_Event_Count 0x0032 100 100 000Old_age Always - 0 198 Offline_Uncorrectable 0x0008 100 100 000Old_age Offline - 0 Device Model: ST3750640AS Firmware Version: 3.AAD 1 Raw_Read_Error_Rate 0x000f 114 083 006Pre-fail Always - 121388046 5 Reallocated_Sector_Ct 0x0033 100 100 036Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 078 065 030Pre-fail Always - 78605591 195 Hardware_ECC_Recovered 0x001a 066 050 000Old_age Always - 194670617 198 Offline_Uncorrectable 0x0010 100 100 000Old_age Offline - 0 Device Model: Sans Digital V.36.B0D Firmware Version: V.36.B0D BTW, sdb-sde are behind PMP, no problems on shutdown. Funniest is that all these counters are 32bit, so during day you see like your disk is estimated to die in 5 days, then suddenly that 32bit counter overflows, and your disk is again healthy as possible. I did not measure what these counters actually count on these 750GB drives, but on 100GB notebook Seagate drive every sector read counts as 3-5 ECC errors, and every Smart data interrogation as 1...
hpt374 sata (Highpoint Rocket 1540)
Hi there, I've had a Highpoint Rocket 1540 (not RocketRAID) SATA controller for a while now, using a proprietary binary driver from Highpoint in a linux 2.4 kernel. The chipset is an hpt374. The hpt366 driver freezes on boot, as reported by others. There are rumours[0][1] of a SATA driver for the hpt372N/302N chips using libata. In 2.6.22, there are PATA drivers for hpt3xx, but no SATA. [0] http://linuxmafia.com/faq/Hardware/sata.html#highpoint [1] http://lkml.org/lkml/2006/1/3/211 I'm wondering if there are or will be libata drivers, or any drivers for that matter, for hpt374-based SATA cards? Cheers, Bob Ham - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hpt374 sata (Highpoint Rocket 1540)
I'm wondering if there are or will be libata drivers, or any drivers for that matter, for hpt374-based SATA cards? The HPT374 is a PATA controller. Some people ship products with the HPT37x controllers and PATA/SATA bridges and those should work with the libata drivers. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] libata: Correct IORDY handling
Debugging a report of a problem with an ancient solid state disk showed
up some problems in the IORDY handling
1. We check the wrong bit to see if the device has IORDY
2. Even then some ancient creaking piles of crap don't support
SETXFER at all.
I think this should go via -mm for a bit. The cases it fixes are obscure
and the risk of side effects is slight but possible. This also moves us
slightly closer to supporting original MFM/RLL disks with libata but
before Jeff panics I have no plans to do that
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.23rc1-mm1/drivers/ata/libata-core.c
linux-2.6.23rc1-mm1/drivers/ata/libata-core.c
--- linux.vanilla-2.6.23rc1-mm1/drivers/ata/libata-core.c 2007-07-26
15:02:57.0 +0100
+++ linux-2.6.23rc1-mm1/drivers/ata/libata-core.c 2007-07-31
10:47:21.152431008 +0100
@@ -2787,7 +2803,11 @@
/* Old CFA may refuse this command, which is just fine */
if (dev-xfer_shift == ATA_SHIFT_PIO ata_id_is_cfa(dev-id))
err_mask = ~AC_ERR_DEV;
-
+ /* Some very old devices and some bad newer ones fail any kind of
+ SET_XFERMODE request but support PIO0-2 timings and no IORDY */
+ if (dev-xfer_shift == ATA_SHIFT_PIO !ata_id_has_iordy(dev-id)
+ dev-pio_mode = XFER_PIO_2)
+ err_mask = ~AC_ERR_DEV;
if (err_mask) {
ata_dev_printk(dev, KERN_ERR, failed to set xfermode
(err_mask=0x%x)\n, err_mask);
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.23rc1-mm1/include/linux/ata.h
linux-2.6.23rc1-mm1/include/linux/ata.h
--- linux.vanilla-2.6.23rc1-mm1/include/linux/ata.h 2007-07-26
15:02:58.0 +0100
+++ linux-2.6.23rc1-mm1/include/linux/ata.h 2007-07-27 19:03:40.0
+0100
@@ -354,7 +355,7 @@
( (((id)[76] != 0x) ((id)[76] != 0x)) \
((id)[78] (1 5)) )
#define ata_id_iordy_disable(id) ((id)[49] (1 10))
-#define ata_id_has_iordy(id) ((id)[49] (1 9))
+#define ata_id_has_iordy(id) ((id)[49] (1 11))
#define ata_id_u32(id,n) \
(((u32) (id)[(n) + 1] 16) | ((u32) (id)[(n)]))
#define ata_id_u64(id,n) \
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hpt374 sata (Highpoint Rocket 1540)
Bob Ham wrote: I've had a Highpoint Rocket 1540 (not RocketRAID) SATA controller for a while now, using a proprietary binary driver from Highpoint in a linux 2.4 kernel. The chipset is an hpt374. The hpt366 driver freezes on boot, as reported by others. Can we see a bootlog please? I'm wondering if there are or will be libata drivers, or any drivers for that matter, for hpt374-based SATA cards? As HPT374 is not a SATA chip, it needs SATA bridges to work with SATA drives, hence no the only HPT374 libata driver that's going to ever be is pata_hpt37x. Cheers, Bob Ham MBR, Sergei - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Boot fails on Intel SATA controller
Hi there, A Mandriva user is reporting that his machine hangs while booting kernels 2.6.22.1 and 2.6.23-rc1. But boots fine with 2.6.21. Here is the 2.6.22 boot log: SCSI subsystem initialized Loading scsi_mod.ko module Loading libata.ko module ACPI: PCI Interrupt :00:1f.2[C] - Loading ahci.ko GSI 20 (level, low) - IRQ 18 module input: ImPS/2 Logitech Wheel Mouse as /class/input/input1 ahci :00:1f.2: AHCI 0001. 32 slots 4 ports 1.5 Gbps 0xf impl IDE mode ahci :00:1f.2: flags: 64bit ncq pm led slum part scsi0 : ahci scsi1 : ahci scsi2 : ahci scsi3 : ahci ata1: SATA max UDMA/133 cmd 0xf881ad00 ctl 0x bmdma 0x irq 18 ata2: SATA max UDMA/133 cmd 0xf881ad80 ctl 0x bmdma 0x irq 18 ata3: SATA max UDMA/133 cmd 0xf881ae00 ctl 0x bmdma 0x irq 18 ata4: SATA max UDMA/133 cmd 0xf881ae80 ctl 0x bmdma 0x irq 18 ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: qc timeout (cmd 0x27) ata1.00: ata_hpa_resize 1: hpa sectors (0) is smaller than sectors (781422768) ata1.00: ATA-7: HDS724040KLSA80, KFAOA20N, max UDMA/133 ata1.00: 781422768 sectors, multi 8: LBA48 ata1.00: failed to set xfermode (err_mask=0x40) ata1: failed to recover some devices, retrying in 5 secs System is a Dell Dimension 8400 with SATA controller $ lspcidrake | grep IDE piix: Intel Corporation|82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller [STORAGE_IDE] ahci: Intel Corporation|82801FR/FRW (ICH6R/ICH6RW) SATA Controller [STORAGE_IDE] There's more info in the ticket: http://qa.mandriva.com/show_bug.cgi?id=32076 -- Luiz Fernando N. Capitulino - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2/4] Expose Power Management Policy option to users
On Tue, 2007-07-31 at 15:27 +0900, Tejun Heo wrote: Jeff Garzik wrote: Any chance the SCSI peeps could ACK this, and then let me include it in the ALPM patchset in the libata tree? ATA link PS is pretty complex with HIPM, DIPM and AHCI ALPM. I'm not sure whether this three level knob would be sufficient. adding more levels later is easy. It might be good enough if we're gonna develop extensive in-kernel black/white list specifying which method works on which combination but my gut tells me that it's best left to userland (probably in the form of per-notebook PS profile). either sucks. AHCI ALPM ought to work if it's supported; it's what other operating systems also use... Adding to the fun, there are quite a few broken devices out there which act weirdly when link PS actions are taken. do you have any specific examples that act funny with the patch in question here? (the patch tries to be careful, previous patches weren't always so please test this patch before claiming the concept as a whole is broken) Also, I generally don't think AHCI ALPM is a good idea. It doesn't have 'cool down' period before entering PS state that's a chipset implementation decision not part of the spec/technology per se. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] libata: Correct IORDY handling
Hello.
Alan Cox wrote:
Debugging a report of a problem with an ancient solid state disk showed
up some problems in the IORDY handling
1. We check the wrong bit to see if the device has IORDY
2. Even then some ancient creaking piles of crap don't support
SETXFER at all.
I think this should go via -mm for a bit. The cases it fixes are obscure
and the risk of side effects is slight but possible. This also moves us
slightly closer to supporting original MFM/RLL disks with libata but
before Jeff panics I have no plans to do that
Signed-off-by: Alan Cox [EMAIL PROTECTED]
Acked-by: Sergei Shtylyov [EMAIL PROTECTED]
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.23rc1-mm1/drivers/ata/libata-core.c
linux-2.6.23rc1-mm1/drivers/ata/libata-core.c
--- linux.vanilla-2.6.23rc1-mm1/drivers/ata/libata-core.c 2007-07-26
15:02:57.0 +0100
+++ linux-2.6.23rc1-mm1/drivers/ata/libata-core.c 2007-07-31
10:47:21.152431008 +0100
@@ -2787,7 +2803,11 @@
/* Old CFA may refuse this command, which is just fine */
if (dev-xfer_shift == ATA_SHIFT_PIO ata_id_is_cfa(dev-id))
err_mask = ~AC_ERR_DEV;
-
+ /* Some very old devices and some bad newer ones fail any kind of
+ SET_XFERMODE request but support PIO0-2 timings and no IORDY */
+ if (dev-xfer_shift == ATA_SHIFT_PIO !ata_id_has_iordy(dev-id)
I'd have joined this to the previous if...
+ dev-pio_mode = XFER_PIO_2)
Overindented line (to my taste :-). And do we really need to check this?
+ err_mask = ~AC_ERR_DEV;
if (err_mask) {
ata_dev_printk(dev, KERN_ERR, failed to set xfermode
(err_mask=0x%x)\n, err_mask);
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.23rc1-mm1/include/linux/ata.h
linux-2.6.23rc1-mm1/include/linux/ata.h
--- linux.vanilla-2.6.23rc1-mm1/include/linux/ata.h 2007-07-26
15:02:58.0 +0100
+++ linux-2.6.23rc1-mm1/include/linux/ata.h 2007-07-27 19:03:40.0
+0100
@@ -354,7 +355,7 @@
( (((id)[76] != 0x) ((id)[76] != 0x)) \
((id)[78] (1 5)) )
#define ata_id_iordy_disable(id) ((id)[49] (1 10))
-#define ata_id_has_iordy(id) ((id)[49] (1 9))
+#define ata_id_has_iordy(id) ((id)[49] (1 11))
Ha, it was cheking for LBA support instead... :-)
MBR, Sergei
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2/4] Expose Power Management Policy option to users
On Tue, 2007-07-31 at 15:27 +0900, Tejun Heo wrote: Jeff Garzik wrote: Any chance the SCSI peeps could ACK this, and then let me include it in the ALPM patchset in the libata tree? ATA link PS is pretty complex with HIPM, DIPM and AHCI ALPM. I'm not sure whether this three level knob would be sufficient. It might be good enough if we're gonna develop extensive in-kernel black/white list specifying which method works on which combination but my gut tells me that it's best left to userland (probably in the form of per-notebook PS profile). Adding to the fun, there are quite a few broken devices out there which act weirdly when link PS actions are taken. Also, I generally don't think AHCI ALPM is a good idea. It doesn't have 'cool down' period before entering PS state which unnecessarily hampers performance and might increase chance of device malfunction. So, mild NACK from me. The other comment is that power saving seems to be a property of the transport rather than the host. If you do it in the transport classes, then you can expose all the knobs the actual transport possesses (which is, unfortunately, none for quite a few SCSI transports). James - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2/4] Expose Power Management Policy option to users
Arjan van de Ven wrote: On Tue, 2007-07-31 at 15:27 +0900, Tejun Heo wrote: Jeff Garzik wrote: Any chance the SCSI peeps could ACK this, and then let me include it in the ALPM patchset in the libata tree? ATA link PS is pretty complex with HIPM, DIPM and AHCI ALPM. I'm not sure whether this three level knob would be sufficient. adding more levels later is easy. Dunno whether they would be linear levels and putting HIPM, DIPM, ALPM selection into SCSI sysfs knob doesn't look so appealing. It might be good enough if we're gonna develop extensive in-kernel black/white list specifying which method works on which combination but my gut tells me that it's best left to userland (probably in the form of per-notebook PS profile). either sucks. AHCI ALPM ought to work if it's supported; it's what other operating systems also use... Adding to the fun, there are quite a few broken devices out there which act weirdly when link PS actions are taken. do you have any specific examples that act funny with the patch in question here? (the patch tries to be careful, previous patches weren't always so please test this patch before claiming the concept as a whole is broken) They were hardware problems. I don't think any amount of proper implementation can fix them. I have one DVD RAM somewhere in my pile of hardware which locks up solidly if any link PS mode is used and had a report of a HDD which had problem with link PS. Can't remember the details tho. Also, IIRC one of my wendies spins down on SLUMBER. Also, I generally don't think AHCI ALPM is a good idea. It doesn't have 'cool down' period before entering PS state that's a chipset implementation decision not part of the spec/technology per se. That's actually something AHCI spec specifically states. From section 8.3.1.3. When PxCMD.ALPE is set to ‘1’, if the HBA recognizes that there are no commands to process, the HBA shall initiate a transition to Partial or Slumber interface power management state based upon the setting of PxCMD.ASP. The HBA recognizes no commands to transmit as either: • PxSACT is set to 0h, and the HBA updates PxCI from a non-zero value to 0h. • PxCI is set to 0h, and a Set Device Bits FIS is received that updates PxSACT from a non-zero value to 0h. Have no idea why it's specified this way. Adding 100ms or 1s cool down time wouldn't burn noticeably more power. Maybe AHCI expects the host driver to queue commands even for non-NCQ drives but libata currently doesn't do that. Anyways, I don't really think this attribute belongs to SCSI sysfs hierarchy. There currently isn't any alternative but sysfs is part of userland visible interface and putting something into SCSI sysfs hierarchy just because libata doesn't have one doesn't look like a good idea. sysfs isn't far from being detached from kobject and driver model. I think it would be best to wait a bit and build proper libata sysfs hierarchy which won't have to be changed later when libata departs from SCSI. Well, it isn't really a good way but IMHO it's better than sticking ATA power saving node into SCSI sysfs hierarchy. Thanks. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Time Problems with 2.6.23-rc1-gf695baf2
* Michal Piotrowski ([EMAIL PROTECTED]) wrote: Hi Eric, On 26/07/07, Eric Sesterhenn / Snakebyte [EMAIL PROTECTED] wrote: * Len Brown ([EMAIL PROTECTED]) wrote: [ 13.506890] ACPI Exception (processor_throttling-0084): AE_NOT_FOUND, Evaluating _PTC [20070126] [ 13.507101] ACPI Exception (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126] Note that these are just noise -- new code being verbose when looking for an optional feature. The fact that hitting the power button a bunch of times to make the system move along suggests some sort of missing interrupt problem -- most likely the timer itself. [ 13.868574] Probing IDE interface ide0... [ 387.279576] Clocksource tsc unstable (delta = 370195339890 ns) 5-minutes -- a long probe:-) CONFIG_NO_HZ=y does CONFIG_NO_HZ=n make a difference? [ 41.007654] EXT3 FS on hda1, internal journal [ 322.133656] Clocksource tsc unstable (delta = 276476174785 ns) Boot went fine but the system got pretty unresponsive later, 2-3 seconds delay after keypresses on an idle system and a hang during shutdown which i had to resolve by pressing the power button (not to switch it of the hard way, but to keep it rebooting) CONFIG_HIGH_RES_TIMERS=y does CONFIG_HIGH_RES_TIMERS=n make a difference? doesnt change anything does irqpoll make any difference? does notsc make any difference? does idle=poll make any difference? I tried these with the HIGH_RES_TIMERS=n, irqpoll and notsc dont change a thing, idle=poll makes it boot normally Please use git-bisect git-bisect start git-bisect bad git-bisect good 7dcca30a32aadb0520417521b0c44f42d09fe05c took some time, but i got a scape goat, added venkatesh to the CC list, greetings, Eric b8550397f1f3d4b8b2c5257c88dae25d58ed is first bad commit commit 18eab8550397f1f3d4b8b2c5257c88dae25d58ed Author: Venkatesh Pallipadi [EMAIL PROTECTED] Date: Fri Jun 15 19:37:00 2007 -0400 ACPI: Enable C3 even when PM2_control is zero On systems that do not have pm2_control_block, we cannot really use ARB_DISABLE before C3. We used to disable C3 totally on such systems. To be compatible with Windows, we need to enable C3 on such systems now. We just skip ARB_DISABLE step before entering the C3-state and assume hardware is handling things correctly. Also, ACPI spec is not clear about pm2_control is _needed_ for C3 or not. We have atleast one system that need this to enable C3. Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED] Signed-off-by: Len Brown [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2/4] Expose Power Management Policy option to users
Arjan van de Ven wrote: either sucks. AHCI ALPM ought to work if it's supported; it's what other operating systems also use... A question. Does the other OS enable ALPM without checking against white/black list? Or is it enabled only on certain configurations - e.g. specific notebooks, etc? -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Time Problems with 2.6.23-rc1-gf695baf2
-Original Message- From: Eric Sesterhenn / Snakebyte [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 31, 2007 7:55 AM To: Michal Piotrowski Cc: Eric Sesterhenn / Snakebyte; Len Brown; [EMAIL PROTECTED]; IDE/ATA development list; Bartlomiej Zolnierkiewicz; [EMAIL PROTECTED]; Ingo Molnar; Thomas Gleixner; Pallipadi, Venkatesh Subject: Re: Time Problems with 2.6.23-rc1-gf695baf2 * Michal Piotrowski ([EMAIL PROTECTED]) wrote: Hi Eric, On 26/07/07, Eric Sesterhenn / Snakebyte [EMAIL PROTECTED] wrote: * Len Brown ([EMAIL PROTECTED]) wrote: [ 13.506890] ACPI Exception (processor_throttling-0084): AE_NOT_FOUND, Evaluating _PTC [20070126] [ 13.507101] ACPI Exception (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126] Note that these are just noise -- new code being verbose when looking for an optional feature. The fact that hitting the power button a bunch of times to make the system move along suggests some sort of missing interrupt problem -- most likely the timer itself. [ 13.868574] Probing IDE interface ide0... [ 387.279576] Clocksource tsc unstable (delta = 370195339890 ns) 5-minutes -- a long probe:-) CONFIG_NO_HZ=y does CONFIG_NO_HZ=n make a difference? [ 41.007654] EXT3 FS on hda1, internal journal [ 322.133656] Clocksource tsc unstable (delta = 276476174785 ns) Boot went fine but the system got pretty unresponsive later, 2-3 seconds delay after keypresses on an idle system and a hang during shutdown which i had to resolve by pressing the power button (not to switch it of the hard way, but to keep it rebooting) CONFIG_HIGH_RES_TIMERS=y does CONFIG_HIGH_RES_TIMERS=n make a difference? doesnt change anything does irqpoll make any difference? does notsc make any difference? does idle=poll make any difference? I tried these with the HIGH_RES_TIMERS=n, irqpoll and notsc dont change a thing, idle=poll makes it boot normally Please use git-bisect git-bisect start git-bisect bad git-bisect good 7dcca30a32aadb0520417521b0c44f42d09fe05c took some time, but i got a scape goat, added venkatesh to the CC list, Eric, This means things should work fine with processor.max_cstate=2 boot option as well. Can you please double check that. Also, please send in the acpidump from your system. Thanks, Venki - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hpt374 sata (Highpoint Rocket 1540)
Sergei Shtylyov wrote: I'm wondering if there are or will be libata drivers, or any drivers for that matter, for hpt374-based SATA cards? As HPT374 is not a SATA chip, it needs SATA bridges to work with SATA drives, hence no the only HPT374 libata driver that's going to ever be is pata_hpt37x. I've 2 of these cards lying around and when I last tested one of them ~2.6.20 thereabouts it worked as well as a pair of sil3112 cards provided you don't want hotplug. I have a test box here I'll fire up next week when I get some more sata drives to play with. Brad -- Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. -- Douglas Adams - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] libata: Correct IORDY handling
+ dev-pio_mode = XFER_PIO_2) Overindented line (to my taste :-). And do we really need to check this? Yes - if it refuses SET_XFER_MODE we really don't want to run any mode above PIO2. No hardware *should* do this but then this is IDE... - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Time Problems with 2.6.23-rc1-gf695baf2
* Pallipadi, Venkatesh ([EMAIL PROTECTED]) wrote: This means things should work fine with processor.max_cstate=2 boot option as well. Can you please double check that. yes, system boots fine with this kernel parameter Also, please send in the acpidump from your system. here we go, if you need some parameters to acpidump, just say so. Thanks, Eric DSDT @ 0xfffc100 : 44 53 44 54 53 22 00 00 01 49 41 53 55 53 00 00 DSDTS...IASUS.. 0010: 4d 45 44 5f 32 30 30 31 00 10 00 00 4d 53 46 54 MED_2001MSFT 0020: 0b 00 00 01 10 19 5c 5f 50 52 5f 5b 83 11 5c 2e ..\_PR_[..\. 0030: 5f 50 52 5f 43 50 55 30 01 10 e4 00 00 06 08 5c _PR_CPU0...\ 0040: 5f 53 30 5f 12 0a 04 0a 00 0a 00 0a 00 0a 00 08 _S0_ 0050: 5c 5f 53 31 5f 12 0a 04 0a 03 0a 03 0a 00 0a 00 \_S1_... 0060: 08 5c 5f 53 34 5f 12 0a 04 0a 07 0a 07 0a 00 0a .\_S4_.. 0070: 00 08 5c 5f 53 35 5f 12 0a 04 0a 07 0a 07 0a 00 ..\_S5_. 0080: 0a 00 14 10 4d 45 4d 53 00 70 45 58 54 4d 61 75 MEMS.pEXTMau 0090: 61 a4 61 5b 80 5c 44 45 42 47 01 0a 80 0a 01 5b a.a[.\DEBG.[ 00a0: 81 0c 5c 44 45 42 47 01 44 42 47 31 08 5b 80 47 ..\DEBG.DBG1.[.G 00b0: 4d 45 4d 00 0b bc 04 0a 02 5b 81 0b 47 4d 45 4d MEM..[..GMEM 00c0: 01 45 58 54 4d 10 5b 80 47 50 4f 42 01 0b 00 e4 .EXTM.[.GPOB 00d0: 0a 4f 5b 81 17 47 50 4f 42 01 00 20 53 43 49 45 .O[..GPOB.. SCIE 00e0: 01 00 4f 12 00 0e 54 52 50 30 01 5b 80 45 43 4f ..O...TRP0.[.ECO 00f0: 53 01 0a 72 0a 02 5b 81 10 45 43 4f 53 01 43 49 S..r..[..ECOS.CI 0100: 44 58 08 43 44 41 54 08 5b 86 44 04 43 49 44 58 DX.CDAT.[.D.CIDX 0110: 43 44 41 54 01 00 40 6d 48 43 55 44 04 48 43 50 [EMAIL PROTECTED] 0120: 49 04 48 44 55 44 04 48 44 50 49 04 48 45 55 44 I.HDUD.HDPI.HEUD 0130: 04 48 45 50 49 04 48 46 55 44 04 48 46 50 49 04 .HEPI.HFUD.HFPI. 0140: 00 08 53 55 53 33 01 00 03 53 4c 53 54 04 08 50 ..SUS3...SLST..P 0150: 52 57 31 12 1e 04 12 06 02 0a 0d 0a 01 12 06 02 RW1. 0160: 0a 0b 0a 01 12 06 02 0a 09 0a 01 12 06 02 0a 08 0170: 0a 01 08 50 52 57 33 12 1e 04 12 06 02 0a 0d 0a ...PRW3. 0180: 03 12 06 02 0a 0b 0a 03 12 06 02 0a 09 0a 03 12 0190: 06 02 0a 08 0a 03 08 50 52 57 54 12 0a 04 0a 0d ...PRWT. 01a0: 0a 0b 0a 09 0a 08 14 33 53 50 52 57 01 70 89 50 ...3SPRW.p.P 01b0: 52 57 54 01 68 00 0a 00 0a 00 60 70 53 55 53 33 RWT.h.`pSUS3 01c0: 62 a0 0d 93 62 00 a4 83 88 50 52 57 31 60 00 a1 b...bPRW1`.. 01d0: 0a a4 83 88 50 52 57 33 60 00 5b 80 47 50 53 43 PRW3`.[.GPSC 01e0: 01 0b 2f e4 0a 01 5b 81 0b 47 50 53 43 01 53 4d ../...[..GPSC.SM 01f0: 43 4d 08 14 4b 09 5c 5f 50 54 53 01 70 68 53 4c CM..K.\_PTS.phSL 0200: 53 54 a0 05 93 68 0a 01 70 01 54 52 50 30 a0 4e ST...h..p.TRP0.N 0210: 05 93 5c 2f 04 5f 53 42 5f 50 43 49 30 50 58 34 ..\/._SB_PCI0PX4 0220: 30 44 45 56 44 0b 96 05 a0 2d 92 94 5c 2f 04 5f 0DEVD-..\/._ 0230: 53 42 5f 50 43 49 30 50 58 34 30 52 45 56 49 0a SB_PCI0PX40REVI. 0240: 12 70 01 5c 2f 04 5f 53 42 5f 50 43 49 30 50 58 .p.\/._SB_PCI0PX 0250: 34 30 50 43 53 41 a1 16 70 01 5c 2f 04 5f 53 42 40PCSA..p.\/._SB 0260: 5f 50 43 49 30 50 58 34 30 50 43 53 30 a1 16 70 _PCI0PX40PCS0..p 0270: 01 5c 2f 04 5f 53 42 5f 50 43 49 30 50 58 34 30 .\/._SB_PCI0PX40 0280: 50 43 53 30 7d 68 0a f0 62 70 62 44 42 47 31 14 PCS0}h..bpbDBG1. 0290: 48 09 5c 5f 57 41 4b 01 a0 4e 05 93 5c 2f 04 5f H.\_WAK..N..\/._ 02a0: 53 42 5f 50 43 49 30 50 58 34 30 44 45 56 44 0b SB_PCI0PX40DEVD. 02b0: 96 05 a0 2d 92 94 5c 2f 04 5f 53 42 5f 50 43 49 ...-..\/._SB_PCI 02c0: 30 50 58 34 30 52 45 56 49 0a 12 70 00 5c 2f 04 0PX40REVI..p.\/. 02d0: 5f 53 42 5f 50 43 49 30 50 58 34 30 50 43 53 41 _SB_PCI0PX40PCSA 02e0: a1 16 70 00 5c 2f 04 5f 53 42 5f 50 43 49 30 50 ..p.\/._SB_PCI0P 02f0: 58 34 30 50 43 53 30 a1 16 70 00 5c 2f 04 5f 53 X40PCS0..p.\/._S 0300: 42 5f 50 43 49 30 50 58 34 30 50 43 53 30 70 00 B_PCI0PX40PCS0p. 0310: 54 52 50 30 70 0a ff 44 42 47 31 86 5c 2e 5f 53 TRP0p..DBG1.\._S 0320: 42 5f 50 57 52 42 0a 02 10 80 eb 01 5c 5f 53 42 B_PWRB..\_SB 0330: 5f 5b 82 19 50 57 52 42 08 5f 48 49 44 0c 41 d0 _[..PWRB._HID.A. 0340: 0c 0c 14 09 5f 53 54 41 00 a4 0a 0b 5b 82 4c 07 _STA[.L. 0350: 4d 45 4d 31 08 5f 48 49 44 0c 41 d0 0c 01 14 4b MEM1._HID.AK 0360: 06 5f 43 52 53 00 08 42 55 46 31 11 35 0a 32 86 ._CRS..BUF1.5.2. 0370: 09 00 01 00 00 00 00 00 00 0a 00 86 09 00 00 00 0380: 00 0f 00 00 00 01 00 86 09 00 01 00 00 10 00 00 0390: 00 00 00 86 09 00 00 00 00 fe ff 00 00 02 00 79 ...y 03a0: 00 8a 42 55 46 31 0a 20 45 4d 4c 4e 70 4d 45 4d ..BUF1. EMLNpMEM 03b0: 53 45 4d 4c 4e 76 45 4d 4c 4e 79 45 4d 4c 4e 0a SEMLNvEMLNyEMLN. 03c0: 14 45 4d 4c 4e a4 42 55 46 31 5b 82 40 10 4c 4e [EMAIL PROTECTED] 03d0: 4b 41 08 5f 48 49 44 0c 41 d0 0c 0f 08 5f 55 49 KA._HID.A_UI 03e0: 44 0a 01 14 27 5f 53 54 41
Re: [patch 2/4] Expose Power Management Policy option to users
They were hardware problems. I don't think any amount of proper implementation can fix them. I have one DVD RAM somewhere in my pile of hardware which locks up solidly if any link PS mode is used and had a and the AHCI ALPM code decides to use power savings on this device? if so, please give us the idents so that we can add it to the blacklist as the first entry... (or can buy it to check it in detail first) -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2/4] Expose Power Management Policy option to users
On Tue, 31 Jul 2007 23:45:25 +0900 Tejun Heo [EMAIL PROTECTED] wrote: Anyways, I don't really think this attribute belongs to SCSI sysfs hierarchy. There currently isn't any alternative but sysfs is part of userland visible interface and putting something into SCSI sysfs hierarchy just because libata doesn't have one doesn't look like a good idea. sysfs isn't far from being detached from kobject and driver model. I think it would be best to wait a bit and build proper libata sysfs hierarchy which won't have to be changed later when libata departs from SCSI. Well, it isn't really a good way but IMHO it's better than sticking ATA power saving node into SCSI sysfs hierarchy. Wait a bit could be a very long time. Who is working on building this new libata sysfs support now? If the answer is no one, which I think it may be, do you want to hold up a feature that actually helps many people for possibly 6 months or more just because we have to go through scsi right now for our sysfs interface? on top of that, the last mail I got from James on this subject indicated that if we kept our granularity large with the power savings levels, SCSI can actually take advantage of this as well. Sure, we may have to tweak things around later, but isn't this what we do routinely? Holding up valuable features from the kernel because things aren't perfect yet seems really broken. As far as your complaints about broken hardware go, keep in mind that the patch set does provide a method of adding these disks to a blacklist, so I don't see that as a problem. And, the default for this feature is off, and user space would have to explicitly enable it. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: errors on shutdown with PMP
At 00:32 7/31/2007, Tejun Heo wrote: Marc Bejarano wrote: At 03:33 7/28/2007, Tejun Heo wrote: Please post the result of 'smartctl -a /dev/sdX' where sdX is the device which went offline. i suppose i should have seen that coming. here you go: === [EMAIL PROTECTED] ~]# /usr/local/sbin/smartctl -a /dev/sdc smartctl version 5.37 [x86_64-unknown-linux-gnu] Copyright (C) 2002-6 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Model Family: Seagate Barracuda 7200.10 family Device Model: ST3750640AS [--snip--] ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 090 079 006Pre-fail Always - 66902364 5 Reallocated_Sector_Ct 0x0033 100 100 036Pre-fail Always - 31 7 Seek_Error_Rate 0x000f 081 060 030Pre-fail Always - 146651228 195 Hardware_ECC_Recovered 0x001a 056 049 000Old_age Always - 102514302 198 Offline_Uncorrectable 0x0010 099 099 000Old_age Offline - 40 Counters don't look too friendly. Do you happen to have another drive of the same model? about 100 or so of them ;) If so, can you post smartctl -a of the drive? here are the other two drives in the unhappy lv: === [EMAIL PROTECTED] ~]# smartctl -a /dev/sdg smartctl version 5.33 [x86_64-redhat-linux-gnu] Copyright (C) 2002-4 Bruce Allen Home page is http://smartmontools.sourceforge.net/ Device: ATA ST3750640AS Version: 3.AA Serial number: 5QD05VBA Device type: disk Local Time is: Tue Jul 31 12:14:00 2007 EDT Device does not support SMART Request Sense failed, [Input/output error] Error Counter logging not supported Error Events logging not supported [GLTSD (Global Logging Target Save Disable) set. Enable Save with '-S on'] Device does not support Self Test logging [EMAIL PROTECTED] ~]# /usr/local/sbin/smartctl -a /dev/sdg smartctl version 5.37 [x86_64-unknown-linux-gnu] Copyright (C) 2002-6 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Model Family: Seagate Barracuda 7200.10 family Device Model: ST3750640AS Serial Number:5QD05VBA Firmware Version: 3.AAE User Capacity:750,156,374,016 bytes Device is:In smartctl database [for details use: -P show] ATA Version is: 7 ATA Standard is: Exact ATA specification draft version not indicated Local Time is:Tue Jul 31 12:14:11 2007 EDT SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x82) Offline data collection activity was completed without error. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: ( 430) seconds. Offline data collection capabilities:(0x5b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. No Conveyance Self-test supported. Selective Self-test supported. SMART capabilities:(0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability:(0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time:( 1) minutes. Extended self-test routine recommended polling time:( 202) minutes. SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 091 082 006Pre-fail Always - 226717799 3 Spin_Up_Time0x0003 093 093 000Pre-fail Always - 0 4 Start_Stop_Count0x0032 100 100 020Old_age Always - 13 5 Reallocated_Sector_Ct 0x0033 100 100 036Pre-fail Always - 15 7 Seek_Error_Rate 0x000f 081 060 030
Re: [patch 2/4] Expose Power Management Policy option to users
On Tue, 31 Jul 2007 15:27:34 +0900 Tejun Heo [EMAIL PROTECTED] wrote: Jeff Garzik wrote: Any chance the SCSI peeps could ACK this, and then let me include it in the ALPM patchset in the libata tree? ATA link PS is pretty complex with HIPM, DIPM and AHCI ALPM. I'm not sure whether this three level knob would be sufficient. It might be good enough if we're gonna develop extensive in-kernel black/white list specifying which method works on which combination but my gut tells me that it's best left to userland (probably in the form of per-notebook PS profile). I think what you are saying is that you'd like a way to use your HIPM and DIPM without ALPM on the AHCI driver. Fine - it's really easy to add these levels later - if they don't make sense at the sysfs interface we can add module params to specify the definition of min_power as being performed via HIPM and DIPM instead of ALPM - although as of yet we have no evidence what so ever that this method actually adds value over ALPM. Adding to the fun, there are quite a few broken devices out there which act weirdly when link PS actions are taken. OK - this is why I added the blacklist for this feature. Also, I generally don't think AHCI ALPM is a good idea. It doesn't have 'cool down' period before entering PS state which unnecessarily hampers performance and might increase chance of device malfunction. might increase? How about some actual examples of where you've shown this to be a problem? I can assert that I think ALPM is a good idea, because I've never had a report of it causing problems. Windows has been using this feature for a very long time - and you have to admit that they have a pretty large market share. Nobody is complaining about ALPM increasing device malfunction, so unless you have proof it seems insane to nak due to this. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2/4] Expose Power Management Policy option to users
Hello, Kristen. Kristen Carlson Accardi wrote: On Tue, 31 Jul 2007 23:45:25 +0900 Tejun Heo [EMAIL PROTECTED] wrote: Anyways, I don't really think this attribute belongs to SCSI sysfs hierarchy. There currently isn't any alternative but sysfs is part of userland visible interface and putting something into SCSI sysfs hierarchy just because libata doesn't have one doesn't look like a good idea. sysfs isn't far from being detached from kobject and driver model. I think it would be best to wait a bit and build proper libata sysfs hierarchy which won't have to be changed later when libata departs from SCSI. Well, it isn't really a good way but IMHO it's better than sticking ATA power saving node into SCSI sysfs hierarchy. Wait a bit could be a very long time. Who is working on building this new libata sysfs support now? I happen to be working on sysfs these days and guess why I started working on sysfs. :-) Disassociating sysfs from driver model is probably one or two patchsets away. It could have happened earlier but I wanted to pace things a bit so that the changes receive some testing through release cycles. Check how many sysfs related changes went through .23-rc1 merge window and expect about the same influx during the next cycle; with some luck, it can be complete before .24-rc1 window. If the answer is no one, which I think it may be, do you want to hold up a feature that actually helps many people for possibly 6 months or more just because we have to go through scsi right now for our sysfs interface? I don't necessarily want to but delaying it might be the right thing to do. Anyways, if we're going to do an interim solution, I don't think mainline SCSI sysfs hierarchy is the right place. Do it with module parameter which carries large to be deprecated sign or maintain out of tree patches. on top of that, the last mail I got from James on this subject indicated that if we kept our granularity large with the power savings levels, SCSI can actually take advantage of this as well. Sure, we may have to tweak things around later, but isn't this what we do routinely? Holding up valuable features from the kernel because things aren't perfect yet seems really broken. As far as your complaints about broken hardware go, keep in mind that the patch set does provide a method of adding these disks to a blacklist, so I don't see that as a problem. And, the default for this feature is off, and user space would have to explicitly enable it. This is gonna be a bit long. Please be patient. Due to the generosity of the ATA committee, we have, by default, at least two ways to achieve link PS - HIPS and DIPS. I dunno why but someone thought we needed two. And then, ahci people thought automatic HIPS would be nice, which I fully agree, and added ALPM. Unfortunately, they mandated ALPM to kick in the moment command engine becomes idle, so most current implementations suffer unnecessary performance hit when ALPM is active. We have this crazy number of combinations. HIPS, DIPS, not-so-hot-looking ALPM and probably some number of broken devices which may be happy with some method but not with others. Some might be happy with PARTIAL but vomit on SLUMBER. I might be being too pessimistic but my last two years in IDE/ATA land taught me to be pessimistic about hardware quality. Heck, I bet you some of non-intel ahci implementations which claim to support ALPM will crap themselves when actually told to do so. If we're gonna do this like NCQ and gonna put knowledge about all the combinations into the driver. The suggested interface is good enough. Heck, we probably don't even need three levels. On and off should be enough if things are done right as link PS doesn't have to incur noticeable performance degradation. But to do that, we'll need to test a lot of combinations and it's gonna be much harder than NCQ (some ahci implementations don't seem to actually enter PS mode when instructed to do so via SControl but turning off the controller saves a lot of power. Maybe ALPM works better on such cases) and the blacklist will probably be longer. The alternate way is to export flexible interface to userland and let userland decide and if we're gonna do that. SCSI sysfs just isn't the place. Thanks. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hpt374 sata (Highpoint Rocket 1540)
Hello, I wrote: I've had a Highpoint Rocket 1540 (not RocketRAID) SATA controller for a while now, using a proprietary binary driver from Highpoint in a linux 2.4 kernel. The chipset is an hpt374. The hpt366 driver freezes on boot, as reported by others. Can we see a bootlog please? ... and the output of 'lspci -v' too. I wonders if R1540 could be identified via the subsystem ID -- SATA bridges HPT uses seem to have limitations WRT DMA modes, i.e. no MWDMA and UDMA modes 0, 4 and higher only are supported... Cheers, Bob Ham MBR, Sergei - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2/4] Expose Power Management Policy option to users
Kristen Carlson Accardi wrote: I think what you are saying is that you'd like a way to use your HIPM and DIPM without ALPM on the AHCI driver. Fine - it's really easy to add these levels later - if they don't make sense at the sysfs interface we can add module params to specify the definition of min_power as being performed via HIPM and DIPM instead of ALPM - although as of yet we have no evidence what so ever that this method actually adds value over ALPM. I don't really care whose PS implementation goes in. Believe me. I try to stay away from that. I don't even like my previous implementation. ALPM has unnecessary performance penalty is not applicable to non-ahci controller. Have you tested ALPM on non-intel ahcis? There are a lot out there these days. I don't think the interface you're suggesting is a good one. Do you? Also, I generally don't think AHCI ALPM is a good idea. It doesn't have 'cool down' period before entering PS state which unnecessarily hampers performance and might increase chance of device malfunction. might increase? How about some actual examples of where you've shown this to be a problem? I wouldn't have used might if I had actual examples. Well, feel free to disregard anything following the might. I just feel uneasy about jumping back and forth between PS and active states between consecutive commands. I can assert that I think ALPM is a good idea, because I've never had a report of it causing problems. Windows has been using this feature for a very long time - and you have to admit that they have a pretty large market share. Nobody is complaining about ALPM increasing device malfunction, so unless you have proof it seems insane to nak due to this. Is ALPM enabled by default? How do they deal with the performance degradation? -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Access beyond end of device
Hello, Since I've started using the pata_via driver in 2.6.22, I'm getting zillions of these messages: attempt to access beyond end of device sda: rw=0, want=156367809, limit=156365903 printk: 22 messages suppressed Buffer I/O error on device sda1, logical block 78183872 ... It also does happen with 2.6.23-rc3. Controller: 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP]) -- Luiz Fernando N. Capitulino - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Access beyond end of device
Em Tue, 31 Jul 2007 15:04:14 -0300 Luiz Fernando N. Capitulino [EMAIL PROTECTED] escreveu: | Since I've started using the pata_via driver in 2.6.22, I'm getting | zillions of these messages: | | | attempt to access beyond end of device | sda: rw=0, want=156367809, limit=156365903 | printk: 22 messages suppressed | Buffer I/O error on device sda1, logical block 78183872 | ... | | | It also does happen with 2.6.23-rc3. Heh, I'm pretty advanced, I meant 2.6.23-rc1. -- Luiz Fernando N. Capitulino - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2/4] Expose Power Management Policy option to users
Arjan van de Ven wrote: They were hardware problems. I don't think any amount of proper implementation can fix them. I have one DVD RAM somewhere in my pile of hardware which locks up solidly if any link PS mode is used and had a and the AHCI ALPM code decides to use power savings on this device? if so, please give us the idents so that we can add it to the blacklist as the first entry... (or can buy it to check it in detail first) Yeap, lemme check. It's TSSTcorpCD/DVDW SH-S183A with firmware revision SB01. Wanna check ID capability bits but 'hdparm -I /dev/sr0' is still broken and it's already past 3 am here. I'll report back tomorrow. Thanks. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Time Problems with 2.6.23-rc1-gf695baf2
On Tue, Jul 31, 2007 at 05:38:08PM +0200, Eric Sesterhenn / Snakebyte wrote:
* Pallipadi, Venkatesh ([EMAIL PROTECTED]) wrote:
This means things should work fine with processor.max_cstate=2 boot
option
as well. Can you please double check that.
yes, system boots fine with this kernel parameter
Also, please send in the acpidump from your system.
here we go, if you need some parameters to acpidump, just say so.
Eric,
Can you check the test patch below (over latest git) and let me know whether it
resolves the issue.
Thanks,
Venki
Enable C3 without bm control only for CST based C3.
Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED]
Index: linux-2.6/drivers/acpi/processor_idle.c
===
--- linux-2.6.orig/drivers/acpi/processor_idle.c2007-07-31
04:29:26.0 -0700
+++ linux-2.6/drivers/acpi/processor_idle.c 2007-07-31 04:52:50.0
-0700
@@ -969,11 +969,17 @@
}
if (pr-flags.bm_check) {
- /* bus mastering control is necessary */
if (!pr-flags.bm_control) {
- /* In this case we enter C3 without bus mastering */
- ACPI_DEBUG_PRINT((ACPI_DB_INFO,
- C3 support without bus mastering control\n));
+ if (pr-flags.has_cst != 1) {
+ /* bus mastering control is necessary */
+ ACPI_DEBUG_PRINT((ACPI_DB_INFO,
+ C3 support requires BM control\n));
+ return;
+ } else {
+ /* Here we enter C3 without bus mastering */
+ ACPI_DEBUG_PRINT((ACPI_DB_INFO,
+ C3 support without BM control\n));
+ }
}
} else {
/*
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2/4] Expose Power Management Policy option to users
On Wed, 01 Aug 2007 03:02:55 +0900 Tejun Heo [EMAIL PROTECTED] wrote: Kristen Carlson Accardi wrote: I think what you are saying is that you'd like a way to use your HIPM and DIPM without ALPM on the AHCI driver. Fine - it's really easy to add these levels later - if they don't make sense at the sysfs interface we can add module params to specify the definition of min_power as being performed via HIPM and DIPM instead of ALPM - although as of yet we have no evidence what so ever that this method actually adds value over ALPM. I don't really care whose PS implementation goes in. Believe me. I try to stay away from that. I don't even like my previous implementation. ALPM has unnecessary performance penalty is not applicable to non-ahci controller. Have you tested ALPM on non-intel ahcis? There are a lot out there these days. I have not personally, however there has been a lot of testing of this hardware feature both on other OS and for this particular implementation by the powertop community, which is composed of community members running all sorts of hardware. So far I've not received any bug reports wrt non-intel AHCI. As I mentioned several times, the default for ALPM is to be off anyway. I don't think the interface you're suggesting is a good one. Do you? I think if it's applicable to SCSI at all it is fine. If it is not, then I think we need to make do with the interface we are given. I do not think we should hold up a feature for libata sysfs integration. Also, I generally don't think AHCI ALPM is a good idea. It doesn't have 'cool down' period before entering PS state which unnecessarily hampers performance and might increase chance of device malfunction. might increase? How about some actual examples of where you've shown this to be a problem? I wouldn't have used might if I had actual examples. Well, feel free to disregard anything following the might. I just feel uneasy about jumping back and forth between PS and active states between consecutive commands. I want us to be careful about spreading a lot of unease without data to back it up. I can assert that I think ALPM is a good idea, because I've never had a report of it causing problems. Windows has been using this feature for a very long time - and you have to admit that they have a pretty large market share. Nobody is complaining about ALPM increasing device malfunction, so unless you have proof it seems insane to nak due to this. Is ALPM enabled by default? How do they deal with the performance degradation? I believe so, but I'm obviously not privvy to their implementation details. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] pata_sis: fix MWDMA for = UDMA66 chipsets and UDMA for UDMA33 chipsets
* Fix MWDMA timings setup in sis_old_set_dmamode() and sis_66_set_dmamode().
The old timings were overclocked (even worse behavior than sis5513 IDE driver
which depends on BIOS to program correct timings), the new timings are taken
from the datasheet (they match timings from ATA spec).
* Fix UDMA timings setup in sis_old_set_dmamode().
Misplaced pci_write_config_word() call resulted in UDMA timings never
being set.
* Fix comments for sis_133_early_set_dmamode() and sis_133_set_dmamode():
- only the former function handles early SiS 961 bridges
- both functions lack MWDMA timings setup
* Fix typos in sis_100_set_piomode() and sis_133_set_piomode() comments.
* Bump driver version.
Cc: Alan Cox [EMAIL PROTECTED]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
Sergei: Yes, I'm working on sis5513 IDE driver. :)
drivers/ata/pata_sis.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
Index: b/drivers/ata/pata_sis.c
===
--- a/drivers/ata/pata_sis.c
+++ b/drivers/ata/pata_sis.c
@@ -2,6 +2,7 @@
*pata_sis.c - SiS ATA driver
*
* (C) 2005 Red Hat [EMAIL PROTECTED]
+ * (C) 2007 Bartlomiej Zolnierkiewicz
*
*Based upon linux/drivers/ide/pci/sis5513.c
* Copyright (C) 1999-2000 Andre Hedrick [EMAIL PROTECTED]
@@ -35,7 +36,7 @@
#include sis.h
#define DRV_NAME pata_sis
-#define DRV_VERSION0.5.1
+#define DRV_VERSION0.5.2
struct sis_chipset {
u16 device; /* PCI host ID */
@@ -237,7 +238,7 @@ static void sis_old_set_piomode (struct
}
/**
- * sis_100_set_pioode - Initialize host controller PATA PIO timings
+ * sis_100_set_piomode - Initialize host controller PATA PIO timings
* @ap: Port whose timings we are configuring
* @adev: Device we are configuring for.
*
@@ -262,7 +263,7 @@ static void sis_100_set_piomode (struct
}
/**
- * sis_133_set_pioode - Initialize host controller PATA PIO timings
+ * sis_133_set_piomode - Initialize host controller PATA PIO timings
* @ap: Port whose timings we are configuring
* @adev: Device we are configuring for.
*
@@ -334,7 +335,7 @@ static void sis_old_set_dmamode (struct
int drive_pci = sis_old_port_base(adev);
u16 timing;
- const u16 mwdma_bits[] = { 0x707, 0x202, 0x202 };
+ const u16 mwdma_bits[] = { 0x008, 0x302, 0x301 };
const u16 udma_bits[] = { 0xE000, 0xC000, 0xA000 };
pci_read_config_word(pdev, drive_pci, timing);
@@ -342,15 +343,15 @@ static void sis_old_set_dmamode (struct
if (adev-dma_mode XFER_UDMA_0) {
/* bits 3-0 hold recovery timing bits 8-10 active timing and
the higer bits are dependant on the device */
- timing = ~ 0x870F;
+ timing = ~0x870F;
timing |= mwdma_bits[speed];
- pci_write_config_word(pdev, drive_pci, timing);
} else {
/* Bit 15 is UDMA on/off, bit 13-14 are cycle time */
speed = adev-dma_mode - XFER_UDMA_0;
timing = ~0x6000;
timing |= udma_bits[speed];
}
+ pci_write_config_word(pdev, drive_pci, timing);
}
/**
@@ -373,7 +374,7 @@ static void sis_66_set_dmamode (struct a
int drive_pci = sis_old_port_base(adev);
u16 timing;
- const u16 mwdma_bits[] = { 0x707, 0x202, 0x202 };
+ const u16 mwdma_bits[] = { 0x008, 0x302, 0x301 };
const u16 udma_bits[] = { 0xF000, 0xD000, 0xB000, 0xA000, 0x9000};
pci_read_config_word(pdev, drive_pci, timing);
@@ -432,8 +433,7 @@ static void sis_100_set_dmamode (struct
* @adev: Device to program
*
* Set UDMA/MWDMA mode for device, in host controller PCI config space.
- * Handles early SiS 961 bridges. Supports MWDMA as well unlike
- * the old ide/pci driver.
+ * Handles early SiS 961 bridges.
*
* LOCKING:
* None (inherited from caller).
@@ -467,8 +467,6 @@ static void sis_133_early_set_dmamode (s
* @adev: Device to program
*
* Set UDMA/MWDMA mode for device, in host controller PCI config space.
- * Handles early SiS 961 bridges. Supports MWDMA as well unlike
- * the old ide/pci driver.
*
* LOCKING:
* None (inherited from caller).
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Time Problems with 2.6.23-rc1-gf695baf2
* Venki Pallipadi ([EMAIL PROTECTED]) wrote:
Can you check the test patch below (over latest git) and let me know whether
it
resolves the issue.
the patch fixes the issue for me,
thanks a lot.
Eric
Enable C3 without bm control only for CST based C3.
Signed-off-by: Venkatesh Pallipadi [EMAIL PROTECTED]
Index: linux-2.6/drivers/acpi/processor_idle.c
===
--- linux-2.6.orig/drivers/acpi/processor_idle.c 2007-07-31
04:29:26.0 -0700
+++ linux-2.6/drivers/acpi/processor_idle.c 2007-07-31 04:52:50.0
-0700
@@ -969,11 +969,17 @@
}
if (pr-flags.bm_check) {
- /* bus mastering control is necessary */
if (!pr-flags.bm_control) {
- /* In this case we enter C3 without bus mastering */
- ACPI_DEBUG_PRINT((ACPI_DB_INFO,
- C3 support without bus mastering control\n));
+ if (pr-flags.has_cst != 1) {
+ /* bus mastering control is necessary */
+ ACPI_DEBUG_PRINT((ACPI_DB_INFO,
+ C3 support requires BM control\n));
+ return;
+ } else {
+ /* Here we enter C3 without bus mastering */
+ ACPI_DEBUG_PRINT((ACPI_DB_INFO,
+ C3 support without BM control\n));
+ }
}
} else {
/*
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2/4] Expose Power Management Policy option to users
On Wed, 01 Aug 2007 02:48:42 +0900 Tejun Heo [EMAIL PROTECTED] wrote: Hello, Kristen. Kristen Carlson Accardi wrote: On Tue, 31 Jul 2007 23:45:25 +0900 Tejun Heo [EMAIL PROTECTED] wrote: Anyways, I don't really think this attribute belongs to SCSI sysfs hierarchy. There currently isn't any alternative but sysfs is part of userland visible interface and putting something into SCSI sysfs hierarchy just because libata doesn't have one doesn't look like a good idea. sysfs isn't far from being detached from kobject and driver model. I think it would be best to wait a bit and build proper libata sysfs hierarchy which won't have to be changed later when libata departs from SCSI. Well, it isn't really a good way but IMHO it's better than sticking ATA power saving node into SCSI sysfs hierarchy. Wait a bit could be a very long time. Who is working on building this new libata sysfs support now? I happen to be working on sysfs these days and guess why I started working on sysfs. :-) Disassociating sysfs from driver model is probably one or two patchsets away. It could have happened earlier but I wanted to pace things a bit so that the changes receive some testing through release cycles. Check how many sysfs related changes went through .23-rc1 merge window and expect about the same influx during the next cycle; with some luck, it can be complete before .24-rc1 window. So at current rate of development and kernel release schedule, the best possible scenario is still 6 months away - whereas this patchset is already tested and ready for merging now. If the answer is no one, which I think it may be, do you want to hold up a feature that actually helps many people for possibly 6 months or more just because we have to go through scsi right now for our sysfs interface? I don't necessarily want to but delaying it might be the right thing to do. Anyways, if we're going to do an interim solution, I don't think mainline SCSI sysfs hierarchy is the right place. Do it with module parameter which carries large to be deprecated sign or maintain out of tree patches. Out of tree patches don't work. Nobody tests them. A module parameter will not work - we need to be able to expose the sysfs interface so that users may chose to turn the feature off and on at will - mainly according to their usage. For example, at boot time - you want ALPM off to maximize performance. Lets say when you are plugged into the wall socket, you leave it off, but then when you go on battery power you would want to enable it. on top of that, the last mail I got from James on this subject indicated that if we kept our granularity large with the power savings levels, SCSI can actually take advantage of this as well. Sure, we may have to tweak things around later, but isn't this what we do routinely? Holding up valuable features from the kernel because things aren't perfect yet seems really broken. As far as your complaints about broken hardware go, keep in mind that the patch set does provide a method of adding these disks to a blacklist, so I don't see that as a problem. And, the default for this feature is off, and user space would have to explicitly enable it. This is gonna be a bit long. Please be patient. Due to the generosity of the ATA committee, we have, by default, at least two ways to achieve link PS - HIPS and DIPS. I dunno why but someone thought we needed two. And then, ahci people thought automatic They thought we needed two because sometimes the device knows when it will be idle faster than the host can. this is why ALPM can determine idleness faster than any software algorithm on the host cpu can. You can use ALPM without having HIPM. You can also use it without having DIPM. HIPS would be nice, which I fully agree, and added ALPM. Unfortunately, they mandated ALPM to kick in the moment command engine becomes idle, so most current implementations suffer unnecessary performance hit when ALPM is active. unnecessary is subjective and at the moment, untrue. You have to make performance/power tradeoffs with anything, whether it's CPU or your AHCI controller. It's the current cost of getting out of these sleep states even if you aren't using ALPM but just doing HIPM or DIPM manually. But, this is why it's so critical to allow the user to control when ALPM is enabled dynamically - which this patchset does. The medium power setting is provided for users who wish to not go to SLUMBER and get the higher latency cost but still have some power savings. We have this crazy number of combinations. HIPS, DIPS, not-so-hot-looking ALPM and probably some number of broken devices which may be happy with some method but not with others. Some might be happy with PARTIAL but vomit on SLUMBER. I might be being too pessimistic but my last two years in IDE/ATA land taught me to be pessimistic about hardware
Re: hpt374 sata (Highpoint Rocket 1540)
On Tue, 2007-07-31 at 13:23 +0100, Alan Cox wrote: I'm wondering if there are or will be libata drivers, or any drivers for that matter, for hpt374-based SATA cards? The HPT374 is a PATA controller. Some people ship products with the HPT37x controllers and PATA/SATA bridges and those should work with the libata drivers. Might I suggest something along the lines of the attached patch in order to avoid future confusion? The information on which cards have which chips comes from the linuxmafia web page. Bob -- Bob Ham [EMAIL PROTECTED] --- Kconfig.old 2007-07-31 14:29:22.0 +0100 +++ Kconfig 2007-07-31 21:05:00.0 +0100 @@ -297,6 +297,11 @@ This option enables support for the majority of the later HPT PATA controllers via the new ATA layer. + Some SATA cards, like the Highpoint Rocket/RocketRAID + 1540/1542/1544/1640 and some versions of the RocketRAID 1520, + use these PATA controllers in conjunction with a SATA/PATA + bridge. This driver should support those cards, too. + If unsure, say N. config PATA_HPT3X2N @@ -304,7 +309,12 @@ depends on PCI EXPERIMENTAL help This option enables support for the N variant HPT PATA - controllers via the new ATA layer + controllers via the new ATA layer. + + Some SATA cards, like the Highpoint Rocket 1520 and some + versions of the RocketRAID 1520, use these PATA controllers + in conjunction with a SATA/PATA bridge. This driver should + support those cards, too. If unsure, say N. signature.asc Description: This is a digitally signed message part
Re: hpt374 sata (Highpoint Rocket 1540)
On Tue, 2007-07-31 at 21:52 +0400, Sergei Shtylyov wrote: Hello, I wrote: I've had a Highpoint Rocket 1540 (not RocketRAID) SATA controller for a while now, using a proprietary binary driver from Highpoint in a linux 2.4 kernel. The chipset is an hpt374. The hpt366 driver freezes on boot, as reported by others. Can we see a bootlog please? ... and the output of 'lspci -v' too. The machine locks hard when the driver is loaded so I can't give a full transcription, but here is the driver's output: HPT374: IDE controller at PCI slot :00:0d.0 ACPI: PCI Interrupt :00:0d.0[A] - GSI 16 (level, low) - IRQ 16 HPT374: chipset revision 7 HPT374: DPLL base: 48 MHz, f_CNT: 141, assuming 33 MHz PCI HPT374: using 50 MHz DPLL clock HPT374: 100% native mode on irq 16 ide2: BM-DMA at 0xec00-0xec07, BIOS settings: hde:DMA, hdf:pio ide3: BM-DMA at 0xec08-0xec0f, BIOS settings: hdg:DMA, hdh:pio ACPI: PCI Interrupt :00:0d.1[A] - GSI 16 (level, low) - IRQ 16 HPT374: no clock data saved by BIOS HPT374: DPLL base: 48 MHz, f_CNT: 93, assuming 33 MHz PCI HPT374: using 50 MHz DPLL clock ide4: BM-DMA at 0xed00-0xed07, BIOS settings: hdi:DMA, hdj:pio ide5: BM-DMA at 0xed08-0xed0f, BIOS settings: hdk:DMA, hdl:pio The pata_hpt37x driver is refusing to work as well but it doesn't crash the machine. Here is the relevant error message: hpt37x: DPLL did not stabilize. pata_hpt37x: BIOS has not set timing clocks. hpt37x: DPLL did not stabilize. lspci gives: 00:0d.0 RAID bus controller: Triones Technologies, Inc. HPT374 (rev 07) Subsystem: Triones Technologies, Inc. Unknown device 0001 Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16 I/O ports at efa0 [size=8] I/O ports at ef9c [size=4] I/O ports at ef90 [size=8] I/O ports at ef98 [size=4] I/O ports at ec00 [size=256] Expansion ROM at fe70 [disabled] [size=128K] Capabilities: [60] Power Management version 2 00:0d.1 RAID bus controller: Triones Technologies, Inc. HPT374 (rev 07) Subsystem: Triones Technologies, Inc. Unknown device 0001 Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16 I/O ports at eff0 [size=8] I/O ports at efe4 [size=4] I/O ports at efa8 [size=8] I/O ports at efe0 [size=4] I/O ports at ed00 [size=256] Capabilities: [60] Power Management version 2 Bob -- Bob Ham [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [PATCH libata-dev#upstream 2/2] libata: move EH repeat reporting into ata_eh_report()
On Tue, 31 Jul 2007 16:51:00 +0900, Tejun Heo wrote: EH is sometimes repeated without any error or action. For example, this happens when probing IDENTIFY fails because of a phantom device. In these cases, all the repeated EH does is making sure there is no unhandled error or pending action and return. This repeation is necessary to avoid losing any event which occurred while EH was in progress. Unfortunately, this dry run causes annonying EH pending after completion message. This patch moves the repeat reporting into ata_eh_report() such that it's more compact and skipped on dry runs. Signed-off-by: Tejun Heo [EMAIL PROTECTED] Cc: Mikael Pettersson [EMAIL PROTECTED] --- Mikael, please verify this removes the annonying message you're seeing. Yes, this patch eliminates the EH pending after completion message I've been getting. However, patch 1/2 in this set, don't skip EH report if action is pending, causes a bunch of new exception ... frozen messages: --- dmesg-2.6.23-rc12007-07-23 12:30:12.0 +0200 +++ - 2007-07-31 23:19:21.162137100 +0200 @@ -1,44 +1,44 @@ ... -pata_pdc2027x :04:02.0: PLL input clock 16660 kHz +pata_pdc2027x :04:02.0: PLL input clock 16651 kHz scsi0 : pata_pdc2027x scsi1 : pata_pdc2027x ata1: PATA max UDMA/133 cmd 0xf88297c0 ctl 0xf8829fda bmdma 0xf8829000 irq 18 ata2: PATA max UDMA/133 cmd 0xf88295c0 ctl 0xf8829dda bmdma 0xf8829008 irq 18 +ata1: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata1.00: ATA-7: ST3320620A, 3.AAD, max UDMA/100 ata1.00: 625142448 sectors, multi 16: LBA48 ata1.00: configured for UDMA/100 +ata2: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen scsi 0:0:0:0: Direct-Access ATA ST3320620A 3.AA PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 625142448 512-byte hardware sectors (320073 MB) sd 0:0:0:0: [sda] Write Protect is off @@ -255,10 +256,11 @@ scsi3 : ata_piix ata3: SATA max UDMA/133 cmd 0x0001ec00 ctl 0x0001e882 bmdma 0x0001e400 irq 19 ata4: SATA max UDMA/133 cmd 0x0001e800 ctl 0x0001e482 bmdma 0x0001e408 irq 19 +ata3: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen +ata4: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata4.00: ATAPI: TSSTcorpCD/DVDW SH-S183A, SB00, max UDMA/33 ata4.00: applying bridge limits ata4.00: configured for UDMA/33 -ata4: EH pending after completion, repeating EH (cnt=4) scsi 3:0:0:0: CD-ROMTSSTcorp CD/DVDW SH-S183A SB00 PQ: 0 ANSI: 5 ata_piix :00:1f.5: MAP [ P0 P2 P1 P3 ] ACPI: PCI Interrupt :00:1f.5[B] - GSI 19 (level, low) - IRQ 19 @@ -267,6 +269,8 @@ scsi5 : ata_piix ata5: SATA max UDMA/133 cmd 0x0001d400 ctl 0x0001d082 bmdma 0x0001c880 irq 19 ata6: SATA max UDMA/133 cmd 0x0001d000 ctl 0x0001cc02 bmdma 0x0001c888 irq 19 +ata5: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen +ata6: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. usbcore: registered new interface driver usbfs This is with both 1/2 and 2/2 applied, with only 2/2 applied the EH pending ... is gone and the new exception ... frozen don't appear. /Mikael - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hpt374 sata (Highpoint Rocket 1540)
Hi,
On Tuesday 31 July 2007, Bob Ham wrote:
On Tue, 2007-07-31 at 21:52 +0400, Sergei Shtylyov wrote:
Hello, I wrote:
I've had a Highpoint Rocket 1540 (not RocketRAID) SATA controller for
a while now, using a proprietary binary driver from Highpoint in a linux
2.4 kernel. The chipset is an hpt374. The hpt366 driver freezes on
boot, as reported by others.
Can we see a bootlog please?
... and the output of 'lspci -v' too.
The machine locks hard when the driver is loaded so I can't give a full
transcription, but here is the driver's output:
HPT374: IDE controller at PCI slot :00:0d.0
ACPI: PCI Interrupt :00:0d.0[A] - GSI 16 (level, low) - IRQ 16
HPT374: chipset revision 7
HPT374: DPLL base: 48 MHz, f_CNT: 141, assuming 33 MHz PCI
HPT374: using 50 MHz DPLL clock
HPT374: 100% native mode on irq 16
ide2: BM-DMA at 0xec00-0xec07, BIOS settings: hde:DMA, hdf:pio
ide3: BM-DMA at 0xec08-0xec0f, BIOS settings: hdg:DMA, hdh:pio
ACPI: PCI Interrupt :00:0d.1[A] - GSI 16 (level, low) - IRQ 16
HPT374: no clock data saved by BIOS
HPT374: DPLL base: 48 MHz, f_CNT: 93, assuming 33 MHz PCI
HPT374: using 50 MHz DPLL clock
ide4: BM-DMA at 0xed00-0xed07, BIOS settings: hdi:DMA, hdj:pio
ide5: BM-DMA at 0xed08-0xed0f, BIOS settings: hdk:DMA, hdl:pio
The pata_hpt37x driver is refusing to work as well but it doesn't crash
the machine. Here is the relevant error message:
hpt37x: DPLL did not stabilize.
pata_hpt37x: BIOS has not set timing clocks.
hpt37x: DPLL did not stabilize.
Does this patch change anything?
[PATCH] hpt366: always tune PIO
Cc: Sergei Shtylyov [EMAIL PROTECTED]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/pci/hpt366.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
Index: b/drivers/ide/pci/hpt366.c
===
--- a/drivers/ide/pci/hpt366.c
+++ b/drivers/ide/pci/hpt366.c
@@ -1,5 +1,5 @@
/*
- * linux/drivers/ide/pci/hpt366.c Version 1.10Jun 29, 2007
+ * linux/drivers/ide/pci/hpt366.c Version 1.11Jul 29, 2007
*
* Copyright (C) 1999-2003 Andre Hedrick [EMAIL PROTECTED]
* Portions Copyright (C) 2001 Sun Microsystems, Inc.
@@ -1265,10 +1265,10 @@ static void __devinit init_hwif_hpt366(i
if (new_mcr != old_mcr)
pci_write_config_byte(dev, hwif-select_data + 1, new_mcr);
- if (!hwif-dma_base) {
- hwif-drives[0].autotune = hwif-drives[1].autotune = 1;
+ hwif-drives[0].autotune = hwif-drives[1].autotune = 1;
+
+ if (hwif-dma_base == 0)
return;
- }
hwif-ultra_mask = hwif-cds-udma_mask;
hwif-mwdma_mask = 0x07;
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hpt374 sata (Highpoint Rocket 1540)
On Tue, 2007-07-31 at 23:32 +0200, Bartlomiej Zolnierkiewicz wrote: Hi, The hpt366 driver freezes on boot, as reported by others. Does this patch change anything? Unfortunately not. -- Bob Ham [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [PATCH 1/2] [IDE] Platform IDE driver
This doesn't mean that shift is better anyway. If everyone considers it better, I give up. But be warned that shift (stride) is not the only property characterizing register accesses -- the regs might be only accessible as 16/32-bit quantities, for example (16-bit is a real world example -- from Amiga or smth of that sort, IIRC). More importantly, reg-shift doesn't say what part of the bigger words to access. A common example is byte-wide registers on a 32-bit-only bus; it's about 50%-50% between connecting the registers to the low byte vs. connecting it to the byte with the lowest address. The only realistic way to handle all this is to put some knowledge into the device driver. This does of course also mean that no reg-shift property is needed; the device driver can look at your compatible property, instead. Why the heck should we care about the UART code taling about IDE?! Consistency? We're not obliged to be consistent with every piece of the kernel code. It would be nice to not name similar properties in the device tree dissimilarly. Kernel code doesn't come into the picture here. Segher - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] [POWERPC] MPC8349E-mITX: use platform IDE driver for CF interface
+ [EMAIL PROTECTED] {
+ compatible = mmio-ide;
+ device_type = ide;
Why not ata?
The hardware is called (E)IDE, the protocol is called ATA.
Or that's what I was told -- I think there's some historic
revisionism involved, too.
Also, what mmio-ide in the compat properly means in the context of
ide_platform which is able to handle both port and memory mapped IDE.
I think
we must get rid with this crap, and since this IDE register mapping is
pretty
much board specific, call it something like mpc8349emitx-ide instead.
mmio-ide simply is not specific enough. The device_type
should go, too.
If this IDE interface is board-specific, thee compatible
property should include the board vendor name and board
name. Oh, that's what emitx tries to do -- it could be
a bit clearer perhaps ;-)
Segher
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] [POWERPC] MPC8349E-mITX: use platform IDE driver for CF interface
The hardware is called (E)IDE, the protocol is called ATA. Or that's what I was told -- I think there's some historic revisionism involved, too. ATA is the interface and standards for the ANSI standards based disk attachment. IDE Integrated Drive Electronics is a marketing name used to cover all sorts of ST412 compatible-ish early interfaces that moved the brains onto the disk. IDE doesn't really mean much but brains on disk, ATA is a real standard. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Access beyond end of device
On Tue, 31 Jul 2007 15:15:46 -0300 Luiz Fernando N. Capitulino [EMAIL PROTECTED] wrote: Em Tue, 31 Jul 2007 15:04:14 -0300 Luiz Fernando N. Capitulino [EMAIL PROTECTED] escreveu: | Since I've started using the pata_via driver in 2.6.22, I'm getting | zillions of these messages: | | | attempt to access beyond end of device | sda: rw=0, want=156367809, limit=156365903 | printk: 22 messages suppressed | Buffer I/O error on device sda1, logical block 78183872 Does your disk have a host protected area set and if so are you telling libata to disable it ? - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Early ATA devices
So I've been doing a scan of the code versus the early ATA specifications (English translation not the original Latin ;)) I've found a couple of problem cases we don't deal with but I'm not sure matter, and an inconsistency #1 We assume identify works. Early ATA actually lists this command as optional #2 We don't allow for INIT_DEV_PARAMS failing which it may do on some early IDE pre ATA devices and the inconsistency We check ATA 4 || non-LBA capable when deciding whether to issue INIT_DEV_PARAMS. ATA 4+ however mandate LBA so the second case isn't theoretically at least possible. Aside from those cases the command issue (but not the detection paths) appear to be clean for everything from ST412 upwards providing a drive is being used in 16 head mode and does its own write precompensation selection. So in theory we can persuade libata to drive original MFM/RLL disks with relatively few changes - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2/4] Expose Power Management Policy option to users
Kristen Carlson Accardi wrote: So at current rate of development and kernel release schedule, the best possible scenario is still 6 months away - whereas this patchset is already tested and ready for merging now. The best possible scenario is .24-rc1 merge window with or without waiting. With waiting, the best possible scenario is harder to achieve tho. Out of tree patches don't work. Nobody tests them. A module parameter will not work - we need to be able to expose the sysfs interface so that users may chose to turn the feature off and on at will - mainly according to their usage. For example, at boot time - you want ALPM off to maximize performance. Lets say when you are plugged into the wall socket, you leave it off, but then when you go on battery power you would want to enable it. You can turn on and off dynamically using a module parameter. Although it's not a pretty interface, it should work as an interim solution if we absolutely must merge ALPM now. Due to the generosity of the ATA committee, we have, by default, at least two ways to achieve link PS - HIPS and DIPS. I dunno why but someone thought we needed two. And then, ahci people thought automatic They thought we needed two because sometimes the device knows when it will be idle faster than the host can. this is why ALPM can determine idleness faster than any software algorithm on the host cpu can. You can use ALPM without having HIPM. You can also use it without having DIPM. I see. I get that one way is better than another in some way. I'm just not convinced whether the advantage is substantial enough to justify the complexity. HIPS would be nice, which I fully agree, and added ALPM. Unfortunately, they mandated ALPM to kick in the moment command engine becomes idle, so most current implementations suffer unnecessary performance hit when ALPM is active. unnecessary is subjective and at the moment, untrue. You have to make performance/power tradeoffs with anything, whether it's CPU or your AHCI controller. It's the current cost of getting out of these sleep states even if you aren't using ALPM but just doing HIPM or DIPM manually. Having short cool-down time would remove most of performance degradation and I'm pretty sure power consumption would stay about the same. But, this is why it's so critical to allow the user to control when ALPM is enabled dynamically - which this patchset does. The medium power setting is provided for users who wish to not go to SLUMBER and get the higher latency cost but still have some power savings. Note that PARTIAL also incurs noticeable performance degradation. I understand you are being cautious based on your prior experience, but again we still have no data to show that we are going to have a lot of problems. Perhaps we should proceed optimistically and deal with problems when they actually occur rather than block something on a bet. I would agree with you, merge it and see the fireworks in -mm if it didn't involve user visible API. We have an API decision to make here and it hasn't been sufficiently considered yet. The alternate way is to export flexible interface to userland and let userland decide and if we're gonna do that. SCSI sysfs just isn't the place. How about a patch? I'd love to have a flexible interface to userland, it was my goal to provide this with the sysfs files. The requirement is that the users be able to turn ALPM off and on dynamically, and to be able to chose the power savings level you want - i.e. SLUMBER vs. PARTIAL - perferrably not using those terms since users really shouldn't need to know AHCI terminology just to chose a power management level. As I wrote before, which level of interface to export to userland is related with where to put the knowledge about working and broken combinations. Unfortunately, we don't have data to support one way or the other at the moment. All I'm saying is that we should be cautious before introducing user-land visible interface which lives in SCSI sysfs as it's unknown whether it would fit the reality or not. Sorry that I don't have an alternative patch now, but something which can relieve the situation is being worked on, so let's give it some time and see how things turn out. Things have to wait till the next -rc1 window anyway. Thanks. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2/4] Expose Power Management Policy option to users
Kristen Carlson Accardi wrote: I don't think the interface you're suggesting is a good one. Do you? I think if it's applicable to SCSI at all it is fine. If it is not, then I think we need to make do with the interface we are given. I do not think we should hold up a feature for libata sysfs integration. Well, I guess we'll have to agree to disagree here and leave the decision to James and Jeff. I can assert that I think ALPM is a good idea, because I've never had a report of it causing problems. Windows has been using this feature for a very long time - and you have to admit that they have a pretty large market share. Nobody is complaining about ALPM increasing device malfunction, so unless you have proof it seems insane to nak due to this. Is ALPM enabled by default? How do they deal with the performance degradation? I believe so, but I'm obviously not privvy to their implementation details. It would be *really* great if we can find more about how they do it. How and when it's enabled and on which systems. Is it possible to find this out? -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH libata-dev#upstream 2/2] libata: move EH repeat reporting into ata_eh_report()
Mikael Pettersson wrote: This is with both 1/2 and 2/2 applied, with only 2/2 applied the EH pending ... is gone and the new exception ... frozen don't appear. Thanks. Right, I'll drop the first patch. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: errors on shutdown with PMP
Hello, Marc Bejarano wrote: Counters don't look too friendly. Do you happen to have another drive of the same model? about 100 or so of them ;) Cool. If so, can you post smartctl -a of the drive? here are the other two drives in the unhappy lv: [--snip--] 5 Reallocated_Sector_Ct 0x0033 100 100 036Pre-fail Always - 15 198 Offline_Uncorrectable 0x0010 100 100 000Old_age Offline - 0 [--snip--] 5 Reallocated_Sector_Ct 0x0033 100 100 036Pre-fail Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000Old_age Offline - 0 Offline uncorrectable is zero on both drives. I think it's likely that the not-responding drive is faulty. Note that write command usually complete right after it fills the buffer, so write errors often show up on cache flush. Also, write failure usually means that even reallocation failed and the drive is in pretty bad shape. Thanks. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: IRQ Delivery Problem for MCP65
[cc'ing linux-pci and quoting whole body.] Any ideas? Craig Block wrote: --- Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] wrote: --- Craig Block [EMAIL PROTECTED] wrote: I'm having trouble getting Linux to see any hard drives on an ASUS M2N-X motherboard with an MCP65 (nForce 520) chipset. When the kernel probes the AHCI controllers, it hangs for a minute or so on each one and returns the following; ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) I googled for some more info about similar issues and found very similar problem being discussed on Gentoo forum: The important part is here: when I disabled Message Signaled Interrupts (MSI and MSI-X) under Bus Options in the kernel, the problem magically went away (disabling MSI) which indicates IRQ routing problems (as suspected from dmesg output and also stated by Tejun). Have you already tried disabling MSI IRQs with pci=nomsi (not nomsi) or even completely disabling CONFIG_PCI_MSI support? Thanks a ton, building the kernel with PCI_MSI not set did the trick. Attempting to disable MSI using pci=nomsi at the boot prompt did not eliminate the problem. I had to build the kernel without MSI support. There's a few interesting differences in the dmesg output with PCI_MSI=y and PCI_MSI not set; With PCI_MSI not set; ata1: SATA max UDMA/133 cmd 0xf8804100 ctl 0x bmdma 0x irq 5 ata2: SATA max UDMA/133 cmd 0xf8804180 ctl 0x bmdma 0x irq 5 ata3: SATA max UDMA/133 cmd 0xf8804200 ctl 0x bmdma 0x irq 5 ata4: SATA max UDMA/133 cmd 0xf8804280 ctl 0x bmdma 0x irq 5 With PCI_MSI=y; ata1: SATA max UDMA/133 cmd 0xf8804100 ctl 0x bmdma 0x irq 219 ata2: SATA max UDMA/133 cmd 0xf8804180 ctl 0x bmdma 0x irq 219 ata3: SATA max UDMA/133 cmd 0xf8804200 ctl 0x bmdma 0x irq 219 ata4: SATA max UDMA/133 cmd 0xf8804280 ctl 0x bmdma 0x irq 219 Also, there's a spurous interrupt message that appears with PCI_MSI=y; spurious 8259A interrupt: IRQ7. I attached the two dmesg instances for reference. -- tejun 6896k available (1556k kernel code, 24352k reserved, 545k data, 168k init, 1179392k highmem) virtual kernel memory layout: fixmap : 0xfffaf000 - 0xf000 ( 320 kB) pkmap : 0xff80 - 0xffc0 (4096 kB) vmalloc : 0xf880 - 0xff7fe000 ( 111 MB) lowmem : 0xc000 - 0xf800 ( 896 MB) .init : 0xc031 - 0xc033a000 ( 168 kB) .data : 0xc0285011 - 0xc030d70c ( 545 kB) .text : 0xc010 - 0xc0285011 (1556 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 4824.67 BogoMIPS (lpj=2412339) Mount-cache hash table entries: 512 CPU: After generic identify, caps: 078bfbff ebd3fbff 2001 011d CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) CPU: After all inits, caps: 078bfbff ebd3fbff 0410 2001 011d Compat vDSO mapped to e000. CPU: AMD Athlon(tm) 64 Processor 3800+ stepping 01 Checking 'hlt' instruction... OK. ExtINT not setup in hardware but reported by MP table ENABLING IO-APIC IRQs ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=0 pin2=0 NET: Registered protocol family 16 PCI: PCI BIOS revision 3.00 entry at 0xf0031, last bus=5 PCI: Using configuration type 1 Setting up standard PCI resources SCSI subsystem initialized libata version 2.21 loaded. PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) PCI: Transparent bridge - :00:08.0 PCI: Using IRQ router default [10de/0441] at :00:01.0 PCI-APIC IRQ transform: :00:01.1[A] - IRQ 10 PCI-APIC IRQ transform: :00:02.0[A] - IRQ 11 PCI-APIC IRQ transform: :00:02.1[B] - IRQ 10 PCI-APIC IRQ transform: :00:07.0[B] - IRQ 11 PCI-APIC IRQ transform: :00:0a.0[A] - IRQ 5 PCI-APIC IRQ transform: :01:08.0[A] - IRQ 11 PCI-APIC IRQ transform: :04:00.0[A] - IRQ 11 PCI: Bridge: :00:08.0 IO window: d000-dfff MEM window: dbf0-dbff Time: tsc clocksource has been installed. PREFETCH window: 8800-880f PCI: Bridge: :00:0b.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: :00:0c.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: :00:0d.0 IO window: e000-efff MEM window: dc00-dfff PREFETCH window: c000-cfff PCI: Bridge: :00:0e.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Setting latency timer of device :00:08.0 to 64 PCI: Setting latency timer of device :00:0b.0 to 64 PCI: Setting latency timer of device :00:0c.0 to 64 PCI: Setting latency timer of device :00:0d.0 to 64 PCI: Setting latency timer of device :00:0e.0 to 64 NET: Registered protocol family 2 IP route cache hash table
Re: [PATCH libata-dev#upstream 1/2] libata: don't skip EH report if action is pending
Tejun Heo wrote: Don't skip EH report if action is pending. Signed-off-by: Tejun Heo [EMAIL PROTECTED] Jeff, this patch needs other changes to avoid exception message during initial probing. Please drop it for now and just apply the second patch. Thanks. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
