via82cxxx_audio driver bug?

via82cxxx_audio driver bug?

[Nicholas Knight]

(my apologies if this gets seen as a little offtopic, I felt this was the 
best place to get results from people who knew what was going on with 
drivers)
My writeup on the bug when I belived it was definitely an XMMS bug is 
avalible here:
http://bugs.xmms.org/show_bug.cgi?id=115
you'll need to scroll down to see details on what I isolated it to

I just sent email to the maintainer of the via82cxxx_audio driver 
regarding this bug, hopefully I'll hear back from him soon, but I'd also 
like to hear from anyone else who has used and/or hacked at this driver, 
and if they've seen XMMS or other audio applications with access to 
/dev/mixer have strange, temporarily lockups when not in root/realtime 
priority. I've yet to be able to test this with other audio applications 
besides XMMS.

Thanks.

Re: via82cxxx_audio driver bug?

[Adrian Cox]

Nicholas Knight wrote:
> I just sent email to the maintainer of the via82cxxx_audio driver 
> regarding this bug, hopefully I'll hear back from him soon, but I'd also 
> like to hear from anyone else who has used and/or hacked at this driver, 
> and if they've seen XMMS or other audio applications with access to 
> /dev/mixer have strange, temporarily lockups when not in root/realtime 
> priority. I've yet to be able to test this with other audio applications 
> besides XMMS.

Are you using 2.4.7 or 2.4.8? Those kernels have new code to talk to the 
AC97 codec, which cures lockups on some boards.
-- 
Adrian Cox   http://www.humboldt.co.uk/

Re: via82cxxx_audio driver bug?

[Anton Altaparmakov]

At 15:19 13/08/2001, Nicholas Knight wrote:
>(my apologies if this gets seen as a little offtopic, I felt this was the
>best place to get results from people who knew what was going on with
>drivers)
>My writeup on the bug when I belived it was definitely an XMMS bug is
>avalible here:
>http://bugs.xmms.org/show_bug.cgi?id=115
>you'll need to scroll down to see details on what I isolated it to
>
>I just sent email to the maintainer of the via82cxxx_audio driver
>regarding this bug, hopefully I'll hear back from him soon, but I'd also
>like to hear from anyone else who has used and/or hacked at this driver,
>and if they've seen XMMS or other audio applications with access to
>/dev/mixer have strange, temporarily lockups when not in root/realtime
>priority. I've yet to be able to test this with other audio applications
>besides XMMS.

Sure enough it locks up as you describe, looks like a bug in the driver. 
The only way to recover is to killproc -9 xmms for me. Sometimes it even 
locks up the window manager (mouse moves but can't click anywhere) and I 
have to Ctrl+Altr+Backspace kill X to get the system back. But these 
lockups seem to depend on application used to play sound as well as on 
whether KDE or Gnome is running. Weird.

However I see some interesting effects when run as a root, too!

Audio playing will sometimes block and appear dead until "something" 
triggers the system call it is blocking in to be interrupted (run strace to 
see what I mean). Then it suddenly starts playing fine (I have seen this 
both as root and as normal user). - Weird. Basically there seems to be some 
problem with blocking i/o and the VIA AC97 codec driver (hardware here 
Class 0401: 1106:3058 (rev 50), Subsystem: 1106:4511 this translates to 
text: VIT Tech... AC97 Audio Controller (rev 50), Subsystem: VIA 
Technologies, Inc.: Unknown device 4511).

And there is something else possibly unrelated: Whenever there is high PCI 
activity I get sound drop outs, distortions and even sound slow downs, 
irrespectable of application used to play sound. For example moving any 
windows around or just causing high number of syscalls (e.g. run strace 
<some application, e.g. gmix in gnome>, then move sliders around in the 
application and listen to the sound or just move the application window 
around. same effect but weaker is produced by just taking a random not 
sound related window and moving it around as quickly as possible, effect is 
amplified when moving it so it moves over the xmms window).

I suspect the distortions/slowdowns are a direct effect of the PCI bus 
being saturated or in some way disturbed? I am not convinced this is a 
driver bug per se but it might be possible to fix it by working around this 
in the driver or in the BIOS settings somehow... The first problem with 
xmms blocking until a syscall interrupt is triggered is a bug in the driver 
though I would suspect (haven't looked at it).

Anton

Output of lspci -vvv follows:

00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03)
         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
         Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort+ >SERR- <PERR-
         Latency: 8
         Region 0: Memory at d2000000 (32-bit, prefetchable) [size=4M]
         Capabilities: [a0] AGP version 2.0
                 Status: RQ=31 SBA+ 64bit- FW+ Rate=x1,x2
                 Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
         Capabilities: [c0] Power Management version 2
                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] 
