On Jan 9, 2008 12:07 AM, Tuomo Valkonen <[EMAIL PROTECTED]> 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 monoli
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
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 r
[EMAIL PROTECTED] (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
El Mon, 14 Jan 2008 11:18:28 -0500
[EMAIL PROTECTED] (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
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
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 so
On 2008-01-14, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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 lis
On 1/14/08, Tuomo Valkonen <[EMAIL PROTECTED]> 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 va
Tuomo Valkonen <[EMAIL PROTECTED]> writes:
>> So why don't you fix it first? Correct system time is essential.
>
> I've tried tuning it with adjtimex and everything, and sometimes it
> works for days, but then just suddenly the clock starts advancing.
Nothing will make it work reliably if the sys
On 2008-01-14, Bernd Petrovitsch <[EMAIL PROTECTED]> wrote:
> 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?
I am testing right now. After all I had to get a new PSU, the old one
being as dead as a rock.
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 tha
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
about it, I got the PSU around two years ago, just like I c
On 2008-01-14 11:06 +0100, Krzysztof Halasa wrote:
> So why don't you fix it first? Correct system time is essential.
I've tried tuning it with adjtimex and everything, and sometimes it
works for days, but then just suddenly the clock starts advancing.
> I guess I would upgrade to some newer vers
On Mon, 14 Jan 2008 10:57:09 +0100
Bernd Petrovitsch <[EMAIL PROTECTED]> wrote:
> On Mon, 2008-01-14 at 09:48 +, Tuomo Valkonen wrote:
> > On 2008-01-14, Bernd Petrovitsch <[EMAIL PROTECTED]> wrote:
> > > Yes, that is a usual bug/problem in common distributions[0] as
> > > there is no real gua
Tuomo Valkonen <[EMAIL PROTECTED]> 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
On Mon, 2008-01-14 at 09:48 +, Tuomo Valkonen wrote:
> On 2008-01-14, Bernd Petrovitsch <[EMAIL PROTECTED]> 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 sys
On 2008-01-14, Bernd Petrovitsch <[EMAIL PROTECTED]> 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
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-ticker
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
In article <[EMAIL PROTECTED]> you wrote:
> Just to clarify, I had about 60 days of uptime, and hence at least
> 60 days since the last FS check/mount/etc., when Linux crashed those
> few days ago, and wanted to start checking disks with "9192 days since
> last file system check".
This, however so
On Mon, Jan 14, 2008 at 12:23:10AM +0200, Tuomo Valkonen wrote:
> On 2008-01-14 00:13 +0200, Tuomo Valkonen wrote:
> > Also, I must say that e2fsck is brain-damaged, if it can be confused
> > by/do the stupid then when the system clock has warped by just a few
> > hours, not the _days_ that a file
On 2008-01-14 00:13 +0200, Tuomo Valkonen wrote:
> Also, I must say that e2fsck is brain-damaged, if it can be confused
> by/do the stupid then when the system clock has warped by just a few
> hours, not the _days_ that a file system check interval typically is,
> and users need to specifically kl
On 2008-01-12 10:06 -0500, Theodore Tso wrote:
> So running the "date" command after the boot sequence is completely
> finished. That doesn't mean that system clock was correct at the time
> when fsck is run.
Unless ntpd has managed to change it by that time, it was correct,
in the local time
On Jan 12, 2008 10:06 AM, Theodore Tso <[EMAIL PROTECTED]> wrote:
[snip]
> Unfortunately Ubuntu users [snip] fit this demographic hugely, and
> Ubuntu refuses to fix this problem[1], so it's been personally very
> vexing, because the users complain to *me*, and I can't fix the problem,
> because it
On Thu, Jan 10, 2008 at 03:41:11PM +0200, Tuomo Valkonen wrote:
> On 2008-01-10 08:16 -0500, Theodore Tso wrote:
> > > It displays just the right time. On boot anyway. (Linux has had some
> > > serious problems keeping the time after the switch from 2.6.7 to 2.6.14,
> > > advanding even 15 minutes
On 12.01.2008 18:10, TimC wrote:
> Bodo Eggert <[EMAIL PROTECTED]> said on Sat, 12 Jan 2008 02:41:17 +0100 (CET):
> > On Fri, 11 Jan 2008, Lennart Sorensen wrote:
> > > On Fri, Jan 11, 2008 at 05:22:45PM +0100, Bodo Eggert wrote:
> >
> > > > What can happen if someone does tune2fs -Lroot /dev/usbs
Bodo Eggert <[EMAIL PROTECTED]> said on Sat, 12 Jan 2008 02:41:17 +0100 (CET):
> On Fri, 11 Jan 2008, Lennart Sorensen wrote:
> > On Fri, Jan 11, 2008 at 05:22:45PM +0100, Bodo Eggert wrote:
>
> > > What can happen if someone does tune2fs -Lroot /dev/usbstick
> > > and puts that stick into this sy
On Fri, 11 Jan 2008, Lennart Sorensen wrote:
> On Fri, Jan 11, 2008 at 05:22:45PM +0100, Bodo Eggert wrote:
> > What can happen if someone does tune2fs -Lroot /dev/usbstick
> > and puts that stick into this system?
>
> Don't know. I use UUIDs rather than LABELs. Having duplicated labels
> just
On Fri, Jan 11, 2008 at 05:22:45PM +0100, Bodo Eggert wrote:
> What can happen if someone does tune2fs -Lroot /dev/usbstick
> and puts that stick into this system?
Don't know. I use UUIDs rather than LABELs. Having duplicated labels
just means being careless. Having duplicate UUIDs should requi
Matthias Schniedermeyer <[EMAIL PROTECTED]> wrote:
>> > Don't use udev then. Good old static dev works fine if you have a fixed
>> > set of devices.
>>
>> It doesn't, with the unpredictable SCSI mapping insanity.
>
> That what LABEL und UUID-Support in mount is for.
>
> You label the filesystem
On 10.01.2008 12:30, Helge Hafting wrote:
> Matthias Schniedermeyer wrote:
Don't use udev then. Good old static dev works fine if you have a fixed
set of devices.
>>> It doesn't, with the unpredictable SCSI mapping insanity.
>>>
>>
>> That what LABEL und UUID-Support in m
On Thu, Jan 10, 2008 at 12:30:31PM +0100, Helge Hafting wrote:
> >- fstab -
> >LABEL=root /xfs defaults,noatime0 1
> >LABEL=boot /bootext2defaults,noatime0 2
> >
> Would've been nice if they worked, but they don't.
>
> Disks should be so easy to identify uni
On 2008-01-10 08:16 -0500, Theodore Tso wrote:
> > It displays just the right time. On boot anyway. (Linux has had some
> > serious problems keeping the time after the switch from 2.6.7 to 2.6.14,
> > advanding even 15 minutes a day -- that ntpd doesn't seem to be able
> > to keep up with -- requi
On Wed, Jan 09, 2008 at 02:16:52PM +, Tuomo Valkonen wrote:
> On 2008-01-09, Mathieu SEGAUD <[EMAIL PROTECTED]> wrote:
> > fix your hardware clock then
>
> It displays just the right time. On boot anyway. (Linux has had some
> serious problems keeping the time after the switch from 2.6.7 to 2.
Matthias Schniedermeyer wrote:
Don't use udev then. Good old static dev works fine if you have a fixed
set of devices.
It doesn't, with the unpredictable SCSI mapping insanity.
That what LABEL und UUID-Support in mount is for.
You label the filesystems (e2label for ext2 and ext3)
On Jan 9, 2008 2:53 PM, Martin Schwidefsky <[EMAIL PROTECTED]> wrote:
> On Jan 9, 2008 1:25 PM, Theodore Tso <[EMAIL PROTECTED]> wrote:
> > On Wed, Jan 09, 2008 at 10:54:11AM +0100, Martin Schwidefsky wrote:
> > > Actually you can force Windows to accept a hardware clock in UTC:
> > > HKEY_LOCAL_MA
On 2008-01-09, Mathieu SEGAUD <[EMAIL PROTECTED]> wrote:
> fix your hardware clock then
It displays just the right time. On boot anyway. (Linux has had some
serious problems keeping the time after the switch from 2.6.7 to 2.6.14,
advanding even 15 minutes a day -- that ntpd doesn't seem to be able
On Jan 9, 2008 1:25 PM, Theodore Tso <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 09, 2008 at 10:54:11AM +0100, Martin Schwidefsky wrote:
> > Actually you can force Windows to accept a hardware clock in UTC:
> > HKEY_LOCAL_MACHINE/SYSTEMCurrentControlSetControl/TimeZoneInformation/RealTimeIsUniversal
>
Vous m'avez dit récemment :
> On 2008-01-08, John Stoffel <[EMAIL PROTECTED]> wrote:
>> Look at your filesystems, using 'tune2fs' and see if the ext3 journal
>> is actually turned on and used. If it's not, then I can see why
>> you're having problems on reboots.
>
> Journalling is on, but it's
On Wed, Jan 09, 2008 at 02:55:53AM -0500, [EMAIL PROTECTED] wrote:
>
> Does this create a snapshot of the *disk* at that moment, or does it
> capture "disk plus still-to-be-written blocks in the cache"?
> (Phrased differently, does it Do The Right Thing regarding "blocks
> queued before lvcreate"
On Wed, 9 Jan 2008 07:25:56 -0500
Theodore Tso <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 09, 2008 at 10:54:11AM +0100, Martin Schwidefsky wrote:
> > On Jan 8, 2008 7:15 PM, Theodore Tso <[EMAIL PROTECTED]> wrote:
> > > That will fix the this issue. The problem you are facing is that
> > > you have
On Wed, Jan 09, 2008 at 11:28:21AM +0100, Matthias Schniedermeyer wrote:
> On 09.01.2008 11:21, Matthias Schniedermeyer wrote:
> > On 09.01.2008 09:56, Tuomo Valkonen wrote:
> > > On 2008-01-09 00:06 +0100, Matthias Schniedermeyer wrote:
> > > > That what LABEL und UUID-Support in mount is for.
> >
On Wed, Jan 09, 2008 at 10:54:11AM +0100, Martin Schwidefsky wrote:
> On Jan 8, 2008 7:15 PM, Theodore Tso <[EMAIL PROTECTED]> wrote:
> > That will fix the this issue. The problem you are facing is that you
> > have your hardware clock set to ticking localtime, instead of GMT.
> > Windows ticks lo
On 09.01.2008 11:21, Matthias Schniedermeyer wrote:
> On 09.01.2008 09:56, Tuomo Valkonen wrote:
> > On 2008-01-09 00:06 +0100, Matthias Schniedermeyer wrote:
> > > That what LABEL und UUID-Support in mount is for.
> >
> > That's udev shit. I don't want it.
>
> No.
To be more verbose.
The 'LABE
On 09.01.2008 09:56, Tuomo Valkonen wrote:
> On 2008-01-09 00:06 +0100, Matthias Schniedermeyer wrote:
> > That what LABEL und UUID-Support in mount is for.
>
> That's udev shit. I don't want it.
No.
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a c
On Jan 8, 2008 7:15 PM, Theodore Tso <[EMAIL PROTECTED]> wrote:
> That will fix the this issue. The problem you are facing is that you
> have your hardware clock set to ticking localtime, instead of GMT.
> Windows ticks localtime, which is a mistake carried over from the
> 1970's and MS-DOS. Tick
On 2008-01-09 00:06 +0100, Matthias Schniedermeyer wrote:
> That what LABEL und UUID-Support in mount is for.
That's udev shit. I don't want it.
--
Tuomo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info a
On Wed, 09 Jan 2008 15:00:46 +0700, BuraphaLinux Server said:
> The help for CONFIG_DM_SNAPSHOT says it is EXPERIMENTAL (in
> 2.6.23.12). So this would mean that there is very high risk of
> software failure using snapshots. Would you want to do that for your
> fsck?
The overall current state of
The help for CONFIG_DM_SNAPSHOT says it is EXPERIMENTAL (in
2.6.23.12). So this would mean that there is very high risk of
software failure using snapshots. Would you want to do that for your
fsck?
On 1/9/08, Kyle Moffett <[EMAIL PROTECTED]> wrote:
> On Jan 08, 2008, at 15:51:53, Andi Kleen wrot
On Tue, 08 Jan 2008 22:21:02 EST, Kyle Moffett said:
> lvcreate -s -n "${VOLUME}-snap" "${VG}/${VOLUME}"
> Basically you can fsck the offline snapshot in the background.
Something the lvcreate manpage is specifically not clear about is:
Does this create a snapshot of the *disk* at that moment,
On Jan 08, 2008, at 15:51:53, Andi Kleen wrote:
Theodore Tso <[EMAIL PROTECTED]> writes:
Now, there are good reasons for doing periodic checks every N
mounts and after M months. And it has to do with PC class
hardware. (Ted's aphorism: "PC class hardware is cr*p").
If these reasons are go
Sorry for feeding the troll:
On Die, 2008-01-08 at 17:52 +, Tuomo Valkonen wrote:
> On 2008-01-08, Andre Noll <[EMAIL PROTECTED]> wrote:
> > Use tune2fs to deactivate checking.
>
> So, a workaround is the answer to a clear bug. Typical FOSS.
At least you get a simple solution for your proble
> > Don't use udev then. Good old static dev works fine if you have a fixed
> > set of devices.
>
> It doesn't, with the unpredictable SCSI mapping insanity.
That what LABEL und UUID-Support in mount is for.
You label the filesystems (e2label for ext2 and ext3) and use that label to
mount them
Tuomo Valkonen <[EMAIL PROTECTED]> wrote:
> On 2008-01-08, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>> "Power users" may still
>> use the index= option of sound card modules and wire it up in
>> /etc/modprobe.d if they prefer.
>
> Another very cryptic directory whose contents say nothing to me.
On Tue 2008-01-08 16:07:27, Tuomo Valkonen wrote:
>
> The ext3 journalling code can be summarised as:
>
> superblock->last_checked = random();
> sync(superblock)
>
> I hate it: every time Linux crashes, e.g. due to power failure, it takes
> almost an hour to boot, because the kernel has
On Tue, Jan 08, 2008 at 09:51:53PM +0100, Andi Kleen wrote:
> Theodore Tso <[EMAIL PROTECTED]> writes:
> >
> > Now, there are good reasons for doing periodic checks every N mounts
> > and after M months. And it has to do with PC class hardware. (Ted's
> > aphorism: "PC class hardware is cr*p").
> "Tuomo" == Tuomo Valkonen <[EMAIL PROTECTED]> writes:
Tuomo> On 2008-01-08, John Stoffel <[EMAIL PROTECTED]> wrote:
>> Look at your filesystems, using 'tune2fs' and see if the ext3 journal
>> is actually turned on and used. If it's not, then I can see why
>> you're having problems on reboot
On Tuesday 08 January 2008 21:51:53 Andi Kleen wrote:
> Theodore Tso <[EMAIL PROTECTED]> writes:
> > Now, there are good reasons for doing periodic checks every N mounts
> > and after M months. And it has to do with PC class hardware. (Ted's
> > aphorism: "PC class hardware is cr*p").
>
> If thes
Theodore Tso <[EMAIL PROTECTED]> writes:
>
> Now, there are good reasons for doing periodic checks every N mounts
> and after M months. And it has to do with PC class hardware. (Ted's
> aphorism: "PC class hardware is cr*p").
If these reasons are good ones (some skepticism here) then the correc
> be a bit longer), but it gets confused and thinks it's been years since
> last check, when it hasn't. I have my doubts that Theodore Tso's reply
> is the problem here, because I didn't use to have this problem; it
> appeared relatively recently. But maybe old versions of e2fsck were
This is a b
On 2008-01-08, Diego Calleja <[EMAIL PROTECTED]> wrote:
> http://freebsd.org
> http://netbsd.org
> http://openbsd.org
> http://opensolaris.org
>
> There're so many options, that wasting your time arguing with people that
> thinks
> that you're a troll is worthless.
Unfortunately they do not suppo
On 2008-01-08, Andre Noll <[EMAIL PROTECTED]> wrote:
> It's not a workaround. The ext3 maintainers argue that every file
> system should be checked from time to time. Therefore it's the
> default. You do not agree with them, so change the default and be
> happy.
The thing is, I agree with them (a
http://freebsd.org
http://netbsd.org
http://openbsd.org
http://opensolaris.org
There're so many options, that wasting your time arguing with people that thinks
that you're a troll is worthless.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On 17:52, Tuomo Valkonen wrote:
> On 2008-01-08, Andre Noll <[EMAIL PROTECTED]> wrote:
> > Use tune2fs to deactivate checking.
>
> So, a workaround is the answer to a clear bug. Typical FOSS.
It's not a workaround. The ext3 maintainers argue that every file
system should be checked from time to t
On Tue, 8 Jan 2008 18:16:49 + (UTC)
Tuomo Valkonen <[EMAIL PROTECTED]> wrote:
> On 2008-01-08, Masoud Sharbiani "Ù
سعÙد شربÛاÙÛ" <[EMAIL
> PROTECTED]> wrote:
> > It isn't a bug. It is a feature;
>
> To me, it seems to be a rather clear bug when the last-checked field
> contains
On 2008-01-08, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> http://linux.oneandoneis2.org/LNW.htm . Replace Windows by favorite OS you wanted to originally have>.
Linux is too much like Windows, and that's a big part of the problem.
People are obssessed on providing WIMPshit interfaces to everyth
On Jan 8 2008 17:48, Tuomo Valkonen wrote:
>
>> You can guess my answer: udev will fix it.
>
>And break everything else, such as my symlinks, permissions, etc.
>I'm not going to learn its cryptic special-case config files for
>such trivial tasks as creating a fucking symlink or change the
>per
On 2008-01-08, Masoud Sharbiani "Ù
سعÙد شربÛاÙÛ" <[EMAIL PROTECTED]>
wrote:
> It isn't a bug. It is a feature;
To me, it seems to be a rather clear bug when the last-checked field
contains an absurd value of years ago, on _all_ disks, and yet there's
no complaint of other superblock
On Tue, Jan 08, 2008 at 05:01:30PM +, Tuomo Valkonen wrote:
> On 2008-01-08, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > tune2fs -i0 -c0 device for each file system
> >
> > Yes that should be default, unfortunately it is not. It's one
> > of the first things I do on new machines.
>
> I hav
On Jan 8 2008 17:52, Tuomo Valkonen wrote:
>On 2008-01-08, Andre Noll <[EMAIL PROTECTED]> wrote:
>> Use tune2fs to deactivate checking.
>
>So, a workaround is the answer to a clear bug. Typical FOSS.
Well if it is a problem for you, why do not you come and fix it?
>> Modify the init scripts or u
On 1/8/08, Tuomo Valkonen <[EMAIL PROTECTED]> wrote:
> On 2008-01-08, Andre Noll <[EMAIL PROTECTED]> wrote:
> > Use tune2fs to deactivate checking.
>
> So, a workaround is the answer to a clear bug. Typical FOSS.
It isn't a bug. It is a feature; Think about silent corruption that
may damage your f
On 2008-01-08, Andre Noll <[EMAIL PROTECTED]> wrote:
> Use tune2fs to deactivate checking.
So, a workaround is the answer to a clear bug. Typical FOSS.
> Modify the init scripts or use another distro.
Another typical FOSS answer. "You have the source, you can fix it."
With what time?
> Don't us
On 2008-01-08, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> Roll your own.
Nah, too much work, and I want all distros to perish.
> "Power users" may still
> use the index= option of sound card modules and wire it up in
> /etc/modprobe.d if they prefer.
Another very cryptic directory whose conte
On 16:07, Tuomo Valkonen wrote:
> I hate it: every time Linux crashes, e.g. due to power failure, it takes
> almost an hour to boot, because the kernel has decided to corrupt the
> superblock to indicate that it's been years since last file system
> check.
Use tune2fs to deactivate checking.
>
On Jan 8 2008 16:52, Tuomo Valkonen wrote:
>
>> I can recommend that you try another distribution then.
>
>They all suck.
Roll your own.
>Typically distros' stock kernels load the intorable integrated buzz-chip
>as the first sound card,
While that is true, configuration tools such as, ads aside
On 2008-01-08, Andi Kleen <[EMAIL PROTECTED]> wrote:
> tune2fs -i0 -c0 device for each file system
>
> Yes that should be default, unfortunately it is not. It's one
> of the first things I do on new machines.
I have ages ago increased those counts, but I don't want to
completely disable them
On 2008-01-08, John Stoffel <[EMAIL PROTECTED]> wrote:
> Look at your filesystems, using 'tune2fs' and see if the ext3 journal
> is actually turned on and used. If it's not, then I can see why
> you're having problems on reboots.
Journalling is on, but it's no use because the superblock always
Tuomo Valkonen <[EMAIL PROTECTED]> writes:
> The ext3 journalling code can be summarised as:
>
> superblock->last_checked = random();
> sync(superblock)
>
> I hate it: every time Linux crashes, e.g. due to power failure, it takes
> almost an hour to boot,
tune2fs -i0 -c0 device for e
On 2008-01-08, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> Do it step-by-step.
Still too much work.
> I can recommend that you try another distribution then.
They all suck.
>>that load drivers in wrong order etc.,
>
> What specific modules and which order do you need for the disks?
> There is a
> "Tuomo" == Tuomo Valkonen <[EMAIL PROTECTED]> writes:
Tuomo> The ext3 journalling code can be summarised as:
superblock-> last_checked = random();
Tuomo> sync(superblock)
Tuomo> I hate it: every time Linux crashes, e.g. due to power failure,
Tuomo> it takes almost an hour to boot, beca
On Jan 8 2008 16:07, 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
>hidd
The ext3 journalling code can be summarised as:
superblock->last_checked = random();
sync(superblock)
I hate it: every time Linux crashes, e.g. due to power failure, it takes
almost an hour to boot, because the kernel has decided to corrupt the
superblock to indicate that it's been year
83 matches
Mail list logo
