Re: PROBLEM: ata_piix.c for the ICH5 SATA Controller.
Johny Mail list wrote: This patch don't work in my case. Please elaborate on "don't work". Especially with a 2.6.18.8 kernel. Sorry but i don't understand when you say : "you may need to patch the patch to contain the correct PCI IDs (from lspci -n)." Where is the correct line in the patch to set the correct value. My lspci -n line for the sata is "00:1f.2 0101: 8086:24d1 (rev 02)". No need to patch it then, as the patch already has 8086:24d1. Cheers - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: ata_piix.c for the ICH5 SATA Controller.
2007/6/29, Mark Lord <[EMAIL PROTECTED]>: Mark Lord wrote: > Johny Mail list wrote: >> 2007/6/28, Mark Lord <[EMAIL PROTECTED]>: >>> I have an ugly (but working) hack for the ICH5 ata_piix driver >>> to support hot insertion/removal of drives, but I don't know if/when >>> I'll be pushing it upstream. >> >> Yes it hang permanently there, after this messages i generally reboot >> the server. >> Yes it not support SATA drive hot insertion/removal, but i have make >> the same test on windows. I unplug one disk when i'm logged and the >> system don't stop. The drive is removed from the devices list. >> >> If you can give me the patch for testing it... I would give you my >> returns about the good/bad functioning in my case. > > Okay, Here is a working patch for a very specific variant of ICH5. > If your PCI IDs don't match what the patch is looking for, > then it should have no effect -- you may need to patch the patch > to contain the correct PCI IDs (from lspci -n). > * * * > > Implement ICH5 chipset handling for drive hot insertion/removal. > This cannot go upstream, as it conflicts with a more generic > polled-hotplug framework that is currently in development. > > Hot-inserted drives are automatically detected within a second or two, > and are ready-to-use within 30 seconds or so. This could be even faster, > but the 2.6.18.8 libata implementation of error-handling is what slows > us down here. ... This patch was for 2.6.18.8 -- it *might* apply to newer kernels, but I haven't ported it forward yet. Cheers This patch don't work in my case. Sorry but i don't understand when you say : "you may need to patch the patch to contain the correct PCI IDs (from lspci -n)." Where is the correct line in the patch to set the correct value. My lspci -n line for the sata is "00:1f.2 0101: 8086:24d1 (rev 02)". I have noticed that the lock of my kernel is when the "ata4: port failed to respond (30sec, Status 0xd0)" is written. Thk - 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: PROBLEM: ata_piix.c for the ICH5 SATA Controller.
Mark Lord wrote: Johny Mail list wrote: 2007/6/28, Mark Lord <[EMAIL PROTECTED]>: I have an ugly (but working) hack for the ICH5 ata_piix driver to support hot insertion/removal of drives, but I don't know if/when I'll be pushing it upstream. Yes it hang permanently there, after this messages i generally reboot the server. Yes it not support SATA drive hot insertion/removal, but i have make the same test on windows. I unplug one disk when i'm logged and the system don't stop. The drive is removed from the devices list. If you can give me the patch for testing it... I would give you my returns about the good/bad functioning in my case. Okay, Here is a working patch for a very specific variant of ICH5. If your PCI IDs don't match what the patch is looking for, then it should have no effect -- you may need to patch the patch to contain the correct PCI IDs (from lspci -n). * * * Implement ICH5 chipset handling for drive hot insertion/removal. This cannot go upstream, as it conflicts with a more generic polled-hotplug framework that is currently in development. Hot-inserted drives are automatically detected within a second or two, and are ready-to-use within 30 seconds or so. This could be even faster, but the 2.6.18.8 libata implementation of error-handling is what slows us down here. ... This patch was for 2.6.18.8 -- it *might* apply to newer kernels, but I haven't ported it forward yet. Cheers - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: ata_piix.c for the ICH5 SATA Controller.
Johny Mail list wrote:
2007/6/28, Mark Lord <[EMAIL PROTECTED]>:
I have an ugly (but working) hack for the ICH5 ata_piix driver
to support hot insertion/removal of drives, but I don't know if/when
I'll be pushing it upstream.
Yes it hang permanently there, after this messages i generally reboot
the server.
Yes it not support SATA drive hot insertion/removal, but i have make
the same test on windows. I unplug one disk when i'm logged and the
system don't stop. The drive is removed from the devices list.
If you can give me the patch for testing it... I would give you my
returns about the good/bad functioning in my case.
Okay, Here is a working patch for a very specific variant of ICH5.
If your PCI IDs don't match what the patch is looking for,
then it should have no effect -- you may need to patch the patch
to contain the correct PCI IDs (from lspci -n).
* * *
Implement ICH5 chipset handling for drive hot insertion/removal.
This cannot go upstream, as it conflicts with a more generic
polled-hotplug framework that is currently in development.
Hot-inserted drives are automatically detected within a second or two,
and are ready-to-use within 30 seconds or so. This could be even faster,
but the 2.6.18.8 libata implementation of error-handling is what slows
us down here.
Hot-removed drives are *not* noticed by the kernel until the next
time they are accessed. If you want this to happen quickly,
then just launch a script like this from /etc/inittab at boot time:
#!/bin/bash
( while ( /bin/true ) ; do /sbin/hdparm -C /dev/sd[a-z] ; sleep 5 ; done )
&>/dev/null &
This hack is not ready for mainline -- it's awaiting Tejun's hp-poll patches,
with which it will eventually be integrated.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
diff -u --recursive --new-file --exclude-from=old/Documentation/dontdiff
old/drivers/scsi/ata_piix.c linux/drivers/scsi/ata_piix.c
--- old/drivers/scsi/ata_piix.c 2007-04-20 14:08:46.0 -0400
+++ linux/drivers/scsi/ata_piix.c 2007-06-26 07:23:21.0 -0400
@@ -106,6 +106,8 @@
PIIX_FLAG_AHCI = (1 << 27), /* AHCI possible */
PIIX_FLAG_CHECKINTR = (1 << 28), /* make sure PCI INTx enabled */
+ PIIX_HOTPLUG_POLL_TM= (2 * (HZ)), /* polling interval for hotplug
*/
+
/* combined mode. if set, PATA is channel 0.
* if clear, PATA is channel 1.
*/
@@ -150,6 +152,171 @@
const struct piix_map_db *map_db;
};
+struct piix_port_priv {
+ int pcs_hotplug_supported;
+ struct timer_list hotplug_timer;
+ u16 old_pcs;
+};
+
+static u32 ich_scr_read (struct ata_port *ap, unsigned int reg)
+{
+ u32 scr = 0;
+
+ if (reg == SCR_STATUS) {
+ struct piix_port_priv *pp = ap->private_data;
+ if (pp && pp->pcs_hotplug_supported) {
+ u16 pcs, port_bit = (1 << ap->hard_port_no);
+ struct pci_dev *pdev = to_pci_dev(ap->dev);
+
+ pci_read_config_word(pdev, ICH5_PCS, &pcs);
+ if (pcs & (port_bit << 4))
+ scr = 0x113;
+ }
+ }
+ return scr;
+}
+
+static int ich_port_offline (struct ata_port *ap)
+{
+ struct pci_dev *pdev;
+ u16 pcs, port_bit = (1 << ap->hard_port_no);
+ struct piix_port_priv *pp = ap->private_data;
+ u8 ostatus;
+ unsigned int offline;
+
+ if (!pp || !pp->pcs_hotplug_supported) {
+ u32 sstatus;
+ if (!sata_scr_read(ap, SCR_STATUS, &sstatus) && (sstatus & 0xf)
!= 0x3)
+ return 1;
+ return 0;
+ }
+
+ /*
+* ICH5 with a mostly good/working PCS register.
+* The only flaw is, it doesn't seem to detect *removed* drives
+* unless we toggle the enable line before checking.
+*/
+ ostatus = ata_altstatus(ap);
+ pdev = to_pci_dev(ap->dev);
+ pci_read_config_word(pdev, ICH5_PCS, &pcs);
+ offline = ((pcs & (port_bit << 4)) == 0);
+
+ if (!offline) {
+ unsigned int usecs;
+
+ /* Cycle PCS register to force it to redetect devices: */
+ pci_write_config_word(pdev, ICH5_PCS, pcs & ~port_bit);
+ udelay(1);
+ pci_write_config_word(pdev, ICH5_PCS, 0x0003);
+
+ /* Wait for SATA PHY to sync up; typically 5->6 usecs */
+ for (usecs = 0; usecs < 100; ++usecs) {
+ pci_read_config_word(pdev, ICH5_PCS, &pcs);
+ offline = ((pcs & (port_bit << 4)) == 0);
+ if (!offline)
+ break;
+ udelay(1);
+ }
+ if (!offline) {
+ unsigned int msecs;
+ /* Wait for drive to become not-BUSY, typically 10->62
msecs */
+ for (msecs = 1; msecs < 150; msecs += 3) {
+
Re: PROBLEM: ata_piix.c for the ICH5 SATA Controller.
2007/6/28, Mark Lord <[EMAIL PROTECTED]>: Johny Mail list wrote: > Hi, > I have a big problem with my SC1425 Dell Servers. I use Linux Software > RAID on them and last days i make few tests on them to see the > reaction of the server about different situations like : power > failure, hard drive prower failure ... > And the hard drive prower failure was the problem. When i unplug the > electric alimentation (or the SATA port cable) of one of my two hard > drives in RAID 1, the server stop responding and i get this messages : > ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen > ata4.00: cmd e7/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0 > res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) > ata4: port is slow to respond, please be patient (Status 0xd0) > ata4: port failed to respond (30sec, Status 0xd0) > ata4: soft resetting port Does it hang permanently there, or keep failing with additional messages? According to Intel, their ICH5 hardware does not support ordinary SATA drive hot insertion/removal. In practice, it can be made to work but not via the standard SATA mechanism. My own observation is that the hardware (CPU) locks up hard when libata attempts to issue SRST (reset) to a removed SATA drive on ICH5. I have an ugly (but working) hack for the ICH5 ata_piix driver to support hot insertion/removal of drives, but I don't know if/when I'll be pushing it upstream. Cheers Yes it hang permanently there, after this messages i generally reboot the server. Yes it not support SATA drive hot insertion/removal, but i have make the same test on windows. I unplug one disk when i'm logged and the system don't stop. The drive is removed from the devices list. If you can give me the patch for testing it... I would give you my returns about the good/bad functioning in my case. Salutation - 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: PROBLEM: ata_piix.c for the ICH5 SATA Controller.
Johny Mail list wrote: Hi, I have a big problem with my SC1425 Dell Servers. I use Linux Software RAID on them and last days i make few tests on them to see the reaction of the server about different situations like : power failure, hard drive prower failure ... And the hard drive prower failure was the problem. When i unplug the electric alimentation (or the SATA port cable) of one of my two hard drives in RAID 1, the server stop responding and i get this messages : ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata4.00: cmd e7/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0 res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata4: port is slow to respond, please be patient (Status 0xd0) ata4: port failed to respond (30sec, Status 0xd0) ata4: soft resetting port Does it hang permanently there, or keep failing with additional messages? According to Intel, their ICH5 hardware does not support ordinary SATA drive hot insertion/removal. In practice, it can be made to work but not via the standard SATA mechanism. My own observation is that the hardware (CPU) locks up hard when libata attempts to issue SRST (reset) to a removed SATA drive on ICH5. I have an ugly (but working) hack for the ICH5 ata_piix driver to support hot insertion/removal of drives, but I don't know if/when I'll be pushing it upstream. Cheers - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
PROBLEM: ata_piix.c for the ICH5 SATA Controller.
Hi, I have a big problem with my SC1425 Dell Servers. I use Linux Software RAID on them and last days i make few tests on them to see the reaction of the server about different situations like : power failure, hard drive prower failure ... And the hard drive prower failure was the problem. When i unplug the electric alimentation (or the SATA port cable) of one of my two hard drives in RAID 1, the server stop responding and i get this messages : ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata4.00: cmd e7/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0 res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata4: port is slow to respond, please be patient (Status 0xd0) ata4: port failed to respond (30sec, Status 0xd0) ata4: soft resetting port I have make the same test on a SC1435 (the next generation) with a broadcom chispset/driver and everything is fine when i unplug one hard drive. On SC1425 my bios is up-to-date from the dell website. You can contact me for more informations, or some tests. Thanks for your work My informations : # sh scripts/ver_linux Linux raid-test 2.6.21.5-grsec-ipvs #1 SMP Thu Jun 28 13:51:34 CEST 2007 x86_64 GNU/Linux Gnu C 4.1.2 Gnu make 3.81 binutils 2.17 util-linux 2.12r mount 2.12r module-init-tools 3.3-pre2 e2fsprogs 1.40-WIP Linux C Library2.3.6 Dynamic linker (ldd) 2.3.6 Procps 3.2.7 Net-tools 1.60 Console-tools 0.2.3 Sh-utils 5.97 udev 105 # cat /proc/ioports -001f : dma1 0020-0021 : pic1 0040-0043 : timer0 0050-0053 : timer1 0060-006f : keyboard 0070-0077 : rtc 0080-008f : dma page reg 00a0-00a1 : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : :00:1f.1 0170-0177 : libata 01f0-01f7 : :00:1f.1 01f0-01f7 : libata 0376-0376 : :00:1f.1 0376-0376 : libata 03c0-03df : vga+ 03f6-03f6 : :00:1f.1 03f6-03f6 : libata 03f8-03ff : serial 0800-087f : :00:1f.0 0800-087f : pnp 00:07 0800-0803 : ACPI PM1a_EVT_BLK 0804-0805 : ACPI PM1a_CNT_BLK 0808-080b : ACPI PM_TMR 0828-082f : ACPI GPE0_BLK 0880-08bf : :00:1f.0 0880-08bf : pnp 00:07 08c0-08df : pnp 00:07 08e0-08e3 : pnp 00:07 0c00-0c0f : pnp 00:07 0c10-0c1f : pnp 00:07 0ca0-0ca7 : pnp 00:07 0ca9-0cab : pnp 00:07 0cf8-0cff : PCI conf1 cc80-cc8f : :00:1f.2 cc80-cc8f : libata cc98-cc9b : :00:1f.2 cc98-cc9b : libata cca0-cca7 : :00:1f.2 cca0-cca7 : libata ccb0-ccb3 : :00:1f.2 ccb0-ccb3 : libata ccb8-ccbf : :00:1f.2 ccb8-ccbf : libata ccc0-ccdf : :00:1d.1 ccc0-ccdf : uhci_hcd cce0-ccff : :00:1d.0 cce0-ccff : uhci_hcd d000-dfff : PCI Bus #04 d800-d8ff : :04:0d.0 dcc0-dcff : :04:03.0 dcc0-dcff : e1000 e000-efff : PCI Bus #01 e000-efff : PCI Bus #02 ecc0-ecff : :02:04.0 ecc0-ecff : e1000 fc00-fc0f : :00:1f.1 fc00-fc0f : libata # cat /proc/iomem -0009 : System RAM - : Crash kernel 0010-1ffb : System RAM 0020-004dcfb9 : Kernel code 004dcfba-0059c9ef : Kernel data 1ffc-1ffcfbff : ACPI Tables 1ffcfc00-1fffefff : reserved 2000-23ff : :00:1f.1 e000-efff : PCI MMCONFIG 0 e000-efff : reserved f000-f7ff : PCI Bus #04 f000-f7ff : :04:0d.0 fe50-fe6f : PCI Bus #04 fe50-fe51 : :04:0d.0 fe5d-fe5d : :04:0d.0 fe5e-fe5f : :04:03.0 fe5e-fe5f : e1000 fe70-feaf : PCI Bus #01 fe90-feaf : PCI Bus #02 fe9e-fe9f : :02:04.0 fe9e-fe9f : e1000 feb0-feb003ff : :00:1d.7 feb0-feb003ff : ehci_hcd fec0-fec8 : reserved fec0-fec00fff : IOAPIC 0 fec8-fec80fff : IOAPIC 1 fed0-fed003ff : HPET 0 fee0-fee00fff : Local APIC ffb0- : reserved # lspci -vvv 00:00.0 Host bridge: Intel Corporation E7520 Memory Controller Hub (rev 09) Subsystem: Dell PowerEdge SC1425 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Message Signalled Interrupts: Mask- 64bit- Queue=0/1 Enable- Address: fee0 Data: Capabilities: [64] Express Root Port (Slot-) IRQ 0 Device: Supported: MaxPayload 256 bytes, PhantFunc 0, ExtTag- Device: Latency L0s <64ns, L1 <1us Device: Errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+ Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- Device: MaxPayload 256 bytes, MaxReadReq 128 bytes Li
