headers
Paul Mackerras | 1 Sep 2009 01:45
Picon
Favicon

Re: time jumps forward/backwards

Ben Gamsa writes:

> It appears to be the case that when the time on the system is around the 
> epoch (1970), that time will occasionally jump forward and then backward 
> by about 17592 seconds.  When it jumps forward, it always jumps back a 
> few milliseconds later.  However, it's not always easy to catch these 
> occurrences.  The delta is more specifically about 17592186059 usec, 
> give or take a few 10s of microseconds (most of the time), despite the 
> fact that the user-level program I have that is testing it only checks 
> every 10 milliseconds.

I don't think the time code in the kernel is designed to handle
negative values, i.e., times before the epoch.  If you want it to do
that you'll have to check places like arch/powerpc/kernel/time.c,
kernel/time/timekeeping.c, arch/powerpc/include/asm/time.h, etc., and
make sure that it uses signed types where necessary and that the
arithmetic is correct.

Paul.
Permalink | Reply | 0 comments |
headers
Benjamin Gamsa | 1 Sep 2009 02:01
Favicon

Re: time jumps forward/backwards

Paul Mackerras wrote:
> Ben Gamsa writes:
> 
>> It appears to be the case that when the time on the system is around the 
>> epoch (1970), that time will occasionally jump forward and then backward 
>> by about 17592 seconds.  When it jumps forward, it always jumps back a 
>> few milliseconds later.  However, it's not always easy to catch these 
>> occurrences.  The delta is more specifically about 17592186059 usec, 
>> give or take a few 10s of microseconds (most of the time), despite the 
>> fact that the user-level program I have that is testing it only checks 
>> every 10 milliseconds.
> 
> I don't think the time code in the kernel is designed to handle
> negative values, i.e., times before the epoch.  If you want it to do
> that you'll have to check places like arch/powerpc/kernel/time.c,
> kernel/time/timekeeping.c, arch/powerpc/include/asm/time.h, etc., and
> make sure that it uses signed types where necessary and that the
> arithmetic is correct.
> 

The time never goes negative.  It starts off at the epoch and moves 
forward, but sometimes it jumps forward by 17952 seconds, and then 
immediately jumps back.  But it never goes negative (or prior to 1970).

	ben
Permalink | Reply | 0 comments |
headers
Anton Vorontsov | 1 Sep 2009 01:47

Re: ECC & Magic bitmask errors with JFFS2 file system on 6.23 kernel for powerpc

On Mon, Aug 31, 2009 at 01:39:10PM -0700, Louise.Yeung <at> Sun.COM wrote:
> *Hi Rupesh,
> 
> We are using a Freescale processor similar to yours with NAND flash
> supporting 2KB page size .

What kernel version and NAND driver you use? I don't think that old
BSP kernels include fsl_elbc_nand driver, which is a much improved
version of the fsl_fcm driver.

So you might want to swith to a newer kernel or back-port the
fsl_elbc_nand driver[1] and a few fixes to your kernel.

