public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* libata, Sound on same IRQ : flaky sound
@ 2008-08-28  0:06 Robert M. Stockmann
  2008-08-28  0:59 ` Jeff Garzik
  0 siblings, 1 reply; 8+ messages in thread
From: Robert M. Stockmann @ 2008-08-28  0:06 UTC (permalink / raw)
  To: linux-kernel


Hi,

I have a couple of AMD64 machines with onboard sound devices running 
and they all have one thing in common : flaky sound when one is 
doing some heavy disk I/O on the SATA disks. Interesting enough 
/proc/interrupts shows that libata is using the same IRQ as the sound 
devices :

model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 6000+
stepping        : 3
cpu MHz         : 3014.679
cache size      : 1024 KB

# cat /proc/interrupts 
           CPU0       CPU1       
  0:      55869  154467838    IO-APIC-edge  timer
  8:          0          0    IO-APIC-edge  rtc
  9:          0          0   IO-APIC-level  acpi
 16:       1453     499686   IO-APIC-level  libata, NVidia CK8S
 17:          0          0   IO-APIC-level  ehci_hcd:usb1
 18:      27633   69978987   IO-APIC-level  eth0
NMI:      10718      12112 
LOC:  154533874  154533852 
ERR:          0
MIS:          0

model name      : AMD Opteron(tm) Processor 246
stepping        : 10
cpu MHz         : 1991.355
cache size      : 1024 KB

# cat /proc/interrupts 
           CPU0       CPU1       
  0:      18108   19856365    IO-APIC-edge  timer
  1:         16       7915    IO-APIC-edge  i8042
  3:          0         56    IO-APIC-edge  serial
  4:          0         56    IO-APIC-edge  serial
  8:          0          0    IO-APIC-edge  rtc
  9:          0          0   IO-APIC-level  acpi
 12:        346      62269    IO-APIC-edge  i8042
 14:          0        190    IO-APIC-edge  ide0
 15:          1        189    IO-APIC-edge  ide1
 16:        827     358917   IO-APIC-level  libata, AMD AMD8111
 17:          0         18   IO-APIC-level  ohci_hcd:usb1, ohci_hcd:usb2
 18:        555     231470   IO-APIC-level  HiSax, nvidia
 19:      15179    3489796   IO-APIC-level  eth0
NMI:        211        511 
LOC:   19871720   19871628 
ERR:          0
MIS:          0

Kernel is 2.6.15,

Preemption Model is (Preemptible Kernel (Low-Latency Desktop)), Memory 
model is (Flat Memory), [*] Preempt The Big Kernel Lock is switched on. 
Timer frequency is (1000 HZ) or (100 HZ), but changing this value is 
of no influence. One of the machines is a genuine dual Opteron machine
but i'm rather disappointed with the NUMA capabilities of
the 2.6.15 kernel. It does do NUMA, but thats all it does, it doesn't
add anything compared to a SMP kernel with NUMA switched off.

Does one really need the PREEMPT_RT approach to get rock solid
sound as described here ? :

"A realtime preemption overview"
 by Paul McKenney, August 10, 2005
http://lwn.net/Articles/146861/

How about giving your sound device a proper seperate IRQ number?
At least libata should like eth0 have its own kernel resources.

Regards,

Robert
PS. please also cc: to my email address.
-- 
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org  stock@stokkie.net


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: libata, Sound on same IRQ : flaky sound
  2008-08-28  0:06 libata, Sound on same IRQ : flaky sound Robert M. Stockmann
@ 2008-08-28  0:59 ` Jeff Garzik
  2008-08-28  1:30   ` Robert M. Stockmann
  0 siblings, 1 reply; 8+ messages in thread
From: Jeff Garzik @ 2008-08-28  0:59 UTC (permalink / raw)
  To: Robert M. Stockmann; +Cc: linux-kernel

Robert M. Stockmann wrote:
> Hi,
> 
> I have a couple of AMD64 machines with onboard sound devices running 
> and they all have one thing in common : flaky sound when one is 
> doing some heavy disk I/O on the SATA disks. Interesting enough 
> /proc/interrupts shows that libata is using the same IRQ as the sound 
> devices :
> 
> model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 6000+
> stepping        : 3
> cpu MHz         : 3014.679
> cache size      : 1024 KB
> 
> # cat /proc/interrupts 
>            CPU0       CPU1       
>   0:      55869  154467838    IO-APIC-edge  timer
>   8:          0          0    IO-APIC-edge  rtc
>   9:          0          0   IO-APIC-level  acpi
>  16:       1453     499686   IO-APIC-level  libata, NVidia CK8S
>  17:          0          0   IO-APIC-level  ehci_hcd:usb1
>  18:      27633   69978987   IO-APIC-level  eth0
> NMI:      10718      12112 
> LOC:  154533874  154533852 
> ERR:          0
> MIS:          0

What is the behavior of a recent kernel?

Is your SATA interface set to legacy mode in BIOS?

	Jeff



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: libata, Sound on same IRQ : flaky sound
  2008-08-28  0:59 ` Jeff Garzik
