Lately, using the nForce IDE driver I have noticed a few glitches with
it that affect stability.
I use the BK tree for my kernel source. Lately, if I 1) clone a fresh
tree (i pull from a few places so sometimes there are some boggling
conflicts that a fresh tree fixes) or 2) run a bk pull, X will SEGV out
of nowhere. At first I thought it was the amount of disk activity.
But after reading the saga of the flukey tty code in the kernel, I am
thinking this could also be because of that? Lots of stuff scrolls by
when doing a bk clone, and when resolve runs after a bk pull there is
often lots of output.
There is no oops at all, nor anything that might be of help in dmesg.
Any ideas? I started noticing it around halfway through 2.5.56...
Regards
Josh
On Mon January 13 2003 22:34, Joshua M. Kwan wrote:
>
> Lately, using the nForce IDE driver I have noticed a few glitches with
> it that affect stability.
>
> I use the BK tree for my kernel source. Lately, if I 1) clone a fresh
> tree (i pull from a few places so sometimes there are some boggling
> conflicts that a fresh tree fixes) or 2) run a bk pull, X will SEGV out
> of nowhere. At first I thought it was the amount of disk activity.
>
> But after reading the saga of the flukey tty code in the kernel, I am
> thinking this could also be because of that? Lots of stuff scrolls by
> when doing a bk clone, and when resolve runs after a bk pull there is
> often lots of output.
>
> There is no oops at all, nor anything that might be of help in dmesg.
> Any ideas? I started noticing it around halfway through 2.5.56...
>
You could just do something like
while true
do
cat /usr/src/linux/MAINTAINERS
done
and see if that kills it. If so then yeah, it could be a tty thing. If not
then it may be mm/fs/vm/harware related. Confirm that by running
dbench/tiobench/etc.
Basically: separate it out, eliminate some variables.
The most valuable thing you can do is to narrow it down to a particular
changeset.