[1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=drivers/mtd/nand/fsl_elbc_nand.c

--

-- 
Anton Vorontsov
email: cbouatmailru <at> gmail.com
irc://irc.freenode.net/bd2
Permalink | Reply | 0 comments |
headers
Benjamin Gamsa | 1 Sep 2009 02:09
Favicon

Re: time jumps forward/backwards

Benjamin Gamsa wrote:
> Paul Mackerras wrote:
>> Ben Gamsa writes:
>>
>>> It appears to be the case that when the time on the system is around 
>>> the epoch (1970), that time will occasionally jump forward and then 
>>> backward by about 17592 seconds.  When it jumps forward, it always 
>>> jumps back a few milliseconds later.  However, it's not always easy 
>>> to catch these occurrences.  The delta is more specifically about 
>>> 17592186059 usec, give or take a few 10s of microseconds (most of the 
>>> time), despite the fact that the user-level program I have that is 
>>> testing it only checks every 10 milliseconds.
>>
>> I don't think the time code in the kernel is designed to handle
>> negative values, i.e., times before the epoch.  If you want it to do
>> that you'll have to check places like arch/powerpc/kernel/time.c,
>> kernel/time/timekeeping.c, arch/powerpc/include/asm/time.h, etc., and
>> make sure that it uses signed types where necessary and that the
>> arithmetic is correct.
>>
> 
> The time never goes negative.  It starts off at the epoch and moves 
> forward, but sometimes it jumps forward by 17952 seconds, and then 
> immediately jumps back.  But it never goes negative (or prior to 1970).
> 

One important thing I forgot to add is that ntpd is running on this 
system, but the ntp servers are not available.  I suspect the problem 
may be related to ntpd, even though I've seen the time jump even when I 
had ntpd stopped within gdb.  I've not yet been able to confirm if the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephen Rothwell | 1 Sep 2009 04:05
Picon
Picon

linux-next: manual merge of the pci tree with the powerpc tree

Hi Jesse,

Today's linux-next merge of the pci tree got a conflict in
arch/powerpc/kernel/pci_64.c between commit
fbe65447197789a3ccccc27755956f6a4c445089 ("powerpc/pci: move pci_64.c
device tree scanning code into pci-common.c") from the powerpc tree and
commit ced66a36d35607c60d18bb531527acd2083c0523 ("PCI/powerpc: support
PCIe fundamental reset") from the pci tree.

The former moved the code that is modified by the latter into another
file.  I fixed it up (see below) and can carry the fix as necessary.
--

-- 
Cheers,
Stephen Rothwell                    sfr <at> canb.auug.org.au

diff --git a/arch/powerpc/kernel/pci_of_scan.c b/arch/powerpc/kernel/pci_of_scan.c
index 72c31bc..7311fdf 100644
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
 <at>  <at>  -139,6 +139,7  <at>  <at>  struct pci_dev *of_create_pci_dev(struct device_node *node,
 	dev->dev.bus = &pci_bus_type;
 	dev->devfn = devfn;
 	dev->multifunction = 0;		/* maybe a lie? */
+	dev->needs_freset = 0;		/* pcie fundamental reset required */

 	dev->vendor = get_int_prop(node, "vendor-id", 0xffff);
 	dev->device = get_int_prop(node, "device-id", 0xffff);
Permalink | Reply | 1 comment |
headers
Benjamin Gamsa | 1 Sep 2009 04:20
Favicon

Re: time jumps forward/backwards

Benjamin Gamsa wrote:
> Benjamin Gamsa wrote:
>> Paul Mackerras wrote:
>>> Ben Gamsa writes:
>>>
>>>> It appears to be the case that when the time on the system is around 
>>>> the epoch (1970), that time will occasionally jump forward and then 
>>>> backward by about 17592 seconds.  When it jumps forward, it always 
>>>> jumps back a few milliseconds later.  However, it's not always easy 
>>>> to catch these occurrences.  The delta is more specifically about 
>>>> 17592186059 usec, give or take a few 10s of microseconds (most of 
>>>> the time), despite the fact that the user-level program I have that 
>>>> is testing it only checks every 10 milliseconds.
>>>
>>> I don't think the time code in the kernel is designed to handle
>>> negative values, i.e., times before the epoch.  If you want it to do
>>> that you'll have to check places like arch/powerpc/kernel/time.c,
>>> kernel/time/timekeeping.c, arch/powerpc/include/asm/time.h, etc., and
>>> make sure that it uses signed types where necessary and that the
>>> arithmetic is correct.
>>>
>>
>> The time never goes negative.  It starts off at the epoch and moves 
>> forward, but sometimes it jumps forward by 17952 seconds, and then 
>> immediately jumps back.  But it never goes negative (or prior to 1970).
>>
> 
> One important thing I forgot to add is that ntpd is running on this 
> system, but the ntp servers are not available.  I suspect the problem 
> may be related to ntpd, even though I've seen the time jump even when I
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sean MacLennan | 1 Sep 2009 04:31
Face

Re: time jumps forward/backwards

On Mon, 31 Aug 2009 22:20:00 -0400
Benjamin Gamsa <ben <at> somanetworks.com> wrote:

> For what it's worth, the problem occurs even when ntp is not even
> started.

This is grasping, but could it have anything to do with the jiffies
wrapping near startup?

Cheers,
  Sean
Permalink | Reply | 0 comments |
headers
Benjamin Gamsa | 1 Sep 2009 05:57
Favicon

Re: time jumps forward/backwards

Sean MacLennan wrote:
> On Mon, 31 Aug 2009 22:20:00 -0400
> Benjamin Gamsa <ben <at> somanetworks.com> wrote:
> 
>> For what it's worth, the problem occurs even when ntp is not even
>> started.
> 
> This is grasping, but could it have anything to do with the jiffies
> wrapping near startup?
> 

I don't know how to test it, but I don't think so, since there are 
multiple of these glitches over an extended period of time.

	ben
Permalink | Reply | 0 comments |
headers
Jake Magee | 1 Sep 2009 06:09
Picon

PPC405 RTC not working

I am currently trying to get a M41T65 sensor to work on a PPC405 based board.  I am using the 2.6.26 kernel with a backported version of  rtc-m41t80.c (from 2.6.30).  Everything compiles and loads fine.  However, there is no /dev/rtc node created.  "/proc/devices" returns "254 rtc" (which I feel isn't correct).  And "/sys/bus/i2c/devices/" list nothing for the RTC.  I do see the information from the device tree in "/proc/device-tree/plb/opb/i2c <at> ef600400/rtc <at> 68/"

Here is my dts information:
 IIC0: i2c <at> ef600400 {
                                compatible = "ibm,iic-405exr", "ibm,iic";
                                reg = <ef600400 14>;
                                interrupt-parent = <&UIC0>;
                                interrupts = <2 4>;
                                index = <0>;
                                rtc <at> 68 {
                                        compatible = "m41t65";
                                        reg = <68>;
                                        };
                        };

Thanks!
Jake Magee

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev <at> lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Permalink | Reply | 0 comments |
headers
Rupesh Kumar | 1 Sep 2009 07:23
Favicon

Re: ECC & Magic bitmask errors with JFFS2 file system on 6.23 kernel for powerpc

Hi Louise,

Earlier we were using kernel 2.6.20(released with LTIB for REVA board of 
MPC8313E) and we were not seeing this problem in that kernel. Since, We 
had time constraint for our project, best thing we did was ported 2.6.20 
kernel on rev 2.1 silicon of MPC8313E. This is working fine.

However, We did try to dig this problem further and found that the problem 
occurs because of the ECC alignment mismatch in read & write on NAND 
flash.
You can look into following points :- 
        1) NAND initialization :-  Page size mentioned correctly in BR/OR 
register Settings.
        2) rfs is made with correct erase size.
        3) ECC placement used in u-boot & Kernel nand driver is same.
        4) Try using different ECC alignments and see if it makes some 
difference.

Regards 
Rupesh 

Anton Vorontsov <avorontsov <at> ru.mvista.com> 
09/01/2009 05:17 AM
Please respond to
avorontsov <at> ru.mvista.com

To
Louise.Yeung <at> Sun.COM
cc
linuxppc-dev <at> lists.ozlabs.org, louise <louise <at> Sun.COM>, Ravinder Kumar 
<Ravinder.Kumar <at> Sun.COM>, Rupesh Kumar <Rupesh.Kumar <at> Lntemsys.com>
Subject
Re: ECC & Magic bitmask errors with JFFS2 file system on 6.23 kernel for 
powerpc

On Mon, Aug 31, 2009 at 01:39:10PM -0700, Louise.Yeung <at> Sun.COM wrote:
> *Hi Rupesh,
> 
> We are using a Freescale processor similar to yours with NAND flash
> supporting 2KB page size .

What kernel version and NAND driver you use? I don't think that old
BSP kernels include fsl_elbc_nand driver, which is a much improved
version of the fsl_fcm driver.

So you might want to swith to a newer kernel or back-port the
fsl_elbc_nand driver[1] and a few fixes to your kernel.

[1] 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=drivers/mtd/nand/fsl_elbc_nand.c

--

-- 
Anton Vorontsov
email: cbouatmailru <at> gmail.com
irc://irc.freenode.net/bd2
Permalink | Reply | 0 comments |

Gmane