@ 2008-08-28  1:30   ` Robert M. Stockmann
  2008-08-28  7:57     ` el es
  2008-08-28 16:33     ` James Ausmus
  0 siblings, 2 replies; 8+ messages in thread
From: Robert M. Stockmann @ 2008-08-28  1:30 UTC (permalink / raw)
  To: Jeff Garzik; +Cc: linux-kernel

On Wed, 27 Aug 2008, Jeff Garzik wrote:

> Date: Wed, 27 Aug 2008 20:59:35 -0400
> From: Jeff Garzik <jeff@garzik.org>
> To: Robert M. Stockmann <stock@stokkie.net>
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: libata, Sound on same IRQ : flaky sound
> 
> Robert M. Stockmann wrote:
> > Hi,
> > 
> > I have a couple of AMD64 machines with onboard sound devices running 
> > and they all have one thing in common : flaky sound when one is 
> > doing some heavy disk I/O on the SATA disks. Interesting enough 
> > /proc/interrupts shows that libata is using the same IRQ as the sound 
> > devices :
> > 
> > model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 6000+
> > stepping        : 3
> > cpu MHz         : 3014.679
> > cache size      : 1024 KB
> > 
> > # cat /proc/interrupts 
> >            CPU0       CPU1       
> >   0:      55869  154467838    IO-APIC-edge  timer
> >   8:          0          0    IO-APIC-edge  rtc
> >   9:          0          0   IO-APIC-level  acpi
> >  16:       1453     499686   IO-APIC-level  libata, NVidia CK8S
> >  17:          0          0   IO-APIC-level  ehci_hcd:usb1
> >  18:      27633   69978987   IO-APIC-level  eth0
> > NMI:      10718      12112 
> > LOC:  154533874  154533852 
> > ERR:          0
> > MIS:          0
> 
> What is the behavior of a recent kernel?
> 
> Is your SATA interface set to legacy mode in BIOS?
> 

the BIOS supports raid0, but the sata disks are running standalone
as /dev/sda /dev/sdb etc.

installing a recent kernel is not that easy, as the required
upgrade of udev will break the initscripts and a lot of installed
services and even the functionality of the KDE desktop. Installing
a recent distro is not desirable as they resemble me only
of a Open Source Vista distro, where it takes months to clean
up the unwanted garbage and bloat inside. Its preposterous that
a upgrade to a recent kernel mandates the installation of a recent
distro. I run Mandrake 10.1 with kernel 2.6.15 and some applications
upgraded like firefox, mplayer and k3b etc.

Robert
-- 
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org  stock@stokkie.net


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: libata, Sound on same IRQ : flaky sound
  2008-08-28  1:30   ` Robert M. Stockmann
@ 2008-08-28  7:57     ` el es
  2008-08-28 16:33     ` James Ausmus
  1 sibling, 0 replies; 8+ messages in thread
From: el es @ 2008-08-28  7:57 UTC (permalink / raw)
  To: linux-kernel

Robert M. Stockmann <stock <at> stokkie.net> writes:


> 
> the BIOS supports raid0, but the sata disks are running standalone
> as /dev/sda /dev/sdb etc.
> 
> installing a recent kernel is not that easy, as the required
> upgrade of udev will break the initscripts and a lot of installed
> services and even the functionality of the KDE desktop. Installing
> a recent distro is not desirable as they resemble me only
> of a Open Source Vista distro, where it takes months to clean
> up the unwanted garbage and bloat inside. Its preposterous that
> a upgrade to a recent kernel mandates the installation of a recent
> distro. I run Mandrake 10.1 with kernel 2.6.15 and some applications
> upgraded like firefox, mplayer and k3b etc.
> 
> Robert


