CF flash IDE failure to attach with 2.6.20+

CF flash IDE failure to attach with 2.6.20+

[Andrew_hall]

We have a series of machines that use CF as a boot media. Since upgrading to
2.6.20 (tried .9-.14), system will boot (from the flash media) but then fail
to initialise the same media. Here is the dmesg from 2.6.20.14:

ata_piix 0000:00:1f.2: version 2.00ac7
ata_piix 0000:00:1f.2: MAP [ P0 P2 P1 P3 ]
ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) -> IRQ 19
PCI: Setting latency timer of device 0000:00:1f.2 to 64
ata1: SATA max UDMA/133 cmd 0xFA00 ctl 0xF902 bmdma 0xF600 irq 19
ata2: SATA max UDMA/133 cmd 0xF800 ctl 0xF702 bmdma 0xF608 irq 19
scsi0 : ata_piix
ata1.00: ATA-0, max MWDMA2, 990864 sectors: LBA
ata1.00: ata1: dev 0 multi count 0
ata1.00: applying bridge limits
ata1.00: configured for MWDMA2
scsi1 : ata_piix
ATA: abnormal status 0x7F on port 0xF807
scsi 0:0:0:0: Direct-Access     ATA      CF CARD 512MB    2007 PQ: 0 ANSI: 5
SCSI device sda: 990864 512-byte hdwr sectors (507 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: disabled, read cache: enabled, doesn't support
DPO or FUA
SCSI device sda: 990864 512-byte hdwr sectors (507 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: disabled, read cache: enabled, doesn't support
DPO or FUA
 sda:<3>ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in
         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1: port is slow to respond, please be patient (Status 0xd0)
ata1: port failed to respond (30 secs, Status 0xd0)
ata1: soft resetting port
ata1.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x80)
ata1.00: revalidation failed (errno=-5)
ata1: failed to recover some devices, retrying in 5 secs
ata1: soft resetting port
ata1.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x80)
ata1.00: revalidation failed (errno=-5)
ata1: failed to recover some devices, retrying in 5 secs
ata1: soft resetting port
ata1.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x80)
ata1.00: revalidation failed (errno=-5)
ata1.00: disabled
ata1: EH complete

At this point the CF is inoperable. I've had no issue prior to 2.6.20. Is
this a known issue? Is there a fix?
-- 
View this message in context: http://www.nabble.com/CF-flash-IDE-failure-to-attach-with-2.6.20%2B-tf3939321.html#a11172839
Sent from the linux-ide mailing list archive at Nabble.com.

Re: CF flash IDE failure to attach with 2.6.20+

[Tejun Heo]

Andrew_hall wrote:
> We have a series of machines that use CF as a boot media. Since upgrading to
> 2.6.20 (tried .9-.14), system will boot (from the flash media) but then fail
> to initialise the same media. Here is the dmesg from 2.6.20.14:
> 
> ata_piix 0000:00:1f.2: version 2.00ac7
> ata_piix 0000:00:1f.2: MAP [ P0 P2 P1 P3 ]
> ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) -> IRQ 19
> PCI: Setting latency timer of device 0000:00:1f.2 to 64
> ata1: SATA max UDMA/133 cmd 0xFA00 ctl 0xF902 bmdma 0xF600 irq 19
> ata2: SATA max UDMA/133 cmd 0xF800 ctl 0xF702 bmdma 0xF608 irq 19
> scsi0 : ata_piix
> ata1.00: ATA-0, max MWDMA2, 990864 sectors: LBA
> ata1.00: ata1: dev 0 multi count 0
> ata1.00: applying bridge limits
> ata1.00: configured for MWDMA2

For some reason, mwdma doesn't work in libata now.  I'm not sure why
tho.  Alan, can you enlighten us?

Thanks.

-- 
tejun

Re: CF flash IDE failure to attach with 2.6.20+

[Alan Cox]

On Mon, 18 Jun 2007 20:26:11 +0900
Tejun Heo <htejun@gmail.com> wrote:

> Andrew_hall wrote:
> > We have a series of machines that use CF as a boot media. Since upgrading to
> > 2.6.20 (tried .9-.14), system will boot (from the flash media) but then fail
> > to initialise the same media. Here is the dmesg from 2.6.20.14:
> > 
> > ata_piix 0000:00:1f.2: version 2.00ac7
> > ata_piix 0000:00:1f.2: MAP [ P0 P2 P1 P3 ]
> > ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) -> IRQ 19
> > PCI: Setting latency timer of device 0000:00:1f.2 to 64
> > ata1: SATA max UDMA/133 cmd 0xFA00 ctl 0xF902 bmdma 0xF600 irq 19
> > ata2: SATA max UDMA/133 cmd 0xF800 ctl 0xF702 bmdma 0xF608 irq 19
> > scsi0 : ata_piix
> > ata1.00: ATA-0, max MWDMA2, 990864 sectors: LBA
> > ata1.00: ata1: dev 0 multi count 0
> > ata1.00: applying bridge limits
> > ata1.00: configured for MWDMA2
> 
> For some reason, mwdma doesn't work in libata now.  I'm not sure why
> tho.  Alan, can you enlighten us?

No idea at all. All my hardware is still happy. 2.6.20 is an "old" kernel
however so it does predate the fixes you did for ata_piix mode setup ?

RE: CF flash IDE failure to attach with 2.6.20+

[Andrew Hall]

> >
> > For some reason, mwdma doesn't work in libata now.  I'm not sure why
> > tho.  Alan, can you enlighten us?
> 
> No idea at all. All my hardware is still happy. 2.6.20 is an "old"
> kernel
> however so it does predate the fixes you did for ata_piix mode setup ?

Old - yes, but more stable in all other respects it seems to the .21 series.
Are these patches available for me to try on .20 or are there dependencies
on 21? 

RE: CF flash IDE failure to attach with 2.6.20+

[Andrew Hall]

> > ata1.00: configured for MWDMA2
> 
> For some reason, mwdma doesn't work in libata now.  I'm not sure why
> tho.  Alan, can you enlighten us?

If the CF is having trouble with DMA, how do I specifically turn off DMA
only on this one bus?

Re: CF flash IDE failure to attach with 2.6.20+

[Tejun Heo]

