Re: Continual reading from the PowerPc time base register is not stable
Hi Kim The isync is not needed, when I only added the long long cast, the problem can never reproduced. And I found after Linux started, I ran the "gettime" test code in the background, if I ran our software application, the gettime could fail sometimes, and even after killing our software application, the gettime still failed, if I didn't run our software application after Linux started, the gettime never fail . I checked out that there is no NTP damone nor cron tasks running behind, but our software application has the mechanism like NTP to synchronize time with other boards in our system, the problem is I cannot figure out why gettime still failed after killing our software application. Maybe there is a timer running for this proprietary NTP implementation, even after killing software application? Thanks Gino 2010/4/22 Kim Phillips > On Sat, 10 Apr 2010 11:14:09 +0800 > Csdncannon wrote: > > > Sorry, I attached the wrong log, this attachment is the right one. > > > > 2010/3/25 Csdncannon > > > > > In my program, the value of the 64-bit time base register is > read > > > out, and you will find the later value is even smaller than the earlier > > > value from the log “log_timebase”. While the kernel depends on the > accuracy > > > of the timebase for the compensation of the lost PIT interrupt, the > negative > > > value between two continual timebase reading will bring to the jump of > the > > > jiffies. And this timebase problem will bring to the instability of the > > > gettimeofday system call. > > > > > > Do you have any idea about this problem, thanks for your any > > > advice. Attached is the code and log. > > Hi, has this been resolved yet? > > I took an 8377 rdb board, and let it run timebase.c (with the isync & > long long casts) all weekend, and have failed to reproduce the issue. > That was on linux 2.6.33, and I've got another machine running the same > thing under 2.6.28 for the last couple of hours, still unable to > reproduce the issue. > > Can you please answer the "custom board or FSL reference board" > question, try duplicating with a newer kernel version, discuss other > time sources that may be running on your system (RTC_DRV, ntp service), > post a .config, ... > > Kim > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Continual reading from the PowerPc time base register is not stable
On Thu, 22 Apr 2010 10:50:16 +1000
Benjamin Herrenschmidt wrote:
> On Wed, 2010-04-21 at 19:44 -0500, Kim Phillips wrote:
> > I took an 8377 rdb board, and let it run timebase.c (with the isync &
> > long long casts) all weekend, and have failed to reproduce the issue.
> > That was on linux 2.6.33, and I've got another machine running the
> > same
> > thing under 2.6.28 for the last couple of hours, still unable to
> > reproduce the issue.
>
> Do we need to add an isync to the vdso and kernel gettimeofday() ?
don't see why: I put two gettimeofday calls in a tight loop, checking
if (t2.tv_sec < t1.tv_sec) || (t2.tv_sec > t1.tv_sec + 1), and the
condition was never met. I also removed all {i,}sync instructions from
timebase.c (but left the long long casts in), and no failures were
reported.
Kim
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Continual reading from the PowerPc time base register is not stable
On Wed, 2010-04-21 at 19:44 -0500, Kim Phillips wrote: > I took an 8377 rdb board, and let it run timebase.c (with the isync & > long long casts) all weekend, and have failed to reproduce the issue. > That was on linux 2.6.33, and I've got another machine running the > same > thing under 2.6.28 for the last couple of hours, still unable to > reproduce the issue. Do we need to add an isync to the vdso and kernel gettimeofday() ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Continual reading from the PowerPc time base register is not stable
On Sat, 10 Apr 2010 11:14:09 +0800 Csdncannon wrote: > Sorry, I attached the wrong log, this attachment is the right one. > > 2010/3/25 Csdncannon > > > In my program, the value of the 64-bit time base register is read > > out, and you will find the later value is even smaller than the earlier > > value from the log “log_timebase”. While the kernel depends on the accuracy > > of the timebase for the compensation of the lost PIT interrupt, the negative > > value between two continual timebase reading will bring to the jump of the > > jiffies. And this timebase problem will bring to the instability of the > > gettimeofday system call. > > > > Do you have any idea about this problem, thanks for your any > > advice. Attached is the code and log. Hi, has this been resolved yet? I took an 8377 rdb board, and let it run timebase.c (with the isync & long long casts) all weekend, and have failed to reproduce the issue. That was on linux 2.6.33, and I've got another machine running the same thing under 2.6.28 for the last couple of hours, still unable to reproduce the issue. Can you please answer the "custom board or FSL reference board" question, try duplicating with a newer kernel version, discuss other time sources that may be running on your system (RTC_DRV, ntp service), post a .config, ... Kim ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Continual reading from the PowerPc time base register is not stable
Sorry, I attached the wrong log, this attachment is the right one. 2010/3/25 Csdncannon > In my program, the value of the 64-bit time base register is read > out, and you will find the later value is even smaller than the earlier > value from the log “log_timebase”. While the kernel depends on the accuracy > of the timebase for the compensation of the lost PIT interrupt, the negative > value between two continual timebase reading will bring to the jump of the > jiffies. And this timebase problem will bring to the instability of the > gettimeofday system call. > > Do you have any idea about this problem, thanks for your any > advice. Attached is the code and log. > > > Thanks > > Gino > > > > gettime.log Description: Binary data ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Continual reading from the PowerPc time base register is not stable
Hi guys In fact my problem is gettimeofday cannot return right value sometimes, and this will bring instability to our system software. You can find a law from the log that there is a 17592 seconds' shift every time error occurs. 2010/3/26 Csdncannon > Yes, the missing 64-bit conversion is the key problem, I will try removing > isync later. > > Thanks for your support. > > > 2010/3/26 Segher Boessenkool > >> > Yes indeed. Could you post the relevant piece if disassembly from >> >> > your original binary (the one that has the problem)? Or send me the >> > binary (not to the mailing list), I'll do it then. >> >> Ah scratch that. I compiled your original code (after fixing the >> compile errors -- there is no such type as "bool" in C). >> >> The problem is that (upper << 32) | lower thing. "upper" is a 32-bit >> type, so shifting it by 32 or more bits is undefined. GCC compiles this >> to (shortened): >> >> 0: mftbu 9 ; mftbl 11 ; mftbu 0 ; cmpw 0,9 ; bne 0b # so far so good >> slwi 0,0,0 ; or 4,0,11 ; li 3,0 ; blr >> >> so it shifts by 0, i.e. it does upper | lower . >> >> Case closed, no hardware problem :-) >> >> >> Segher >> >> > gettime.c Description: Binary data gettime.log Description: Binary data ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Continual reading from the PowerPc time base register is not stable
Yes, the missing 64-bit conversion is the key problem, I will try removing isync later. Thanks for your support. 2010/3/26 Segher Boessenkool > > Yes indeed. Could you post the relevant piece if disassembly from > > your original binary (the one that has the problem)? Or send me the > > binary (not to the mailing list), I'll do it then. > > Ah scratch that. I compiled your original code (after fixing the > compile errors -- there is no such type as "bool" in C). > > The problem is that (upper << 32) | lower thing. "upper" is a 32-bit > type, so shifting it by 32 or more bits is undefined. GCC compiles this > to (shortened): > > 0: mftbu 9 ; mftbl 11 ; mftbu 0 ; cmpw 0,9 ; bne 0b # so far so good > slwi 0,0,0 ; or 4,0,11 ; li 3,0 ; blr > > so it shifts by 0, i.e. it does upper | lower . > > Case closed, no hardware problem :-) > > > Segher > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Continual reading from the PowerPc time base register is not stable
> Yes indeed. Could you post the relevant piece if disassembly from > your original binary (the one that has the problem)? Or send me the > binary (not to the mailing list), I'll do it then. Ah scratch that. I compiled your original code (after fixing the compile errors -- there is no such type as "bool" in C). The problem is that (upper << 32) | lower thing. "upper" is a 32-bit type, so shifting it by 32 or more bits is undefined. GCC compiles this to (shortened): 0: mftbu 9 ; mftbl 11 ; mftbu 0 ; cmpw 0,9 ; bne 0b # so far so good slwi 0,0,0 ; or 4,0,11 ; li 3,0 ; blr so it shifts by 0, i.e. it does upper | lower . Case closed, no hardware problem :-) Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Continual reading from the PowerPc time base register is not stable
[please do not top-post] >> Do you now ever get two consecutive time readings that are closer >> that 64 tick together? If not, it's simply hiding the problem. >> >> Do you ever now read a value that does not have the bit with value >> 0x40 set? > I enabled the printing of all values. There is bigger gap between two > reading, it seems isync bring to performance drop. Yes exactly, which is to be expected. > Could you elaborate what does "closer that 64 tick together" mean? It means I cannot type -- "closer than 64 ticks". My concern was that the sync;isync thing might slow down things so much that you always get readings 64 or more cycles apart. But you don't. > You can see the attached log, the 0x40 is not always set. Yes indeed. Could you post the relevant piece if disassembly from your original binary (the one that has the problem)? Or send me the binary (not to the mailing list), I'll do it then. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Continual reading from the PowerPc time base register is not stable
Ben Attached is the previous failing one. Thanks Gino 2010/3/26 Benjamin Herrenschmidt > On Fri, 2010-03-26 at 09:11 +0800, Csdncannon wrote: > > After trying the new code with "isync" and unsigned long long > > convertion, this problem doesn't happen(I tested for several minutes). > > But the previous block of codes(lacking of isync) is borrowed from > > kernel. And if this is a bug of kernel? > > There's an outstanding question about that. Some processors make mftb > context synchronizing but it appears that it may not be the case for all > of them. > > Thus indeed, we -might- need some isync's in some places, it's not > totally clear to me though. > > Can you send the code that fails (without the isync) ? The one you sent > did have them everywhere. > > Cheers, > Ben. > > > Thanks > > Gino > > > > 2010/3/26 Benjamin Herrenschmidt > > On Thu, 2010-03-25 at 23:00 +0800, Csdncannon wrote: > > > I am really sorry that the previously attached code is > > wrong, this one > > > "timebase.c" is the right one, and the "log_timebase" file > > is the > > > right log. > > > > > > We are using FreeScale PowerPc 8378, kernel 2.6.28 and > > compiled as > > > 32-bit. > > > > > > And despite all those sync/isync you can still observe the > > timebase > > going backward ? That sounds scary. However, at this stage all > > I can > > suggest is getting freescale folks to have a look, as this > > should really > > not happen. Maybe there's some setting with that specific SoC > > that is > > missing or similar... > > > > Cheers, > > Ben. > > > > > > > > > > Thanks > > > Gino > > > > > > 2010/3/25 Arnd Bergmann > > > On Thursday 25 March 2010, Benjamin Herrenschmidt > > wrote: > > > > On Thu, 2010-03-25 at 10:41 +0800, Csdncannon > > wrote: > > > > > In my program, the value of the 64-bit > > time base > > > register is > > > > > read out, and you will find the later value is > > even > > > smaller than the > > > > > earlier value from the log “log_timebase”. While > > the > > > kernel depends on > > > > > the accuracy of the timebase for the > > compensation of the > > > lost PIT > > > > > interrupt, the negative value between two > > continual > > > timebase reading > > > > > will bring to the jump of the jiffies. And this > > timebase > > > problem will > > > > > bring to the instability of the gettimeofday > > system call. > > > > > > > > > > Do you have any idea about this > > problem, thanks > > > for your any > > > > > advice. Attached is the code and log. > > > > > > > > This is a concern, it should definitely not > > happen. What > > > machine is > > > > that ? is the code compiled 32-bit or 64-bit ? > > What kernel > > > version ? > > > > > > > > Arnd, any chance that could relate to the bug > > you've been > > > chasing on > > > > Cell ? > > > > > > > > > We're still busy with the problem analysis on Cell, > > waiting > > > for a time > > > slot to run the next test kernel. So far it seems > > like the > > > timebase > > > is actually synchronized at a significant accuracy > > on QS22 to > > > never > > > cause this problem with correct code, however it is > > possible > > > to > > > observe incorrect timebase values on Cell whenever > > the mftb > > > instruction > > > is not serialized with memory accesses, e.g. by > > using an isync > > > in front > > > of the mftb. On Power6 and other CPUs, that problem > > will not > > > happen. > > > > > >Arnd > > > > > > > > > > > > > > timebase.c Description: Binary data ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Continual reading from the PowerPc time base register is not stable
I enabled the printing of all values. There is bigger gap between two reading, it seems isync bring to performance drop. Could you elaborate what does "closer that 64 tick together" mean? You can see the attached log, the 0x40 is not always set. Thanks Gino 2010/3/26 Segher Boessenkool > > After trying the new code with "isync" and unsigned long long convertion, > > this problem doesn't happen(I tested for several minutes). > > Do you now ever get two consecutive time readings that are closer > that 64 tick together? If not, it's simply hiding the problem. > > Do you ever now read a value that does not have the bit with value > 0x40 set? > > > Segher > log Description: Binary data timebase.c Description: Binary data ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Continual reading from the PowerPc time base register is not stable
On Fri, 2010-03-26 at 09:11 +0800, Csdncannon wrote: > After trying the new code with "isync" and unsigned long long > convertion, this problem doesn't happen(I tested for several minutes). > But the previous block of codes(lacking of isync) is borrowed from > kernel. And if this is a bug of kernel? There's an outstanding question about that. Some processors make mftb context synchronizing but it appears that it may not be the case for all of them. Thus indeed, we -might- need some isync's in some places, it's not totally clear to me though. Can you send the code that fails (without the isync) ? The one you sent did have them everywhere. Cheers, Ben. > Thanks > Gino > > 2010/3/26 Benjamin Herrenschmidt > On Thu, 2010-03-25 at 23:00 +0800, Csdncannon wrote: > > I am really sorry that the previously attached code is > wrong, this one > > "timebase.c" is the right one, and the "log_timebase" file > is the > > right log. > > > > We are using FreeScale PowerPc 8378, kernel 2.6.28 and > compiled as > > 32-bit. > > > And despite all those sync/isync you can still observe the > timebase > going backward ? That sounds scary. However, at this stage all > I can > suggest is getting freescale folks to have a look, as this > should really > not happen. Maybe there's some setting with that specific SoC > that is > missing or similar... > > Cheers, > Ben. > > > > > > Thanks > > Gino > > > > 2010/3/25 Arnd Bergmann > > On Thursday 25 March 2010, Benjamin Herrenschmidt > wrote: > > > On Thu, 2010-03-25 at 10:41 +0800, Csdncannon > wrote: > > > > In my program, the value of the 64-bit > time base > > register is > > > > read out, and you will find the later value is > even > > smaller than the > > > > earlier value from the log “log_timebase”. While > the > > kernel depends on > > > > the accuracy of the timebase for the > compensation of the > > lost PIT > > > > interrupt, the negative value between two > continual > > timebase reading > > > > will bring to the jump of the jiffies. And this > timebase > > problem will > > > > bring to the instability of the gettimeofday > system call. > > > > > > > > Do you have any idea about this > problem, thanks > > for your any > > > > advice. Attached is the code and log. > > > > > > This is a concern, it should definitely not > happen. What > > machine is > > > that ? is the code compiled 32-bit or 64-bit ? > What kernel > > version ? > > > > > > Arnd, any chance that could relate to the bug > you've been > > chasing on > > > Cell ? > > > > > > We're still busy with the problem analysis on Cell, > waiting > > for a time > > slot to run the next test kernel. So far it seems > like the > > timebase > > is actually synchronized at a significant accuracy > on QS22 to > > never > > cause this problem with correct code, however it is > possible > > to > > observe incorrect timebase values on Cell whenever > the mftb > > instruction > > is not serialized with memory accesses, e.g. by > using an isync > > in front > > of the mftb. On Power6 and other CPUs, that problem > will not > > happen. > > > >Arnd > > > > > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Continual reading from the PowerPc time base register is not stable
> After trying the new code with "isync" and unsigned long long convertion, > this problem doesn't happen(I tested for several minutes). Do you now ever get two consecutive time readings that are closer that 64 tick together? If not, it's simply hiding the problem. Do you ever now read a value that does not have the bit with value 0x40 set? Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Continual reading from the PowerPc time base register is not stable
After trying the new code with "isync" and unsigned long long convertion, this problem doesn't happen(I tested for several minutes). But the previous block of codes(lacking of isync) is borrowed from kernel. And if this is a bug of kernel? Thanks Gino 2010/3/26 Benjamin Herrenschmidt > On Thu, 2010-03-25 at 23:00 +0800, Csdncannon wrote: > > I am really sorry that the previously attached code is wrong, this one > > "timebase.c" is the right one, and the "log_timebase" file is the > > right log. > > > > We are using FreeScale PowerPc 8378, kernel 2.6.28 and compiled as > > 32-bit. > > And despite all those sync/isync you can still observe the timebase > going backward ? That sounds scary. However, at this stage all I can > suggest is getting freescale folks to have a look, as this should really > not happen. Maybe there's some setting with that specific SoC that is > missing or similar... > > Cheers, > Ben. > > > > > Thanks > > Gino > > > > 2010/3/25 Arnd Bergmann > > On Thursday 25 March 2010, Benjamin Herrenschmidt wrote: > > > On Thu, 2010-03-25 at 10:41 +0800, Csdncannon wrote: > > > > In my program, the value of the 64-bit time base > > register is > > > > read out, and you will find the later value is even > > smaller than the > > > > earlier value from the log “log_timebase”. While the > > kernel depends on > > > > the accuracy of the timebase for the compensation of the > > lost PIT > > > > interrupt, the negative value between two continual > > timebase reading > > > > will bring to the jump of the jiffies. And this timebase > > problem will > > > > bring to the instability of the gettimeofday system call. > > > > > > > > Do you have any idea about this problem, thanks > > for your any > > > > advice. Attached is the code and log. > > > > > > This is a concern, it should definitely not happen. What > > machine is > > > that ? is the code compiled 32-bit or 64-bit ? What kernel > > version ? > > > > > > Arnd, any chance that could relate to the bug you've been > > chasing on > > > Cell ? > > > > > > We're still busy with the problem analysis on Cell, waiting > > for a time > > slot to run the next test kernel. So far it seems like the > > timebase > > is actually synchronized at a significant accuracy on QS22 to > > never > > cause this problem with correct code, however it is possible > > to > > observe incorrect timebase values on Cell whenever the mftb > > instruction > > is not serialized with memory accesses, e.g. by using an isync > > in front > > of the mftb. On Power6 and other CPUs, that problem will not > > happen. > > > >Arnd > > > > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Continual reading from the PowerPc time base register is not stable
On Mar 25, 2010, at 10:00 AM, Csdncannon wrote: > I am really sorry that the previously attached code is wrong, this one > "timebase.c" is the right one, and the "log_timebase" file is the right log. > > We are using FreeScale PowerPc 8378, kernel 2.6.28 and compiled as 32-bit. > > > Thanks > Gino Is this a custom board or FSL reference board? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Continual reading from the PowerPc time base register is not stable
On Thu, 2010-03-25 at 16:00 -0600, Chris Friesen wrote: > Shouldn't "upper" be cast to 64-bit before shifting? Yup but that doesn't explain his results. I think Segher nailed it to a stuck bit tho, so I would blame defective HW or HW used outside of normal operating conditions (maybe the TB is sourced out of bounds ?) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Continual reading from the PowerPc time base register is not stable
On 03/25/2010 09:00 AM, Csdncannon wrote:
> I am really sorry that the previously attached code is wrong, this one
> "timebase.c" is the right one, and the "log_timebase" file is the right log.
>
> We are using FreeScale PowerPc 8378, kernel 2.6.28 and compiled as 32-bit.
volatile unsigned long long getTimeBase()
{
unsigned long upper,lower,upper2;
do {
asm volatile("sync; isync":::"memory");
asm volatile("mftbu %0" : "=r" (upper));
asm volatile("sync; isync":::"memory");
asm volatile("mftbl %0" : "=r" (lower));
asm volatile("sync; isync":::"memory");
asm volatile("mftbu %0" : "=r" (upper2));
asm volatile("sync; isync":::"memory");
}while(upper2!=upper);
return (upper<<32)|lower;
}
Shouldn't "upper" be cast to 64-bit before shifting?
Chris
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Continual reading from the PowerPc time base register is not stable
> In my program, the value of the 64-bit time base register is read > out, and you will find the later value is even smaller than the earlier > value from the log log_timebase. > Do you have any idea about this problem, thanks for your any > advice. Attached is the code and log. Your code has a problem, you do (upper << 32) | lower, it should be ((unsigned long long)upper << 32) | lower . That is not the problem though: in your TBL, the bit with value 0x40 is stuck to 1. Broken hardware? Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Continual reading from the PowerPc time base register is not stable
On Thu, 2010-03-25 at 23:00 +0800, Csdncannon wrote: > I am really sorry that the previously attached code is wrong, this one > "timebase.c" is the right one, and the "log_timebase" file is the > right log. > > We are using FreeScale PowerPc 8378, kernel 2.6.28 and compiled as > 32-bit. And despite all those sync/isync you can still observe the timebase going backward ? That sounds scary. However, at this stage all I can suggest is getting freescale folks to have a look, as this should really not happen. Maybe there's some setting with that specific SoC that is missing or similar... Cheers, Ben. > > Thanks > Gino > > 2010/3/25 Arnd Bergmann > On Thursday 25 March 2010, Benjamin Herrenschmidt wrote: > > On Thu, 2010-03-25 at 10:41 +0800, Csdncannon wrote: > > > In my program, the value of the 64-bit time base > register is > > > read out, and you will find the later value is even > smaller than the > > > earlier value from the log “log_timebase”. While the > kernel depends on > > > the accuracy of the timebase for the compensation of the > lost PIT > > > interrupt, the negative value between two continual > timebase reading > > > will bring to the jump of the jiffies. And this timebase > problem will > > > bring to the instability of the gettimeofday system call. > > > > > > Do you have any idea about this problem, thanks > for your any > > > advice. Attached is the code and log. > > > > This is a concern, it should definitely not happen. What > machine is > > that ? is the code compiled 32-bit or 64-bit ? What kernel > version ? > > > > Arnd, any chance that could relate to the bug you've been > chasing on > > Cell ? > > > We're still busy with the problem analysis on Cell, waiting > for a time > slot to run the next test kernel. So far it seems like the > timebase > is actually synchronized at a significant accuracy on QS22 to > never > cause this problem with correct code, however it is possible > to > observe incorrect timebase values on Cell whenever the mftb > instruction > is not serialized with memory accesses, e.g. by using an isync > in front > of the mftb. On Power6 and other CPUs, that problem will not > happen. > >Arnd > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Continual reading from the PowerPc time base register is not stable
I am really sorry that the previously attached code is wrong, this one "timebase.c" is the right one, and the "log_timebase" file is the right log. We are using FreeScale PowerPc 8378, kernel 2.6.28 and compiled as 32-bit. Thanks Gino 2010/3/25 Arnd Bergmann > On Thursday 25 March 2010, Benjamin Herrenschmidt wrote: > > On Thu, 2010-03-25 at 10:41 +0800, Csdncannon wrote: > > > In my program, the value of the 64-bit time base register is > > > read out, and you will find the later value is even smaller than the > > > earlier value from the log “log_timebase”. While the kernel depends on > > > the accuracy of the timebase for the compensation of the lost PIT > > > interrupt, the negative value between two continual timebase reading > > > will bring to the jump of the jiffies. And this timebase problem will > > > bring to the instability of the gettimeofday system call. > > > > > > Do you have any idea about this problem, thanks for your any > > > advice. Attached is the code and log. > > > > This is a concern, it should definitely not happen. What machine is > > that ? is the code compiled 32-bit or 64-bit ? What kernel version ? > > > > Arnd, any chance that could relate to the bug you've been chasing on > > Cell ? > > We're still busy with the problem analysis on Cell, waiting for a time > slot to run the next test kernel. So far it seems like the timebase > is actually synchronized at a significant accuracy on QS22 to never > cause this problem with correct code, however it is possible to > observe incorrect timebase values on Cell whenever the mftb instruction > is not serialized with memory accesses, e.g. by using an isync in front > of the mftb. On Power6 and other CPUs, that problem will not happen. > >Arnd > timebase.c Description: Binary data ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Continual reading from the PowerPc time base register is not stable
On Thursday 25 March 2010, Benjamin Herrenschmidt wrote: > On Thu, 2010-03-25 at 10:41 +0800, Csdncannon wrote: > > In my program, the value of the 64-bit time base register is > > read out, and you will find the later value is even smaller than the > > earlier value from the log “log_timebase”. While the kernel depends on > > the accuracy of the timebase for the compensation of the lost PIT > > interrupt, the negative value between two continual timebase reading > > will bring to the jump of the jiffies. And this timebase problem will > > bring to the instability of the gettimeofday system call. > > > > Do you have any idea about this problem, thanks for your any > > advice. Attached is the code and log. > > This is a concern, it should definitely not happen. What machine is > that ? is the code compiled 32-bit or 64-bit ? What kernel version ? > > Arnd, any chance that could relate to the bug you've been chasing on > Cell ? We're still busy with the problem analysis on Cell, waiting for a time slot to run the next test kernel. So far it seems like the timebase is actually synchronized at a significant accuracy on QS22 to never cause this problem with correct code, however it is possible to observe incorrect timebase values on Cell whenever the mftb instruction is not serialized with memory accesses, e.g. by using an isync in front of the mftb. On Power6 and other CPUs, that problem will not happen. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Continual reading from the PowerPc time base register is not stable
On Thu, 2010-03-25 at 10:41 +0800, Csdncannon wrote: > In my program, the value of the 64-bit time base register is > read out, and you will find the later value is even smaller than the > earlier value from the log “log_timebase”. While the kernel depends on > the accuracy of the timebase for the compensation of the lost PIT > interrupt, the negative value between two continual timebase reading > will bring to the jump of the jiffies. And this timebase problem will > bring to the instability of the gettimeofday system call. > > Do you have any idea about this problem, thanks for your any > advice. Attached is the code and log. This is a concern, it should definitely not happen. What machine is that ? is the code compiled 32-bit or 64-bit ? What kernel version ? Arnd, any chance that could relate to the bug you've been chasing on Cell ? Cheers, Ben. > > Thanks > > Gino > > > > > > ___ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