If you don't want bloat AND you want a recent kernel AND lots to fiddle around
and figure out for yourself, install PLD Linux :) No, seriously. Last time I
tried, a usable graphic environment (GNOME that is, dunno about KDE) fitted in
300-500 MiB ON DISK. (without graphical env. fitted in 150MB ON DISK). Try that.

el es


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: libata, Sound on same IRQ : flaky sound
       [not found] <fa.t59JCw5e/IAg/3vXyG2sheD1AnE@ifi.uio.no>
@ 2008-08-28 14:41 ` Robert Hancock
  2008-08-28 17:27   ` Robert M. Stockmann
  0 siblings, 1 reply; 8+ messages in thread
From: Robert Hancock @ 2008-08-28 14:41 UTC (permalink / raw)
  To: Robert M. Stockmann; +Cc: linux-kernel

Robert M. Stockmann wrote:
> Hi,
> 
> I have a couple of AMD64 machines with onboard sound devices running 
> and they all have one thing in common : flaky sound when one is 
> doing some heavy disk I/O on the SATA disks. Interesting enough 
> /proc/interrupts shows that libata is using the same IRQ as the sound 
> devices :
> 
> model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 6000+
> stepping        : 3
> cpu MHz         : 3014.679
> cache size      : 1024 KB
> 
> # cat /proc/interrupts 
>            CPU0       CPU1       
>   0:      55869  154467838    IO-APIC-edge  timer
>   8:          0          0    IO-APIC-edge  rtc
>   9:          0          0   IO-APIC-level  acpi
>  16:       1453     499686   IO-APIC-level  libata, NVidia CK8S
>  17:          0          0   IO-APIC-level  ehci_hcd:usb1
>  18:      27633   69978987   IO-APIC-level  eth0
> NMI:      10718      12112 
> LOC:  154533874  154533852 
> ERR:          0
> MIS:          0
> 
> model name      : AMD Opteron(tm) Processor 246
> stepping        : 10
> cpu MHz         : 1991.355
> cache size      : 1024 KB
> 
> # cat /proc/interrupts 
>            CPU0       CPU1       
>   0:      18108   19856365    IO-APIC-edge  timer
>   1:         16       7915    IO-APIC-edge  i8042
>   3:          0         56    IO-APIC-edge  serial
>   4:          0         56    IO-APIC-edge  serial
>   8:          0          0    IO-APIC-edge  rtc
>   9:          0          0   IO-APIC-level  acpi
>  12:        346      62269    IO-APIC-edge  i8042
>  14:          0        190    IO-APIC-edge  ide0
>  15:          1        189    IO-APIC-edge  ide1
>  16:        827     358917   IO-APIC-level  libata, AMD AMD8111
>  17:          0         18   IO-APIC-level  ohci_hcd:usb1, ohci_hcd:usb2
>  18:        555     231470   IO-APIC-level  HiSax, nvidia
>  19:      15179    3489796   IO-APIC-level  eth0
> NMI:        211        511 
> LOC:   19871720   19871628 
> ERR:          0
> MIS:          0
> 
> Kernel is 2.6.15,
> 
> Preemption Model is (Preemptible Kernel (Low-Latency Desktop)), Memory 
> model is (Flat Memory), [*] Preempt The Big Kernel Lock is switched on. 
> Timer frequency is (1000 HZ) or (100 HZ), but changing this value is 
> of no influence. One of the machines is a genuine dual Opteron machine
> but i'm rather disappointed with the NUMA capabilities of
> the 2.6.15 kernel. It does do NUMA, but thats all it does, it doesn't
> add anything compared to a SMP kernel with NUMA switched off.
> 
> Does one really need the PREEMPT_RT approach to get rock solid
> sound as described here ? :
> 
> "A realtime preemption overview"
>  by Paul McKenney, August 10, 2005
> http://lwn.net/Articles/146861/
> 
> How about giving your sound device a proper seperate IRQ number?
> At least libata should like eth0 have its own kernel resources.

That's an issue with the way the motherboard IRQ lines are wired. 
There's nothing the kernel can do about it.

Normally I wouldn't expect that to make a big difference though..

