The ext3 way of journalling - Kernel

This is a discussion on The ext3 way of journalling - Kernel ; On 2008-01-13 18:11 -0500, Theodore Tso wrote: > It's much more likely that this early in your boot cycle, your clock is > sometimes incorrect. I doubt it. I get this nearly _always_ when the system crashes, which accounts for ...

+ Reply to Thread
Page 4 of 4 FirstFirst ... 2 3 4
Results 61 to 74 of 74

Thread: The ext3 way of journalling

  1. Re: The ext3 way of journalling

    On 2008-01-13 18:11 -0500, Theodore Tso wrote:
    > It's much more likely that this early in your boot cycle, your clock is
    > sometimes incorrect.


    I doubt it. I get this nearly _always_ when the system crashes, which
    accounts for the vast majority of the times I boot it. (I wish swsusp
    didn't suck so much..)

    > Is the "9192" number roughly constant, or is it always changing?


    No. That's the number I got last time, but typically I've got
    something in the 3xxxx range.

    > If your machine is on the network, then the "ntpdate"
    > program could be setting your time so that it looks correct, but
    > that's after e2fsck is run.


    ntpdate isn't run by any of the init scripts. ntpd is, but like I
    already mentioned, I doubt it would correct vastly incorrect time,
    not even being able to track and correct when it advances fast.

    --
    Tuomo
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: The ext3 way of journalling

    On Mon, 2008-01-14 at 13:11 +0200, Tuomo Valkonen wrote:
    > On 2008-01-14 10:57 +0100, Bernd Petrovitsch wrote:
    > > That leads to the question why the clock starts to run like crazy at
    > > some time so that `ntpd` can't cope with it.

    >
    > I do wonder whether the PSU could've been causing it. Now that think


    We have some embedded systems where some strange problems[0] were caused
    by bad/cheap/low-quality PSUs.

    > about it, I got the PSU around two years ago, just like I compiled
    > 2.6.14. This PSU coincidentally seems to have been the cause of the
    > crash that started this thread, and went completely silent during
    > the same day, on the third crash. But even if the PSU could cause
    > the timer interrupt to signal too frequently or so, doesn't explain
    > why nearly always after a crash (when journal recovery would be the
    > normal course of action), fsck starts checking with absurd intervals
    > since last check, whereas there's no trouble booting after normal
    > shutdown.


    But for normal PCs, I don't know how much the quality of a PSU is
    relevant for the speed of the clock.
    Can you test with a different PSU?

    Bernd

    [0]: I don't know more details out of the top of my head.
    --
    Firmix Software GmbH http://www.firmix.at/
    mobil: +43 664 4416156 fax: +43 1 7890849-55
    Embedded Linux Development and Services


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: The ext3 way of journalling

    Tuomo Valkonen writes:

    > It isn't, right after boot. But while the system is on, it sometimes
    > starts advancing very fast, 15min a day or so.


    So why don't you fix it first? Correct system time is essential.

    I guess I would upgrade to some newer version, perhaps one which isn't
    more than two years old...
    --
    Krzysztof Halasa
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: The ext3 way of journalling

    On 2008-01-14, Bernd Petrovitsch wrote:
    > Yes, that is a usual bug/problem in common distributions[0] as there is
    > no real guarantee that your clock is not far off.


    It isn't, right after boot. But while the system is on, it sometimes
    starts advancing very fast, 15min a day or so. To my knowledge, the
    time the CMOS clock is not used then, but rather the kernel tracks the
    time based on scheduler interrupts, with ntpd occasionally correcting.
    However, ntpd refuses to correct when the time has drifted too much,
    causing even further drift.


    > That the reason to activate `ntpdate` unconditionally: It sets the
    > current time to an (somewhat) accurate value and `ntpd` handles the
    > rest.


    Nope, as explained above. ntpdate at boot wouldn't help much, because
    the time is (approximately) correct after boot. It only drifts after it.

    --
    Tuomo

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: The ext3 way of journalling

    On Mon, 2008-01-14 at 09:15 +0200, Tuomo Valkonen wrote:
    [...]
    > ntpdate isn't run by any of the init scripts. ntpd is, but like I


    Yes, that is a usual bug/problem in common distributions[0] as there is
    no real guarantee that your clock is not far off.
    Add your timeservers in /etc/ntp/step-tickers whereever your
    distribution looks into to decide if ntpdate should run or activate the
    ntpdate init.d script.
    And some distributions run `ntpdate` quite late BTW ....

    > already mentioned, I doubt it would correct vastly incorrect time,
    > not even being able to track and correct when it advances fast.


    That the reason to activate `ntpdate` unconditionally: It sets the
    current time to an (somewhat) accurate value and `ntpd` handles the
    rest.

    Bernd

    [0]: Perhaps there is some reason for this. However I don't of any and
    none came ever to my mind.
    --
    Firmix Software GmbH http://www.firmix.at/
    mobil: +43 664 4416156 fax: +43 1 7890849-55
    Embedded Linux Development and Services


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: The ext3 way of journalling

    On 2008-01-14, me@bobcopeland.com wrote:
    > It sounds like you have CONFIG_PM_TRACE turned on. From the Kconfig help:


    It isn't listed in /proc/config.gz. No, I don't think I even have
    swsusp stuff compiled in, if it's related to that.

    --
    Tuomo

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: The ext3 way of journalling

    On Mon, Jan 14, 2008 at 01:46:56PM +0100, Krzysztof Halasa wrote:
    > Nothing will make it work reliably if the system clock isn't stable.


    I remember my nforce2 board having totally insane clock behaviour back
    around 2.6.14/2.6.15 or so. It has since been fixed in newer kernels.
    I seem to recall some ATI chipsets were even more insane than the nvidia
    at the time, with some running double speed for the system time.

    --
    Len Sorensen
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: The ext3 way of journalling

    On 1/14/08, Tuomo Valkonen wrote:
    > On 2008-01-13 18:11 -0500, Theodore Tso wrote:
    > > It's much more likely that this early in your boot cycle, your clock is
    > > sometimes incorrect.

    >
    > I doubt it. I get this nearly _always_ when the system crashes, which
    > accounts for the vast majority of the times I boot it. (I wish swsusp
    > didn't suck so much..)


    It sounds like you have CONFIG_PM_TRACE turned on. From the Kconfig help:

    This enables some cheesy code to save the last PM event point in the
    RTC across reboots, so that you can debug a machine that just hangs
    during suspend (or more commonly, during resume).

    [...]

    CAUTION: this option will cause your machine's real-time clock to be
    set to an invalid time after a resume.

    -Bob
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: The ext3 way of journalling

    Tuomo Valkonen wrote:
    > On 2008-01-13 18:11 -0500, Theodore Tso wrote:
    >> It's much more likely that this early in your boot cycle, your clock is
    >> sometimes incorrect.

    >
    > I doubt it. I get this nearly _always_ when the system crashes, which
    > accounts for the vast majority of the times I boot it. (I wish swsusp
    > didn't suck so much..)
    >
    >> Is the "9192" number roughly constant, or is it always changing?

    >
    > No. That's the number I got last time, but typically I've got
    > something in the 3xxxx range.
    >
    >> If your machine is on the network, then the "ntpdate"
    >> program could be setting your time so that it looks correct, but
    >> that's after e2fsck is run.

    >
    > ntpdate isn't run by any of the init scripts. ntpd is, but like I
    > already mentioned, I doubt it would correct vastly incorrect time,
    > not even being able to track and correct when it advances fast.
    >


    ntpd will allow an initial correction that is arbitrarily large, if run
    with the -g option. This is a commonly used option. I see it is running
    on my stock Fedora Core 8, for example. So there is often no need to run
    ntpdate.

    Also, ntpd keeps track of how fast your local clock tends to drift, and
    attempts to compensate. So, even if the local clock runs quite fast or
    slow, you'll normally get good results. The exception would be if you
    clock's drift rate jumps around; for example: fast today, slow tomorrow.

    On most systems, ntpd will also copy the current time back to the CMOS,
    periodically, and during an orderly shutdown.

    Hope that adds some clarity.

    thanks,
    John Hubbard
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. Re: The ext3 way of journalling

    El Mon, 14 Jan 2008 11:18:28 -0500
    lsorense@csclub.uwaterloo.ca (Lennart Sorensen) escribió:

    > On Mon, Jan 14, 2008 at 01:46:56PM +0100, Krzysztof Halasa wrote:
    > > Nothing will make it work reliably if the system clock isn't stable.

    >
    > I remember my nforce2 board having totally insane clock behaviour back
    > around 2.6.14/2.6.15 or so. It has since been fixed in newer kernels.


    My experience too with a Uli 1697 based mb. Estrange clock behaviour with
    kernel around .15-20 but fixed now (suffering too with ext3 fsck now i use jfs)

    Back in the day i blamed the new mb but now that it runs fine i can only blame
    the kernel or ubuntu user space.

    > I seem to recall some ATI chipsets were even more insane than the nvidia
    > at the time, with some running double speed for the system time.
    >
    > --
    > Len Sorensen
    > --

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: The ext3 way of journalling

    lsorense@csclub.uwaterloo.ca (Lennart Sorensen) writes:

    > I remember my nforce2 board having totally insane clock behaviour back
    > around 2.6.14/2.6.15 or so. It has since been fixed in newer kernels.
    > I seem to recall some ATI chipsets were even more insane than the nvidia
    > at the time, with some running double speed for the system time.


    Right, I remember some reports about that, probably IOAPIC or other
    HPET issues. Personally never seen that. Thus the suggestion of kernel
    upgrade.
    --
    Krzysztof Halasa
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  12. Re: The ext3 way of journalling

    On Tue, Jan 15, 2008 at 12:13:51AM +0100, Alejandro Riveira Fern??ndez wrote:
    > My experience too with a Uli 1697 based mb. Estrange clock behaviour with
    > kernel around .15-20 but fixed now (suffering too with ext3 fsck now i use jfs)
    >
    > Back in the day i blamed the new mb but now that it runs fine i can only blame
    > the kernel or ubuntu user space.


    A lot was due to bugs in the BIOS setup on many of the boards, and a few
    even due to bugs in the chip design (like ATI's as far as I remember),
    which the kernel then had to detect and work around.

    --
    Len Sorensen
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  13. Re: The ext3 way of journalling

    On Tue, Jan 15, 2008 at 02:09:02AM +0100, Krzysztof Halasa wrote:
    > Right, I remember some reports about that, probably IOAPIC or other
    > HPET issues. Personally never seen that. Thus the suggestion of kernel
    > upgrade.


    I believe the ATI chipset managed to somehow get the timer interrupt to
    arive both on the legacy 8259 and the APIC causing each timer tick to
    count twice. Nice way to double your system time rate. The nforce2
    didn't double, it just ran fast some of the time, which I have no idea
    how happened, but it went away with newer kernels (and wasn't there with
    earlier kernels either).

    --
    Len Sorensen
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  14. Re: The ext3 way of journalling

    On Jan 9, 2008 12:07 AM, Tuomo Valkonen wrote:
    > One should always indicate the version of software when complaining. Well,
    >
    > $ uname -a
    > Linux noi 2.6.14 #1 PREEMPT Sun Oct 30 20:18:48 EET 2005 i686 GNU/Linux
    >
    > I've tried upgrading, and failed: the megatonne monolith with a gazillion
    > hidden options (and totally worthless make oldconfig) is impossible to
    > compile these days, and the distros' stock kernel are utter and total crap
    > that load drivers in wrong order etc., and are difficult to configure
    > (demanding crap that demands udev to edit their initrds). Not to even
    > speak of the udev-demanding scsi-mapping insanity of SATA etc. devices
    > these days.
    >


    somebody has been reading the Unix Haters Handbook...

    I like that book too. In a way it a very good guideline for unix developers.


    > I've had it with Linux. It's no longer for power users. It's so complex
    > that it's only for idiot users that are content with the shoddy defaults,
    > and (paid) developers.
    >
    > --
    > Tuomo
    >


    I said that 2 weeks ago. And after trying out alternatives im back to linux.

    But i bought the minix 3 book...

    --
    Lay low and nourish in obscurity
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 4 of 4 FirstFirst ... 2 3 4