[-- Attachment #1: Type: text/plain, Size: 732 bytes --]

Andrew Hall wrote:
>>> For some reason, mwdma doesn't work in libata now.  I'm not sure why
>>> tho.  Alan, can you enlighten us?
>> No idea at all. All my hardware is still happy. 2.6.20 is an "old"
>> kernel
>> however so it does predate the fixes you did for ata_piix mode setup ?
> 
> Old - yes, but more stable in all other respects it seems to the .21 series.
> Are these patches available for me to try on .20 or are there dependencies
> on 21? 
> 

I suppose you were using ata_piix too in older kernel, right?  Can you
post the boot dmesg of 2.6.19?  We used to ignore mwdma mode before and
enabled it at some point after that.  That may be the cause here.

Also, please try the attached patch on top of 2.6.20.

-- 
tejun

[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 2514 bytes --]

diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index 9c07b88..924e447 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -685,8 +685,14 @@ static void piix_set_piomode (struct ata_port *ap, struct ata_device *adev)
 	if (adev->class == ATA_DEV_ATA)
 		control |= 4;	/* PPE enable */
 
+	/* PIO configuration clears DTE unconditionally.  It will be
+	 * programmed in set_dmamode which is guaranteed to be called
+	 * after set_piomode if any DMA mode is available.
+	 */
 	pci_read_config_word(dev, master_port, &master_data);
 	if (is_slave) {
+		/* clear TIME1|IE1|PPE1|DTE1 */
+		master_data &= 0xff0f;
 		/* Enable SITRE (seperate slave timing register) */
 		master_data |= 0x4000;
 		/* enable PPE1, IE1 and TIME1 as needed */
@@ -694,12 +700,14 @@ static void piix_set_piomode (struct ata_port *ap, struct ata_device *adev)
 		pci_read_config_byte(dev, slave_port, &slave_data);
 		slave_data &= (ap->port_no ? 0x0f : 0xf0);
 		/* Load the timing nibble for this slave */
-		slave_data |= ((timings[pio][0] << 2) | timings[pio][1]) << (ap->port_no ? 4 : 0);
+		slave_data |= ((timings[pio][0] << 2) | timings[pio][1])
+						<< (ap->port_no ? 4 : 0);
 	} else {
-		/* Master keeps the bits in a different format */
-		master_data &= 0xccf8;
+		/* clear ISP|RCT|TIME0|IE0|PPE0|DTE0 */
+		master_data &= 0xccf0;
 		/* Enable PPE, IE and TIME as appropriate */
 		master_data |= control;
+		/* load ISP and RCT */
 		master_data |=
 			(timings[pio][0] << 12) |
 			(timings[pio][1] << 8);
@@ -816,7 +824,7 @@ static void do_pata_set_dmamode (struct ata_port *ap, struct ata_device *adev, i
 			master_data &= 0xFF4F;  /* Mask out IORDY|TIME1|DMAONLY */
 			master_data |= control << 4;
 			pci_read_config_byte(dev, 0x44, &slave_data);
-			slave_data &= (0x0F + 0xE1 * ap->port_no);
+			slave_data &= (ap->port_no ? 0x0f : 0xf0);
 			/* Load the matching timing */
 			slave_data |= ((timings[pio][0] << 2) | timings[pio][1]) << (ap->port_no ? 4 : 0);
 			pci_write_config_byte(dev, 0x44, slave_data);
@@ -828,8 +836,11 @@ static void do_pata_set_dmamode (struct ata_port *ap, struct ata_device *adev, i
 				(timings[pio][0] << 12) |
 				(timings[pio][1] << 8);
 		}
-		udma_enable &= ~(1 << devid);
-		pci_write_config_word(dev, master_port, master_data);
+
+		if (ap->udma_mask) {
+			udma_enable &= ~(1 << devid);
+			pci_write_config_word(dev, master_port, master_data);
+		}
 	}
 	/* Don't scribble on 0x48 if the controller does not support UDMA */
 	if (ap->udma_mask)

RE: CF flash IDE failure to attach with 2.6.20+

[Andrew Hall]

> I suppose you were using ata_piix too in older kernel, right?  Can you
> post the boot dmesg of 2.6.19?  We used to ignore mwdma mode before and
> enabled it at some point after that.  That may be the cause here.
> 
> Also, please try the attached patch on top of 2.6.20.

Sorry guys, I've actually got it wrong. The hardware that I have been
testing on has a different chipset: Intel ICH8, to what I was using
previously with success with 2.6.19 (this was ICH4 based hardware) - so the
driver is actually different now. 

Tejun, your patch for 2.6.20 failed with the same errors.

For completeness I have tested the newer ICH8 hardware with everything from
2.6.15 through to 2.6.21.5 using the ata_piix drivers and it (the Compact
Flash) fails in all kernels. Here is the (relevant) dmesg from 2.6.21.5
showing the CF being disabled:

ata_piix 0000:00:1f.2: version 2.10ac1
ata_piix 0000:00:1f.2: MAP [ P0 P2 P1 P3 ]
ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) -> IRQ 19
PCI: Setting latency timer of device 0000:00:1f.2 to 64
ata1: SATA max UDMA/133 cmd 0x0001fa00 ctl 0x0001f902 bmdma 0x0001f600 irq
19
ata2: SATA max UDMA/133 cmd 0x0001f800 ctl 0x0001f702 bmdma 0x0001f608 irq
19
scsi0 : ata_piix
ata1.00: ATA-0: CF CARD 512MB, 20070131, max MWDMA2
ata1.00: 990864 sectors, multi 0: LBA
ata1.00: applying bridge limits
ata1.00: configured for MWDMA2
scsi1 : ata_piix
ATA: abnormal status 0x7F on port 0x0001f807
scsi 0:0:0:0: Direct-Access     ATA      CF CARD 512MB    2007 PQ: 0 ANSI: 5
SCSI device sda: 990864 512-byte hdwr sectors (507 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: disabled, read cache: enabled, doesn't support
DPO or FUA
SCSI device sda: 990864 512-byte hdwr sectors (507 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: disabled, read cache: enabled, doesn't support
DPO or FUA
 sda:<3>ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in
         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1: port is slow to respond, please be patient (Status 0xd0)
ata1: port failed to respond (30 secs, Status 0xd0)
ata1: soft resetting port
ata1.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x80)
ata1.00: revalidation failed (errno=-5)
ata1: failed to recover some devices, retrying in 5 secs
ata1: soft resetting port
ata1.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x80)
ata1.00: revalidation failed (errno=-5)
ata1.00: limiting speed to MWDMA2:PIO3
ata1: failed to recover some devices, retrying in 5 secs
ata1: soft resetting port
ata1.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x80)
ata1.00: revalidation failed (errno=-5)
ata1.00: disabled
ata1: EH complete
sd 0:0:0:0: SCSI error: return code = 0x00040000
end_request: I/O error, dev sda, sector 0

Here is the lspci -v for the controller:

00:1f.2 IDE interface: Intel Corporation 82801H (ICH8 Family) 4 port SATA
IDE Controller (rev 02) (prog-if 8f [Master SecP SecO PriP PriO])
        Subsystem: Intel Corporation 82801H (ICH8 Family) 4 port SATA IDE
Controller
        Flags: bus master, 66Mhz, medium devsel, latency 0, IRQ 19
        I/O ports at fa00 [size=8]
        I/O ports at f900 [size=4]
        I/O ports at f800 [size=8]
        I/O ports at f700 [size=4]
        I/O ports at f600 [size=16]
        I/O ports at f500 [size=16]
        Capabilities: [70] Power Management version 3

Please let me know if there is any further information I can provide to help
fix this issue.

Thanks,

Re: CF flash IDE failure to attach with 2.6.20+

[Tejun Heo]

Andrew Hall wrote:
>> I suppose you were using ata_piix too in older kernel, right?  Can you
>> post the boot dmesg of 2.6.19?  We used to ignore mwdma mode before and
>> enabled it at some point after that.  That may be the cause here.
>>
>> Also, please try the attached patch on top of 2.6.20.
> 
> Sorry guys, I've actually got it wrong. The hardware that I have been
> testing on has a different chipset: Intel ICH8, to what I was using
> previously with success with 2.6.19 (this was ICH4 based hardware) - so the
> driver is actually different now. 
> 
> Tejun, your patch for 2.6.20 failed with the same errors.
> 
> For completeness I have tested the newer ICH8 hardware with everything from
> 2.6.15 through to 2.6.21.5 using the ata_piix drivers and it (the Compact
> Flash) fails in all kernels. Here is the (relevant) dmesg from 2.6.21.5
> showing the CF being disabled:

Does piix driver work?  If so, can you post boot dmesg and the result of
'hdparm -I /dev/hdX'?

-- 
tejun

RE: CF flash IDE failure to attach with 2.6.20+

[Andrew Hall]

> 
> Does piix driver work?  If so, can you post boot dmesg and the result
> of
> 'hdparm -I /dev/hdX'?

Unfortunately it doesn't seem to be detected at all, although I'm not
exactly sure which driver you're referring to. I have tried:

New ATA drivers: 
Intel ESB, ICH, PIIX3, PIIX4 PATA/SATA support - is detected but fails
Intel PATA MPIIX support - is not detected at all (which I think is right)
Intel PATA old PIIX support (Experimental) - is not detected at all (which I
think is wrong - it should be)

Old ATA/IDE driver:
Intel PIIXn chipsets support - is not detected at all (which is right as the
bus is SATA)

Thanks,

Re: CF flash IDE failure to attach with 2.6.20+

[Mark Lord]

Andrew Hall wrote:
>> Does piix driver work?  If so, can you post boot dmesg and the result
>> of
>> 'hdparm -I /dev/hdX'?
> 
> Unfortunately it doesn't seem to be detected at all, although I'm not
> exactly sure which driver you're referring to. I have tried:
> 
> New ATA drivers: 
> Intel ESB, ICH, PIIX3, PIIX4 PATA/SATA support - is detected but fails
> Intel PATA MPIIX support - is not detected at all (which I think is right)
> Intel PATA old PIIX support (Experimental) - is not detected at all (which I
> think is wrong - it should be)
> 
> Old ATA/IDE driver:
> Intel PIIXn chipsets support - is not detected at all (which is right as the
> bus is SATA)

I think Tejun would like you to patch the PCI ID for your ICH8
into the "Old ATA/IDE PIIXn" driver, and then try that.

Cheers

RE: CF flash IDE failure to attach with 2.6.20+

[Andrew Hall]

 
> I think Tejun would like you to patch the PCI ID for your ICH8
> into the "Old ATA/IDE PIIXn" driver, and then try that.

Maybe I'm a bit slow on the uptake, but how exactly do I do this "patch the
PCI ID into the driver"? I run a monolithic kernel will all these drivers
compiled in. None of them are found by the hardware except the newer libATA
driver (CONFIG_ATA_PIIX) for Intel ESB, ICH, PIIX3, PIIX4 PATA/SATA. If I
have removed each driver in turn and none of the others are detected. 

RE: CF flash IDE failure to attach with 2.6.20+

[Andrew Hall]

> Does piix driver work?  If so, can you post boot dmesg and the result
> of
> 'hdparm -I /dev/hdX'?

I've still been battling to get this hardware detected with any of the
drivers mentioned previously except the newer libata piix driver. However
when using the old driver and using "all-generic-ide" and "irqpoll" as
kernel parameters I now have the device being detected albeit complaining
about lost interrupts and DMA timeouts. Here is the output from the hdparm
-I /dev/hda that you requested:

/dev/hda:

ATA device, with non-removable media
        Model Number:       CF CARD 512MB
        Serial Number:      CF512       0001943B
        Firmware Revision:  20070131
Standards:
        Likely used: 5
Configuration:
        Logical         max     current
        cylinders       983     983
        heads           16      16
        sectors/track   63      63
        --
        CHS current addressable sectors:     990864
        LBA    user addressable sectors:     990864
        device size with M = 1024*1024:         483 MBytes
        device size with M = 1000*1000:         507 MBytes
Capabilities:
        LBA, IORDY(may be)(cannot be disabled)
        bytes avail on r/w long: 4      Queue depth: 1
        Standby timer values: spec'd by Vendor
        R/W multiple sector transfer: Max = 1   Current = 1
        DMA: mdma0 mdma1 *mdma2
             Cycle time: min=120ns recommended=120ns
        PIO: pio0 pio1 pio2 pio3 pio4
             Cycle time: no flow control=120ns  IORDY flow control=120ns
