> Why is it that when the kernel locks up on me (very unoften) the VCs
> still work? Even when the system is loaded down to the point that I
> cannot type, the VCs still work without any load? Just curious, and too
> lazy to sit around for hours trying to look in the code... :)
This is because VC switches are done from the keyboard interrupts. Even
when the kernel panics interrupts are still processed. I really like
this feature, that is being able to switch VC's even after a panic and
regardless of system load or paging etc.
It is a pain that it doesn't work this way in grafix modes too (I'm
working on that).
Yes, I know some people would prefer it in a user level daemon, that would
hang on system crash or might suffer from memory shortage, paging, load
etc. I prefer a stable system.
Someone (whose name I accidently deleted) experienced a loss of 3.4 ms
during a VC switch in his joystick driver.
This is probably due to the text screen being written to the card on the
vc switch over the slow systems bus. BTW, did you measure the loss in kernel
or in user space? In the latter case it could also be due to
I don't think the loss of 3.4 ms is THAT important to the joystick driver.
You trigger a new AD conversion and.. well you just read it back some
time later. The program using the joystick should disable itself anyway
if the console is switched away, so it really makes no difference.
If you really really want higher response you might hook into the timerirq
to get more precise timing. IRQ's are not switched off during most of the
keyboard driver/vc switching. I saw there are now new funcs to dynamically
hook into the timerirq even from a module. However they are one shot only,
so you must reregister from your irq routine. That might cause to muche
overhead... I dunno.. give it a try.
Michael.
(eowmob@exp-math.uni-essen.de or eowmob@pollux.exp-math.uni-essen.de
Please do not use my vm or de0hrz1a accounts anymore. In case of real
problems reaching me try mat42b@aixrs1.hrz.uni-essen.de instead.)