(prog-if 00 [Normal decode])
         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
         Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort+ >SERR- <PERR-
         Latency: 0
         Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
         I/O behind bridge: 0000f000-00000fff
         Memory behind bridge: fff00000-000fffff
         Prefetchable memory behind bridge: fff00000-000fffff
         BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
         Capabilities: [80] Power Management version 2
                 Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] 
(rev 40)
         Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge
         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping+ SERR- FastB2B-
         Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
         Latency: 0
         Capabilities: [c0] Power Management version 2
                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06) 
(prog-if 8a [Master SecP PriP])
         Subsystem: VIA Technologies, Inc. Bus Master IDE
         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
         Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
         Latency: 32
         Region 4: I/O ports at d000 [size=16]
         Capabilities: [c0] Power Management version 2
                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16) (prog-if 
00 [UHCI])
         Subsystem: Unknown device 0925:1234
         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
         Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
         Latency: 32, cache line size 08
         Interrupt: pin D routed to IRQ 11
         Region 4: I/O ports at d400 [size=32]
         Capabilities: [80] Power Management version 2
                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16) (prog-if 
00 [UHCI])
         Subsystem: Unknown device 0925:1234
         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
         Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
         Latency: 32, cache line size 08
         Interrupt: pin D routed to IRQ 11
         Region 4: I/O ports at d800 [size=32]
         Capabilities: [80] Power Management version 2
                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
         Subsystem: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
         Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
         Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
         Interrupt: pin ? routed to IRQ 10
         Capabilities: [68] Power Management version 2
                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.5 Multimedia audio controller: VIA Technologies, Inc. AC97 Audio 
Controller (rev 50)
         Subsystem: VIA Technologies, Inc.: Unknown device 4511
         Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
         Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
         Interrupt: pin C routed to IRQ 15
         Region 0: I/O ports at dc00 [size=256]
         Region 1: I/O ports at e000 [size=4]
         Region 2: I/O ports at e400 [size=4]
         Capabilities: [c0] Power Management version 2
                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:0c.0 Ethernet controller: 3Com Corporation 3c900B-TPO [Etherlink XL TPO] 
(rev 04)
         Subsystem: 3Com Corporation 3C900B-TPO Etherlink XL TPO 10Mb
         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
         Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
         Latency: 32 (2500ns min, 12000ns max), cache line size 08
         Interrupt: pin A routed to IRQ 15
         Region 0: I/O ports at e800 [size=128]
         Region 1: Memory at d2400000 (32-bit, non-prefetchable) [size=128]
         Expansion ROM at <unassigned> [disabled] [size=128K]
         Capabilities: [dc] Power Management version 1
                 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
PME(D0-,D1+,D2+,D3hot+,D3cold-)
                 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:0d.0 VGA compatible controller: Tseng Labs Inc ET6000 (rev 70) (prog-if 
00 [VGA])
         Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
         Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
         Interrupt: pin A routed to IRQ 11
         Region 0: Memory at d1000000 (32-bit, non-prefetchable) [size=16M]
         Region 1: I/O ports at ec00 [size=256]
         Expansion ROM at <unassigned> [disabled] [size=16M]



-- 
   "Nothing succeeds like success." - Alexandre Dumas
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

Re: via82cxxx_audio driver bug?

[Paul Jakma]

On Mon, 13 Aug 2001, Nicholas Knight wrote:

> and if they've seen XMMS or other audio applications with access to
> /dev/mixer have strange, temporarily lockups when not in root/realtime
> priority. I've yet to be able to test this with other audio applications
> besides XMMS.

yes.. i see this too with the via82cxxx_audio driver on my Tyan
AMD751+Via southbridge board.

/anything/ that accesses /dev/mixer or /dev/dsp while sound is being
played is locked. Eg, play an mp3 with xmms. while playing, xmms and
things like the gnome and WM mixer applets are all unresponsive. they
respond to UI interaction maybe only every 30 seconds or longer.

xmms with real-time priority does not suffer from this
unresponsiveness.

from the haze of my memory i think this behaviour started with the
mmap support that Jeff brought in 1.1.13 or 1.1.14. but i can't be
sure.

I've tried playing with the size of the buffers
(VIA_MAX_BUFFER_DMA_PAGES) and the _TIME and FRAG_ defines. best
result was that perioid of the unresponsiveness was reduced slightly,
but not eliminated (by reducing the buffering times and number of
fragments).

