On Sun, 14 Oct 2007 13:31:34 -0400, Jeff Garzik wrote:
> Mikael Pettersson wrote:
> > On Thu, 16 Aug 2007 21:19:40 +0100, Alan Cox wrote:
> Unfortunately this breaks pata_pdc2027x on my PowerMac G3:
> >>> Did this ever get resolved?
> >> All went quiet so I assume its gone away ?
> >
> > -ENO
Mikael Pettersson wrote:
> On Thu, 16 Aug 2007 21:19:40 +0100, Alan Cox wrote:
Unfortunately this breaks pata_pdc2027x on my PowerMac G3:
>>> Did this ever get resolved?
>> All went quiet so I assume its gone away ?
>
> -ENOTIME
>
> The regression is still there in 2.6.23-rc3 (I just checked
On Thu, 16 Aug 2007 21:19:40 +0100, Alan Cox wrote:
> > > Unfortunately this breaks pata_pdc2027x on my PowerMac G3:
> >
> > Did this ever get resolved?
>
> All went quiet so I assume its gone away ?
-ENOTIME
The regression is still there in 2.6.23-rc3 (I just checked),
but I haven't had time t
> > Unfortunately this breaks pata_pdc2027x on my PowerMac G3:
>
> Did this ever get resolved?
All went quiet so I assume its gone away ?
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Mikael Pettersson wrote:
> (cc:ing linuxppc-dev)
>
> On Tue, 26 Jun 2007 13:43:15 +0800, Albert Lee wrote:
>> Recently the PLL input clock of pata_pdc2027x is sometimes detected
>> higer than expected (e.g. 20.027 MHz compared to 16.714 MHz).
>> It seems sometimes the mdelay() function is not as p
Mikael Pettersson wrote:
> On Wed, 11 Jul 2007 10:45:35 +0800, Albert Lee wrote:
>
>>So, it seems both mdelay(37) and do_gettimeofday() are working properly on
>>PowerMac G3.
>>Maybe the calculated wrong PLL input is due to wrong reading of the counter
>>register?
>>Could you please try the atta
On Wed, 11 Jul 2007 10:45:35 +0800, Albert Lee wrote:
> Mikael Pettersson wrote:
> >
> >
> > 2.6.22 + this prints the following on my G3:
> >
> > pata_pdc2027x :00:0e.0: version 0.9
> > usec_elapsed for mdelay(37) [35431]
> > start time: [1184112028]s [775333]us
> > end time: [1184112028]
Mikael Pettersson wrote:
>
>
> 2.6.22 + this prints the following on my G3:
>
> pata_pdc2027x :00:0e.0: version 0.9
> usec_elapsed for mdelay(37) [35431]
> start time: [1184112028]s [775333]us
> end time: [1184112028]s [810764]us
> pata_pdc2027x :00:0e.0: PLL input clock 1691741 kHz
On Tue, 10 Jul 2007 11:52:59 +0800, Albert Lee wrote:
> >>Recently the PLL input clock of pata_pdc2027x is sometimes detected
> >>higer than expected (e.g. 20.027 MHz compared to 16.714 MHz).
> >>It seems sometimes the mdelay() function is not as precise as it
> >>used to be. Per Alan's advice, HT
Mikael Pettersson wrote:
> (cc:ing linuxppc-dev)
>
> On Tue, 26 Jun 2007 13:43:15 +0800, Albert Lee wrote:
>
>>Recently the PLL input clock of pata_pdc2027x is sometimes detected
>>higer than expected (e.g. 20.027 MHz compared to 16.714 MHz).
>>It seems sometimes the mdelay() function is not as p
(cc:ing linuxppc-dev)
On Tue, 26 Jun 2007 13:43:15 +0800, Albert Lee wrote:
> Recently the PLL input clock of pata_pdc2027x is sometimes detected
> higer than expected (e.g. 20.027 MHz compared to 16.714 MHz).
> It seems sometimes the mdelay() function is not as precise as it
> used to be. Per Ala
11 matches
Mail list logo