HW reset results:
        CBLID- below Vih
        Device num = 0

Many thanks for your help.

CF flash PATA on libata failure to attach

[Andrew Hall]

Hello,

I have been wrestling now for several days trying to get a Compact Flash
(IDE) card detected and mounted properly under any version of Linux 2.6.x.
using ICH8 hardware. My understanding is that this hardware uses a SATA to
PATA bridge, and so I have tried unsuccessfully to use the newer Intel ESB,
ICH, PIIX3, PIIX4 PATA/SATA drivers and the older Intel PATA old PIIX
drivers with and without the older standard ATA support compiled in.

I have spoken with the hardware manufacturer who tells me there are Intel
specific issues that "may" break support for compact flash. Is this true? I
have tried the latest 2.6.22rc6 still with no success. I include the output
from dmesg here and can provide any information that someone may need to
help me isolate and fix this issue. I am not a kernel developer and have no
idea about the structure of the ATA interface but am willing to help in
whatever way to help get this issue resolved, as our product depends on CF
working.

If someone can at least please tell me if this is supposed to work ( I refer
to comments from the hardware manufacturer and comments on the libata
development site about issues with 32bit I/O mode and CF), that would be
great.

Dmesg:

<5>Linux version 2.6.22-rc6 (root@localhost) (gcc version 4.1.1 20070105
(Red Hat 4.1.1-51)) #1 SMP Tue Jun 26 19:10:55 EST 2007
<6>BIOS-provided physical RAM map:
<4> BIOS-e820: 0000000000000000 - 000000000009f400 (usable)
<4> BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved)
<4> BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
<4> BIOS-e820: 0000000000100000 - 000000007fde0000 (usable)
<4> BIOS-e820: 000000007fde0000 - 000000007fde3000 (ACPI NVS)
<4> BIOS-e820: 000000007fde3000 - 000000007fdf0000 (ACPI data)
<4> BIOS-e820: 000000007fdf0000 - 000000007fe00000 (reserved)
<4> BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
<4> BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
<5>1149MB HIGHMEM available.
<5>896MB LOWMEM available.
<6>found SMP MP-table at 000f3330
<4>NX (Execute Disable) protection: active
<7>Entering add_active_range(0, 0, 523744) 0 entries of 256 used
<4>Zone PFN ranges:
<4>  DMA             0 ->     4096
<4>  Normal       4096 ->   229376
<4>  HighMem    229376 ->   523744
<4>early_node_map[1] active PFN ranges
<4>    0:        0 ->   523744
<7>On node 0 totalpages: 523744
<7>  DMA zone: 32 pages used for memmap
<7>  DMA zone: 0 pages reserved
<7>  DMA zone: 4064 pages, LIFO batch:0
<7>  Normal zone: 1760 pages used for memmap
<7>  Normal zone: 223520 pages, LIFO batch:31
<7>  HighMem zone: 2299 pages used for memmap
<7>  HighMem zone: 292069 pages, LIFO batch:31
<6>DMI 2.3 present.
<4>ACPI: RSDP 000F6D50, 0014 (r0 IntelR)
<4>ACPI: RSDT 7FDE3040, 0030 (r1 IntelR AWRDACPI 42302E31 AWRD        0)
<4>ACPI: FACP 7FDE30C0, 0074 (r1 IntelR AWRDACPI 42302E31 AWRD        0)
<4>ACPI: DSDT 7FDE3180, 44BA (r1 INTELR AWRDACPI     1000 MSFT  3000000)
<4>ACPI: FACS 7FDE0000, 0040
<4>ACPI: MCFG 7FDE7780, 003C (r1 IntelR AWRDACPI 42302E31 AWRD        0)
<4>ACPI: APIC 7FDE7680, 0084 (r1 IntelR AWRDACPI 42302E31 AWRD        0)
<6>ACPI: PM-Timer IO Port: 0x408
<7>ACPI: Local APIC address 0xfee00000
<6>ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
<4>Processor #0 6:15 APIC version 20
<6>ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
<4>Processor #1 6:15 APIC version 20
<6>ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] disabled)
<6>ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] disabled)
<6>ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
<6>ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
<6>ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
<6>ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
<6>ACPI: IOAPIC (id[0x04] address[0xfec00000] gsi_base[0])
<4>IOAPIC[0]: apic_id 4, version 32, address 0xfec00000, GSI 0-23
<6>ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
<6>ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
<7>ACPI: IRQ0 used by override.
<7>ACPI: IRQ2 used by override.
<7>ACPI: IRQ9 used by override.
<4>Enabling APIC mode:  Flat.  Using 1 I/O APICs
<6>Using ACPI (MADT) for SMP configuration information
<4>Allocating PCI resources starting at 80000000 (gap: 7fe00000:60200000)
<4>Built 1 zonelists.  Total pages: 519653
<5>Kernel command line: root=/dev/ram0 ramdisk=65535 single
<7>mapped APIC to ffffd000 (fee00000)
<7>mapped IOAPIC to ffffc000 (fec00000)
<6>Enabling fast FPU save and restore... done.
<6>Enabling unmasked SIMD FPU exception support... done.
<6>Initializing CPU#0
<4>PID hash table entries: 4096 (order: 12, 16384 bytes)
<4>Detected 1862.098 MHz processor.
<4>Console: colour VGA+ 80x25
<4>Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
<4>Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
<6>Memory: 2060720k/2094976k available (4104k kernel code, 33012k reserved,
1729k data, 336k init, 1177472k highmem)
<4>virtual kernel memory layout:
<4>    fixmap  : 0xfff50000 - 0xfffff000   ( 700 kB)
<4>    pkmap   : 0xffc00000 - 0xffe00000   (2048 kB)
<4>    vmalloc : 0xf8800000 - 0xffbfe000   ( 115 MB)
<4>    lowmem  : 0xc0000000 - 0xf8000000   ( 896 MB)
<4>      .init : 0xc06bb000 - 0xc070f000   ( 336 kB)
<4>      .data : 0xc0502061 - 0xc06b2858   (1729 kB)
<4>      .text : 0xc0100000 - 0xc0502061   (4104 kB)
<4>Checking if this processor honours the WP bit even in supervisor mode...
Ok.
<4>Calibrating delay using timer specific routine.. 3726.92 BogoMIPS
(lpj=7453842)
<4>Mount-cache hash table entries: 512
<7>CPU: After generic identify, caps: bfebfbff 20100000 00000000 00000000
0000e3bd 00000000 00000001
<4>monitor/mwait feature present.
<4>using mwait in idle threads.
<6>CPU: L1 I cache: 32K, L1 D cache: 32K
<6>CPU: L2 cache: 4096K
<6>CPU: Physical Processor ID: 0
<6>CPU: Processor Core ID: 0
<7>CPU: After all inits, caps: bfebfbff 20100000 00000000 00003940 0000e3bd
00000000 00000001
<6>Intel machine check architecture supported.
<6>Intel machine check reporting enabled on CPU#0.
<4>Compat vDSO mapped to ffffe000.
<6>Checking 'hlt' instruction... OK.
<6>Freeing SMP alternatives: 18k freed
<6>ACPI: Core revision 20070126
<4>CPU0: Intel(R) Core(TM)2 CPU          6320  @ 1.86GHz stepping 06
<4>Booting processor 1/1 eip 2000
<6>Initializing CPU#1
<4>Calibrating delay using timer specific routine.. 3724.29 BogoMIPS
(lpj=7448583)
<7>CPU: After generic identify, caps: bfebfbff 20100000 00000000 00000000
0000e3bd 00000000 00000001
<4>monitor/mwait feature present.
<6>CPU: L1 I cache: 32K, L1 D cache: 32K
<6>CPU: L2 cache: 4096K
<6>CPU: Physical Processor ID: 0
<6>CPU: Processor Core ID: 1
<7>CPU: After all inits, caps: bfebfbff 20100000 00000000 00003940 0000e3bd
00000000 00000001
<6>Intel machine check architecture supported.
<6>Intel machine check reporting enabled on CPU#1.
<4>CPU1: Intel(R) Core(TM)2 CPU          6320  @ 1.86GHz stepping 06
<6>Total of 2 processors activated (7451.21 BogoMIPS).
<4>ENABLING IO-APIC IRQs
<6>..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
<6>checking TSC synchronization [CPU#0 -> CPU#1]: passed.
<6>Brought up 2 CPUs
<4>migration_cost=74
<6>NET: Registered protocol family 16
<6>ACPI: bus type pci registered
<6>PCI: Using configuration type 1
<4>Setting up standard PCI resources
<6>ACPI: Interpreter enabled
<6>ACPI: Using IOAPIC for interrupt routing
<6>ACPI: PCI Root Bridge [PCI0] (0000:00)
<7>PCI: Probing PCI hardware (bus 00)
<4>PCI quirk: region 0400-047f claimed by ICH6 ACPI/GPIO/TCO
<4>PCI quirk: region 0480-04bf claimed by ICH6 GPIO
<4>PCI: PXH quirk detected, disabling MSI for SHPC device
<4>PCI: PXH quirk detected, disabling MSI for SHPC device
<6>PCI: Transparent bridge - 0000:00:1e.0
<7>ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
<7>ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX0._PRT]
<7>ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX1._PRT]
<7>ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX2._PRT]
<7>ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX3._PRT]
<7>ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX4._PRT]
<7>ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX5._PRT]
<7>ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT]
<4>ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 11 12 *14 15)
<4>ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
<4>ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
<4>ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 11 12 14 *15)
<4>ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0,
disabled.
<4>ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0,
disabled.
<4>ACPI: PCI Interrupt Link [LNK0] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0,
disabled.
<4>ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
<6>Linux Plug and Play Support v0.97 (c) Adam Belay
<6>pnp: PnP ACPI init
<6>ACPI: bus type pnp registered
<6>pnp: PnP ACPI: found 13 devices
<6>ACPI: ACPI bus type pnp unregistered
<5>SCSI subsystem initialized
<7>libata version 2.21 loaded.
<6>usbcore: registered new interface driver usbfs
<6>usbcore: registered new interface driver hub
<6>usbcore: registered new device driver usb
<6>PCI: Using ACPI for IRQ routing
<6>PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a
report
<6>pnp: 00:09: ioport range 0x400-0x4bf could not be reserved
<6>pnp: 00:0b: iomem range 0xe0000000-0xefffffff could not be reserved
<6>pnp: 00:0c: iomem range 0xf0000-0xfffff could not be reserved
<6>pnp: 00:0c: iomem range 0x7fe00000-0x7fefffff has been reserved
<6>pnp: 00:0c: iomem range 0x7fde0000-0x7fdfffff could not be reserved
<6>pnp: 00:0c: iomem range 0x0-0x9ffff could not be reserved
<6>Time: tsc clocksource has been installed.
<6>PCI: Bridge: 0000:01:00.0
<6>  IO window: 7000-7fff
<6>  MEM window: fd200000-fd2fffff
<6>  PREFETCH window: fce00000-fcefffff
<6>PCI: Bridge: 0000:01:00.2
<6>  IO window: 6000-6fff
<6>  MEM window: fd100000-fd1fffff
<6>  PREFETCH window: fcd00000-fcdfffff
<6>PCI: Bridge: 0000:00:01.0
<6>  IO window: 6000-7fff
<6>  MEM window: fd100000-fd2fffff
<6>  PREFETCH window: fcd00000-fcefffff
<6>PCI: Bridge: 0000:00:1c.0
<6>  IO window: 5000-5fff
<6>  MEM window: fde00000-fdefffff
<6>  PREFETCH window: fdd00000-fddfffff
<6>PCI: Bridge: 0000:00:1c.1
<6>  IO window: d000-dfff
<6>  MEM window: fdc00000-fdcfffff
<6>  PREFETCH window: fdb00000-fdbfffff
<6>PCI: Bridge: 0000:00:1c.2
<6>  IO window: c000-cfff
<6>  MEM window: fda00000-fdafffff
<6>  PREFETCH window: fd900000-fd9fffff
<6>PCI: Bridge: 0000:00:1c.3
<6>  IO window: a000-afff
<6>  MEM window: fd800000-fd8fffff
<6>  PREFETCH window: fd700000-fd7fffff
<6>PCI: Bridge: 0000:00:1c.4
<6>  IO window: 9000-9fff
<6>  MEM window: fd600000-fd6fffff
<6>  PREFETCH window: fd500000-fd5fffff
<6>PCI: Bridge: 0000:00:1c.5
<6>  IO window: 8000-8fff
<6>  MEM window: fd400000-fd4fffff
<6>  PREFETCH window: fd300000-fd3fffff
<6>PCI: Bridge: 0000:00:1e.0
<6>  IO window: b000-bfff
<6>  MEM window: fd000000-fd0fffff
<6>  PREFETCH window: fcf00000-fcffffff
<6>ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 16 (level, low) -> IRQ 16
<7>PCI: Setting latency timer of device 0000:00:01.0 to 64
<7>PCI: Setting latency timer of device 0000:01:00.0 to 64
<7>PCI: Setting latency timer of device 0000:01:00.2 to 64
<6>ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 16 (level, low) -> IRQ 16
<7>PCI: Setting latency timer of device 0000:00:1c.0 to 64
<6>ACPI: PCI Interrupt 0000:00:1c.1[B] -> GSI 17 (level, low) -> IRQ 17
<7>PCI: Setting latency timer of device 0000:00:1c.1 to 64
<6>ACPI: PCI Interrupt 0000:00:1c.2[C] -> GSI 18 (level, low) -> IRQ 18
<7>PCI: Setting latency timer of device 0000:00:1c.2 to 64
<6>ACPI: PCI Interrupt 0000:00:1c.3[D] -> GSI 19 (level, low) -> IRQ 19
<7>PCI: Setting latency timer of device 0000:00:1c.3 to 64
<6>ACPI: PCI Interrupt 0000:00:1c.4[A] -> GSI 16 (level, low) -> IRQ 16
<7>PCI: Setting latency timer of device 0000:00:1c.4 to 64
<6>ACPI: PCI Interrupt 0000:00:1c.5[B] -> GSI 17 (level, low) -> IRQ 17
<7>PCI: Setting latency timer of device 0000:00:1c.5 to 64
<7>PCI: Setting latency timer of device 0000:00:1e.0 to 64
<6>NET: Registered protocol family 2
<4>IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
<4>TCP established hash table entries: 131072 (order: 8, 1572864 bytes)
<4>TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
<6>TCP: Hash tables configured (established 131072 bind 65536)
<6>TCP reno registered
<6>checking if image is initramfs...<6>Switched to high resolution mode on
CPU 1
<6>Switched to high resolution mode on CPU 0
<4>it isn't (no cpio magic); looks like an initrd
<6>Freeing initrd memory: 9197k freed
<6>Machine check exception polling timer started.
<4>highmem bounce pool size: 64 pages
<6>SGI XFS with no debug enabled
<6>io scheduler noop registered
<6>io scheduler anticipatory registered (default)
<6>io scheduler deadline registered
<6>io scheduler cfq registered
<7>Boot video device is 0000:00:02.0
<7>PCI: Setting latency timer of device 0000:00:01.0 to 64
<4>assign_interrupt_mode Found MSI capability
<7>Allocate Port Service[0000:00:01.0:pcie00]
<7>PCI: Setting latency timer of device 0000:00:1c.0 to 64
<4>assign_interrupt_mode Found MSI capability
<7>Allocate Port Service[0000:00:1c.0:pcie00]
<7>Allocate Port Service[0000:00:1c.0:pcie02]
<7>PCI: Setting latency timer of device 0000:00:1c.1 to 64
<4>assign_interrupt_mode Found MSI capability
<7>Allocate Port Service[0000:00:1c.1:pcie00]
<7>Allocate Port Service[0000:00:1c.1:pcie02]
<7>PCI: Setting latency timer of device 0000:00:1c.2 to 64
<4>assign_interrupt_mode Found MSI capability
<7>Allocate Port Service[0000:00:1c.2:pcie00]
<7>Allocate Port Service[0000:00:1c.2:pcie02]
<7>PCI: Setting latency timer of device 0000:00:1c.3 to 64
<4>assign_interrupt_mode Found MSI capability
<7>Allocate Port Service[0000:00:1c.3:pcie00]
<7>Allocate Port Service[0000:00:1c.3:pcie02]
<7>PCI: Setting latency timer of device 0000:00:1c.4 to 64
<4>assign_interrupt_mode Found MSI capability
<7>Allocate Port Service[0000:00:1c.4:pcie00]
<7>Allocate Port Service[0000:00:1c.4:pcie02]
<7>PCI: Setting latency timer of device 0000:00:1c.5 to 64
<4>assign_interrupt_mode Found MSI capability
<7>Allocate Port Service[0000:00:1c.5:pcie00]
<7>Allocate Port Service[0000:00:1c.5:pcie02]
<6>input: Power Button (FF) as /class/input/input0
<6>ACPI: Power Button (FF) [PWRF]
<6>input: Power Button (CM) as /class/input/input1
<6>ACPI: Power Button (CM) [PWRB]
<6>ACPI: Thermal Zone [THRM] (40 C)
<6>Real Time Clock Driver v1.12ac
<6>Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
<6>00:06: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
<6>00:07: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
<6>Floppy drive(s): fd0 is unknown type 13 (usb?), fd1 is unknown type 15
(usb?)
<4>floppy0: no floppy controllers found
<4>RAMDISK driver initialized: 16 RAM disks of 65535K size 1024 blocksize
<6>loop: module loaded
<4>Compaq SMART2 Driver (v 2.6.0)
<6>HP CISS Driver (v 3.6.14)
<6>Intel(R) PRO/1000 Network Driver - version 7.3.20-k2-NAPI
<6>Copyright (c) 1999-2006 Intel Corporation.
<6>ACPI: PCI Interrupt 0000:04:00.0[A] -> GSI 16 (level, low) -> IRQ 16
<7>PCI: Setting latency timer of device 0000:04:00.0 to 64
<6>e1000: 0000:04:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1)
00:10:f3:10:53:e8
<6>e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
<6>ACPI: PCI Interrupt 0000:05:00.0[A] -> GSI 17 (level, low) -> IRQ 17
<7>PCI: Setting latency timer of device 0000:05:00.0 to 64
<6>e1000: 0000:05:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1)
00:10:f3:10:53:e9
<6>e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection
<6>ACPI: PCI Interrupt 0000:06:00.0[A] -> GSI 18 (level, low) -> IRQ 18
<7>PCI: Setting latency timer of device 0000:06:00.0 to 64
<6>e1000: 0000:06:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1)
00:10:f3:10:53:ea
<6>e1000: eth2: e1000_probe: Intel(R) PRO/1000 Network Connection
<6>ACPI: PCI Interrupt 0000:07:00.0[A] -> GSI 19 (level, low) -> IRQ 19
<7>PCI: Setting latency timer of device 0000:07:00.0 to 64
<6>e1000: 0000:07:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1)
00:10:f3:10:53:eb
<6>e1000: eth3: e1000_probe: Intel(R) PRO/1000 Network Connection
<6>ACPI: PCI Interrupt 0000:08:00.0[A] -> GSI 16 (level, low) -> IRQ 16
<7>PCI: Setting latency timer of device 0000:08:00.0 to 64
<6>e1000: 0000:08:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1)
00:10:f3:10:53:ec
<6>e1000: eth4: e1000_probe: Intel(R) PRO/1000 Network Connection
<6>ACPI: PCI Interrupt 0000:09:00.0[A] -> GSI 17 (level, low) -> IRQ 17
<7>PCI: Setting latency timer of device 0000:09:00.0 to 64
<6>e1000: 0000:09:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1)
00:10:f3:10:53:ed
<6>e1000: eth5: e1000_probe: Intel(R) PRO/1000 Network Connection
<6>ACPI: PCI Interrupt 0000:0a:0e.0[A] -> GSI 18 (level, low) -> IRQ 18
<6>e1000: 0000:0a:0e.0: e1000_probe: (PCI:33MHz:32-bit) 00:10:f3:10:53:ee
<6>e1000: eth6: e1000_probe: Intel(R) PRO/1000 Network Connection
<6>ACPI: PCI Interrupt 0000:0a:0f.0[A] -> GSI 17 (level, low) -> IRQ 17
<6>e1000: 0000:0a:0f.0: e1000_probe: (PCI:33MHz:32-bit) 00:10:f3:10:53:ef
<6>e1000: eth7: e1000_probe: Intel(R) PRO/1000 Network Connection
<6>pcnet32.c:v1.33 27.Jun.2006 tsbogend@alpha.franken.de
<6>e100: Intel(R) PRO/100 Network Driver, 3.5.17-k4-NAPI
<6>e100: Copyright(c) 1999-2006 Intel Corporation
<6>ns83820.c: National Semiconductor DP83820 10/100/1000 driver.
<6>PPP generic driver version 2.4.2
<6>PPP Deflate Compression module registered
<6>PPP BSD Compression module registered
<6>PPP MPPE Compression module registered
<6>NET: Registered protocol family 24
<6>tun: Universal TUN/TAP device driver, 1.6
<6>tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
<4>Loading Adaptec I2O RAID: Version 2.4 Build 5go
<6>Detecting Adaptec I2O RAID controllers...
<6>Adaptec aacraid driver (1.1-5[2437]-mh4)
<5>aic94xx: Adaptec aic94xx SAS/SATA driver version 1.0.3 loaded
<4>scsi: <fdomain> Detection failed (no card)
<6>DC390: clustering now enabled by default. If you get problems load
<4>	with "disable_clustering=1" and report to maintainers
<6>megaraid cmm: 2.20.2.7 (Release Date: Sun Jul 16 00:01:03 EST 2006)
<6>megaraid: 2.20.5.1 (Release Date: Thu Nov 16 15:32:35 EST 2006)
<6>megasas: 00.00.03.10-rc5 Thu May 17 10:09:32 PDT 2007
<4>GDT-HA: Storage RAID Controller Driver. Version: 3.05
<4>GDT-HA: Found 0 PCI Storage RAID Controllers
<4>3ware Storage Controller device driver for Linux v1.26.02.002.
<4>3ware 9000 Storage Controller device driver for Linux v2.26.02.008.
<6>nsp32: loading...
<7>ata_piix 0000:00:1f.2: version 2.11
<6>ata_piix 0000:00:1f.2: MAP [ P0 P2 P1 P3 ]
<6>ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) -> IRQ 19
<7>PCI: Setting latency timer of device 0000:00:1f.2 to 64
<6>scsi0 : ata_piix
<6>scsi1 : ata_piix
<6>ata1: SATA max UDMA/133 cmd 0x0001fa00 ctl 0x0001f902 bmdma 0x0001f600
irq 0
<6>ata2: SATA max UDMA/133 cmd 0x0001f800 ctl 0x0001f702 bmdma 0x0001f608
irq 0
<6>ata1.00: ATA-0: CF CARD 512MB, 20070131, max MWDMA2
<6>ata1.00: 990864 sectors, multi 0: LBA 
<6>ata1.00: applying bridge limits
<6>ata1.00: configured for MWDMA2
<4>ATA: abnormal status 0x7F on port 0x0001f807
<5>scsi 0:0:0:0: Direct-Access     ATA      CF CARD 512MB    2007 PQ: 0
ANSI: 5
<5>sd 0:0:0:0: [sda] 990864 512-byte hardware sectors (507 MB)
<5>sd 0:0:0:0: [sda] Write Protect is off
<7>sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
<5>sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't
support DPO or FUA
<5>sd 0:0:0:0: [sda] 990864 512-byte hardware sectors (507 MB)
<5>sd 0:0:0:0: [sda] Write Protect is off
<7>sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
<5>sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't
support DPO or FUA
<6> sda:<3>ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
<3>ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096
in
<4>         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
<4>ata1: port is slow to respond, please be patient (Status 0xd0)
<4>ata1: device not ready (errno=-16), forcing hardreset
<3>ata1: BUG: prereset() requested invalid reset type
<6>ata1: soft resetting port
<4>ata1.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x80)
<3>ata1.00: revalidation failed (errno=-5)
<4>ata1: failed to recover some devices, retrying in 5 secs
<6>ata1: soft resetting port
<4>ata1.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x80)
<3>ata1.00: revalidation failed (errno=-5)
<4>ata1.00: limiting speed to MWDMA2:PIO3
<4>ata1: failed to recover some devices, retrying in 5 secs
<6>ata1: soft resetting port
<4>ata1.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x80)
<3>ata1.00: revalidation failed (errno=-5)
<4>ata1.00: disabled
<6>ata1: EH complete
<6>sd 0:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00
<4>end_request: I/O error, dev sda, sector 0
<3>Buffer I/O error on device sda, logical block 0
<6>sd 0:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00
<4>end_request: I/O error, dev sda, sector 0
<3>Buffer I/O error on device sda, logical block 0
<4> unable to read partition table
<5>sd 0:0:0:0: [sda] Attached SCSI disk
<5>sd 0:0:0:0: Attached scsi generic sg0 type 0
<6>ata_piix 0000:00:1f.5: MAP [ P0 P2 P1 P3 ]
<6>ACPI: PCI Interrupt 0000:00:1f.5[B] -> GSI 19 (level, low) -> IRQ 19
<7>PCI: Setting latency timer of device 0000:00:1f.5 to 64
<6>scsi2 : ata_piix
<6>scsi3 : ata_piix
<6>ata3: SATA max UDMA/133 cmd 0x0001f300 ctl 0x0001f202 bmdma 0x0001ef00
irq 0
<6>ata4: SATA max UDMA/133 cmd 0x0001f100 ctl 0x0001f002 bmdma 0x0001ef08
irq 0
<4>ATA: abnormal status 0x7F on port 0x0001f307
<4>ATA: abnormal status 0x7F on port 0x0001f107