> Thanks.

regards,

--paulj

Re: via82cxxx_audio driver bug?

[Nicholas Knight]

On Monday 13 August 2001 08:19 am, Adrian Cox wrote:
> Nicholas Knight wrote:
> > I just sent email to the maintainer of the via82cxxx_audio driver
> > regarding this bug, hopefully I'll hear back from him soon, but I'd
> > also like to hear from anyone else who has used and/or hacked at this
> > driver, and if they've seen XMMS or other audio applications with
> > access to /dev/mixer have strange, temporarily lockups when not in
> > root/realtime priority. I've yet to be able to test this with other
> > audio applications besides XMMS.
>
> Are you using 2.4.7 or 2.4.8? Those kernels have new code to talk to
> the AC97 codec, which cures lockups on some boards.

Both, and previous kernels back to 2.4.3 have also shown this.
I also replaced via82cxxx_audio.c in 2.4.8 with the latest (.15, 2.4.8 is 
".14b") and recompiled, and the problem persists.

Keep in mind, this isn't a *total* lockup, it's a problem of the UI in 
XMMS and other applications becoming unresponsive. Audio skips from this 
are rare but not unknown to me.

Re: via82cxxx_audio driver bug?

[Nicholas Knight]

On Monday 13 August 2001 10:46 am, Paul Jakma wrote:
> On Mon, 13 Aug 2001, Nicholas Knight wrote:
> > and if they've seen XMMS or other audio applications with access to
> > /dev/mixer have strange, temporarily lockups when not in
> > root/realtime priority. I've yet to be able to test this with other
> > audio applications besides XMMS.
>
> yes.. i see this too with the via82cxxx_audio driver on my Tyan
> AMD751+Via southbridge board.
>
> /anything/ that accesses /dev/mixer or /dev/dsp while sound is being

