*massive* slowdowns on 2.4.1-pre1[1|2]
Sorry if this is a redundant post, but I didn't see any related posts (at least from the subject lines)...
Kernel 2.4.1-pre11 and pre12 are both massively slower than 2.4.0 on the same machine, compiled with the same options. The machine is a Athlon 900 on a KT133 chipset. The slowdown is noticealbe in all areas... booting takes over five minutes, keyboard input is noticeably delayed, and the PC speaker makes much longer beeps when beeping the console. I just wanted to post this since 2.4.1 is soon for release (at least according to Linus' post on -pre11) and we wouldn't want to release this if it affects more than just me. I've tried a number of different options to make this work, but none have seemed to work. BTW, my problems are nothing similar to the current discussion of KT133 misbehaviour, especially since this machine works perfectly on 2.4.0. -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 3 lines
Kernel 2.4.1-pre11 and pre12 are both massively slower than 2.4.0 on the same machine, compiled with the same options. The machine is a Athlon 900 on a KT133 chipset. The slowdown is noticealbe in all areas...
this is known: Linus decreed that, since two people reported disk corruption on VIA, any machine with a VIA southbridge must boot in stupid 1992 mode (PIO). (yes, it might be possible to boot with ide=autodma or something, but who would guess?)
Linus: I hope you don't consider this a releasable state! VIA now owns 40% of the chipset market...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 8 lines · Mark Hahn
Quoted 3 lines
Kernel 2.4.1-pre11 and pre12 are both massively slower than 2.4.0 on the same machine, compiled with the same options. The machine is a Athlon 900 on a KT133 chipset. The slowdown is noticealbe in all areas...
this is known: Linus decreed that, since two people reported disk corruption on VIA, any machine with a VIA southbridge must boot in stupid 1992 mode (PIO). (yes, it might be possible to boot with ide=autodma or something, but who would guess?)
The only patch concerning VIA IDE in 2.4.1 is a patch that honors the user's choise in "make menuconfig" regarding using DMA by default. Just say yes to that option, and you should have DMA enabled at boot, as you had in 2.4.0.
The old behaviour was a bug.
/Tobias
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
In article <Pine.LNX.4.10.10101292102030.28124-100000@coffee.psychology.mcmaster.ca>,
Quoted 11 lines · Mark Hahn
Quoted 3 lines
Kernel 2.4.1-pre11 and pre12 are both massively slower than 2.4.0 on the same machine, compiled with the same options. The machine is a Athlon 900 on a KT133 chipset. The slowdown is noticealbe in all areas...
this is known: Linus decreed that, since two people reported disk corruption on VIA, any machine with a VIA southbridge must boot in stupid 1992 mode (PIO). (yes, it might be possible to boot with ide=autodma or something, but who would guess?)
Linus: I hope you don't consider this a releasable state! VIA now owns 40% of the chipset market...
So find somebody who can figure out why the corruption happens, and I'll be really happy with a patch that fixes it. In the meantime, "releaseable" very much means that we did _everything_ possible to make sure that people don't screw their disks over.
You have to realize that stability takes precedence over EVERYTHING.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 5 lines · Linus Torvalds
You have to realize that stability takes precedence over EVERYTHING.
Linus
At least with Linux, if something is *slow*, it generally works *perfect* or damn near close to it. I'll take that; over Microsoft's being slow AND buggy AND just fucks me up.
I've lost soo much data on my disks - but ONLY on my MS partitions and running an MS operating system. Granted, I don't use Linux to access ANYTHING that is FAT based (unless I use mtools).
I'm running with a VIA board, and I'll be happy to have something slow and reliable, than really fast and really able to fuck my data up. ;p
- Mike
===========================================================================
Michael B. Trausch [email protected]
Avid Linux User since April, '96! AIM: ML100Smkr
Contactable via IRC (DALNet) or AIM as ML100Smkr
===========================================================================
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
On Mon, Jan 29, 2001 at 11:17:58PM -0800, Linus Torvalds wrote:
You have to realize that stability takes precedence over EVERYTHING.
Are you sure his desciption describes only disk-slow down? Seems to me something else is going on... why would speaker beeps take longer? Maybe some kind of PM weirdo?
--cw
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 9 lines · Chris Wedgwood
On Mon, Jan 29, 2001 at 11:17:58PM -0800, Linus Torvalds wrote:
You have to realize that stability takes precedence over EVERYTHING.
Are you sure his desciption describes only disk-slow down? Seems to me something else is going on... why would speaker beeps take longer? Maybe some kind of PM weirdo?
My problem had nothing to do with disk access. Keyboard input isn't slowed by disk access. I knew that... In any case, sub-486 speeds aren't attained through using PIO instead of UDMA... my 486 uses PIO disks anyway, so it's moot. The real culprit was ACPI, which is having some temporary problems. I turned it off and everything's great (thanks, Andrew).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/