Re: CF flash PATA on libata failure to attach

[Mark Lord]

Andrew Hall wrote:
> Hello,
> 
> I have been wrestling now for several days trying to get a Compact Flash
> (IDE) card detected and mounted properly under any version of Linux 2.6.x.
> using ICH8 hardware. My understanding is that this hardware uses a SATA to
> PATA bridge, and so I have tried unsuccessfully to use the newer Intel ESB,
> ICH, PIIX3, PIIX4 PATA/SATA drivers and the older Intel PATA old PIIX
> drivers with and without the older standard ATA support compiled in.
...
> <5>Linux version 2.6.22-rc6 (root@localhost) (gcc version 4.1.1 20070105
...
> <7>ata_piix 0000:00:1f.2: version 2.11
> <6>ata_piix 0000:00:1f.2: MAP [ P0 P2 P1 P3 ]
> <6>ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) -> IRQ 19
> <7>PCI: Setting latency timer of device 0000:00:1f.2 to 64
> <6>scsi0 : ata_piix
> <6>scsi1 : ata_piix
> <6>ata1: SATA max UDMA/133 cmd 0x0001fa00 ctl 0x0001f902 bmdma 0x0001f600
> irq 0
> <6>ata2: SATA max UDMA/133 cmd 0x0001f800 ctl 0x0001f702 bmdma 0x0001f608
> irq 0
> <6>ata1.00: ATA-0: CF CARD 512MB, 20070131, max MWDMA2
> <6>ata1.00: 990864 sectors, multi 0: LBA 
> <6>ata1.00: applying bridge limits
> <6>ata1.00: configured for MWDMA2
> <4>ATA: abnormal status 0x7F on port 0x0001f807
> <5>scsi 0:0:0:0: Direct-Access     ATA      CF CARD 512MB    2007 PQ: 0
> ANSI: 5
> <5>sd 0:0:0:0: [sda] 990864 512-byte hardware sectors (507 MB)
> <5>sd 0:0:0:0: [sda] Write Protect is off
> <7>sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
> <5>sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't
> support DPO or FUA
> <5>sd 0:0:0:0: [sda] 990864 512-byte hardware sectors (507 MB)
> <5>sd 0:0:0:0: [sda] Write Protect is off
> <7>sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
> <5>sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't
> support DPO or FUA
> <6> sda:<3>ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
> <3>ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096
> in
> <4>         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> <4>ata1: port is slow to respond, please be patient (Status 0xd0)
> <4>ata1: device not ready (errno=-16), forcing hardreset
> <3>ata1: BUG: prereset() requested invalid reset type
> <6>ata1: soft resetting port
> <4>ata1.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x80)
> <3>ata1.00: revalidation failed (errno=-5)
> <4>ata1: failed to recover some devices, retrying in 5 secs
> <6>ata1: soft resetting port
> <4>ata1.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x80)
> <3>ata1.00: revalidation failed (errno=-5)
> <4>ata1.00: limiting speed to MWDMA2:PIO3
> <4>ata1: failed to recover some devices, retrying in 5 secs
> <6>ata1: soft resetting port
> <4>ata1.00: failed to IDENTIFY (INIT_DEV_PARAMS failed, err_mask=0x80)
> <3>ata1.00: revalidation failed (errno=-5)
> <4>ata1.00: disabled
> <6>ata1: EH complete
> <6>sd 0:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00
> <4>end_request: I/O error, dev sda, sector 0
> <3>Buffer I/O error on device sda, logical block 0
> <6>sd 0:0:0:0: [sda] Result: hostbyte=0x04 driverbyte=0x00
> <4>end_request: I/O error, dev sda, sector 0
> <3>Buffer I/O error on device sda, logical block 0
> <4> unable to read partition table
> <5>sd 0:0:0:0: [sda] Attached SCSI disk
> <5>sd 0:0:0:0: Attached scsi generic sg0 type 0
> <6>ata_piix 0000:00:1f.5: MAP [ P0 P2 P1 P3 ]
> <6>ACPI: PCI Interrupt 0000:00:1f.5[B] -> GSI 19 (level, low) -> IRQ 19
> <7>PCI: Setting latency timer of device 0000:00:1f.5 to 64
> <6>scsi2 : ata_piix
> <6>scsi3 : ata_piix
> <6>ata3: SATA max UDMA/133 cmd 0x0001f300 ctl 0x0001f202 bmdma 0x0001ef00
> irq 0
> <6>ata4: SATA max UDMA/133 cmd 0x0001f100 ctl 0x0001f002 bmdma 0x0001ef08
> irq 0
> <4>ATA: abnormal status 0x7F on port 0x0001f307
> <4>ATA: abnormal status 0x7F on port 0x0001f107

