i810 audio problem

Switching from 2.4.2 to 2.4.5 breaks i810_audio on my intel MX440 based notebook:

After some (in fact a few) seconds of playback it gets stuck until the app closes and reopens /dev/dsp. (I do NOT use esd)

I tried 2.4.4 and 2.4.5 (and the ac patches on both) but it does't work anyway.

Jun 18 13:45:50 argo kernel: Intel 810 + AC97 Audio, version 0.03, 13:40:09 Jun 18 2001
Jun 18 13:45:50 argo kernel: PCI: Setting latency timer of device 00:00.1 to 64
Jun 18 13:45:50 argo kernel: i810: Intel 440MX found at IO 0x1500 and 0x1600, IRQ 5
Jun 18 13:45:50 argo kernel: ac97_codec: AC97 Audio codec, id: 0x4352:0x5934 (Cirrus Logic CS4299 rev D)
Jun 18 13:45:50 argo kernel: i810_audio: called i810_set_dac_rate : rate = 48000/48000
Jun 18 13:45:50 argo kernel: i810_audio: allocated 65536 (order = 4) bytes at cb660000
Jun 18 13:45:50 argo kernel: i810_audio: prog_dmabuf, sample rate = 48000, format = 3,
Jun 18 13:45:50 argo kernel: ^Inumfrag = 32, fragsize = 2048 dmasize = 65536
Jun 18 13:45:50 argo kernel: i810_audio: 17768 bytes in 50 milliseconds
Jun 18 13:45:50 argo kernel: i810_audio: setting clocking to 25934
Jun 18 13:58:06 argo kernel: i810_audio: called i810_set_dac_rate : rate = 14806/8000

[snip]

Here starts the playback

Jun 18 13:58:06 argo kernel: i810_audio: i810_ioctl, arg=0x0, cmd=SNDCTL_DSP_RESET
Jun 18 13:58:06 argo kernel: i810_audio: i810_ioctl, arg=0x20000c, cmd=SNDCTL_DSP_SETFRAGMENT 0x10000, 4096, 16
Jun 18 13:58:06 argo kernel: i810_audio: i810_ioctl, arg=0x10, cmd=SNDCTL_DSP_SETFMT
Jun 18 13:58:06 argo kernel: i810_audio: i810_ioctl, arg=0x10, cmd=SNDCTL_DSP_SETFMT
Jun 18 13:58:06 argo kernel: i810_audio: i810_ioctl, arg=0x1, cmd=SNDCTL_DSP_STEREO
Jun 18 13:58:06 argo kernel: i810_audio: i810_ioctl, arg=0xac44, cmd=SNDCTL_DSP_SPEED
Jun 18 13:58:06 argo kernel: i810_audio: called i810_set_dac_rate : rate = 40811/22050
Jun 18 13:58:06 argo kernel: i810_audio: i810_ioctl, arg=0x0, cmd=i810_audio: allocated 65536 (order = 4) bytes at c7880000
Jun 18 13:58:06 argo kernel: i810_audio: prog_dmabuf, sample rate = 40811, format = 3,
Jun 18 13:58:06 argo kernel: ^Inumfrag = 32, fragsize = 2048 dmasize = 65536
Jun 18 13:58:06 argo kernel: SNDCTL_DSP_GETBLKSIZE 4096
Jun 18 13:58:07 argo kernel: i810_audio: i810_write called, count = 3788
Jun 18 13:58:07 argo kernel: i810_audio: i810_ioctl, arg=0x0, cmd=SNDCTL_DSP_GETOSPACE 61748, 4096, 15, 16
Jun 18 13:58:07 argo kernel: i810_audio: i810_write called, count = 3788
Jun 18 13:58:07 argo kernel: i810_audio: i810_ioctl, arg=0xf, cmd=SNDCTL_DSP_GETOSPACE 60080, 4096, 14, 16
Jun 18 13:58:07 argo kernel: i810_audio: i810_write called, count = 3788
Jun 18 13:58:07 argo kernel: i810_audio: i810_ioctl, arg=0xe, cmd=SNDCTL_DSP_GETOSPACE 56340, 4096, 13, 16

[snip]

Jun 18 13:58:07 argo kernel: i810_audio: i810_write called, count = 3788
Jun 18 13:58:07 argo kernel: i810_audio: i810_ioctl, arg=0x1, cmd=SNDCTL_DSP_GETOSPACE 3732, 4096, 0, 16
Jun 18 13:58:07 argo kernel: i810_audio: i810_write called, count = 3788
Jun 18 13:58:07 argo kernel: i810_audio: i810_ioctl, arg=0x0, cmd=SNDCTL_DSP_GETOSPACE 4074, 4096, 0, 16
Jun 18 13:58:07 argo kernel: i810_audio: i810_write called, count = 3788
Jun 18 13:58:07 argo kernel: i810_audio: i810_ioctl, arg=0x0, cmd=SNDCTL_DSP_GETOSPACE 286, 4096, 0, 16
Jun 18 13:58:07 argo kernel: i810_audio: i810_write called, count = 3788
Jun 18 13:58:07 argo kernel: i810_audio: playback schedule timeout, dmasz 65536 fragsz 2048 count 65536 hwptr 4294842946 swptr 6722
Jun 18 13:58:38 argo last message repeated 77 times
Jun 18 13:59:39 argo last message repeated 152 times
Jun 18 13:59:40 argo last message repeated 4 times

It goes on until I kill the app, then it says:

Jun 18 13:59:42 argo kernel: i810_audio: drain_dac, dma timeout?

Any idea(s), suggestions ...

Thank you

--
Delio

[..]

What a co-incidence. I just hit this problem a few days ago.

The problem here is that:
1. the dma buffer drains to zero.
2. interrupt handler set LVI to CIV.
3. app write more than a buffer size of data to dma buffer.
4. LVI is un-changed!

There's a kludgey work-around I used, (never use more than 31 segments of the DMA buffer). (I.e. never use the last dmabuf->fragsize of the dma buffer). This cures the hang but it isn't an optimal solutions.

@@ -1194,6 +1194,10 @@

		cnt = dmabuf->dmasize - swptr;
		if(cnt > (dmabuf->dmasize - dmabuf->count))
			cnt = dmabuf->dmasize - dmabuf->count;

+
+ if (cnt >= dmabuf->fragsize && (dmabuf->count + cnt) >= dmabuf->dmasize)
+ cnt -= dmabuf->fragsize;
+

		spin_unlock_irqrestore(&state->card->lock, flags);

		if (cnt > count)

A better fix _may_ be to set CIV to LVI instead of the other way around. (This assumes CIV is writeable). No testing at all; may not be a fix.

Something like:

diff -u i810_audio.c.old i810_audio.c
@@ -807,11 +807,11 @@

	 * means no data on read, handle appropriately
	 */
	if(!rec && dmabuf->count == 0) {
-		outb(inb(port+OFF_CIV),port+OFF_LVI);
+		outb(inb(port+OFF_LVI),port+OFF_CIV);
		return;
	}
	if(rec && dmabuf->count == dmabuf->dmasize) {
-		outb(inb(port+OFF_CIV),port+OFF_LVI);
+		outb(inb(port+OFF_LVI),port+OFF_CIV);
		return;
	}
	/* swptr - 1 is the tail of our transfer */

but with testing and a glance at the docs. :)

Michael.

Thank you, but sadly the cure doesn't work for me (it just takes more time to die) I tried it against 2.4.5 tree.
I'll take a look at the specs later and hope for inspiration :)

Regards

--
Delio