it is the interrupts and the timing... a kernel bug in general
not SMP specific..
> 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...
> As far as I know, there's _no_ problem using just the console,
maybe with the timewarp, but not the mouse..
> there are less problems using IO-APIC-Level with X and no
> problems
> when using XT-PIC with X. Anyone with other experiences,
> please mail.
this is what I have found out too...
> 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?
> 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....
> My first thought when I heard this problem was a race
> condition somewhere.
I found one with X and the xfs..
> BTW: I don't claim to know much about X. In fact, I've never
> even made any
> program for it. So no warranty so far...
ditto...
> The NFS problems were partly solved. That is to say that there
> are buggy MB's
> out there that will give you this trouble. Not everything is
> solved this way,
> though. So that's a rounded off part for now.
I am guessing that you are including the BIOS as one of the
buggiest parts of a MB
> A bit of commenting:
> > I have moved this over to the kernel mailing list as well
> > because if this interrupt bug is as you say it is then it
> may
> > affect non smp machines in a different way then SMP machines
> and
> > may cause problems elsewhere...
> Non SMP machines see time problems too, but as far as I know,
> _not_
> the mouse problem. (non-SMP == XT-PIC usage)
I figured this was the case.. however I think that they may see
other problems possible that may be caused by timeing..
> 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 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)
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?
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?
_____________________________________________________________
Do You Yahoo!?
Free instant messaging and more at http://messenger.yahoo.com
-
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/