Re: 2.6.5, 2.6.6-rc2 sluggish interrupts

Re: 2.6.5, 2.6.6-rc2 sluggish interrupts

[Justin Pryzby]

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

The problem persists with 2.6.6 final, but get this: I was recompiling
with preempt disabled (which didn't do anything to solve the problem),
but during the compile, there were very few music skips / mouse skips.
Not sure what that could mean though..
Justin

On Fri, Apr 30, 2004 at 03:18:04AM +0000, Peter Chubb wrote:
> >>>>> 'Justin' == Justin Pryzby <justinpryzby@users.sourceforge.net> writes:
> 
> Justin> --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii
> Justin> Content-Disposition: inline Content-Transfer-Encoding:
> Justin> quoted-printable
> 
> Justin> It feels to me like it always happens when the disk is
> Justin> accessed (possibly just because I can _hear_ that), and it
> Justin> seems like it happens when the disk hasn't been used in a
> Justin> while.
> 
> Try
>    1. booting with elevator=deadline
>    2. hdparm -u /dev/hda

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

Re: 2.6.5, 2.6.6-rc2 sluggish interrupts

[Justin Pryzby]

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

This also suffices to cease the skipping:

	while true; do false; done;

I also see this, by the way:

	May 19 15:15:51 andromeda kernel: psmouse.c: Mouse at
	isa0060/serio1/input0 lost
	 synchronization, throwing 2 bytes away.
	May 19 15:16:02 andromeda kernel: psmouse.c: Mouse at
	isa0060/serio1/input0 lost
	 synchronization, throwing 1 bytes away.
	May 19 15:16:03 andromeda kernel: psmouse.c: Mouse at
	isa0060/serio1/input0 lost
	 synchronization, throwing 2 bytes away.

But these don't correlate with the skips, which frequently happen even
when there's no kernel log entry for the mouse.  FWIW, that could be a
legitimate hardware problem, though it happens even when I'm using an
external mouse (laptop).

Justin

On Wed, May 19, 2004 at 03:19:00PM -0400, pryzbyj wrote:
> The problem persists with 2.6.6 final, but get this: I was recompiling
> with preempt disabled (which didn't do anything to solve the problem),
> but during the compile, there were very few music skips / mouse skips.
> Not sure what that could mean though..

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

Re: 2.6.5, 2.6.6-rc2 sluggish interrupts

[Justin Pryzby]

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

Found a solution: disable cpufreq.  I also saw these:

	May 16 12:39:48 andromeda kernel: cpufreq: change failed with new_state
	0 and result 3
	May 16 14:59:13 andromeda kernel: cpufreq: change failed with new_state
	0 and result 3
	May 16 14:59:13 andromeda kernel: cpufreq: change failed with new_state
	0 and result 3

Justin

On Wed, May 19, 2004 at 03:24:14PM -0400, pryzbyj wrote:
> This also suffices to cease the skipping:
> 
> 	while true; do false; done;
> 
> I also see this, by the way:
> 
> 	May 19 15:15:51 andromeda kernel: psmouse.c: Mouse at
> 	isa0060/serio1/input0 lost
> 	 synchronization, throwing 2 bytes away.
> 	May 19 15:16:02 andromeda kernel: psmouse.c: Mouse at
> 	isa0060/serio1/input0 lost
> 	 synchronization, throwing 1 bytes away.
> 	May 19 15:16:03 andromeda kernel: psmouse.c: Mouse at
> 	isa0060/serio1/input0 lost
> 	 synchronization, throwing 2 bytes away.
> 
> But these don't correlate with the skips, which frequently happen even
> when there's no kernel log entry for the mouse.  FWIW, that could be a
> legitimate hardware problem, though it happens even when I'm using an
> external mouse (laptop).
> 
> Justin
> 
> On Wed, May 19, 2004 at 03:19:00PM -0400, pryzbyj wrote:

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

Re: 2.6.5, 2.6.6-rc2 sluggish interrupts

[Peter Chubb]

>>>>> "Justin" == Justin Pryzby <justinpryzby@users.sourceforge.net> writes:

Justin> Found a solution: disable cpufreq.  
The alternative may be to use a more stable timesource than the TSC
(which varies in rate when cpufreq is enabled)

--
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
The technical we do immediately,  the political takes *forever*

Re: 2.6.5, 2.6.6-rc2 sluggish interrupts

[Peter Chubb]

>>>>> "Justin" == Justin Pryzby <justinpryzby@users.sourceforge.net> writes:

Justin> --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii
Justin> Content-Disposition: inline Content-Transfer-Encoding:
Justin> quoted-printable

Justin> It feels to me like it always happens when the disk is
Justin> accessed (possibly just because I can _hear_ that), and it
Justin> seems like it happens when the disk hasn't been used in a
Justin> while.

Try 
    1.  booting with elevator=deadline
    2. hdparm -u /dev/hda

One of these might help.

Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
The technical we do immediately,  the political takes *forever*

2.6.5, 2.6.6-rc2 sluggish interrupts

[Justin Pryzby]

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

I noticed this first with Linux 2.6.5 (but not with 2.6.2) and also now
with 2.6.6-rc2.  The machine responds very slugishly while excercizing
one interrupt when another interrupt happens.  Ex.  I'm circling the
mouse pointer around the screen, and suddenly the hard drive decides to
`sync`, or some such.  The pointer then freezes for at least a
half-second.  It affects the keyboard too.  (Though, presumably, it
could also be a display issue).  I notice myself losing alot of
keystrokes as a result of this (I don't know what that means about the
problem..)  I don't know enough to say that this is about interrupts,
but take a look: 

	pryzbyj@andromeda:~$ cat /proc/interrupts 
		   CPU0       
	  0:    3835408          XT-PIC  timer
	  1:       9797          XT-PIC  i8042
	  2:          0          XT-PIC  cascade
	  5:          0          XT-PIC  Maestro3
	  7:          1          XT-PIC  parport0
	  8:          4          XT-PIC  rtc
	  9:          1          XT-PIC  acpi
	 11:     310777          XT-PIC  yenta, yenta, uhci_hcd, eth0, r128@PCI:1:0:0
	 12:      10454          XT-PIC  i8042
	 14:      11802          XT-PIC  ide0
	 15:         17          XT-PIC  ide1
	NMI:          0 
	LOC:          0 
	ERR:          0
	MIS:          0

I don't recall seeing that r128@PCI:1:0:0 entry there before (I haven't
changed hardware, I've been using the console framebuffer for a while,
AGP, DRM have always been on).  And it seems to be making lots of noise
(though I don't know that that's wrong).  I do know there's a general
problem though - sometimes it feels like I'm using a remote machine when
I'm not.

It feels to me like it always happens when the disk is accessed
(possibly just because I can _hear_ that), and it seems like it happens
when the disk hasn't been used in a while.

Please Cc: me.

Justin

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