/dev/mixer is the sole problem on my end, as long as I block XMMS's 
access to /dev/mixer (wether via permissions or pointing it to a device 
that doesn't exist), it plays out /dev/dsp alone just fine, except for 
the lack of XMMS-side volume control.

> played is locked. Eg, play an mp3 with xmms. while playing, xmms and
> things like the gnome and WM mixer applets are all unresponsive. they
> respond to UI interaction maybe only every 30 seconds or longer.

The UI in other apps is a little iffy on my end, sometimes they lock, 
sometimes not.

>
> xmms with real-time priority does not suffer from this
> unresponsiveness.
>

same here

> from the haze of my memory i think this behaviour started with the
> mmap support that Jeff brought in 1.1.13 or 1.1.14. but i can't be
> sure.

what version was in kernel 2.4.3? I first started reporting this when I 
installed Mandrake 8.0 and noticed it a couple months ago.

>
> I've tried playing with the size of the buffers
> (VIA_MAX_BUFFER_DMA_PAGES) and the _TIME and FRAG_ defines. best
> result was that perioid of the unresponsiveness was reduced slightly,
> but not eliminated (by reducing the buffering times and number of
> fragments).
>
> > Thanks.
>
> regards,
>
> --paulj

Re: via82cxxx_audio driver bug?

[Martin Hoeller]

On Mon, 13 Aug 2001, Nicholas Knight wrote:

> On Monday 13 August 2001 08:19 am, Adrian Cox wrote:
> >
> > Are you using 2.4.7 or 2.4.8? Those kernels have new code to talk to
> > the AC97 codec, which cures lockups on some boards.
> 
> Both, and previous kernels back to 2.4.3 have also shown this.
> I also replaced via82cxxx_audio.c in 2.4.8 with the latest (.15, 2.4.8 is 
> ".14b") and recompiled, and the problem persists.

I've the same problem on my Asus K7V Motherboard with kernel 2.4.[1-3].
In earlier kernels (2.2.1[78]) everything worked fine for me.

Note, that my lockups are just about 1s or so.


- martin

--------------------------------------------------------------------
\       Martin Hoeller          | email: martin.hoeller@xss.co.at /    
 \      xS+S Andreas Haumer     | phone: +43-1-6060114-30        /
  \     Karmarschgasse 51/2/20  | fax:   +43-1-6060114-71       /
   \    A-1100 Vienna/Austria   |                              /
    -----------------------------------------------------------

Re: via82cxxx_audio driver bug?

[Adrian Cox]

Nicholas Knight wrote:
> Keep in mind, this isn't a *total* lockup, it's a problem of the UI in 
> XMMS and other applications becoming unresponsive. Audio skips from this 
> are rare but not unknown to me.

What's difficult is that it doesn't happen to all of us. I can turn the 
volume up and down through XMMS or through the Gnome mixer without the 
slightest problem while playing MP3s. I haven't yet worked out the 
pattern which marks when this occurs.

Could people having this problem send me the following info, and I'll 
summarise any pattern I spot:

lspci -x of the Via southbridge function 5
Motherboard
Processor
Kernel/driver versions
AC97 Codec ID (IMPORTANT)

-- 
Adrian Cox   http://www.humboldt.co.uk/

Re: via82cxxx_audio driver bug?

[Paul Jakma]

On Mon, 13 Aug 2001, Nicholas Knight wrote:

> The UI in other apps is a little iffy on my end, sometimes they lock,
> sometimes not.

well.. even mpg123 seems to suffer. it doesn't have a UI :) but it
doesn't respond to ^C straight away.

> what version was in kernel 2.4.3? I first started reporting this when I
> installed Mandrake 8.0 and noticed it a couple months ago.

i honestly don't remember.

Jeff has a newer driver out, 1.1.15, i didn't get a chance to try it
out last night. wondering whether it fixes the problem. (it has a lot
of fixups).

regards,

--paulj

Re: via82cxxx_audio driver bug?

[Nicholas Knight]

On Tuesday 14 August 2001 04:06 am, Paul Jakma wrote:
> On Mon, 13 Aug 2001, Nicholas Knight wrote:
> > The UI in other apps is a little iffy on my end, sometimes they lock,
> > sometimes not.
>
> well.. even mpg123 seems to suffer. it doesn't have a UI :) but it
> doesn't respond to ^C straight away.

I'll try to monitor CPU usage of XMMS when /dev/mixer is avalible to it

>
> > what version was in kernel 2.4.3? I first started reporting this when
> > I installed Mandrake 8.0 and noticed it a couple months ago.
>
> i honestly don't remember.
>
> Jeff has a newer driver out, 1.1.15, i didn't get a chance to try it
> out last night. wondering whether it fixes the problem. (it has a lot
> of fixups).

nope, I've already tried it, same problems :(

>
> regards,
>
> --paulj

Re: via82cxxx_audio driver bug?

[Petr Baudis]

> > and if they've seen XMMS or other audio applications with access to
> > /dev/mixer have strange, temporarily lockups when not in root/realtime
> > priority. I've yet to be able to test this with other audio applications
> > besides XMMS.
> 
> yes.. i see this too with the via82cxxx_audio driver on my Tyan
> AMD751+Via southbridge board.
> 
> /anything/ that accesses /dev/mixer or /dev/dsp while sound is being
> played is locked. Eg, play an mp3 with xmms. while playing, xmms and
> things like the gnome and WM mixer applets are all unresponsive. they
> respond to UI interaction maybe only every 30 seconds or longer.
> 
> xmms with real-time priority does not suffer from this
> unresponsiveness.

This bug was reported before some time even on sourceforge, where this
driver is developed.

It happens even when running silly volume adjusting console program
(http://pasky.ji.cz/~pasky/cp/volume.c) - try to strace it, it hangs
in depth of the ioctl()s called - but it happens only when you are
actually playing something also.

-- 

				Petr "Pasky" Baudis
.                                                                       .
#define BITCOUNT(x)     (((BX_(x)+(BX_(x)>>4)) & 0x0F0F0F0F) % 255)
#define  BX_(x)         ((x) - (((x)>>1)&0x77777777)                    \
                             - (((x)>>2)&0x33333333)                    \
                             - (((x)>>3)&0x11111111))
             -- really weird C code to count the number of bits in a word
.                                                                       .
My public PGP key is on: http://pasky.ji.cz/~pasky/pubkey.txt
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d- s++:++ a--- C+++ UL++++$ P+ L+++ E--- W+ N !o K- w-- !O M-
!V PS+ !PE Y+ PGP+>++ t+ 5 X(+) R++ tv- b+ DI(+) D+ G e-> h! r% y?
------END GEEK CODE BLOCK------

Re: via82cxxx_audio driver bug?

[Adrian Cox]

John Weber wrote:

> I would get you the AC97 Codec ID if I knew how to get it, but
> the rest of the info is here.

It's in the startup messages of the driver.
Try dmesg | grep ac97
or
grep ac97 /var/log/dmesg (or wherever else your distribution puts them).

-- 
Adrian Cox   http://www.humboldt.co.uk/