This looks a lot like the other CF-card problem that was being debugged
here over the past week -- the one where POLLING had to be turned on.
Robert de Rooy (copied) was the reporter for that one.
Perhaps you two could compare notes ?

Cheers

RE: CF flash PATA on libata failure to attach

[Andrew Hall]

> 
> This looks a lot like the other CF-card problem that was being debugged
> here over the past week -- the one where POLLING had to be turned on.
> Robert de Rooy (copied) was the reporter for that one.
> Perhaps you two could compare notes ?
> 
> Cheers

Thanks for getting back to me. I read through the thread Robert initiated
with CF on PCMCIA and noted with interest that the issue seemed to be
related in the end to lost interrupts. However the compact flash I'm using
is an IDE/PATA device connected directly to the motherboard with no
intermediate devices such as PCMCIA. As the issue is unlikely to be the same
but maybe similar I followed the same path, applying the patches that Tejun
issued to 2.6.22rc6 to provide more debug information in the hope that
someone can help me identify this issue.

I have applied 2.6.22rc6 + timing-debug.patch +
disable-dev_init_params.patch as per:

http://marc.info/?l=linux-kernel&m=117966084223982&w=2

Here is the relevant output from dmesg:

Linux version 2.6.22-rc6 (root@localhost) (gcc version 4.1.1 20070105 (Red
Hat 4
.1.1-51)) #3 SMP Wed Jun 27 14:25:12 EST 2007
...

