intense disk or tty activity SEGV's X

intense disk or tty activity SEGV's X

[Joshua M. Kwan]

[-- Attachment #1: Type: text/plain, Size: 784 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: intense disk or tty activity SEGV's X

[Andrew Morton]

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.