[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <44FA71E4.70408@gmail.com>
Date: Sun, 03 Sep 2006 15:10:44 +0900
From: Tejun Heo <htejun@...il.com>
To: Keith Owens <kaos@....com.au>
CC: Andrew Morton <akpm@...l.org>, Linus Torvalds <torvalds@...l.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Jeff Garzik <jeff@...zik.org>
Subject: Re: Linux v2.6.18-rc5
Hello, Keith Owens.
Sorry about late respond. I'm quite occupied with personal stuff these
days.
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. Also, note that ICH7
>> suffers from ghost device probing problem if PCS is not honored exactly.
>> Are you sure it's the same problem?
>
> It definitely looks like it. Stock 2.6.18-rc5 plus this patch to
> activate ata_debug from boot until just after probing drives.
[--snip--]
> <3>piix_sata_present_mask: ata1: ENTER, pcs=0x15 base=0
> <3>piix_sata_present_mask: ata1: LEAVE, pcs=0x15 present_mask=0x3
> <3>piix_sata_present_mask: ata1: ENTER, pcs=0x0 base=0
> <3>piix_sata_present_mask: ata1: LEAVE, pcs=0x0 present_mask=0x3
> <3>piix_sata_present_mask: ata1: ENTER, pcs=0x15 base=0
> <3>piix_sata_present_mask: ata1: LEAVE, pcs=0x15 present_mask=0x3
> <3>piix_sata_present_mask: ata1: ENTER, pcs=0x0 base=0
> <3>piix_sata_present_mask: ata1: LEAVE, pcs=0x0 present_mask=0x3
> <3>piix_sata_present_mask: ata1: ENTER, pcs=0x15 base=0
Yeah, it definitely looks like it. Does the kernel print a message
which looks like the following before those debug messages?
"updating PCS from 0x0 to 0x5"
> Note the pcs=0x0 values. Adding PIIX_FLAG_IGNORE_PCS to
> ich6m_sata_ahci gets past the failure to detect pcs, with no sign of
> any ghost devices. BTW, dropping down to 2.6.17 with the same config
> has no problem detecting the disk, even without PIIX_FLAG_IGNORE_PCS on
> ich6m_sata_ahci.
BTW, you can set PIIX_FLAG_IGNORE_PCS by using force_pcs=1 module
parameter now.
> lspci extract, this is an ICH7M.
>
> 00:1f.0 Class 0601: 8086:27b9 (rev 02)
> Subsystem: 1033:832c
> Flags: bus master, medium devsel, latency 0
> Capabilities: [e0] Vendor Specific Information
>
> 00:1f.2 Class 0101: 8086:27c4 (rev 02) (prog-if 80)
> Subsystem: 1033:832c
> Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 18
> I/O ports at <unassigned>
> I/O ports at <unassigned>
> I/O ports at <unassigned>
> I/O ports at <unassigned>
> I/O ports at 18b0 [size=16]
> Capabilities: [70] Power Management version 2
>
> 00:1f.3 Class 0c05: 8086:27da (rev 02)
> Subsystem: 1033:832c
> Flags: medium devsel, IRQ 11
> I/O ports at 18c0 [size=32]
>
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.
Sorry this PCS business causes you and other people so much trouble. It
just doesn't work quite as ata_piix developers expect.
Thanks.
--
tejun
View attachment "patch" of type "text/plain" (3418 bytes)
Powered by blists - more mailing lists