ata_piix 0000:00:1f.2: MAP [ P0 P2 P1 P3 ]
ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) -> IRQ 19
scsi0 : ata_piix
scsi1 : ata_piix
ata1: SATA max UDMA/133 cmd 0x0001fa00 ctl 0x0001f902 bmdma 0x0001f600 irq 0
ata2: SATA max UDMA/133 cmd 0x0001f800 ctl 0x0001f702 bmdma 0x0001f608 irq 0
ata1: soft resetting port
ata1: reset complete
ata1.00: issuing IDENTIFY
ata1.00: IDENTIFY complete
ata1.00: ATA-0: CF CARD 512MB, 20070131, max MWDMA2
ata1.00: 990864 sectors, multi 0: LBA
ata1.00: applying bridge limits
ata1.00: issuing IDENTIFY
ata1.00: IDENTIFY complete
ata1.00: configured for MWDMA2
ata1: EH complete
ata2: soft resetting port
ata2: reset complete
ATA: abnormal status 0x7F on port 0x0001f807
ata2: EH complete
scsi 0:0:0:0: Direct-Access     ATA      CF CARD 512MB    2007 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 990864 512-byte hardware sectors (507 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't
support DP
O or FUA
sd 0:0:0:0: [sda] 990864 512-byte hardware sectors (507 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't
support DP
O or FUA
 sda:<3>ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in
         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1: port is slow to respond, please be patient (Status 0xd0)
ata1: device not ready (errno=-16), forcing hardreset
ata1: BUG: prereset() requested invalid reset type
ata1: soft resetting port
ata1: reset complete
ata1.00: issuing IDENTIFY
ata1.00: IDENTIFY complete
ata1.00: model number mismatch 'CF CARD 512MB' != ''
ata1.00: revalidation failed (errno=-19)
ata1.00: limiting speed to MWDMA2:PIO3
ata1: failed to recover some devices, retrying in 5 secs
ata1: soft resetting port
ata1: reset complete
ata1.00: issuing IDENTIFY
ata1.00: IDENTIFY complete
ata1.00: model number mismatch 'CF CARD 512MB' != ''
ata1.00: revalidation failed (errno=-19)
ata1.00: disabled
ata1: soft resetting port
ata1: reset complete
ata1.00: issuing IDENTIFY
ata1.00: IDENTIFY complete
ata1.00: ATA-0: , , max PIO0
ata1.00: 0 sectors, multi 0, CHS 0/0/0
ata1.00: applying bridge limits
ata1.00: issuing IDENTIFY
ata1.00: IDENTIFY complete
ata1.00: model number mismatch '' != 'CF CARD 512MB'
ata1.00: revalidation failed (errno=-19)
ata1: failed to recover some devices, retrying in 5 secs
ata1: soft resetting port
ata1: reset complete
ata1.00: issuing IDENTIFY
ata1.00: IDENTIFY complete
ata1.00: issuing IDENTIFY
ata1.00: IDENTIFY complete
ata1.00: configured for PIO0
ata1: EH complete
divide error: 0000 [#1]
SMP
CPU:    1
EIP:    0060:[<c03c7a48>]    Not tainted VLI
EFLAGS: 00010046   (2.6.22-rc6 #3)
EIP is at ata_build_rw_tf+0x20e/0x275
eax: 00000000   ebx: 00000000   ecx: 00000000   edx: 00000000
esi: c2134a40   edi: 00000000   ebp: 00000000   esp: f7c4be94
ds: 007b   es: 007b   fs: 00d8  gs: 0000  ss: 0068
Process scsi_eh_0 (pid: 972, ti=f7c4a000 task=f7867070 task.ti=f7c4a000)
Stack: 00000000 c2134188 00000000 00000000 f7c42bc0 c2134188 c2134a30
c03c8a86
       00000000 00000000 00000008 00000000 00000000 00000000 c20fb140
f7c42bc0
       00000000 f7c3bb58 00000000 00000000 00000008 c2134a30 f7c42bc0
c2134188
Call Trace:
 [<c03c8a86>] ata_scsi_rw_xlat+0x13d/0x1f8
 [<c030b815>] scsi_done+0x0/0x16
 [<c03c8c57>] ata_scsi_translate+0xf0/0x156
 [<c01215e8>] lock_timer_base+0x19/0x35
 [<c030b815>] scsi_done+0x0/0x16
 [<c03cad64>] ata_scsi_queuecmd+0x10f/0x12c
 [<c03c8949>] ata_scsi_rw_xlat+0x0/0x1f8
 [<c030bb44>] scsi_dispatch_cmd+0x185/0x1c9
 [<c030fdc4>] scsi_request_fn+0x20d/0x2c2
 [<c021fcf8>] blk_remove_plug+0x4f/0x5b
 [<c0220064>] blk_run_queue+0x37/0x63
 [<c030f46f>] scsi_run_host_queues+0x10/0x22
 [<c030e4bd>] scsi_error_handler+0x237/0x26f
 [<c0114d80>] complete+0x39/0x48
 [<c030e286>] scsi_error_handler+0x0/0x26f
 [<c01292f3>] kthread+0x38/0x5d
 [<c01292bb>] kthread+0x0/0x5d
 [<c0103153>] kernel_thread_helper+0x7/0x10
 =======================
Code: 0f 77 7b 81 7c 24 28 00 01 00 00 77 71 8b 54 24 04 89 f0 e8 f1 a2 ff
ff 85
 c0 78 69 8b 54 24 04 89 f8 0f b7 8a 40 02 00 00 31 d2 <f7> f1 89 04 24 8b
44 24
 04 89 d1 31 d2 0f b7 98 3e 02 00 00 8b
EIP: [<c03c7a48>] ata_build_rw_tf+0x20e/0x275 SS:ESP 0068:f7c4be94 

Re: CF flash PATA on libata failure to attach

[Mark Lord]

Andrew Hall wrote:
>> This looks a lot like the other CF-card problem that was being debugged
>> here over the past week -- the one where POLLING had to be turned on.
>> Robert de Rooy (copied) was the reporter for that one.
>> Perhaps you two could compare notes ?

Do you have a spare device you can send me?

Or exactly what is this gizmo, anyway?
(brand, model, form factor ...)

Thanks

RE: CF flash PATA on libata failure to attach

[Andrew Hall]

Hi Mark,

The device is a Nexcom NSA1083 appliance:

http://www.nexcom.com/product/productshow.jsp?iid=13&pid=878

It's an OEM appliance that uses the Intel 965 chipset. We use it as one of
three platforms for our access control and compliance products as it has 8
built in Ethernet ports and a dual core processor - with built in compact
flash. The older appliance that this new (1083) one is superseding also had
built in CF although this one apparently had separate PATA and SATA
controllers, whereas the 1083 has only one 4 channel ICH8 Intel SATA
controller which interfaces to one CF connector and one IDE connector via a
SATA to PATA bridge ( I don't know exactly what this bridge is or how it
interfaces to the SATA bus - but I can probably find this out from the
manufacturer). The CF is a standard 512MB Sandisk/Kingston chip that we boot
from and write configuration data to.

I appreciate your offer to look at this issue and depending on where you
are, we can probably ship you an appliance directly from Taiwan. The other
option possibly is to get you/someone remote access into one of these units
via the net, if that would help. The ridiculous thing is that we can boot
off the CF with no problems and the libata/piix driver goes some way to
recognizing that it's compact flash, so I believe the issue can't be too
difficult to resolve - I just need someone with a bit of knowledge on the
driver that can guide me through things to try or areas to look.
    
Many thanks,

> -----Original Message-----
> From: Mark Lord [mailto:liml@rtr.ca]
> Sent: Thursday, 28 June 2007 12:08 AM
> To: Andrew Hall
> Cc: linux-ide@vger.kernel.org; robert.de.rooy@gmail.com
> Subject: Re: CF flash PATA on libata failure to attach
> 
> Andrew Hall wrote:
> >> This looks a lot like the other CF-card problem that was being
> debugged
> >> here over the past week -- the one where POLLING had to be turned
> on.
> >> Robert de Rooy (copied) was the reporter for that one.
> >> Perhaps you two could compare notes ?
> 
> Do you have a spare device you can send me?
> 
> Or exactly what is this gizmo, anyway?
> (brand, model, form factor ...)
> 
> Thanks

Re: CF flash PATA on libata failure to attach

[Mark Lord]

Andrew Hall wrote:
 > Hi Mark,
 >
 > The device is a Nexcom NSA1083 appliance:
 >
 > http://www.nexcom.com/product/productshow.jsp?iid=13&pid=878
 >
 > It's an OEM appliance that uses the Intel 965 chipset. We use it as one of
 > three platforms for our access control and compliance products as it has 8
 > built in Ethernet ports and a dual core processor - with built in compact
 > flash. The older appliance that this new (1083) one is superseding also had
 > built in CF although this one apparently had separate PATA and SATA
 > controllers, whereas the 1083 has only one 4 channel ICH8 Intel SATA
 > controller which interfaces to one CF connector and one IDE connector via a
 > SATA to PATA bridge ( I don't know exactly what this bridge is or how it
 > interfaces to the SATA bus - but I can probably find this out from the
 > manufacturer). The CF is a standard 512MB Sandisk/Kingston chip that we boot
 > from and write configuration data to.
..

I'm betting that the SATA/PATA converter is getting confused with
the ata_piix driver's attempt to use MDMA2 on it.

PIO appears to be working fine -- the BIOS uses it to boot,
and libata uses it to do the IDENTIFY operation.

So, try this hack, which should force ata_piix to use only PIO
for the ICH8 chipset. So long as you don't have any real SATA
drives, this might do the trick.

Cheers

--- linux/drivers/ata/ata_piix.c.orig 2007-06-27 11:20:51.000000000 -0400
+++ linux/drivers/ata/ata_piix.c 2007-06-28 13:32:27.000000000 -0400
@@ -526,8 +526,8 @@
.flags = PIIX_SATA_FLAGS | PIIX_FLAG_SCR |
PIIX_FLAG_AHCI,
.pio_mask = 0x1f, /* pio0-4 */
- .mwdma_mask = 0x07, /* mwdma0-2 */
- .udma_mask = 0x7f, /* udma0-6 */
+ .mwdma_mask = 0x00, /* mwdma0-2 */
+ .udma_mask = 0x00, /* udma0-6 */
.port_ops = &piix_sata_ops,
},

@@ -537,8 +537,8 @@
.flags = PIIX_SATA_FLAGS | PIIX_FLAG_SCR |
PIIX_FLAG_AHCI,
.pio_mask = 0x1f, /* pio0-4 */
- .mwdma_mask = 0x07, /* mwdma0-2 */
- .udma_mask = 0x7f, /* udma0-6 */
+ .mwdma_mask = 0x00, /* mwdma0-2 */
+ .udma_mask = 0x00, /* udma0-6 */
.port_ops = &piix_sata_ops,
},

RE: CF flash PATA on libata failure to attach

[Andrew Hall]

> 
> I'm betting that the SATA/PATA converter is getting confused with
> the ata_piix driver's attempt to use MDMA2 on it.
> 
> PIO appears to be working fine -- the BIOS uses it to boot,
> and libata uses it to do the IDENTIFY operation.
> 
> So, try this hack, which should force ata_piix to use only PIO
> for the ICH8 chipset. So long as you don't have any real SATA
> drives, this might do the trick.
> 
> Cheers
> 
> --- linux/drivers/ata/ata_piix.c.orig 2007-06-27 11:20:51.000000000 -
> 0400
> +++ linux/drivers/ata/ata_piix.c 2007-06-28 13:32:27.000000000 -0400
> @@ -526,8 +526,8 @@
> .flags = PIIX_SATA_FLAGS | PIIX_FLAG_SCR |
> PIIX_FLAG_AHCI,
> .pio_mask = 0x1f, /* pio0-4 */
> - .mwdma_mask = 0x07, /* mwdma0-2 */
> - .udma_mask = 0x7f, /* udma0-6 */
> + .mwdma_mask = 0x00, /* mwdma0-2 */
> + .udma_mask = 0x00, /* udma0-6 */
> .port_ops = &piix_sata_ops,
> },
> 
> @@ -537,8 +537,8 @@
> .flags = PIIX_SATA_FLAGS | PIIX_FLAG_SCR |
> PIIX_FLAG_AHCI,
> .pio_mask = 0x1f, /* pio0-4 */
> - .mwdma_mask = 0x07, /* mwdma0-2 */
> - .udma_mask = 0x7f, /* udma0-6 */
> + .mwdma_mask = 0x00, /* mwdma0-2 */
> + .udma_mask = 0x00, /* udma0-6 */
> .port_ops = &piix_sata_ops,
> },

