Update: dropouts still do occur while moving windows, but rarely. When they
do occur, they are severe. A debian dist-upgrade just caused a dropout - and
another just now, about 3 seconds long. I feel that tweaking is only going
to get us so far with this. The situation re scheduling in 2.5 feels much as
the vm situation did in 2.3, in other words, we're halfway down a long twisty
road that ends with something that works, after having tried and failed at
many flavors of tweaking and tuning. Ultimately the problem will be solved
by redesign, and probably not just limited to kernel code.
> I had 2.5.74 freeze up a couple of times yesterday, resulting in a totally
> dead, unpingable system, so now I'm running 2.5.74-mm1 with kgdb and hoping
> to catch one of those beasts in the wild.
Update: this is easily repeatable. A few quick switches between X and text
mode triggers the freeze reliably. On two occasions, I had a lockup while
just doing an innocent window operation. It also happens in 2.4, so it isn't
a 2.5 problem per se. Is it a pure hardware problem? It's always easy to
take that position. I can only guess at the moment. Kgdb is no help in
diagnosing, as the kgdb stub also goes comatose, or at least the serial link
does. No lockups have occurred so far when I was not interacting with the
system via the keyboard or mouse. Suggestions?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/