You'd really have to try a newer kernel first in order to get much help, 
though. That's a pretty ancient kernel. Quite likely the situation is 
improved in newer versions.

> 
> Regards,
> 
> Robert
> PS. please also cc: to my email address.


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: libata, Sound on same IRQ : flaky sound
  2008-08-28  1:30   ` Robert M. Stockmann
  2008-08-28  7:57     ` el es
@ 2008-08-28 16:33     ` James Ausmus
  1 sibling, 0 replies; 8+ messages in thread
From: James Ausmus @ 2008-08-28 16:33 UTC (permalink / raw)
  To: Robert M. Stockmann; +Cc: Jeff Garzik, linux-kernel

On Wed, Aug 27, 2008 at 6:30 PM, Robert M. Stockmann <stock@stokkie.net> wrote:
<snip>
> installing a recent kernel is not that easy, as the required
> upgrade of udev will break the initscripts and a lot of installed
> services and even the functionality of the KDE desktop. Installing
> a recent distro is not desirable as they resemble me only
> of a Open Source Vista distro, where it takes months to clean
> up the unwanted garbage and bloat inside. Its preposterous that
> a upgrade to a recent kernel mandates the installation of a recent
> distro. I run Mandrake 10.1 with kernel 2.6.15 and some applications
> upgraded like firefox, mplayer and k3b etc.
>

Not to divert this into a distro discussion, but you should look into
Gentoo (http://www.gentoo.org) - it offers the kind of customization
and flexibility (as well as pick and choose update capabilities) that
it sounds like you are interested in.

-James



> Robert
> --
> Robert M. Stockmann - RHCE
> Network Engineer - UNIX/Linux Specialist
> crashrecovery.org  stock@stokkie.net
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: libata, Sound on same IRQ : flaky sound
  2008-08-28 14:41 ` Robert Hancock
@ 2008-08-28 17:27   ` Robert M. Stockmann
  2008-08-29 12:57     ` Clemens Ladisch
  0 siblings, 1 reply; 8+ messages in thread
From: Robert M. Stockmann @ 2008-08-28 17:27 UTC (permalink / raw)
  To: Robert Hancock; +Cc: linux-kernel

On Thu, 28 Aug 2008, Robert Hancock wrote:

> Date: Thu, 28 Aug 2008 08:41:08 -0600
> From: Robert Hancock <hancockr@shaw.ca>
> To: Robert M. Stockmann <stock@stokkie.net>
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: libata, Sound on same IRQ : flaky sound
> 
> Robert M. Stockmann wrote:
> > Hi,
> > 
> > I have a couple of AMD64 machines with onboard sound devices running 
> > and they all have one thing in common : flaky sound when one is 
> > doing some heavy disk I/O on the SATA disks. Interesting enough 
> > /proc/interrupts shows that libata is using the same IRQ as the sound 
> > devices :
> > 
> > model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 6000+
> > stepping        : 3
> > cpu MHz         : 3014.679
> > cache size      : 1024 KB
> > 
> > # cat /proc/interrupts 
> >            CPU0       CPU1       
> >   0:      55869  154467838    IO-APIC-edge  timer
> >   8:          0          0    IO-APIC-edge  rtc
> >   9:          0          0   IO-APIC-level  acpi
> >  16:       1453     499686   IO-APIC-level  libata, NVidia CK8S
> >  17:          0          0   IO-APIC-level  ehci_hcd:usb1
> >  18:      27633   69978987   IO-APIC-level  eth0
> > NMI:      10718      12112 
> > LOC:  154533874  154533852 
> > ERR:          0
> > MIS:          0
> > 
> > model name      : AMD Opteron(tm) Processor 246
> > stepping        : 10
> > cpu MHz         : 1991.355
> > cache size      : 1024 KB
> > 
> > # cat /proc/interrupts 
> >            CPU0       CPU1       
> >   0:      18108   19856365    IO-APIC-edge  timer
> >   1:         16       7915    IO-APIC-edge  i8042
> >   3:          0         56    IO-APIC-edge  serial
> >   4:          0         56    IO-APIC-edge  serial
> >   8:          0          0    IO-APIC-edge  rtc
> >   9:          0          0   IO-APIC-level  acpi
> >  12:        346      62269    IO-APIC-edge  i8042
> >  14:          0        190    IO-APIC-edge  ide0
> >  15:          1        189    IO-APIC-edge  ide1
> >  16:        827     358917   IO-APIC-level  libata, AMD AMD8111
> >  17:          0         18   IO-APIC-level  ohci_hcd:usb1, ohci_hcd:usb2
> >  18:        555     231470   IO-APIC-level  HiSax, nvidia
> >  19:      15179    3489796   IO-APIC-level  eth0
> > NMI:        211        511 
> > LOC:   19871720   19871628 
> > ERR:          0
> > MIS:          0
> > 
> > Kernel is 2.6.15,
> > 
> > Preemption Model is (Preemptible Kernel (Low-Latency Desktop)), Memory 
> > model is (Flat Memory), [*] Preempt The Big Kernel Lock is switched on. 
> > Timer frequency is (1000 HZ) or (100 HZ), but changing this value is 
> > of no influence. One of the machines is a genuine dual Opteron machine
> > but i'm rather disappointed with the NUMA capabilities of
> > the 2.6.15 kernel. It does do NUMA, but thats all it does, it doesn't
> > add anything compared to a SMP kernel with NUMA switched off.
> > 
> > Does one really need the PREEMPT_RT approach to get rock solid
> > sound as described here ? :
> > 
> > "A realtime preemption overview"
> >  by Paul McKenney, August 10, 2005
> > http://lwn.net/Articles/146861/
> > 
> > How about giving your sound device a proper seperate IRQ number?
> > At least libata should like eth0 have its own kernel resources.
> 
> That's an issue with the way the motherboard IRQ lines are wired. 
> There's nothing the kernel can do about it.