Yes!! It worked.. which means you were right - forcing the channel to PIO4
and the drive was happy. The problem I have now is that we do in fact also
have a SATA HDD connected to the same controller used for database and
logging data - this now also is forced to use PIO4. How can I force the
first channel to only use PIO and the remainder to use MWDMA2? 

Thanks for your help..

Re: CF flash PATA on libata failure to attach

[Mark Lord]

Andrew Hall wrote:
>
> Yes!! It worked.. which means you were right - forcing the channel to PIO4
> and the drive was happy. The problem I have now is that we do in fact also
> have a SATA HDD connected to the same controller used for database and
> logging data - this now also is forced to use PIO4. How can I force the
> first channel to only use PIO and the remainder to use MWDMA2? 
> 
> Thanks for your help..

You're welcome.

Here's a slightly modified hack, which should leave your SATA
drive working as well as the CF card.

Tejun / Alan : do we really want to continue attempting mdma2
on a modern chipset such as ICH8 ???

The best mdma2 can do is the same throughput as pio4,
and the bus occupancy is so high for mdma2 that it really
probably isn't worthwhile -- only CF cards seem to use it
in modern systems anyway.

Signed-off-by:  Mark Lord <mlord@pobox.com>
---
--- linux/drivers/ata/ata_piix.c.orig	2007-06-10 18:58:27.000000000 -0400
+++ linux/drivers/ata/ata_piix.c	2007-06-28 21:09:04.000000000 -0400
@@ -537,7 +537,7 @@
 		.flags		= PIIX_SATA_FLAGS | PIIX_FLAG_SCR |
 				  PIIX_FLAG_AHCI,
 		.pio_mask	= 0x1f,	/* pio0-4 */
