lkml.org 
[lkml]   [2006]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Linux v2.6.18-rc5
Date
Tejun Heo (on Sun, 03 Sep 2006 15:10:44 +0900) wrote:
>Keith Owens wrote:
>>>> (2) I have seen the same intermittent bug on ICH7 SATA but
>>>> PIIX_FLAG_IGNORE_PCS is only set for ich5 and i6300esb_sata. It
>>>> probably needs to be set for ich7 as well.
>>> No, ICH7 up to this point has been believed to have well-behaving PCS.
>>> If you report PCS problem, you'll be the first.
>
>Hmm... Can you try the attached patch and see what happens? ATM, I'm on
>the road and can't test the patch, so it's only compile-tested. This
>patch basically reverts some of the effects of the following commit and
>makes PCS update a little bit more aggressive iff necessary.
>
>ea35d29e2fa8b3d766a2ce8fbcce599dce8d2734
>[libata] ata_piix: Consolidate PCS register writing
>
>If this works for you ich7m, can you please test this on your formerly
>problematic ich5 with force_pcs=2 specified? I initially thought that
>the ich5 problem was caused by exact PCS map change and thus added
>IGNORE_PCS as workaround but if the same problem occurs on ich7 and is
>fixed by the attached patch, it's due to conservative PCS update change
>and thus the original IGNORE_PCS fix on ich5 might not be necessary.
>just doesn't work quite as ata_piix developers expect.

Tested the patch on my ich7 (actually ich6m) laptop, on top of
2.6.18-rc7. It failed after about 6 reboots. Hand copied portion of
the boot log (no serial port on this laptop).

ata_piix 0000:00:1f.2: MA{ [ P0 P2 IDE IDE ]
ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) -> IRQ 18
ata: 0x170 IDE port busy
ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x18B0 irq 14
scsi0: ata_piix
ata1: failed to update PCS after 10 tries, old=0x0 cur=0x0 new=0x5

I also booted my problem ich5 system with this patch on 2.6.18-rc7 with
ata_piix.force_pcs=2. It gets the 'force honoring PCS' message and so
far it has not failed. 95 reboots later, and every single one detected
the disk in 0 tries. Go figure.

Remember that adding the kdb patch and turning on kdb debugging makes
this problem more likely to occur. I can reproduce the problem on both
machines using 2.6.18-rc5 without kdb, so kdb is not the cause.

Also remember that the ich5 box is actually a 64 bit system. I have
only ever seen this problem when running in i386 mode, in x86_64 mode
pcs always just works.

Maybe we are looking at a timing race or a memory mapping problem?

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

\
 
 \ /
  Last update: 2006-09-15 09:43    [W:0.119 / U:0.260 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site