That sounds rather strange to me, as IRQ line 16 is a virtual
IRQ as part of IO-APIC.

> Normally I wouldn't expect that to make a big difference though..

fact is that when copying a iso from one SATA disk to the
other results in flaky sound when playing online internet radio.
Even starting firefox for the 1st time after booting results
in flaky sound for a short time.

> You'd really have to try a newer kernel first in order to get much help, 
> though. That's a pretty ancient kernel. Quite likely the situation is 
> improved in newer versions.

I sure would like todo that. But why doesn't the linux-kernel community
know howto pull virtual IRQ lines apart, as part of configuring
a linux kernel? In the days of 386/486 cpu's, IRQ's of several
add-on cards could be adjusted manually by jumpers. Why is there not
such a thing for virtual IRQ's inside the IO-APIC system?

The libata driver should like eth0 on IRQ 19 have its own IRQ.

Robert
-- 
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org  stock@stokkie.net


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: libata, Sound on same IRQ : flaky sound
  2008-08-28 17:27   ` Robert M. Stockmann
@ 2008-08-29 12:57     ` Clemens Ladisch
  0 siblings, 0 replies; 8+ messages in thread
From: Clemens Ladisch @ 2008-08-29 12:57 UTC (permalink / raw)
  To: Robert M. Stockmann; +Cc: Robert Hancock, linux-kernel

Robert M. Stockmann wrote:
> On Thu, 28 Aug 2008, Robert Hancock wrote:
> > Robert M. Stockmann wrote:
> > > How about giving your sound device a proper seperate IRQ number?
> > > At least libata should like eth0 have its own kernel resources.
> >
> > That's an issue with the way the motherboard IRQ lines are wired.
> > There's nothing the kernel can do about it.
>
> That sounds rather strange to me, as IRQ line 16 is a virtual
> IRQ as part of IO-APIC.

The IRQ isn't virtual; in IO-APIC mode, all PCI interrupts (PCI cards
and internal PCI devices) are hard-wired to certain interrupt vectors.


Regards,
Clemens

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2008-08-29 15:41 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-08-28  0:06 libata, Sound on same IRQ : flaky sound Robert M. Stockmann
2008-08-28  0:59 ` Jeff Garzik
2008-08-28  1:30   ` Robert M. Stockmann
2008-08-28  7:57     ` el es
2008-08-28 16:33     ` James Ausmus
     [not found] <fa.t59JCw5e/IAg/3vXyG2sheD1AnE@ifi.uio.no>
2008-08-28 14:41 ` Robert Hancock
2008-08-28 17:27   ` Robert M. Stockmann
2008-08-29 12:57     ` Clemens Ladisch

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox