Possible critical VIA vt82c686a chip bug (private question)
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 9 lines · Richard B. Johnson
../drivers/block/ide.c, line 162, on version 2.2.17 does bad things to the timer. It writes 0 to the control-word for timer 0. This does the following:o Selects timer 0.
o Latches the timer.
o Selects mode 0.
o Programs it to a 16 bit counter.
Quoted 6 lines
The result is a latched (stopped) counter. Bits 5 and 4 should have been selected. Then you read bits 0-7 from
0x40, followed by bits 8-15 from the same port.Also, there is no spin-lock protecting access to these ports. If anybody else is mucking with the timer, all bets are off.
Well, at least on 2.4.0-test9, the above timing code is #ifed to DISK_RECOVERY_TIME > 0, which in turn is #defined to 0 in include/linux/ide.h.
So this is not our problem here. Anyway I guess it's time to hunt for i8259 accesses in the kernel that lack the necessary spinlock, even when they're not probably the cause of the problem we see here.
Signature · 6 lines
Vojtech Pavlik SuSE Labs - 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 · Vojtech Pavlik
Quoted 3 lines · Richard B. Johnson
../drivers/block/ide.c, line 162, on version 2.2.17 does bad things to the timer. It writes 0 to the control-word for timer 0. This does the following:
[Snipped...]
Quoted 8 lines
Well, at least on 2.4.0-test9, the above timing code is #ifed to
DISK_RECOVERY_TIME> 0, which in turn is #defined to 0 ininclude/linux/ide.h.So this is not our problem here. Anyway I guess it's time to hunt for i8259 accesses in the kernel that lack the necessary spinlock, even when they're not probably the cause of the problem we see here.
Okay, good.
Cheers,
Dick Johnson
Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk.
-
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 · Richard B. Johnson
Quoted 3 lines
Quoted 3 lines
../drivers/block/ide.c, line 162, on version 2.2.17 does bad things to the timer. It writes 0 to the control-word for timer 0. This does the following:[Snipped...]
Quoted 5 lines
Well, at least on 2.4.0-test9, the above timing code is #ifed to
DISK_RECOVERY_TIME> 0, which in turn is #defined to 0 ininclude/linux/ide.h.
Quoted 5 lines
Quoted 3 lines
So this is not our problem here. Anyway I guess it's time to hunt for i8259 accesses in the kernel that lack the necessary spinlock, even when they're not probably the cause of the problem we see here.
Okay, good.
Ok, here is a list of places within the kernel that access the PIT timer, plus the method of locking (i386 arch only):
Usage: Lock method:
arch/i386/kernel/time.c:170: spin_lock()arch/i386/kernel/time.c:491: spin_lock()arch/i386/kernel/time.c:575: none (init)arch/i386/kernel/i8259.c:491: none (init)arch/i386/kernel/apm.c:871: cli()arch/i386/kernel/apic.c:398: spin_lock_irqsave()
drivers/char/vt.c:121: cli()drivers/char/ftape/lowlevel/ftape-calibr.c:80: cli()drivers/char/ftape/lowlevel/ftape-calibr.c:99: cli()drivers/char/joystick/analog.c:142: cli() __cli()drivers/char/joystick/gameport.c:66: cli()drivers/ide/hd.c:137: cli()drivers/ide/ide.c:206: __cli()
I guess we'll need to fix this. While races here are not likely (the most likely is a beep by vt.c at a wrong moment), they're possible.
However, these don't seem to be the cause of the problem we see here anyway.
Signature · 6 lines
Vojtech Pavlik SuSE Labs - 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 11 lines · Vojtech Pavlik
Quoted 9 lines · Richard B. Johnson
Quoted 3 lines
Quoted 3 lines
../drivers/block/ide.c, line 162, on version 2.2.17 does bad things to the timer. It writes 0 to the control-word for timer 0. This does the following:[Snipped...]
Quoted 5 lines
Well, at least on 2.4.0-test9, the above timing code is #ifed to
DISK_RECOVERY_TIME> 0, which in turn is #defined to 0 ininclude/linux/ide.h.
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
So this is not our problem here. Anyway I guess it's time to hunt for i8259 accesses in the kernel that lack the necessary spinlock, even when they're not probably the cause of the problem we see here.
Okay, good.
Ok, here is a list of places within the kernel that access the PIT timer, plus the method of locking (i386 arch only):
[...]
Ok, I just tested if the problem was always present without the IDE subsystem...
The answer is it is not... so it isn't an IDE problem.
Signature · 7 lines
-- Yoann http://www.mandrakesoft.com/~yoann/ An engineer from NVidia, while asking him to release cards specs said : "Actually, we do write our drivers without documentation." - 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 18 lines · Yoann Vandoorselaere
Quoted 9 lines
Quoted 9 lines
Quoted 3 lines
Quoted 3 lines
../drivers/block/ide.c, line 162, on version 2.2.17 does bad things to the timer. It writes 0 to the control-word for timer 0. This does the following:[Snipped...]
Quoted 5 lines
Well, at least on 2.4.0-test9, the above timing code is #ifed to
DISK_RECOVERY_TIME> 0, which in turn is #defined to 0 ininclude/linux/ide.h.Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
So this is not our problem here. Anyway I guess it's time to hunt for i8259 accesses in the kernel that lack the necessary spinlock, even when they're not probably the cause of the problem we see here.
Okay, good.
Ok, here is a list of places within the kernel that access the PIT timer, plus the method of locking (i386 arch only):
Quoted 6 lines
[...]
Ok, I just tested if the problem was always present without the IDE subsystem...
The answer is it is not... so it isn't an IDE problem.
Uh, guess too many negations. You wanted to say that the problem was present even when you disabled the IDE subsystem, right?
So now it seems that possibly enough PCI traffic / busmastering traffic can cause the problem ...
Signature · 6 lines
Vojtech Pavlik SuSE Labs - 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 22 lines · Vojtech Pavlik
Quoted 20 lines · Yoann Vandoorselaere
Quoted 17 lines
Quoted 9 lines
Quoted 3 lines
Quoted 3 lines
../drivers/block/ide.c, line 162, on version 2.2.17 does bad things to the timer. It writes 0 to the control-word for timer 0. This does the following:[Snipped...]
Quoted 5 lines
Well, at least on 2.4.0-test9, the above timing code is #ifed to
DISK_RECOVERY_TIME> 0, which in turn is #defined to 0 ininclude/linux/ide.h.Quoted 5 lines
Quoted 3 lines
So this is not our problem here. Anyway I guess it's time to hunt for i8259 accesses in the kernel that lack the necessary spinlock, even when they're not probably the cause of the problem we see here.
Okay, good.
Ok, here is a list of places within the kernel that access the PIT timer, plus the method of locking (i386 arch only):
[...]
Quoted 7 lines
Quoted 4 lines
Ok, I just tested if the problem was always present without the IDE subsystem...
The answer is it is not... so it isn't an IDE problem.
Uh, guess too many negations. You wanted to say that the problem was present even when you disabled the IDE subsystem, right?
yop
Quoted 3 lines
So now it seems that possibly enough PCI traffic / busmastering traffic can cause the problem ...
yop, I 've done :
make -j10 World
in the xfree tree and simulateously :
while true; do make dep && make clean && make bzImage; done in the kernel tree
Signature · 7 lines
-- Yoann http://www.mandrakesoft.com/~yoann/ An engineer from NVidia, while asking him to release cards specs said : "Actually, we do write our drivers without documentation." - 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 7 lines · Yoann Vandoorselaere
yop, I 've done :
make -j10 World
in the xfree tree and simulateously :while true; do make dep && make clean && make bzImage; done in the kernel tree
Now it'd be nice to verify that the problem also happens when the system is not running out of memory (which -j10 quite causes I think) ...
Signature · 6 lines
Vojtech Pavlik SuSE Labs - 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 4 lines · Vojtech Pavlik
Quoted 2 lines · Yoann Vandoorselaere
yop, I 've done :
Quoted 8 lines
Quoted 5 lines
make -j10 World
in the xfree tree and simulateously :while true; do make dep && make clean && make bzImage; done in the kernel tree
Now it'd be nice to verify that the problem also happens when the system is not running out of memory (which -j10 quite causes I think) ...
Nope, my system was loaded, but was usable
(at least until the problem occured)...
Athlon 750 with 128mb of ram and 103mb of swap.
Signature · 7 lines
-- Yoann http://www.mandrakesoft.com/~yoann/ An engineer from NVidia, while asking him to release cards specs said : "Actually, we do write our drivers without documentation." - 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 · Yoann Vandoorselaere
Quoted 7 lines · Vojtech Pavlik
Quoted 5 lines · Yoann Vandoorselaere
yop, I 've done :
make -j10 World
in the xfree tree and simulateously :
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
while true; do make dep && make clean && make bzImage; done in the kernel tree
Now it'd be nice to verify that the problem also happens when the system is not running out of memory (which -j10 quite causes I think) ...
Nope, my system was loaded, but was usable
(at least until the problem occured)...
Good to know.
Signature · 6 lines
Vojtech Pavlik SuSE Labs - 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/
Hi!
Quoted 3 lines
So this is not our problem here. Anyway I guess it's time to hunt for i8259 accesses in the kernel that lack the necessary spinlock, even when they're not probably the cause of the problem we see here.
BTW what about trying to modify your work-around code to make it attempt to read the timer again? This way we could test whether it was a race condition during timer read or really timer jumping to a bogus value.
Have a nice fortnight
Signature · 6 lines
Martin `MJ' Mares <[email protected]> <[email protected]> http://atrey.karlin.mff.cuni.cz/~mj/ "This line is umop apisdn." - 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 · Martin Mares
Quoted 3 lines
So this is not our problem here. Anyway I guess it's time to hunt for i8259 accesses in the kernel that lack the necessary spinlock, even when they're not probably the cause of the problem we see here.
BTW what about trying to modify your work-around code to make it attempt to read the timer again? This way we could test whether it was a race condition during timer read or really timer jumping to a bogus value.
Actually if I don't reprogram the timer (and just ignore the value for example), the work-around code keeps being called again and again very often (between 1x/minute to 100x/second) after the first failure, even when the system is idle.
When reprogramming, next failure happens only after stressing the system again.
So it's not just a race, the impact of the failure on the chip is permanent and stays till it's reprogrammed.
Signature · 6 lines
Vojtech Pavlik SuSE Labs - 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 16 lines · Vojtech Pavlik
Quoted 8 lines · Martin Mares
Quoted 3 lines
So this is not our problem here. Anyway I guess it's time to hunt for i8259 accesses in the kernel that lack the necessary spinlock, even when they're not probably the cause of the problem we see here.
BTW what about trying to modify your work-around code to make it attempt to read the timer again? This way we could test whether it was a race condition during timer read or really timer jumping to a bogus value.
Actually if I don't reprogram the timer (and just ignore the value for example), the work-around code keeps being called again and again very often (between 1x/minute to 100x/second) after the first failure, even when the system is idle.
Quoted 5 lines
When reprogramming, next failure happens only after stressing the system again.
So it's not just a race, the impact of the failure on the chip is permanent and stays till it's reprogrammed.
Are you sure there is not an error in the way the
chipset is programmed ?
Signature · 8 lines
-- Yoann http://www.mandrakesoft.com/~yoann/ "Programming is a race between programmers, who try and make more and more idiot-proof software, and universe, which produces more and more remarkable idiots. Until now, universe leads the race" -- R. Cook - 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 14 lines · Yoann Vandoorselaere
Quoted 14 lines
Quoted 8 lines
Quoted 3 lines
So this is not our problem here. Anyway I guess it's time to hunt for i8259 accesses in the kernel that lack the necessary spinlock, even when they're not probably the cause of the problem we see here.
BTW what about trying to modify your work-around code to make it attempt to read the timer again? This way we could test whether it was a race condition during timer read or really timer jumping to a bogus value.
Actually if I don't reprogram the timer (and just ignore the value for example), the work-around code keeps being called again and again very often (between 1x/minute to 100x/second) after the first failure, even when the system is idle.
Quoted 8 lines
Quoted 5 lines
When reprogramming, next failure happens only after stressing the system again.
So it's not just a race, the impact of the failure on the chip is permanent and stays till it's reprogrammed.
Are you sure there is not an error in the way the
chipset is programmed ?
Which part of the chipset you mean? The PIT (programmable interrupt timer)? That one is standard since XT times. The rest of the ISA bridge? Maybe, but that's mostly BIOS work and shouldn't impact the PIT under sane conditions.
Signature · 6 lines
Vojtech Pavlik SuSE Labs - 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 22 lines · Vojtech Pavlik
Quoted 20 lines · Yoann Vandoorselaere
Quoted 19 lines
Quoted 8 lines
Quoted 3 lines
So this is not our problem here. Anyway I guess it's time to hunt for i8259 accesses in the kernel that lack the necessary spinlock, even when they're not probably the cause of the problem we see here.
BTW what about trying to modify your work-around code to make it attempt to read the timer again? This way we could test whether it was a race condition during timer read or really timer jumping to a bogus value.
Actually if I don't reprogram the timer (and just ignore the value for example), the work-around code keeps being called again and again very often (between 1x/minute to 100x/second) after the first failure, even when the system is idle.
When reprogramming, next failure happens only after stressing the system again.
So it's not just a race, the impact of the failure on the chip is permanent and stays till it's reprogrammed.
Quoted 7 lines
Quoted 2 lines
Are you sure there is not an error in the way the
chipset is programmed ?Which part of the chipset you mean? The PIT (programmable interrupt timer)? That one is standard since XT times. The rest of the ISA bridge? Maybe, but that's mostly BIOS work and shouldn't impact the PIT under sane conditions.
What is strange is that a number of persons seem to be hit by this problem... And if VIA didn't corrected it it's probably because they are not aware of it...
I think that if such problem occured under windows (thinking to the windows user base), VIA would be already in touch.
Signature · 9 lines
-- Yoann http://www.mandrakesoft.com/~yoann/ Tiniest "mesures unities?" - lenght : millimeter - volume : milliliter - intelligence : military man - 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 11 lines · Yoann Vandoorselaere
Quoted 4 lines
Which part of the chipset you mean? The PIT (programmable interrupt timer)? That one is standard since XT times. The rest of the ISA bridge? Maybe, but that's mostly BIOS work and shouldn't impact the PIT under sane conditions.
What is strange is that a number of persons seem to be hit by this problem... And if VIA didn't corrected it it's probably because they are not aware of it...
I think that if such problem occured under windows (thinking to the windows user base), VIA would be already in touch.
It can't happen under Windows, because Windows timer runs at 18 Hz (timer programmed to 65535), while Linux uses 100 Hz (timer programmed to approx 11920), so when the timer unprograms itself due to the bug to 65535, only Linux notices it, Windows can't.
Signature · 6 lines
Vojtech Pavlik SuSE Labs - 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/