Messages in this thread |  | | | Date | Sun, 29 Mar 1998 14:20:04 -0600 (CST) | | From | Doug Ledford <> | | Subject | Re: GGI and cli/sti in X |
| |
On Sat, 28 Mar 1998, Pavel Machek wrote:
[ 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
|  |