Re: cached PCS

[Jeff Garzik <jeff@garzik.org>]

Tejun Heo wrote:
> Jeff Garzik wrote:
>> Tejun Heo wrote:
>>> Jeff Garzik wrote:
>>>> Tejun Heo wrote:
>>>>> Jeff Garzik wrote:
>>>>>> can you resurrect your cached PCS patch?
>>>>>>
>>>>>> 2.6.18-rc didn't fix the ghost device and long boot delay problems 
>>>>>> for everybody.
>>>>>
>>>>> The cached PCS patch was to fix device detection failure on some 
>>>>> ICH5s where PCS is cleared while probing the first port.  Remaining 
>>>>> ghost device and long boot delay are fixed by honor-PCS patch.  Do 
>>>>> you want me to resurrect both?
>>>>
>>>> hrm.  Maybe just honor-PCS?
>>>
>>> Yeap, we need to verify whether the less-jealous-PCS-update patch 
>>> cured the ICH5 problem.
>>
>> If you are talking about the patch currently in 2.6.18-rc, I got 
>> several ACKs that it fixed their problems.
>>
>> But OTOH, there was also
>> http://marc.theaimsgroup.com/?t=115346292700002&r=1&w=2
> 
> I was talking about bugzilla bug #6724.
> 
> http://bugzilla.kernel.org/show_bug.cgi?id=6724
> 
> It was a weird case of ICH5 clearing PCS present bits while the first 
> port is being probed.  The clearing happens during actual probe, that 
> is, the bits look okay till the end of the first prereset() but on entry 
> to prereset() for the second port, enabled bits are gone.  IIRC, 
> bug#6724 is different from all other reports.
> 
> I asked the reporter to test 2.6.18-rc4 and see whether the problem is 
> gone with new PCS handling.  I'm a bit skeptical about the result.  If 
> the problem remains with 2.6.18-rc4, we'll need that cached PCS to solve 
> that particular case.
> 
> BTW, do you know what Keith Owen's chipset was?

(Keith CC'd)

I didn't see lspci output, but it looks like ICH5 from his drivers/ide 
dmesg output.

Did you look at some of the other messages?  He provided some debug 
traces in follow-up messages.

	Jeff