> > I have too taken a look at the X sources. There is in fact a problem
> > there. It depends a lot on the hardware, but many boards suffer from
> > this problem. It is in fact a usable work around to switch to XT-PIC.
> > It is possible to have a discussion about who is wrong, but it's
> > certainly the combination that gives trouble.
> I figured there was a problem there too.. so I sent email to X
> but never heard a word from them...
Hmm. Where did you send it? To XFree86 mailing lists?
> > As far as I know, there's _no_ problem using just the console,
> maybe with the timewarp, but not the mouse..
Even the time warp does not appear to occur on my machine without X.
Strange. Only in X I get time warps. But that's just _my_ 4 machines
probably (though 4 machines may be a lot).
> > By the way, not only the mouse is a problem. The keyboard on boards
> > with PS/2 keyboards can have problems too. So it's not purely mouse.
> well it is actually sounding like an interrupt/timing problem,
> and seems to affect any heavily used interrupt, but not in the
> same way. Probably because each interrupt is used differently by
> different devices they all react in a different manor.
>
> > As long as this is not solved, I would advice people with
> > production
> > machines to switch to XT-PIC for the mouse interrupt.
> via the patch that you did? did you post this somewhere outside
> of this list?
It's an option to use my patch, and no, I haven't post this patch somewhere
else. If people want, it may be posted everywhere. Other option is of course
to use noapic.
> > Everything worked normally except for the mouse and the keyboard. Killling
> > X from a console just solved everything. Restarting X does not
> > give problems again. So only X suffered from the problems.
> ditto here....
The strangest thing I noticed (just checked with double trouble machine
here), is that the problem seems to be triggered by X only. Hmm. Thinking:
X uses a device to listen to. That's quite normal. The device is used only
by X. This device is opened with "open(mouse->mseDevice, O_RDWR | O_NDELAY)".
It would be interesting what would happen if I open the mouse device this way,
and if I will _force_ time warps. The program that reads this device should do
simple parsing to show what's going on. As my keyboard goes crazy too normally,
it should be an easy trigger. If I can trigger it outside X, then there's
_much_ less overhead involved.
Report tomorrow (I hope).
BTW: It does _not_ need to be the interrupt handling, it can be the device
handling in general that cannot stand time warps.
> > My first thought when I heard this problem was a race
> > condition somewhere.
> I found one with X and the xfs..
And that one is?
> I am guessing that you are including the BIOS as one of the
> buggiest parts of a MBo
Yup. But not only. I've seen one board (GigaByte) that had severe errors
on the lines. (One line wasn't where it belonged to be. It was just not
there.)
> > This would explain behaviour. But how do you explain that my time may
> > warp, but my mouse does not give trouble using XT-PIC? (This is an open
> > question, not retorical)
> my guess would be because timing is more important in an SMP
> machine, especially where interrupts are distibuted and heavily
> used.
I would think that more in the direction that 2 processors are doing
two related things. One changes for example time and confused the other
running driver (mouse device)
> I am not an interrupt or kernel guru, but here are some guesses
> / questions
>
> 1) Don't interrupts rely on timing? So if the timing is off or
> thrown in a warp, don't the interrupts get thrown off too? (yes
> / no)
partly yes, partly no. No interrupts don't get thrown off because
of the clock. Yes, because interrupts may wait an amount of time
before doing things.
> 2) If the clock jumps forward and then jumps back how does this
> affect the CPU's? Maybe they are loosing the interrupt during
> the warp, or missing interrupts? (my guess is missing)
> ** maybe the interrupt is not delievered?
Maybe it is delivered normally, and handled normally. Maybe it is
just the part of the kernel that puts it sends it to X (via the
device in /dev) that's causing trouble.
> 3) If the CPU looses track of an interrupt in a none SMP kernel
> there is only one CPU that has to recover that interrupt,
> however if there are two CPU's, maybe the interrupt is not
> recovered correctly?
Unlikely to me.
Think of it this way: The exact value of the timer is only known
to the kernel and the OS. Not to the hardware. So the interrupt
controller(s) don't know about time, only about sequence of commands
and interrupts. Therefore the timing will only impact the delays done
on base of the this.
So if time warps are the source of the trouble, there has to be a part
of the kernel that can't handle it (or a strange hack in XFree86 that
can't handle it).
But first let's see if this is directly causing troubles in the first
place.
Greetings,
Jos van de Ven
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/