-		.mwdma_mask	= 0x07, /* mwdma0-2 */
+		.mwdma_mask	= 0x00, /* mwdma0-2 */
 		.udma_mask	= 0x7f,	/* udma0-6 */
 		.port_ops	= &piix_sata_ops,
 	},

Re: CF flash PATA on libata failure to attach

[Tejun Heo]

Hello,

Mark Lord wrote:
> Here's a slightly modified hack, which should leave your SATA
> drive working as well as the CF card.
> 
> Tejun / Alan : do we really want to continue attempting mdma2
> on a modern chipset such as ICH8 ???

One thing that worries me is that we have reports where the IDE piix can
do mwdma but ata_piix can't.  I wonder whether Andrew is hitting the
same problem.

> The best mdma2 can do is the same throughput as pio4,
> and the bus occupancy is so high for mdma2 that it really
> probably isn't worthwhile -- only CF cards seem to use it
> in modern systems anyway.

There also seem to be devices which claim to support mwdma2 but pukes
when actual commands are given.  Do we know whether the other os uses
mwdma mode?

-- 
tejun

RE: CF flash PATA on libata failure to attach

[Andrew Hall]

> Here's a slightly modified hack, which should leave your SATA
> drive working as well as the CF card.
> 
> Tejun / Alan : do we really want to continue attempting mdma2
> on a modern chipset such as ICH8 ???
> 
> The best mdma2 can do is the same throughput as pio4,
> and the bus occupancy is so high for mdma2 that it really
> probably isn't worthwhile -- only CF cards seem to use it
> in modern systems anyway.
> 
> Signed-off-by:  Mark Lord <mlord@pobox.com>
> ---
> --- linux/drivers/ata/ata_piix.c.orig	2007-06-10 18:58:27.000000000
> -0400
> +++ linux/drivers/ata/ata_piix.c	2007-06-28 21:09:04.000000000 -0400
> @@ -537,7 +537,7 @@
>  		.flags		= PIIX_SATA_FLAGS | PIIX_FLAG_SCR |
>  				  PIIX_FLAG_AHCI,
>  		.pio_mask	= 0x1f,	/* pio0-4 */
> -		.mwdma_mask	= 0x07, /* mwdma0-2 */
> +		.mwdma_mask	= 0x00, /* mwdma0-2 */
>  		.udma_mask	= 0x7f,	/* udma0-6 */
>  		.port_ops	= &piix_sata_ops,
>  	},

That worked a treat! CF is flagged as PIO4 and HDD is now UDMA. I can't tell
you how grateful I am that you were able to point out the fix / modification
but I can certainly now sleep a bit easier.

Furthermore, if there is anything else I can do or would like me to test
while we have this type of hardware, please let me know.

Thanks again, Mark..

Re: CF flash PATA on libata failure to attach

[Mark Lord]

Tejun Heo wrote:
> Hello,
> 
> Mark Lord wrote:
>> Here's a slightly modified hack, which should leave your SATA
>> drive working as well as the CF card.
>>
>> Tejun / Alan : do we really want to continue attempting mdma2
>> on a modern chipset such as ICH8 ???
> 
> One thing that worries me is that we have reports where the IDE piix can
> do mwdma but ata_piix can't.  I wonder whether Andrew is hitting the
> same problem.

I think Andrew said he had tried the old IDE driver,
but perhaps it didn't match his PCI IDs ?

Andrew?

Re: CF flash PATA on libata failure to attach

[Mark Lord]

Andrew Hall wrote:
>..
>> Signed-off-by:  Mark Lord <mlord@pobox.com>
>> ---
>> --- linux/drivers/ata/ata_piix.c.orig	2007-06-10 18:58:27.000000000
>> -0400
>> +++ linux/drivers/ata/ata_piix.c	2007-06-28 21:09:04.000000000 -0400
>> @@ -537,7 +537,7 @@
>>  		.flags		= PIIX_SATA_FLAGS | PIIX_FLAG_SCR |
>>  				  PIIX_FLAG_AHCI,
>>  		.pio_mask	= 0x1f,	/* pio0-4 */
>> -		.mwdma_mask	= 0x07, /* mwdma0-2 */
>> +		.mwdma_mask	= 0x00, /* mwdma0-2 */
>>  		.udma_mask	= 0x7f,	/* udma0-6 */
>>  		.port_ops	= &piix_sata_ops,
>>  	},
> 
> That worked a treat! CF is flagged as PIO4 and HDD is now UDMA. I can't tell
> you how grateful I am that you were able to point out the fix / modification
> but I can certainly now sleep a bit easier.
> 
> Furthermore, if there is anything else I can do or would like me to test
> while we have this type of hardware, please let me know.
> 
> Thanks again, Mark..

You can certainly also thank Tejun and Jeff,
for making libata so easy to tune with a one-liner liner like this!

Per my other email -- did you try the legacy IDE driver
instead of libata?  Can you provide a boot log from that for Tejun?

Cheers!

RE: CF flash PATA on libata failure to attach

[Andrew Hall]

> You can certainly also thank Tejun and Jeff,
> for making libata so easy to tune with a one-liner liner like this!
> 
> Per my other email -- did you try the legacy IDE driver
> instead of libata?  Can you provide a boot log from that for Tejun?

Too true.. thanks Tejun, Jeff and Alan also.. much appreciated..

I did try the legacy driver but couldn't get it to be detected at all. I
wasn't sure how to modify it (ide/pci/piix.c) to add the right PCI-ID but am
happy to get Tejun the dmesg if you can tell me how I derive the PCI-ID for
my hardware and where to add it. Also because this is IDE via SATA, when
disabling the libata drivers do I need to enable the old "Support for SATA"
compile option to get the device to be detected?

RE: CF flash PATA on libata failure to attach

[Andrew Hall]

> 
> Per my other email -- did you try the legacy IDE driver
> instead of libata?  Can you provide a boot log from that for Tejun?

Further to this the PATA to SATA bridge being used in this case is:

http://www.jmicron.com/JM20330.html

..as you will see only PIO and UDMA modes are supported.

Re: CF flash PATA on libata failure to attach

[Alan Cox]

On Thu, Jun 28, 2007 at 09:10:06PM -0400, Mark Lord wrote:
> Here's a slightly modified hack, which should leave your SATA
> drive working as well as the CF card.
> 
> Tejun / Alan : do we really want to continue attempting mdma2
> on a modern chipset such as ICH8 ???

Thats a good question is it only has a SATA interface, however while our
PIO locks IRQs off and sucks the answer is probably yes, because we still
see MWDMA2 CD drives on boxes like this and they work.

Alan

Re: CF flash PATA on libata failure to attach

[Alan Cox]

On Fri, Jun 29, 2007 at 05:34:36PM +1000, Andrew Hall wrote:
> Further to this the PATA to SATA bridge being used in this case is:
> 
> http://www.jmicron.com/JM20330.html
> 
> ..as you will see only PIO and UDMA modes are supported.

In which case their microcontroller in the middle should be masking ident
bits. Without a way to detect the presence of the device I don't see an
easy way for us to handle it automatically at all

Re: CF flash PATA on libata failure to attach

[Tejun Heo]

Alan Cox wrote:
> On Fri, Jun 29, 2007 at 05:34:36PM +1000, Andrew Hall wrote:
>> Further to this the PATA to SATA bridge being used in this case is:
>>
>> http://www.jmicron.com/JM20330.html
>>
>> ..as you will see only PIO and UDMA modes are supported.
> 
> In which case their microcontroller in the middle should be masking ident
> bits. Without a way to detect the presence of the device I don't see an
> easy way for us to handle it automatically at all

I'll ask JMicron about it.

-- 
tejun

Re: CF flash PATA on libata failure to attach

[Albert Lee]

Alan Cox wrote:
> On Fri, Jun 29, 2007 at 05:34:36PM +1000, Andrew Hall wrote:
> 
>>Further to this the PATA to SATA bridge being used in this case is:
>>
>>http://www.jmicron.com/JM20330.html
>>
>>..as you will see only PIO and UDMA modes are supported.
> 
> 
> In which case their microcontroller in the middle should be masking ident
> bits. Without a way to detect the presence of the device I don't see an
> easy way for us to handle it automatically at all
> 

I didn't test whether MWDMA2 is supported by the JMicron bridge or not.
But I'm sure that the JMicron bridge doesn't mangle the IDENTIFY to
indicat anything about MWDMA unsupported:
(Previous test report:
http://www.spinics.net/lists/linux-ide/msg01514.html)

The Acard ARC-770 bridge from another vendor does mangle the IDENTIFY
data and indicates MWDMA unsupported as Alan advised.

Andrew, maybe you could test if such bridge works with your CF device.
(http://www.acard.com/english/fb0101.jsp?type1_idno=1&type2_idno=17)
--
albert