Re: 2.6.23-rc7-mm1 AHCI ATA errors -- won't boot
Jeff Garzik wrote:
Would it also be possible for you to send along 'hdparm --Istdout'
output for your config disk thingy, /dev/sdd ?
One of these appears in my system as well (ASUS P5W-DH Deluxe
mainboard). Here's the hdparm output:
/dev/sdb:
0040 3fff c837 0010 003f
3030 3030 3030 305f 5f5f 5f5f
5f5f 5f5f 5f30 5f41 0003 3e00 0004 5247
4c31 3033 3634 436f 6e66 6967 2020 4469
736b 2020 2020 2020 2020 2020 2020 2020
2020 2020 2020 2020 2020 2020 2020 8001
2f00 4000 0200 0007 3fff 0010
003f fc10 00fb 0101 0280 0407
0003 0078 0078 0078 0078
0201
007e 001b 0068 5060 4000 1000 4000
407f fffe c0fe
0001
0001
0017 2040
baa5
Since about 2.6.17 or 2.6.18, it has been causing long delays while booting:
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00: qc timeout (cmd 0xec)
ata2.00: failed to IDENTIFY (I/O error, err_mask=0x5)
ata2: port is slow to respond, please be patient (Status 0x80)
ata2: COMRESET failed (errno=-16)
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00: ATA-6: Config Disk, RGL10364, max UDMA/133
ata2.00: 640 sectors, multi 1: LBA
ata2.00: configured for UDMA/133
Bernd
-
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: Chipset selection for NCQ md RAID
If support for SiI chips is the most robust, would multiple SiI3124/SiI3132 chips be most reliable? Or is support for something They seem to be pretty solid. We have a few bugs with multiple cards in bugzilla mostly with Nvidia boards. I suspect a hardware issue but we don't really 100% know. What about port multiplier support? Do they ever introduce stability problems with the drivers? The PMP code is pretty new and it means more overhead. Is native libata support for high-density Areca cards planned? Does anyone know if the manufacturer driver is good enough to rely on for the above config to just work? I'd personally like to stay within libata. (Comments from any Areca Linux users with an ARC-1261ML? http://www.areca.com.tw/products/pcie341.htm) I'm not sure where this got to but there was certainly some stuff going on to try and get Areca polished and merged, but it seems to have gone quiet of late. - 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] ahci: enable GHC.AE bit before set GHC.HR
On Wed, 26 Sep 2007 00:03:19 -0400 Jeff Garzik [EMAIL PROTECTED] wrote: Peer Chen wrote: According to the description of section 5.2.2.1 and 10.1.2 of AHCI specification rev1_1/rev1_2, GHC.HR shall only be set to ¡®1¡¯ by software when GHC.AE is set to ¡®1¡¯. Signed-off-by: Peer Chen [EMAIL PROTECTED] --- --- linux-2.6.23-rc7/drivers/ata/ahci.c.orig2007-09-20 11:01:55.0 -0400 +++ linux-2.6.23-rc7/drivers/ata/ahci.c 2007-09-20 11:07:31.0 -0400 @@ -834,6 +834,10 @@ static int ahci_reset_controller(struct void __iomem *mmio = host-iomap[AHCI_PCI_BAR]; u32 tmp; +/* turn on AHCI mode before controller reset*/ +writel(HOST_AHCI_EN, mmio + HOST_CTL); +(void) readl(mmio + HOST_CTL); /* flush */ applied the attached patch, inspired by yours. NAK - mmio is an iomap so writel and readl are the wrong things to use - 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, ata_piix, add notebook to short cable list
Hello,
hopefully the right place for this small patch. My new notebook uses
a short 40 pin ide-cable, ata_piix therefore disabled UDMA33. I added
the chipset ids to the short-cable list and now everything working fine
with UDMA100.
regards
---
--- linux-2.6.22/drivers/ata/ata_piix.c 2007-07-09 01:32:17.0 +0200
+++ linux/drivers/ata/ata_piix.c2007-09-13 21:08:07.0 +0200
@@ -578,6 +578,7 @@
{ 0x27DF, 0x0005, 0x0280 }, /* ICH7 on Acer 5602WLMi */
{ 0x27DF, 0x1025, 0x0110 }, /* ICH7 on Acer 3682WLMi */
{ 0x27DF, 0x1043, 0x1267 }, /* ICH7 on Asus W5F */
+ { 0x27DF, 0x103C, 0x30A1 }, /* ICH7 on HP Compaq nc2400 */
{ 0x24CA, 0x1025, 0x0061 }, /* ICH4 on ACER Aspire 2023WLMi */
/* end marker */
{ 0, }
-
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, ata_piix, add notebook to short cable list
On Wed, 26 Sep 2007 12:52:07 +0200
Andreas Messer [EMAIL PROTECTED] wrote:
Hello,
hopefully the right place for this small patch. My new notebook uses
a short 40 pin ide-cable, ata_piix therefore disabled UDMA33. I added
the chipset ids to the short-cable list and now everything working fine
with UDMA100.
regards
---
--- linux-2.6.22/drivers/ata/ata_piix.c 2007-07-09 01:32:17.0
+0200
+++ linux/drivers/ata/ata_piix.c 2007-09-13 21:08:07.0 +0200
@@ -578,6 +578,7 @@
{ 0x27DF, 0x0005, 0x0280 }, /* ICH7 on Acer 5602WLMi */
{ 0x27DF, 0x1025, 0x0110 }, /* ICH7 on Acer 3682WLMi */
{ 0x27DF, 0x1043, 0x1267 }, /* ICH7 on Asus W5F */
+ { 0x27DF, 0x103C, 0x30A1 }, /* ICH7 on HP Compaq nc2400 */
{ 0x24CA, 0x1025, 0x0061 }, /* ICH4 on ACER Aspire 2023WLMi */
/* end marker */
{ 0, }
-
Acked-by: Alan Cox [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] ahci: enable GHC.AE bit before set GHC.HR
Alan Cox wrote: On Wed, 26 Sep 2007 00:03:19 -0400 Jeff Garzik [EMAIL PROTECTED] wrote: Peer Chen wrote: According to the description of section 5.2.2.1 and 10.1.2 of AHCI specification rev1_1/rev1_2, GHC.HR shall only be set to ¡®1¡¯ by software when GHC.AE is set to ¡®1¡¯. Signed-off-by: Peer Chen [EMAIL PROTECTED] --- --- linux-2.6.23-rc7/drivers/ata/ahci.c.orig2007-09-20 11:01:55.0 -0400 +++ linux-2.6.23-rc7/drivers/ata/ahci.c 2007-09-20 11:07:31.0 -0400 @@ -834,6 +834,10 @@ static int ahci_reset_controller(struct void __iomem *mmio = host-iomap[AHCI_PCI_BAR]; u32 tmp; +/* turn on AHCI mode before controller reset*/ +writel(HOST_AHCI_EN, mmio + HOST_CTL); +(void) readl(mmio + HOST_CTL); /* flush */ applied the attached patch, inspired by yours. NAK - mmio is an iomap so writel and readl are the wrong things to use The patch is consistent with the rest of the driver. You are welcome to submit a patch to convert ahci to using ioremap. Jeff - 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: Polling (was Re: [PATCHSET 2/2] implement PMP support, take 6)
Jeff Garzik wrote: [--snip--] There, even the concept of port is fluid, and the libata EH model of freezing and thawing a port (with the desired irq-off result) just doesn't fit the hardware. Well, the current model was developed while struggling with the first generation PMP hardware which had a lot of quirks. More focus was on making the system run and keeping it that way. Anyways, now that the quirks are better understood, I think we can make PMP register access irq-driven safely. [--snip--] As such, polling is simply an outmoded concept. It does not make sense on new hardware, and forcing design decisions down that path only lead to a cascade of similar design decisions -- pmp_read polling being just one example of such a result. For pmp read/write, I agree that IRQ driven access would be better but even for fairly advanced controllers like ahci or sil24, I think resetting-by-polling is a good idea. Just like the Linux kernel MM platform API presents 3 levels of page table entries, even when the hardware may only have 2, libata high level API _must_ be implemented as 100% asynchronous event driven API. Or allow both? If the default implementation chooses to use polling -- i.e. all SFF controllers -- that's fine. But in the new SAS/SATA world its clear that we have far too many polling-related assumptions as it is. Polling just flat out doesn't make sense on modern SAS/SATA -- and even a couple modern SATA controllers. On such controllers, we are notified immediately via interrupt even in the event of errors. For SAS, I don't have any strong opinion. For SATA, I think we definitely need to allow or even prefer polling for host port resets. Is this NACK on the patchset or can we update PMP access later? -- 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] pata_pdc202xx_old
I've been doing an audit of this driver to try and find out why we have
problems with some Clevo boxes that use it. Didn't get anywhere other
than to discover all the bug reporters I have use vmware, which may or
may not be chance.
In the process however I did find out our MWDMA2 performance was a bit
low and code review showed the MWDMA0/2 timings are reversed due to a
thinko in the table ordering
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --exclude-from /usr/src/exclude --new-file --recursive
linux.vanilla-2.6.23rc6-mm1/drivers/ata/pata_pdc202xx_old.c
linux-2.6.23rc6-mm1/drivers/ata/pata_pdc202xx_old.c
--- linux.vanilla-2.6.23rc6-mm1/drivers/ata/pata_pdc202xx_old.c 2007-09-18
15:32:51.0 +0100
+++ linux-2.6.23rc6-mm1/drivers/ata/pata_pdc202xx_old.c 2007-09-26
14:03:33.430372856 +0100
@@ -9,7 +9,7 @@
* First cut with LBA48/ATAPI
*
* TODO:
- * Channel interlock/reset on both required
+ * Channel interlock/reset on both required ?
*/
#include linux/kernel.h
@@ -22,7 +22,7 @@
#include linux/libata.h
#define DRV_NAME pata_pdc202xx_old
-#define DRV_VERSION 0.4.2
+#define DRV_VERSION 0.4.3
static int pdc2026x_cable_detect(struct ata_port *ap)
{
@@ -106,9 +106,9 @@
{ 0x20, 0x01 }
};
static u8 mdma_timing[3][2] = {
- { 0x60, 0x03 },
- { 0x60, 0x04 },
{ 0xe0, 0x0f },
+ { 0x60, 0x04 },
+ { 0x60, 0x03 },
};
u8 r_bp, r_cp;
@@ -139,6 +139,9 @@
*
* In UDMA3 or higher we have to clock switch for the duration of the
* DMA transfer sequence.
+ *
+ * Note: The host lock held by the libata layer protects
+ * us from two channels both trying to set DMA bits at once
*/
static void pdc2026x_bmdma_start(struct ata_queued_cmd *qc)
@@ -187,6 +190,9 @@
*
* After a DMA completes we need to put the clock back to 33MHz for
* PIO timings.
+ *
+ * Note: The host lock held by the libata layer protects
+ * us from two channels both trying to set DMA bits at once
*/
static void pdc2026x_bmdma_stop(struct ata_queued_cmd *qc)
@@ -206,7 +212,6 @@
iowrite32(0, atapi_reg);
iowrite8(ioread8(clock) ~sel66, clock);
}
- /* Check we keep host level locking here */
/* Flip back to 33Mhz for PIO */
if (adev-dma_mode = XFER_UDMA_2)
iowrite8(ioread8(clock) ~sel66, clock);
-
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_ns87415: Initial cut at 87415/87560 IDE support
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --exclude-from /usr/src/exclude --new-file --recursive
linux.vanilla-2.6.23rc6-mm1/drivers/ata/Kconfig
linux-2.6.23rc6-mm1/drivers/ata/Kconfig
--- linux.vanilla-2.6.23rc6-mm1/drivers/ata/Kconfig 2007-09-18
15:32:51.0 +0100
+++ linux-2.6.23rc6-mm1/drivers/ata/Kconfig 2007-09-24 17:07:45.0
+0100
@@ -450,6 +450,15 @@
If unsure, say N.
+config PATA_NS87415
+ tristate Nat Semi NS87410 PATA support (Experimental)
+ depends on PCI EXPERIMENTAL
+ help
+ This option enables support for the National Semiconductor
+ NS87415 PCI-IDE controller.
+
+ If unsure, say N.
+
config PATA_OPTI
tristate OPTI621/6215 PATA support (Very Experimental)
depends on PCI EXPERIMENTAL
diff -u --exclude-from /usr/src/exclude --new-file --recursive
linux.vanilla-2.6.23rc6-mm1/drivers/ata/libata-core.c
linux-2.6.23rc6-mm1/drivers/ata/libata-core.c
--- linux.vanilla-2.6.23rc6-mm1/drivers/ata/libata-core.c 2007-09-18
15:32:51.0 +0100
+++ linux-2.6.23rc6-mm1/drivers/ata/libata-core.c 2007-09-20
15:04:41.0 +0100
diff -u --exclude-from /usr/src/exclude --new-file --recursive
linux.vanilla-2.6.23rc6-mm1/drivers/ata/libata-sff.c
linux-2.6.23rc6-mm1/drivers/ata/libata-sff.c
--- linux.vanilla-2.6.23rc6-mm1/drivers/ata/libata-sff.c2007-09-18
15:32:51.0 +0100
+++ linux-2.6.23rc6-mm1/drivers/ata/libata-sff.c2007-09-24
18:47:50.0 +0100
@@ -156,7 +156,7 @@
{
struct ata_ioports *ioaddr = ap-ioaddr;
- tf-command = ata_check_status(ap);
+ tf-command = ap-ops-check_status(ap);
tf-feature = ioread8(ioaddr-error_addr);
tf-nsect = ioread8(ioaddr-nsect_addr);
tf-lbal = ioread8(ioaddr-lbal_addr);
diff -u --exclude-from /usr/src/exclude --new-file --recursive
linux.vanilla-2.6.23rc6-mm1/drivers/ata/Makefile
linux-2.6.23rc6-mm1/drivers/ata/Makefile
--- linux.vanilla-2.6.23rc6-mm1/drivers/ata/Makefile2007-09-18
15:32:51.0 +0100
+++ linux-2.6.23rc6-mm1/drivers/ata/Makefile2007-09-24 17:38:14.0
+0100
@@ -40,6 +40,7 @@
obj-$(CONFIG_PATA_JMICRON) += pata_jmicron.o
obj-$(CONFIG_PATA_NETCELL) += pata_netcell.o
obj-$(CONFIG_PATA_NS87410) += pata_ns87410.o
+obj-$(CONFIG_PATA_NS87415) += pata_ns87415.o
obj-$(CONFIG_PATA_OPTI)+= pata_opti.o
obj-$(CONFIG_PATA_OPTIDMA) += pata_optidma.o
obj-$(CONFIG_PATA_MPC52xx) += pata_mpc52xx.o
diff -u --exclude-from /usr/src/exclude --new-file --recursive
linux.vanilla-2.6.23rc6-mm1/drivers/ata/pata_ns87415.c
linux-2.6.23rc6-mm1/drivers/ata/pata_ns87415.c
--- linux.vanilla-2.6.23rc6-mm1/drivers/ata/pata_ns87415.c 1970-01-01
01:00:00.0 +0100
+++ linux-2.6.23rc6-mm1/drivers/ata/pata_ns87415.c 2007-09-24
18:51:18.243315320 +0100
@@ -0,0 +1,466 @@
+/*
+ *pata_ns87415.c - NS87415 (non PARISC) PATA
+ *
+ * (C) 2005 Red Hat [EMAIL PROTECTED]
+ *
+ *This is a fairly generic MWDMA controller. It has some limitations
+ *as it requires timing reloads on PIO/DMA transitions but it is otherwise
+ *fairly well designed.
+ *
+ *This driver assumes the firmware has left the chip in a valid ST506
+ *compliant state, either legacy IRQ 14/15 or native INTA shared. You
+ *may need to add platform code if your system fails to do this.
+ *
+ *The same cell appears in the 87560 controller used by some PARISC
+ *systems. This has its own special mountain of errata.
+ *
+ *TODO:
+ * Test PARISC SuperIO
+ * Get someone to test on SPARC
+ * Implement lazy pio/dma switching for better performance
+ * 8bit shared timing.
+ * See if we need to kill the FIFO for ATAPI
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/pci.h
+#include linux/init.h
+#include linux/blkdev.h
+#include linux/delay.h
+#include linux/device.h
+#include scsi/scsi_host.h
+#include linux/libata.h
+#include linux/ata.h
+
+#define DRV_NAME pata_ns87415
+#define DRV_VERSION0.0.1
+
+/**
+ * ns87415_set_mode - Initialize host controller mode timings
+ * @ap: Port whose timings we are configuring
+ * @adev: Device whose timings we are configuring
+ * @mode: Mode to set
+ *
+ * Program the mode registers for this controller, channel and
+ * device. Because the chip is quite an old design we have to do this
+ * for PIO/DMA switches.
+ *
+ * LOCKING:
+ * None (inherited from caller).
+ */
+
+static void ns87415_set_mode(struct ata_port *ap, struct ata_device *adev, u8
mode)
+{
+ struct pci_dev *dev = to_pci_dev(ap-host-dev);
+ int unit= 2 * ap-port_no + adev-devno;
+ int timing = 0x44 + 2 * unit;
+ unsigned long T = 10 / 3; /* PCI clocks */
+ struct ata_timing t;
+ u16 clocking;
+ u8 iordy;
+ u8 status;
+
+
Re: 2.6.23-rc7-mm1 AHCI ATA errors -- won't boot
Bernd Schmidt wrote: One of these appears in my system as well (ASUS P5W-DH Deluxe mainboard). Here's the hdparm output: Yup, same mainboard here. Since about 2.6.17 or 2.6.18, it has been causing long delays while booting: ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata2.00: qc timeout (cmd 0xec) ata2.00: failed to IDENTIFY (I/O error, err_mask=0x5) ata2: port is slow to respond, please be patient (Status 0x80) ata2: COMRESET failed (errno=-16) ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata2.00: ATA-6: Config Disk, RGL10364, max UDMA/133 ata2.00: 640 sectors, multi 1: LBA ata2.00: configured for UDMA/133 And yup, same problem with the painful boot delays since 2.6.18. Tejun indicated that a fix would get merged with 2.6.23, but that didn't happen. Here's hoping something makes it into .24! Berck - 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] ahci: enable GHC.AE bit before set GHC.HR
Alan Cox wrote: NAK - mmio is an iomap so writel and readl are the wrong things to use The patch is consistent with the rest of the driver. You are welcome to submit a patch to convert ahci to using ioremap. You could just flip the relevant function to use ioread while you are tidying it up, instead of spreading new bugs into the code. No, as I just noted above, the proper fix for this driver is to use ioremap rather than pci_iomap. Adding support to ahci for legacy PIO is completely pointless. Jeff - 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] ahci: enable GHC.AE bit before set GHC.HR
On Wed, 26 Sep 2007 10:33:28 -0400 Jeff Garzik [EMAIL PROTECTED] wrote: Alan Cox wrote: NAK - mmio is an iomap so writel and readl are the wrong things to use The patch is consistent with the rest of the driver. You are welcome to submit a patch to convert ahci to using ioremap. You could just flip the relevant function to use ioread while you are tidying it up, instead of spreading new bugs into the code. No, as I just noted above, the proper fix for this driver is to use ioremap rather than pci_iomap. Adding support to ahci for legacy PIO is completely pointless. iomap isn't just for legacy PIO. It allows us to handle future weird mappings in ways ioremap cannot. - 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] ahci: enable GHC.AE bit before set GHC.HR
Alan Cox wrote: On Wed, 26 Sep 2007 10:33:28 -0400 Jeff Garzik [EMAIL PROTECTED] wrote: Alan Cox wrote: NAK - mmio is an iomap so writel and readl are the wrong things to use The patch is consistent with the rest of the driver. You are welcome to submit a patch to convert ahci to using ioremap. You could just flip the relevant function to use ioread while you are tidying it up, instead of spreading new bugs into the code. No, as I just noted above, the proper fix for this driver is to use ioremap rather than pci_iomap. Adding support to ahci for legacy PIO is completely pointless. iomap isn't just for legacy PIO. It allows us to handle future weird mappings in ways ioremap cannot. Well, when needs dictate, we can re-evaluate. Until some future date arrives where it matters for all these MMIO-only drivers and hardware, it's just a bunch of pointless overhead for ahci and many other drivers. It's also just not the Linux way to punish everybody for some edge case that so far only exists in email conversations. The beauty of libata is that you don't have to enforce such a pogrom across all libata drivers. The libata high level API is completely free from ioread/iowrite junk, leaving each driver to make its own decision. Jeff - 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] Fix HPA handling regression
Restore the support for handling drives that report one sector too many
(ie SCSI not ATA style). This worked before the HPA update but was
removed in that process
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --exclude-from /usr/src/exclude --recursive
linux.vanilla-2.6.23rc8-mm1/drivers/ata/libata-core.c
linux-2.6.23rc8-mm1/drivers/ata/libata-core.c
--- linux.vanilla-2.6.23rc8-mm1/drivers/ata/libata-core.c 2007-09-26
16:46:48.515293608 +0100
+++ linux-2.6.23rc8-mm1/drivers/ata/libata-core.c 2007-09-26
17:02:06.530734048 +0100
@@ -921,7 +921,8 @@
*max_sectors = ata_tf_to_lba48(tf);
else
*max_sectors = ata_tf_to_lba(tf);
-
+if (dev-horkage ATA_HORKAGE_HPA_SIZE)
+ (*max_sectors)--;
return 0;
}
@@ -3957,6 +3958,10 @@
{ WDC WD2500JD-00HBB0, WD-WMAL71490727, ATA_HORKAGE_BROKEN_HPA },
{ MAXTOR 6L080L4, A93.0500, ATA_HORKAGE_BROKEN_HPA },
+ /* Devices which report 1 sector over size HPA */
+ { ST340823A, NULL, ATA_HORKAGE_HPA_SIZE, },
+ { ST320413A, NULL, ATA_HORKAGE_HPA_SIZE, },
+
/* End Marker */
{ }
};
diff -u --new-file --exclude-from /usr/src/exclude --recursive
linux.vanilla-2.6.23rc8-mm1/include/linux/libata.h
linux-2.6.23rc8-mm1/include/linux/libata.h
--- linux.vanilla-2.6.23rc8-mm1/include/linux/libata.h 2007-09-26
16:46:57.844875296 +0100
+++ linux-2.6.23rc8-mm1/include/linux/libata.h 2007-09-26 17:11:56.215088400
+0100
@@ -315,7 +315,8 @@
ATA_HORKAGE_NONCQ = (1 2), /* Don't use NCQ */
ATA_HORKAGE_MAX_SEC_128 = (1 3), /* Limit max sects to 128 */
ATA_HORKAGE_BROKEN_HPA = (1 4), /* Broken HPA */
- ATA_HORKAGE_DRQ = (1 5), /* Device forgets to clear DRQ
on error */
+ ATA_HORKAGE_HPA_SIZE= (1 5), /* Reports native size off by
one */
+ ATA_HORKAGE_DRQ = (1 6), /* Device forgets to clear DRQ
on error */
/* DMA mask for user DMA control: User visible values do not
renumber */
-
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_hpt3x2n: Clean up DPLL stuff
Nobody commented when I asked for review earlier so it must be ok 8)
Lets stick it in -mm to be sure
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --exclude-from /usr/src/exclude --recursive
linux.vanilla-2.6.23rc8-mm1/drivers/ata/pata_hpt37x.c
linux-2.6.23rc8-mm1/drivers/ata/pata_hpt37x.c
--- linux.vanilla-2.6.23rc8-mm1/drivers/ata/pata_hpt37x.c 2007-09-26
16:46:48.0 +0100
+++ linux-2.6.23rc8-mm1/drivers/ata/pata_hpt37x.c 2007-09-18
16:44:32.0 +0100
@@ -1,5 +1,5 @@
/*
- * Libata driver for the highpoint 37x and 30x UDMA66 ATA controllers.
+ * Libata driver for the highpoint 37x and 30x UDMA ATA controllers.
*
* This driver is heavily based upon:
*
@@ -844,6 +844,46 @@
/* Never went stable */
return 0;
}
+
+static void *hpt_tune_function(struct pci_dev *dev, int dpll, int clock_slot)
+{
+ static const int MHz[4] = { 33, 40, 50, 66 };
+ /*
+* For non UDMA133 capable devices we should
+* use a 50MHz DPLL by choice
+*/
+ unsigned int f_low, f_high;
+ int adjust;
+
+ f_low = (MHz[clock_slot] * 48) / MHz[dpll];
+ f_high = f_low + 2;
+ if (clock_slot 1)
+ f_high += 2;
+ /* Select the DPLL clock. */
+ pci_write_config_byte(dev, 0x5b, 0x21);
+ pci_write_config_dword(dev, 0x5C, (f_high 16) | f_low | 0x100);
+
+ for(adjust = 0; adjust 8; adjust++) {
+ if (hpt37x_calibrate_dpll(dev))
+ break;
+ /* See if it'll settle at a fractionally different clock */
+ if (adjust 1)
+ f_low -= adjust 1;
+ else
+ f_high += adjust 1;
+ pci_write_config_dword(dev, 0x5C, (f_high 16) | f_low |
0x100);
+ }
+ if (adjust == 8) {
+ printk(KERN_WARNING hpt37x: DPLL did not stabilize.\n);
+ return NULL;
+ }
+ printk(KERN_INFO hpt37x: Bus clock %dMHz, using DPLL.\n, MHz[dpll]);
+ if (dpll == 3)
+ return hpt37x_timings_66;
+ else
+ return hpt37x_timings_50;
+}
+
/**
* hpt37x_init_one - Initialise an HPT37X/302
* @dev: PCI device
@@ -944,7 +984,7 @@
u8 mcr1;
u32 freq;
int prefer_dpll = 1;
-
+ int hpt374alt = 0;
unsigned long iobase = pci_resource_start(dev, 4);
const struct hpt_chip *chip_table;
@@ -1046,16 +1086,28 @@
if (chip_table == hpt372a)
outb(0x0e, iobase + 0x9c);
+ /*
+* PLL must be done once
+*/
+
+ if (chip_table == hpt374 PCI_FUNC(dev-devfn) 1) {
+ /* The HPT374 secondary devfn is tuned to 50MHz when we find
+ the primary */
+ port_info = *port;
+ port_info.private_data = hpt37x_timings_50;
+ }
/* Some devices do not let this value be accessed via PCI space
according to the old driver */
-
freq = inl(iobase + 0x90);
if ((freq 12) != 0xABCDE) {
int i;
u8 sr;
u32 total = 0;
-
+
printk(KERN_WARNING pata_hpt37x: BIOS has not set timing
clocks.\n);
+ if (hpt374alt == 1)
+ printk(KERN_ERR pata_hpt37x: No saved frequency on
primary function.\n);
+
/* This is the process the HPT371 BIOS is reported to use */
for(i = 0; i 128; i++) {
@@ -1074,48 +1126,19 @@
clock_slot = hpt37x_clock_slot(freq, chip_table-base);
if (chip_table-clocks[clock_slot] == NULL || prefer_dpll) {
- /*
-* We need to try PLL mode instead
-*
-* For non UDMA133 capable devices we should
-* use a 50MHz DPLL by choice
-*/
- unsigned int f_low, f_high;
- int dpll, adjust;
-
/* Compute DPLL */
- dpll = (port-udma_mask 0xC0) ? 3 : 2;
-
- f_low = (MHz[clock_slot] * 48) / MHz[dpll];
- f_high = f_low + 2;
- if (clock_slot 1)
- f_high += 2;
-
- /* Select the DPLL clock. */
- pci_write_config_byte(dev, 0x5b, 0x21);
- pci_write_config_dword(dev, 0x5C, (f_high 16) | f_low |
0x100);
-
- for(adjust = 0; adjust 8; adjust++) {
- if (hpt37x_calibrate_dpll(dev))
- break;
- /* See if it'll settle at a fractionally different
clock */
- if (adjust 1)
- f_low -= adjust 1;
- else
- f_high += adjust 1;
- pci_write_config_dword(dev, 0x5C, (f_high 16) |
f_low | 0x100);
-
Re: [PATCH] pata_ns87415: Initial cut at 87415/87560 IDE support
Just some quick review and build test on PARISC.
On Wed, Sep 26, 2007 at 03:27:31PM +0100, Alan Cox wrote:
+ tristate Nat Semi NS87410 PATA support (Experimental)
NS87415 shirley?
+ *pata_ns87415.c - NS87415 (non PARISC) PATA
+ * Test PARISC SuperIO
works fine. :)
+static u8 ns87560_read_buggy(unsigned long port)
+{
+ int retries = SUPERIO_IDE_MAX_RETRIES;
+ do {
+ tmp = ioread8(port);
+ if (tmp != 0)
+ return tmp;
+ udelay(50);
+ } while(retries-- 0);
+ return tmp;
+}
u8 tmp is undefined, and port should be void __iomem * if we're going to
use pci-iomap accessors.
Works good otherwise, I was able to mount and copy a cd. Patch attached.
Queued a patch to move SUPERIO_IDE_MAX_RETRIES to asm/superio.h.
Cheers,
Kyle
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 5a5e677..fb460a6 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -433,7 +433,7 @@ config PATA_NS87410
If unsure, say N.
config PATA_NS87415
- tristate Nat Semi NS87410 PATA support (Experimental)
+ tristate Nat Semi NS87415 PATA support (Experimental)
depends on PCI EXPERIMENTAL
help
This option enables support for the National Semiconductor
diff --git a/drivers/ata/pata_ns87415.c b/drivers/ata/pata_ns87415.c
index 239628d..cfe4ef2 100644
--- a/drivers/ata/pata_ns87415.c
+++ b/drivers/ata/pata_ns87415.c
@@ -222,8 +222,9 @@ static int ns87415_check_atapi_dma(struct ata_queued_cmd
*qc)
* Work around chipset problems in the 87560 SuperIO chip
*/
-static u8 ns87560_read_buggy(unsigned long port)
+static u8 ns87560_read_buggy(void __iomem *port)
{
+ u8 tmp;
int retries = SUPERIO_IDE_MAX_RETRIES;
do {
tmp = ioread8(port);
-
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: Update the blacklist with a few more devices
Alan Cox wrote:
+ { ST3160812AS,3.AD, ATA_HORKAGE_NONCQ, },
Seagate firmware version is 5 chars. I think the correct string would
be 3.ADJ. Did you take it from SCSI probe message?
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: 2.6.23-rc7 - _random_ IRQ23 : nobody cared
Paul Rolland wrote: Hi David, On Mon, 24 Sep 2007 23:56:59 +0930 David Newall [EMAIL PROTECTED] wrote: Paul Rolland (???) wrote: Hell, IRQ 23 is shared between libata and my modem !!! Tried using the modem? When no problem is reported, both the libata part and the modem are OK. When the problem is reported, at that time, only libata is handling IRQ23 (the modem is a WinModem, and the driver is an out-kernel module), this is still kernel boot time, and the disabling of the IRQ makes my machine unable to complete the boot process (too many disk timeout). It could be good to be able to delay the disabling of an IRQ something long enough to allow all the modules to be loaded... Can you change driver load order such that the driver for the modem is loaded first? -- 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: 2.6.23-rc7-mm1 AHCI ATA errors -- won't boot
Berck E. Nash wrote: Bernd Schmidt wrote: One of these appears in my system as well (ASUS P5W-DH Deluxe mainboard). Here's the hdparm output: Yup, same mainboard here. Since about 2.6.17 or 2.6.18, it has been causing long delays while booting: ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata2.00: qc timeout (cmd 0xec) ata2.00: failed to IDENTIFY (I/O error, err_mask=0x5) ata2: port is slow to respond, please be patient (Status 0x80) ata2: COMRESET failed (errno=-16) ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata2.00: ATA-6: Config Disk, RGL10364, max UDMA/133 ata2.00: 640 sectors, multi 1: LBA ata2.00: configured for UDMA/133 And yup, same problem with the painful boot delays since 2.6.18. Tejun indicated that a fix would get merged with 2.6.23, but that didn't happen. Here's hoping something makes it into .24! Yeah, it is the sil4726 virtual device which is really crappy as an ATA device. About the fix, I thought PMP support would fix it but the controller on P5W-DH doesn't support PMP. It can only talk to the virtual device or the device attached to the first port depending on how the PMP chip is configured. It seems we'll have to blacklist the mainboard and skip or use modified reset sequence on the affected port, so that's why the fix was delayed. I'm currently on the road but I'll look into it when I get back (next week). 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: Improper disk shutdown with 2.6.22.6?
[cc'ing Henrique and Jeff] Robert wrote: Hello, When shutting down this system running Linux 2.6.22.6, I get a warning about the possibility that the disks are not properly shut down. When the power is turned off, it sounds like the disks aren't spun down (but I may be mistaken on that point). http://linux-ata.org/shutdown.html claims that kernels newer than 2.6.21 will always spin down the disks, but is this really the case? The manage_start_stop files exist. Tell me if you'd like more detailed information about configuration and hardware. You're on debian, right? You need to update your shutdown utilities. Henrique, what information should we put into the faq page to properly direct debian users to needed updates? 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
