[ Cc:ing this to linux-kernel because it might actually be of some use ]
> > Although I can't say for sure, this sounds suspiciously like a bug in X
> > (well, we know that already, but I'll be more specific). During the
> > switch
>
> Actually, it is bug in both X and kernel (well, locking up is X
> problem, but lost keypresses are kernel's).
Not really, if X does a hardware cli() and then never recovers from it,
there is nothing the kernel can do about lost keypresses or anything else.
When the interrupts are disabled like that, the kernel is essentially
saying "You are a trusted binary and I'm giving you access to instructions
that can bring the whole system down, USE THEM WITH CARE!" and in response
the X server is saying "OK, I'm disabling interrupts" and then something
goes wrong in the X server and those interrupts never get re-enabled. So,
the X server obviously ignored that "USE THEM WITH CARE!" part of its
permissions the kernel allowed it to have or else the hardware did
something the X server didn't expect and things went downhill from there.
I would be willing to bet a large portion of my annual salary that the
problem is at least partially hardware related. AKA, the exact model (or
models) of video card you have, combined with your particular PC BUS, are
in certain cases not reliable. You could always try things like going
into the BIOS and changing around the PCI/ISA/EISA bus timings a little
bit to see if that helps (it has solved hardware problems in the past on
some of my systems, so I know that this item can sometimes correct bad
behavior).
Example, on a P166 PCI/ISA system using a Pro-Audio Spectrum 16 sound
card. Any attempt to play doom or use any other audio function that
resulted in large amounts of DMA activity would frequently result in "DMA
timed out: IRQ/DRQ conflict error?" messages (or something like that).
After some discussions with Hannu, I found out that the PAS-16 cards are
extremely touchy on their DMA timing. At his recommendation, I started
diddling with the I/O wait states on my ISA bus. Lo and behold, the
problem went from being a constant problem to very rare under some of my
settings. Now, it didn't solve the problem entirely in this case because
I had too much other DMA activity taking place (working on the aic7xxx
driver, I have lots of DMA from it as I'm doing testing and the like).
However, on an older system that didn't beat up the machine with DMA, it
worked flawlessly. Now, all this boils down to a very touchy chip/card
that needs the right setting to work properly. What would make anyone
think that certain video cards are any different (and from the comments
made on this list, probably worse)? If that's the problem you're having
with your system, then KGI won't help you. Nothing will. It would be a
hardware problem that has to be fixed.
FWIW, that PAS-16 and that P166 system are now running Win95 as my wife's
computer. It's been changed from all SCSI to all IDE. With the reduced
load, the card now works flawlessly. However, I can force a problem with
the card by doing certain operations on her machine and then trying to
play a wav or some such. So, given that there exists hardware such as
this, people need to make sure they do things like check out bus timing
and other assorted possible sources of problems before they diagnose
something as unfixable.
As a side note, the problems you have with switching consoles sometimes
resulting in the text console and the graphics console ebing displayed at
the same time (so that kernel messages and type keystrokes just serve to
confuse the screen) sounds like this may indeed be the problem. That kind
of thing should happen because it would indicate that the text buffer has
been mapped into video mem or vice versa. The X server shouldn't allow
this to happen, and I'm sure that a generic bug in the X server wouldn't
exist that would cause this. It's more like during a switch the
programming of the video card got screwed up. This could be because of a
bug in the particular low level hardware driver X is using, or it could be
because of the card having hardware problems.
--------------------------------------
Doug Ledford <dledford@dialnet.net>
Opinions expressed are my own, but
they should be everybody's.
--------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu