--- Tim
Jos van de Ven wrote:
>
> Hi,
>
> > > 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/