Message-Id: <1203221372.6124.29.camel@popeye>
Date:	Sat, 16 Feb 2008 22:09:32 -0600
From:	Chris Holvenstot <cholvenstot@...cast.net>
To:	Jiri Kosina <jkosina@...e.cz>
Cc:	elendil@...net.nl, Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Ingo Molnar <mingo@...e.hu>,
	Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [2.6.25-rc1] jerky mouse cursor and randoooom key repeats

Jiri - 

This is just to confirm that I have been running all day on a kernel
built with CONFIG_GROUP_SCHED turned 'off' and have not seen the problem
with my keyboard (I never noticed a problem with the mouse as others
have)

At slack moments through the day I have taken the oppertunity to perform
7 boots and could not recreate the failure (see my previous note which
has some lame speculation that the conditions for the failure are seeded
at boot time)

If there is anything else you would like to have performed in an attempt
to further isolate this issue I will try my best to provide it.  This
includes going back to a 2.6.25-rc2 kernel with CONFIG_GROUP_SCHED
turned 'on' if you think that further confirmation of the problem is
required or would be useful. 

Once again, thank you for taking the lead on this issue.

Chris




On Sat, 2008-02-16 at 19:08 +0100, Jiri Kosina wrote:
> [ Peter and Ingo added to CC, as this is apparently another instance of 
>   CONFIG_GROUP_SCHED causing mouse/keyboard misbehavior ]
> 
> Thanks for testing, Chris.
> 
> On Sat, 16 Feb 2008, Chris Holvenstot wrote:
> 
> > Jiri - 
> > 
> > 
> > Sorry for the delay in getting this information back to you. I am now up
> > and running on 2.6.25-rc2 with CONFIG_GROUP_SCHED not set (and for the
> > record, I did NOT use the nohpet directive when booting)
> > 
> > 
> > A copy of the dot-config file from this build has been inserted below. 
> > 
> > 
> > So far everything is working nicely with CONFIG_GROUP_SCHED not set.
> > However I have one observation to make, and I am very likely missing
> > something here, is that over the past few days while I have been trying
> > to isolate a broke / not broke point with git bisect it would seem that
> > the conditions which lead to the repeating key failure are seeded at the
> > time of the boot.
> > 
> > 
> > By this I mean that given a specific kernel configuration I can boot it
> > 'x' number of times - out of all those boot cycles I may get one
> > instance of the failure. The rest of the time it works fine.
> > 
> > 
> > On those occasions when I do get the repeating key failure it would
> > appear that the failure lives for the lifespan of the boot. Twice now
> > when I have had the failure I have tried restarting X to see if it
> > clears, but so far I have not had any luck with that.
> > 
> > 
> > I have compared the dmesg output from a good boot to that of a boot
> > where I see the repeating key issue and except for the expected minor
> > differences in the timestamps nothing jumps out at me.
> > 
> > 
> > I built the kernel you requested with the '-j2' option to load up the
> > CPU - I thought that the suggestion made earlier by someone else about
> > this failure happening while the CPU was loaded had some merit - it was
> > one factor I did not take into consideration during my efforts and might
> > explain why I was getting inconsistent results. 
> > 
> > 
> > However, even though both cores were running along at nearly 100% during
> > this build, I did not see the problem. At this point I am about ready to
> > select a previously unused section of wall to bang my head against.
> > 
> > 
> > Thank you for your continued support - 
> > 
> > 
> > Chris
> > 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists