Re: [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

Re: [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Rene Herman]

On 09-03-08 16:34, Ivan Kokshaysky wrote:

> On Fri, Mar 07, 2008 at 09:58:28PM -0600, Bob Tracy wrote:
>> (1) Using the sox-based "play" command to play a short ".wav" file
>>     results in the file being played approx. 1.5 times, i.e., it plays
>>     all the way through, then restarts from the beginning and quits
>>     somewhere in the middle of the second playback.  At least the
>>     sound doesn't seem distorted...
>>
>> (2) Using "mpg123" results in silence at first, then after about 30
>>     seconds, a tight loop of random repeating sound (doesn't sound like
>>     part of the mp3 file, but it's probably derived from it :-)) until
>>     the process is forcibly killed.
> 
> Sounds like a DMA screwup. However, I'm pretty sure that it's not a
> generic ALSA problem with ISA DMA, as my good old GUS MAX still works
> perfectly on lx164 (machine that is very similar to your miata) as
> I checked yesterday with patched 2.6.25-rc4. :-)
> 
>> I have to hit <ctrl>C twice to interrupt playback.
>>
>> /proc/asound/cards looks normal:
>>
>>  0 [ES1888         ]: ES1888 - ESS AudioDrive ES1888
>>                       ESS AudioDrive ES1888 at 0x220, irq 5, dma1 1, dma2 5
> 
> I wonder if it still works on x86 - perhaps you ought to ask ALSA folks.
> I'll search my machine room next week - I recall that there were a dozen
> of old ISA soundcards, maybe there is some es18xx stuff, but chances
> are slim...

Missed the original mssage, adding alsa-devel. I have a few dozen es18xx's 
cards but no Alpha's. Am compiling a 2.6.25-rc4 onto an x86 test box now.

Rene.

Re: [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Rene Herman]

On 10-03-08 08:34, Michael Cree wrote:

> Bob Tracy wrote:

>> Supposedly with the ES1888, dma1 is for capture, dma2 is for playback. 
>> dma2 == 5 is a 16-bit channel, yes?  That could explain much...

It is, but what would it explain? You're only having playback problems, right?

>>
>> As for the values "chosen" for dma1 and dma2, they are the ones that
>>  keep showing up in the Alpha sound "howto" postings/documents.
> 
> Running 'show config' in SRM on my Alphas (PWS500au and XP1000) reveals
> the settings (except possibly for mpu_port) for the ESS1888 sound chip.
> I recall that they are as reported in Alpha sound howtos.

Can it be forced to use dma2=0 (an 8-bit channel, and the usual capture 
channel on es18xx)? However, that might not be the issue anyway:

> I hadn't been using the ESS1888 for awhile, but have just tried it out
> since you reported problems.  I am running kernel 2.6.24.3 and Debian
> testing on the XP1000.  I tried playing a number of wav files with
> alsa's aplay, sox's play and with mocp.  I found that aplay and mocp
> worked reliably through the ESS1888.  Sox's play on some files did play
> back a small extra segment of the file - particularly on short files and
> usually some section near the end of the file - once it had completed
> playing the file once; maybe this is what you are also observing. 

This sounds very suspiciously like a difference with playing through the 
native ALSA interface and the OSS emulaion. Could you and/or Bob confirm 
that sox is using the OSS emulation and not ALSA natively?

I could very well imagine the ALSA OSS emulation being broken on Alpha. I 
doubt any of teh developers has an Alpha. And if aplay works correctly this 
seems very likely.

"sox" _can_ use ALSA natively as well by the way (see manpage for the 
version you have installed).

> More onerously, my testing eventually ended in a complete system lock up!
> I ran play (or was it aplay - sorry can't remember now)

Vital if play is using the OSS interface...

> and the system locked up. Got a response with ping across the network but
> couldn't log in via ssh.  Have been playing mplayer through the ESS1888
> for the last couple of days (don't like it though - the sound quality of
> the ESS1888 is not good enough for my ears) and haven't had another one
> of those lockups since.

Mmm.

Rene.

Re: [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Rene Herman]

On 10-03-08 16:17, Rene Herman wrote:

> On 10-03-08 08:34, Michael Cree wrote:
> 
>> Bob Tracy wrote:
> 
>>> Supposedly with the ES1888, dma1 is for capture, dma2 is for 
>>> playback. dma2 == 5 is a 16-bit channel, yes?  That could explain 
>>> much...
> 
> It is, but what would it explain? You're only having playback problems, 
> right?
> 
>>>
>>> As for the values "chosen" for dma1 and dma2, they are the ones that
>>>  keep showing up in the Alpha sound "howto" postings/documents.
>>
>> Running 'show config' in SRM on my Alphas (PWS500au and XP1000) reveals
>> the settings (except possibly for mpu_port) for the ESS1888 sound chip.
>> I recall that they are as reported in Alpha sound howtos.
> 
> Can it be forced to use dma2=0 (an 8-bit channel, and the usual capture 
> channel on es18xx)? However, that might not be the issue anyway:
> 
>> I hadn't been using the ESS1888 for awhile, but have just tried it out
>> since you reported problems.  I am running kernel 2.6.24.3 and Debian
>> testing on the XP1000.  I tried playing a number of wav files with
>> alsa's aplay, sox's play and with mocp.  I found that aplay and mocp
>> worked reliably through the ESS1888.  Sox's play on some files did play
>> back a small extra segment of the file - particularly on short files and
>> usually some section near the end of the file - once it had completed
>> playing the file once; maybe this is what you are also observing. 
> 
> This sounds very suspiciously like a difference with playing through the 
> native ALSA interface and the OSS emulaion. Could you and/or Bob confirm 
> that sox is using the OSS emulation and not ALSA natively?

Bob is spam-blocking me (sigh...) so perhaps you can make sure he sees this.

> I could very well imagine the ALSA OSS emulation being broken on Alpha. 
> I doubt any of teh developers has an Alpha. And if aplay works correctly 
> this seems very likely.
> 
> "sox" _can_ use ALSA natively as well by the way (see manpage for the 
> version you have installed).
> 
>> More onerously, my testing eventually ended in a complete system lock up!
>> I ran play (or was it aplay - sorry can't remember now)
> 
> Vital if play is using the OSS interface...
> 
>> and the system locked up. Got a response with ping across the network but
>> couldn't log in via ssh.  Have been playing mplayer through the ESS1888
>> for the last couple of days (don't like it though - the sound quality of
>> the ESS1888 is not good enough for my ears) and haven't had another one
>> of those lockups since.
> 
> Mmm.

Rene

Re: [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Bob Tracy]

Rene Herman wrote:
> > Bob Tracy wrote:
> 
> >> Supposedly with the ES1888, dma1 is for capture, dma2 is for playback. 
> >> dma2 == 5 is a 16-bit channel, yes?  That could explain much...
> 
> It is, but what would it explain? You're only having playback problems, right?

dma2 is for playback, I'm having playback problems, dma2 == 5 is a
a 16-bit channel, and 16-bit DMA is an issue with the es18xx driver
(according to the comment near the top of the file).

> Can it be forced to use dma2=0 (an 8-bit channel, and the usual capture 
> channel on es18xx)? However, that might not be the issue anyway:

I'll try a few things like dma2 == dma1, and setting dma2 to an 8-bit
channel, but I think the various configuration parameters are hard-wired
on the Alpha (not PnP).

> This sounds very suspiciously like a difference with playing through the 
> native ALSA interface and the OSS emulaion. Could you and/or Bob confirm 
> that sox is using the OSS emulation and not ALSA natively?
> 
> I could very well imagine the ALSA OSS emulation being broken on Alpha. I 
> doubt any of teh developers has an Alpha. And if aplay works correctly this 
> seems very likely.

I'll see if I can verify whether it's a native ALSA vs. OSS emulation
issue.

The local version of sox (Debian 12.7.9-1) contains a library dependency
on libasound.so.2, and a "strings" on the binary yields "ALSA_0.9.0rc4"
as well as several ALSA error message strings.  However, output by
default goes to /dev/dsp (major 14, minor 3), which is definitely OSS.

-- 
------------------------------------------------------------------------
Bob Tracy          |  "I was a beta tester for dirt.  They never did
rct@frus.com       |   get all the bugs out." - Steve McGrew on /.
------------------------------------------------------------------------

Re: [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Rene Herman]

On 10-03-08 17:21, Bob Tracy wrote:

> Rene Herman wrote:

>>> Bob Tracy wrote:
>>>> Supposedly with the ES1888, dma1 is for capture, dma2 is for playback. 
>>>> dma2 == 5 is a 16-bit channel, yes?  That could explain much...
>> It is, but what would it explain? You're only having playback problems, right?
> 
> dma2 is for playback, I'm having playback problems, dma2 == 5 is a
> a 16-bit channel, and 16-bit DMA is an issue with the es18xx driver
> (according to the comment near the top of the file).

Yes, never mind, misread.

>> Can it be forced to use dma2=0 (an 8-bit channel, and the usual capture 
>> channel on es18xx)? However, that might not be the issue anyway:
> 
> I'll try a few things like dma2 == dma1, and setting dma2 to an 8-bit
> channel, but I think the various configuration parameters are hard-wired
> on the Alpha (not PnP).

Settable through BIOS perhaps? But anyways, if it used to work, it should 
work and I really suspect it's just a matter of a  broken OSS emulation on 
alpha anyways. In fact, I fairly distinctly remember this being an issue not 
too long ago but google is coming up empty...

Takashi? Wasn't there an OSS emulation on Alpha thing a while ago?

>> This sounds very suspiciously like a difference with playing through the 
>> native ALSA interface and the OSS emulaion. Could you and/or Bob confirm 
>> that sox is using the OSS emulation and not ALSA natively?
>>
>> I could very well imagine the ALSA OSS emulation being broken on Alpha. I 
>> doubt any of teh developers has an Alpha. And if aplay works correctly this 
>> seems very likely.
> 
> I'll see if I can verify whether it's a native ALSA vs. OSS emulation
> issue.
> 
> The local version of sox (Debian 12.7.9-1) contains a library dependency
> on libasound.so.2, and a "strings" on the binary yields "ALSA_0.9.0rc4"
> as well as several ALSA error message strings.  However, output by
> default goes to /dev/dsp (major 14, minor 3), which is definitely OSS.

That's an expected string and very likely doesn't mean you have a 0.9.0-rc4 
alsa-lib installed. "strings [ ... ] | grep ^ALSA_" probably shows a few 
later versions as well. But if the problem's the (kernel) OSS emulation then 
userspace dopesn't matter anyway.

You seem to have sox installed, so try

$ sox foo.wav -t alsa default

and

$ sox foo.wav -t ossdsp /dev/dsp

to have it play through the ALSA and OSS interfaces, respectively.

Rene.

Re: [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Takashi Iwai]

At Mon, 10 Mar 2008 17:56:49 +0100,
Rene Herman wrote:
> 
> >> Can it be forced to use dma2=0 (an 8-bit channel, and the usual capture 
> >> channel on es18xx)? However, that might not be the issue anyway:
> > 
> > I'll try a few things like dma2 == dma1, and setting dma2 to an 8-bit
> > channel, but I think the various configuration parameters are hard-wired
> > on the Alpha (not PnP).
> 
> Settable through BIOS perhaps? But anyways, if it used to work, it should 
> work and I really suspect it's just a matter of a  broken OSS emulation on 
> alpha anyways. In fact, I fairly distinctly remember this being an issue not 
> too long ago but google is coming up empty...
> 
> Takashi? Wasn't there an OSS emulation on Alpha thing a while ago?

No, I don't know of.  OSS emulation code is written fairly
independently from architectures.  Maybe just a missing
CONFIG_SND_PCM_PLUGINS kconfig?


Takashi

Re: [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Rene Herman]

On 10-03-08 23:22, Bob Tracy wrote:

> Rene Herman wrote:

>> Bob? How short are "short" wav files by the way?
> 
> The one I was using for testing is 50,272 bytes. A slightly longer file 
> that exhibits "more exotic" looping behavior is 97,898 bytes (just a bit 
> over 6 seconds of audio). I'll send you the shorter file under separate 
> cover.

Thanks. No problems here, using either the ALSA or OSS interfaces. Have been 
busy switching cards -- I have no hardware that can use anything other than 
DMA 0, 1 or 3. First test is to see if it's ALSA or just the OSS emulation 
though...

Rene.

Re: [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Bob Tracy]

Rene Herman wrote:
> You seem to have sox installed, so try
> 
> $ sox foo.wav -t alsa default

Playback results in infinite loop over the first quarter second or so
of audio.  Using "aplay" results in same looping behavior over a longer
segment of audio -- maybe a half second.

> and
> 
> $ sox foo.wav -t ossdsp /dev/dsp

Identical results to using "play" (as expected): for the 50K ".wav"
file, I hear the entire file approx. 1.8 times.

I tried a few rmmod/insmod cycles with different values for dma2.
Results as follows:

(a) dma2=1 (== dma1): no change
(b) dma2 option omitted : no change
(c) dma2=-1 : probe failed

-- 
------------------------------------------------------------------------
Bob Tracy          |  "I was a beta tester for dirt.  They never did
rct@frus.com       |   get all the bugs out." - Steve McGrew on /.
------------------------------------------------------------------------

Re: [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Bob Tracy]

Rene Herman wrote:
> This is behaviour consistent with the IRQ being dead ...
>
> I suppose it used to work and I suppose the behaviour 
> you are describing above is 100% repeatable?

I can't tell you exactly *when* it used to work, or even *if* it did
with 2.6 kernels.  I'll try to explain...

Sometime back in the 2.6.14 to 2.6.16 timeframe there was an issue with
the ALSA driver not recognizing interrupts (causing looping).  Tyson
Whitehead had put together a patch for the interrupt problem that worked
for him, but not for me or Michael.  One workaround back then was using
the snd-sb8 driver that supports only one DMA channel (half-duplex
operation) anyway: that was a reliable workaround, and may be what I'm
remembering for the "it used to work" case.  I can't find any reliable
evidence that I've *ever* been able to use the ES1888 with its proper
driver under ALSA with 2.6 kernels.  As far as Tyson's patch, I know
he reported it upstream to the ALSA developers, but I saw no followup
communication from either Tyson or the developers.

> Given that you can use aplay -- probably no difference with "aplay -M" ?

I'll give it a shot.

> To get to the bottom of this we might need to get a specific failed version 
> (for readers, it's not been verified that this is a regression since 2.6.24) 
> but we can try to get lucky first.

I'm beginning to think this is *not* a regression, but merely a long-
standing ALSA issue that was never addressed.  I would be fine with
reclassifying this as an ALSA bug and dropping linux-kernel from the
discussion.

> Okay. (tests) seem to at least confirm it's not the 16-bit DMA.

As far as how to proceed from here, I'm certain things were broken in
2.6.1[4-6].  I could try various later releases between .16 and .24 to
see if snd-es18xx worked for any of those, but I think the answer will
be "no."  I think a useful test would be to see if "snd-sb8" works in
2.6.25-rcX, which would at least narrow things down a bit.

-- 
------------------------------------------------------------------------
Bob Tracy          |  "I was a beta tester for dirt.  They never did
rct@frus.com       |   get all the bugs out." - Steve McGrew on /.
------------------------------------------------------------------------

Re: [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Bob Tracy]

Well, I built a 2.6.22 kernel last night, and in tests this morning
there's no difference relative to the ALSA behavior seen in 2.6.25-rc4.
Since the question came up (or was strongly implied), I took the time to
check the status of IRQ 5 in /proc/interrupts, and while it shows up as
assigned to the sound card, no interrupts are being seen/processed by
the es18xx driver.  When I remove the snd-es18xx module and install the
snd-sb8 module with the same parameters (other than there's no second
DMA channel), the /proc/interrupts counter for IRQ 5 increments as
expected when playing sound files.

At this point I'm pretty sure the es18xx issue isn't a regression: it's
"just" a bug that has been around since I first loaded 2.6.X on my
Alpha.

-- 
------------------------------------------------------------------------
Bob Tracy          |  "I was a beta tester for dirt.  They never did
rct@frus.com       |   get all the bugs out." - Steve McGrew on /.
------------------------------------------------------------------------

Re: [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Rene Herman]

On 12-03-08 15:40, Bob Tracy wrote:

> Well, I built a 2.6.22 kernel last night, and in tests this morning
> there's no difference relative to the ALSA behavior seen in 2.6.25-rc4.

Okay. If someone is tracking this as a 2.6.25 regresion, it can be stricken 
of that list.

> Since the question came up (or was strongly implied), I took the time to
> check the status of IRQ 5 in /proc/interrupts, and while it shows up as
> assigned to the sound card, no interrupts are being seen/processed by
> the es18xx driver.

That is indeed what it soundeed like, or the first bit at least.

> When I remove the snd-es18xx module and install the snd-sb8 module with
> the same parameters (other than there's no second DMA channel), the
> /proc/interrupts counter for IRQ 5 increments as expected when playing
> sound files.

What does cat /proc/config.gz | grep CONFIG_ALPHA_ say? Miuchael, and for 
you? For some Alpha configs, arch/alpha/kernel/es1888.c is compiled and for 
some not. I expect for you (Bob) it's compiled in? And Michael?

Rene.

Re: [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Rene Herman]

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

On 12-03-08 21:31, Bob Tracy wrote:

> Here is the requested list of CONFIG_ALPHA_* items for the
> 2.6.25-rc4+iommu_patch kernel with support for snd-es18xx and snd-sb8:
> 
> CONFIG_ALPHA=y
> CONFIG_ALPHA_MIATA=y
> CONFIG_ALPHA_EV5=y
> CONFIG_ALPHA_CIA=y
> CONFIG_ALPHA_EV56=y
> CONFIG_ALPHA_PYXIS=y
> CONFIG_ALPHA_SRM=y
> CONFIG_ALPHA_LEGACY_START_ADDRESS=y
> 
>>From arch/alpha/kernel/Makefile, obj-${CONFIG_ALPHA_MIATA} adds es1888.o
> as a built-in object, so yes, it's built-in.

Okay, and applying the attached just makes your sound completely dead in the 
water?

> I never noticed the init support for the ES1888 chip before...  The code
> appears to set up DMA channel 1, but does not mention anything about the
> second 16-bit DMA channel.

Indeed. It seems to init it as an sb8...

Rene.


[-- Attachment #2: alpha_miata_no_es1888.diff --]
[-- Type: text/plain, Size: 1002 bytes --]

diff --git a/arch/alpha/kernel/Makefile b/arch/alpha/kernel/Makefile
index dccf052..f53a3a2 100644
--- a/arch/alpha/kernel/Makefile
+++ b/arch/alpha/kernel/Makefile
@@ -77,7 +77,7 @@ obj-$(CONFIG_ALPHA_EIGER)	+= sys_eiger.o irq_i8259.o
 obj-$(CONFIG_ALPHA_JENSEN)	+= sys_jensen.o pci-noop.o irq_i8259.o
 obj-$(CONFIG_ALPHA_MARVEL)	+= sys_marvel.o 
 obj-$(CONFIG_ALPHA_MIATA)	+= sys_miata.o irq_pyxis.o irq_i8259.o \
-				   es1888.o smc37c669.o
+				   smc37c669.o
 obj-$(CONFIG_ALPHA_MIKASA)	+= sys_mikasa.o irq_i8259.o irq_srm.o
 obj-$(CONFIG_ALPHA_NAUTILUS)	+= sys_nautilus.o irq_i8259.o irq_srm.o
 obj-$(CONFIG_ALPHA_NORITAKE)	+= sys_noritake.o irq_i8259.o
diff --git a/arch/alpha/kernel/sys_miata.c b/arch/alpha/kernel/sys_miata.c
index 910b43c..5601d7e 100644
--- a/arch/alpha/kernel/sys_miata.c
+++ b/arch/alpha/kernel/sys_miata.c
@@ -236,7 +236,6 @@ miata_init_pci(void)
 {
 	cia_init_pci();
 	SMC669_Init(0); /* it might be a GL (fails harmlessly if not) */
-	es1888_init();
 }
 
 static void

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Bob Tracy]

Rene Herman wrote:
> Okay, and applying the attached just makes your sound completely dead in the 
> water?
> (patch to delete es1888_init function)

Oddly enough, the patch had no effect whatsoever (at least with the
ALSA drivers: I didn't try building a kernel with the OSS "sb" driver).
Just to make sure I wasn't "benefiting" from initialization inherited
from a prior boot, I even powered-down the machine for 30 seconds
before booting on the new kernel.  snd-sb8 still works, and snd-es18xx
is still broken (in exactly the same way as before).

-- 
------------------------------------------------------------------------
Bob Tracy          |  "I was a beta tester for dirt.  They never did
rct@frus.com       |   get all the bugs out." - Steve McGrew on /.
------------------------------------------------------------------------

Re: [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Bob Tracy]

rct wrote:
> Rene Herman wrote:
> > Okay, and applying the attached just makes your sound completely dead in the 
> > water?
> > (patch to remove es1888_init from a Miata build omitted)
> 
> I'll try a build with the old OSS "sb" driver, and if that works ok, we
> may be able to do away with es1888_init() on the Miata.  Tyson -- I
> think you have a Miata if I'm remembering correctly: can you confirm
> these observations?

Quick followup: OSS "sb" driver works fine without es1888_init().

-- 
------------------------------------------------------------------------
Bob Tracy          |  "I was a beta tester for dirt.  They never did
rct@frus.com       |   get all the bugs out." - Steve McGrew on /.
------------------------------------------------------------------------

Re: [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Rene Herman]

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

On 13-03-08 05:24, Bob Tracy wrote:

> Rene Herman wrote:
>> Okay, and applying the attached just makes your sound completely dead in the 
>> water?
>> (patch to delete es1888_init function)
> 
> Oddly enough, the patch had no effect whatsoever (at least with the
> ALSA drivers: I didn't try building a kernel with the OSS "sb" driver).
> Just to make sure I wasn't "benefiting" from initialization inherited
> from a prior boot, I even powered-down the machine for 30 seconds
> before booting on the new kernel.  snd-sb8 still works, and snd-es18xx
> is still broken (in exactly the same way as before).

Okay, thought I'd stare at this thing a bit -- there's no specific 1888 
documentation available it seems but I did notice something in the 1878 
datasheet which might mean something. The docs says that bits 0-1 are don't 
care for DMA but don't for IRQ, so could it possibly be as simple as the 
attached?

1878 sheet doesn't document register 0x7f, it seems...

Assuming it's not just this, this thing is going to require quite a bit of 
trial and error and without the hardware this will be troublesome. I expect 
this is not it, since the arch init code also doesn't care about bit 0 when 
setting that same register for IRQ 5.

If this is not it -- I'd try s/0x50/0x10/ in that line, even completely 
commenting out the IRQ setting line (with the arch code built in) and just 
generally frolic around 'till something blows up...

Rene.


[-- Attachment #2: es18xx_trial_and_error.diff --]
[-- Type: text/plain, Size: 1273 bytes --]

diff --git a/sound/isa/es18xx.c b/sound/isa/es18xx.c
index 90498e4..71d1b96 100644
--- a/sound/isa/es18xx.c
+++ b/sound/isa/es18xx.c
@@ -1449,16 +1449,16 @@ static int __devinit snd_es18xx_initialize(struct snd_es18xx *chip)
 		switch (chip->irq) {
 		case 2:
 		case 9:
-			irqmask = 0;
+			irqmask = 0x0;
 			break;
 		case 5:
-			irqmask = 1;
+			irqmask = 0x5;
 			break;
 		case 7:
-			irqmask = 2;
+			irqmask = 0xa;
 			break;
 		case 10:
-			irqmask = 3;
+			irqmask = 0xf;
 			break;
 		default:
 			snd_printk(KERN_ERR "invalid irq %d\n", chip->irq);
@@ -1497,7 +1497,7 @@ static int __devinit snd_es18xx_initialize(struct snd_es18xx *chip)
 		}
 
 		/* Enable and set Audio 1 IRQ */
-		snd_es18xx_write(chip, 0xB1, 0x50 | (irqmask << 2));
+		snd_es18xx_write(chip, 0xB1, 0x50 | irqmask);
 		/* Enable and set Audio 1 DMA */
 		snd_es18xx_write(chip, 0xB2, 0x50 | (dma1mask << 2));
 		/* Set Audio 2 DMA */
@@ -1513,7 +1513,9 @@ static int __devinit snd_es18xx_initialize(struct snd_es18xx *chip)
 			   FM enabled */
 			snd_es18xx_mixer_write(chip, 0x40, 0x43 | (chip->mpu_port & 0xf0) >> 1);
 		}
+#if 0
 		snd_es18xx_mixer_write(chip, 0x7f, ((irqmask + 1) << 1) | 0x01);
+#endif
 	}
 	if (chip->caps & ES18XX_NEW_RATE) {
 		/* Change behaviour of register A1

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Tyson Whitehead]

Takashi Iwai wrote:
> At Fri, 14 Mar 2008 21:18:19 -0400,
> 
>>  Even 
>> then, though, I believe it still only works in 8bit mode.
> 
> Maybe the problem is in a different place, then...

It certainly doesn't work at all without it.  It is definetly not 
managing to figure out that the generated interupt is for itself.

> ---
> 
> diff -r 82e6201fc907 sound/isa/es18xx.c
> --- a/sound/isa/es18xx.c	Mon Mar 17 14:36:24 2008 +0100
> +++ b/sound/isa/es18xx.c	Mon Mar 17 17:32:59 2008 +0100
> @@ -765,9 +765,10 @@ static irqreturn_t snd_es18xx_interrupt(
>  		/* Read Interrupt status */
>  		status = snd_es18xx_mixer_read(chip, 0x7f) >> 4;
>  	}
> -#if 0
> -	else {
> -		status = 0;
> +
> +#ifdef CONFIG_ALPHA
> +	if (!(status & (AUDIO1_IRQ | AUDIO2_IRQ))) {
> +		/* status = 0; */
>  		if (inb(chip->port + 0x0C) & 0x01)
>  			status |= AUDIO1_IRQ;
>  		if (snd_es18xx_mixer_read(chip, 0x7A) & 0x80)
> @@ -777,7 +778,6 @@ static irqreturn_t snd_es18xx_interrupt(
>  			status |= HWV_IRQ;
>  	}
>  #endif
> -
>  	/* Audio 1 & Audio 2 */
>          if (status & AUDIO2_IRQ) {
>                  if (chip->active & DAC2)

This looks like it should accomplish the same thing (assuming not bits 
get set in status on the initial attempt to read it), without affecting 
other platforms and possible the alpha if anyone has a card that just 
works for whatever reason.  A better patch all around.  : )

Cheers!  -Tyson

PS:  I've managed to recover my disks, and the machine is compiling 
2.25-rc5 even as I write.

Re: [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Rene Herman]

On 18-03-08 14:55, Tyson Whitehead wrote:

>> Could you attach that patch? Links I'm finding are to

Thanks, interesting. I see Bob already tried this without luck though. Also 
see you guys both have a ES1888, so somewhat odd.

Rene.

Re: [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Michael Cree]

Rene Herman wrote:
> On 23-03-08 11:40, Michael Cree wrote:
> 
>> I have been able to run some tests.
>>
>> The es18xx and cmipci drivers work fine on the XP1000.  I base that 
>> observation on using a variety of software, such as mplayer and mocp, 
>> through both sound cards, mainly through oss, but also have tried 
>> alsa, over the last year for es18xx and for the last three or four 
>> months for cmipci.  (I have noted that the M-Audio Revolution 7.1 
>> sound card with the ice1724 driver fails to work and causes system 
>> crashes on the XP1000,
>> but that's a different discussion).
> 
> Was there ever a follow-up in that thread? :
> 
> http://mailman.alsa-project.org/pipermail/alsa-devel/2008-March/006513.html

Takashi replied with a suggestion to disable MMAP in the ice1724 driver. 
  I have been preoccupied with other things for the last couple of weeks 
so haven't had a chance to try it out.

> There's a patch attached that disables mmap on MIATA. You and Bob seem 
> to be experiencing problems of a different nature (or severity at the 
> least) but for both of you it would be good to hear what applying this 
> and then playing using "aplay -D hw foo.wav" (on the miata systems, 
> ofcourse) brings.

I have applied the patch to the PWS600au.  Sound now works.  I can play 
8bit and 16bit sound files through the es1887 and the C-Media CM8738. 
They are both working fine.  I managed to get a 32bit sound file to play 
through the M-Audio Revolution too. (Though another 32bit sound file 
just produces silence through the M-Audio Rev. Haven't been able to 
establish why - the file looks fine to me.)  Repeated playing of files 
doesn't cause any problems.

I can't get sox's play to work (reports no mmap support, which is, of 
course, quite true).  I don't know how to tell sox to use the equivalent 
of alsa's hw device.  So I can't do the test on short files that Bob was 
  performing.

At this stage I've run out of time to test the M-Audio Rev in the XP1000 
and see if the MMAP disable patch help there.

Michael.

Re: [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Rene Herman]

On 25-03-08 02:22, Michael Cree wrote:

>> should do it. Here's a file Bob passed me as a problematic one. 8-bit, 
>> 11025, mono:
>>
>> http://members.home.nl/rene.herman/asskickd.wav
> 
> Right, got that.  On the PWS600au it shows the same problems that Bob 
> describes!  When I play it with aplay (through the es1887) I get the 
> last "pal" repeated at the end.  When I play it with sox (also through 
> the es1887) I get the words "current event" repeated at the end.
> 
> Playing through the CM8738 also repeats the words "current event" at the 
> end when playing with sox.  But using aplay through the CM8738 only 
> results in silence and aplay hangs.  A ctrl-c successfully breaks it.

Lovely, so different problem between you and Bob. When you (either of you) 
have some time for it again, could you try:

$ sox asskickd.wav -w -t alsa hw
$ sox asskickd.wav -w -r 44100 -t alsa hw
$ sox asskickd.wav -w -r 44100 -c 2 -t alsa hw

and report if things start working? First transforms into 16-bit, second 
16-bit and 44100 rate, third 16-bit, 44100 rate, stereo.

> I suspect you are right - the symptoms I have observed (complete system 
> crashes) are separate from what Bob observes.  One question I have is 
> what is different about Bob's set up that enables the sound to work with 
> mmap?

Not a clue. Takashi -- is it possible that Bob wasn't using mmap to being 
with if he didn't do anything specific to not do so?

And perhaps you guys have firmware settable options that touch that area of 
coherent DMA? Maybe even a specific chipset bug on his machine? No idea how 
different/similar your machines are...

> On the XP1000 (which has an unmodified kernel 2.6.24.3) I managed to 
> play the sound file once with aplay through the es1887 (and it repeated 
> "pal" at the end).  Then I tried using sox and complete silence 
> resulted.   No,  it's just playing back at the wrong rate - everything 
> is sounding slow and extremely flat - the silence is just the artefact 
> of a little bit of silence at the start of the file being played at far 
> too a slow sample rate.  Even other client programs are affected - mocp 
> is playing back music at a horrendously slow sample rate. Yuk. Hopefully 
> a rmmod es1887 might fix that - but I can't test it to I send this 
> message and shut down X.
> 
> Anyway I really must start marking that pile of assignments I told the 
> students that I would have done by tomorrow.  Further testing will have 
> to wait to later this week.

No rush. Thanks for the current amount of testing already.

Rene.

Re: [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Bob Tracy]

Ok...  I'm back.  Replies to the long queue of messages will be sent as
I have time to try the various patches.

Tyson Whitehead wrote:
> Takashi Iwai wrote:
> > ---
> > 
> > diff -r 82e6201fc907 sound/isa/es18xx.c
> > --- a/sound/isa/es18xx.c	Mon Mar 17 14:36:24 2008 +0100
> > +++ b/sound/isa/es18xx.c	Mon Mar 17 17:32:59 2008 +0100
> > @@ -765,9 +765,10 @@ static irqreturn_t snd_es18xx_interrupt(
> >  		/* Read Interrupt status */
> >  		status = snd_es18xx_mixer_read(chip, 0x7f) >> 4;
> >  	}
> > -#if 0
> > -	else {
> > -		status = 0;
> > +
> > +#ifdef CONFIG_ALPHA
> > +	if (!(status & (AUDIO1_IRQ | AUDIO2_IRQ))) {
> > +		/* status = 0; */
> >  		if (inb(chip->port + 0x0C) & 0x01)
> >  			status |= AUDIO1_IRQ;
> >  		if (snd_es18xx_mixer_read(chip, 0x7A) & 0x80)
> > @@ -777,7 +778,6 @@ static irqreturn_t snd_es18xx_interrupt(
> >  			status |= HWV_IRQ;
> >  	}
> >  #endif
> > -
> >  	/* Audio 1 & Audio 2 */
> >          if (status & AUDIO2_IRQ) {
> >                  if (chip->active & DAC2)
> 
> This looks like it should accomplish the same thing (assuming not bits 
> get set in status on the initial attempt to read it), without affecting 
> other platforms and possible the alpha if anyone has a card that just 
> works for whatever reason.  A better patch all around.  : )

Unfortunately, this does nothing to fix the ES1888 on my system.  Same
broken behavior as described previously.  I'll try something else in
the queue later today after I get some sleep...

-- 
------------------------------------------------------------------------
Bob Tracy          |  "I was a beta tester for dirt.  They never did
rct@frus.com       |   get all the bugs out." - Steve McGrew on /.
------------------------------------------------------------------------

Re: [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Bob Tracy]

Rene Herman wrote:
> There's a patch attached that disables mmap on MIATA. You and Bob seem to be 
> experiencing problems of a different nature (or severity at the least) but 
> for both of you it would be good to hear what applying this and then playing 
> using "aplay -D hw foo.wav" (on the miata systems, ofcourse) brings.
> 
> (...)
> 
> The mmap thing is sort of the last hickup to be expected from me -- having 
> no Alpha machines and with trouble not isolated to a specific driver nor 
> Alpha model, this would at that point ideally want someone with some more 
> specific Alpha insights to step in.
> 
> (...)
> 
> diff --git a/include/sound/asound.h b/include/sound/asound.h
> index 3eaf155..e3b9c2d 100644
> --- a/include/sound/asound.h
> +++ b/include/sound/asound.h
> @@ -241,8 +241,14 @@ typedef int __bitwise snd_pcm_subformat_t;
>  #define	SNDRV_PCM_SUBFORMAT_STD		((__force snd_pcm_subformat_t) 0)
>  #define	SNDRV_PCM_SUBFORMAT_LAST	SNDRV_PCM_SUBFORMAT_STD
>  
> +#ifdef CONFIG_ALPHA_MIATA
> +#define SNDRV_PCM_INFO_MMAP		0		/* the useful comment goes here */
> +#define SNDRV_PCM_INFO_MMAP_VALID	0
> +#else
>  #define SNDRV_PCM_INFO_MMAP		0x00000001	/* hardware supports mmap */
>  #define SNDRV_PCM_INFO_MMAP_VALID	0x00000002	/* period data are valid during transfer */
> +#endif
> +
>  #define SNDRV_PCM_INFO_DOUBLE		0x00000004	/* Double buffering needed for PCM start/stop */
>  #define SNDRV_PCM_INFO_BATCH		0x00000010	/* double buffering */
>  #define SNDRV_PCM_INFO_INTERLEAVED	0x00000100	/* channels are interleaved */

Late this evening I starting building a kernel with the above patch
applied.  It should be ready for testing sometime tomorrow.  Sorry for
the delay.

-- 
------------------------------------------------------------------------
Bob Tracy          |  "I was a beta tester for dirt.  They never did
rct@frus.com       |   get all the bugs out." - Steve McGrew on /.
------------------------------------------------------------------------

Re: [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Bob Tracy]

Rene Herman wrote:
> Lovely, so different problem between you and Bob. When you (either of you) 
> have some time for it again, could you try:
> 
> $ sox asskickd.wav -w -t alsa hw

Tight loop at the beginning of the file: rapid continuous repeat of approx.
the first couple tenths of a second.  Hitting <ctrl>C caused playback to
advance to the next small section of the soundfile.  Further <ctrl>C's did
nothing I noticed: had to type <ctrl>\ to kill sox.

> $ sox asskickd.wav -w -r 44100 -t alsa hw

Several seconds of silence, followed by what sounded like continuous pitched
machine-gun fire.  Each <ctrl>C advanced through the file (the pitch of the
machine-gun fire changed slightly).  Still had to type <ctrl>\ to kill sox.

> $ sox asskickd.wav -w -r 44100 -c 2 -t alsa hw

Silence for longer than I had patience to wait :-).  Hitting <ctrl>C several
times finally got me to an even more rapid machine-gun fire than the previous
test.  As in the previous test, each <ctrl>C advanced further through the file,
although the perceived increment was smaller.  Still had to type <ctrl>\ to
kill sox.

-- 
------------------------------------------------------------------------
Bob Tracy          |  "I was a beta tester for dirt.  They never did
rct@frus.com       |   get all the bugs out." - Steve McGrew on /.
------------------------------------------------------------------------

Re: [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Michael Cree]

Bob Tracy wrote:
> Rene Herman wrote:
>> $ sox asskickd.wav -w -r 44100 -t alsa hw
> 
> Several seconds of silence, followed by what sounded like continuous pitched
> machine-gun fire.  Each <ctrl>C advanced through the file (the pitch of the
> machine-gun fire changed slightly).  Still had to type <ctrl>\ to kill sox.

Right, that sounds just like the older PWS600au I have - the one with 
the ESS1888 - except that what Bob describes as machine gun fire, I 
thought was, ahem, flatulence.

The newer PWS600au (with the ESS1887) plays the sound files correctly, 
except for the repeated bits at the end.

Michael.

Re: [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Michael Cree]

On 31/03/2008, at 5:14 AM, Ivan Kokshaysky wrote:

> On Sat, Mar 29, 2008 at 01:09:34PM +0100, Rene Herman wrote:
>> Okay. The thing that "fixed" Tyson was disabling mmap from the  
>> driver:
>>
>> http://mailman.alsa-project.org/pipermail/alsa-devel/2008-March/006911.html
>
> Weird - I was sure the mmap problem has been fixed, but obviously
> the patch didn't go in...
>
> Andrew, could you please queue this up for 2.6.26?

I have applied the patch against the 2.6.24.3 kernel, and now have  
working sound on the newer PWS600au with mmap enabled alsa.  Verified  
through the on board ESS1887 and via the M-Audio Revolution 7.1 sound  
card.  (Ran out of time to also try the C-Media sound card.  Also ran  
out of time to try it out on the other alphas I have.)

The problem with the repeated sound bits playing at the end of certain  
sound files via the ESS1887 remains.

Michael.

Re: [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Bob Tracy]

Michael Cree wrote:
> Bob
> >> (miata_no_mmap.diff patch)
> >
> > Made no difference for any of the "sox" tests, and "play" is still
> > broken in the way it always has been.  However, "aplay" generated an
> > interesting error I haven't seen before:
> >
> > $ aplay asskickd.wav
> > Playing WAVE 'asskickd.wav' : Unsigned 8 bit, Rate 11025 Hz, Mono
> > ALSA lib pcm_plug.c:773:(snd_pcm_plug_hw_refine_schange) Unable to  
> > find an usable access for 'default'
> > aplay: aplay.c:919: set_params: Assertion `err >= 0' failed.
> 
> Add in the "-D hw" option to the aplay command when using the mmap  
> disabled alsa sound.

Thanks!  I now get "Maybe yo<>Maybe yo<>Maybe yo<>Maybe yo..." in an
endlessly repeating loop.  <ctrl>C is sufficient to stop playback,
however.  Still no activity on IRQ 5 seen by the ES18xx driver.

-- 
------------------------------------------------------------------------
Bob Tracy          |  "I was a beta tester for dirt.  They never did
rct@frus.com       |   get all the bugs out." - Steve McGrew on /.
------------------------------------------------------------------------

Re: [alsa-devel] [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Tyson Whitehead]

Bob Tracy wrote:
> rct wrote:
>> Rene Herman wrote:
>>> Okay, and applying the attached just makes your sound completely dead in the 
>>> water?
>>> (patch to remove es1888_init from a Miata build omitted)
>> I'll try a build with the old OSS "sb" driver, and if that works ok, we
>> may be able to do away with es1888_init() on the Miata.  Tyson -- I
>> think you have a Miata if I'm remembering correctly: can you confirm
>> these observations?
> 
> Quick followup: OSS "sb" driver works fine without es1888_init().
> 

Okay.  I finally got everything tested on my Miata.  Unless I missed 
something, the es1888_init routine only gets compiled in with 
CONFIG_ALPHA_MIATA.  As I've been using the debian generic kernel (i.e., 
CONFIG_ALPHA_GENERIC), I have never relied on this routine for anything.

I did discover, however, when I compiled my own kernel (2.6.25-rc5) with 
CONFIG_ALPHA_MIATA, things stopped working.  Specifically, I no longer 
got any interupts (with or without the es1888_init patch and with or 
without the alternative es188xx interupt patch) associated with either 
the builtin sound card (es1888) or the IDE controller (CMD646).

With CONFIG_ALPHA_GENERIC I only get one interupt with the es18xx driver 
unless I applied to "alternative interupt" handling code.  Further, 
sometime between 2.6.14 and 2.6.16, mpg321 (using the alsa driver) 
started generating "Bad page state in process 'mpg321' ... Trying to fix 
it up, but a reboot is needed" kernel messages.

The machine would continue to operate okay though.  However, somewhere 
between 2.6.16 and 2.6.24, it also started crashing very shortly 
thereafter, giving the following backtrace: free_pages_check, 
free_hot_cold_pages, put_pages, free_page_and_swap_cache, unmap_cmas, 
unmap_region, default_wake_function, do_munmap, sys_munmap, entSys.

Hope this helps.

Cheers!  -Tyson

Re: [alsa-devel] [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Rene Herman]

On 01-04-08 20:07, Tyson Whitehead wrote:

> Hope this helps.

Not really no. A lot of data has come in by now and I'll try to sort through 
it trying to distill some sense out of it all later but throwing my hands up 
in the air and finding some older Alpha system to urinate on sounds about as 
good an idea as any at the moment.

Rene.

Re: [alsa-devel] [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Rene Herman]

On 01-04-08 20:07, Tyson Whitehead wrote:

> Hope this helps.

Not really no. A lot of data has come in by now and I'll try to sort through 
it trying to distill some sense out of it all later but throwing my hands up 
in the air and finding some older Alpha system to urinate on sounds about as 
good an idea as any at the moment.

Rene.

Re: [alsa-devel] [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Rene Herman]

On 01-04-08 20:07, Tyson Whitehead wrote:

> Hope this helps.

Not really no. A lot of data has come in by now and I'll try to sort through 
it trying to distill some sense out of it all later but throwing my hands up 
in the air and finding some older Alpha system to urinate on sounds about as 
good an idea as any at the moment.

Rene.

Re: [alsa-devel] [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Rene Herman]

On 01-04-08 20:34, Rene Herman wrote:

> On 01-04-08 20:07, Tyson Whitehead wrote:
> 
>> Hope this helps.
> 
> Not really no.

Sorry for the multiple copies; my ISP is crashing again.

Rene.

Re: [alsa-devel] [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Bob Tracy]

Tyson Whitehead wrote:
> Okay.  I finally got everything tested on my Miata.  Unless I missed 
> something, the es1888_init routine only gets compiled in with 
> CONFIG_ALPHA_MIATA.

The current arch/alpha/kernel/Makefile build logic shows es1888.o built
as part of CONFIG_ALPHA_GENERIC, but if that option isn't enabled, then
enabling any of the following configuration options will cause es1888.o
to be built:

CONFIG_ALPHA_DP264
CONFIG_ALPHA_SHARK
CONFIG_ALPHA_MIATA

> As I've been using the debian generic kernel (i.e., 
> CONFIG_ALPHA_GENERIC), I have never relied on this routine for anything.
> 
> I did discover, however, when I compiled my own kernel (2.6.25-rc5) with 
> CONFIG_ALPHA_MIATA, things stopped working.  Specifically, I no longer 
> got any interupts (with or without the es1888_init patch and with or 
> without the alternative es188xx interupt patch) associated with either 
> the builtin sound card (es1888) or the IDE controller (CMD646).

Interesting.  I *seldom* use the Debian generic kernel.  It's available,
and I install updated versions when they are released, but all of my
testing has been with kernels built from the standard kernel.org sources
with CONFIG_ALPHA_MIATA enabled.

> With CONFIG_ALPHA_GENERIC I only get one interupt with the es18xx driver 
> unless I applied to "alternative interupt" handling code.  Further, 
> sometime between 2.6.14 and 2.6.16, mpg321 (using the alsa driver) 
> started generating "Bad page state in process 'mpg321' ... Trying to fix 
> it up, but a reboot is needed" kernel messages.

This is consistent with what I remember you reporting when we were
looking at this back in the 2.6.14 timeframe.  I was reporting the "bad
page state" problems with 2.6.22-rc6 and -rc7.  In my case, the trigger
was a different application, but only happened when snd_es18xx was
loaded.  Hugh Dickins suggested it was a regression introduced in
2.6.15 that I had managed to successfully avoid tripping on :-).  The
analysis went something like this:

sound/isa/es18xx.c:
	snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV, ...
led us to sound/core/memalloc.c:
	res = dma_alloc_coherent(dev, PAGE_SIZE << pg, dma, gfp_flags);
where __GFP_COMP was carefully included in gfp_flags to avoid the
kinds of problems I was seeing (replacing the pre-2.6.15 use of
PageReserved).

Hugh said we could blame him or Nick for removing the special
PageReserved usage, or the Alpha for ignoring gfp_flags in the
following:

  #define dma_alloc_coherent(dev, size, addr, gfp)      \
                pci_alloc_consistent(alpha_gendev_to_pci(dev), size, addr)

The workaround (until the official patch was issued) was a small patch
against arch/alpha/kernel/pci_iommu.c:pci_alloc_consistent() that
replaced "gfp_t gfp = GFP_ATOMIC;" with "gfp_t gfp = GFP_ATOMIC|__GFP_COMP;".
That eliminated the "bad page state" errors for me, and I don't recall
what the official patch was.

-- 
------------------------------------------------------------------------
Bob Tracy          |  "I was a beta tester for dirt.  They never did
rct@frus.com       |   get all the bugs out." - Steve McGrew on /.
------------------------------------------------------------------------

Re: [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Bob Tracy]

Rene Herman wrote:
> On 01-04-08 20:34, Rene Herman wrote:
> 
> > On 01-04-08 20:07, Tyson Whitehead wrote:
> > 
> >> Hope this helps.
> > 
> > Not really no.
> 
> Sorry for the multiple copies; my ISP is crashing again.
> 
> Rene.

And here I was, thinking you were giving us a *really* strong hint that
you would like one of us to ship you an Alpha to play with :-).

-- 
------------------------------------------------------------------------
Bob Tracy          |  "I was a beta tester for dirt.  They never did
rct@frus.com       |   get all the bugs out." - Steve McGrew on /.
------------------------------------------------------------------------

Re: [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Michael Cree]

On 2/04/2008, at 9:26 AM, Bob Tracy wrote:
> Hugh said we could blame him or Nick for removing the special
> PageReserved usage, or the Alpha for ignoring gfp_flags in the
> following:
>
>  #define dma_alloc_coherent(dev, size, addr, gfp)      \
>                pci_alloc_consistent(alpha_gendev_to_pci(dev), size,  
> addr)
>
> The workaround (until the official patch was issued) was a small patch
> against arch/alpha/kernel/pci_iommu.c:pci_alloc_consistent() that
> replaced "gfp_t gfp = GFP_ATOMIC;" with "gfp_t gfp = GFP_ATOMIC| 
> __GFP_COMP;".
> That eliminated the "bad page state" errors for me, and I don't recall
> what the official patch was.

The official patch has just been uploaded to the -mm kernel.  Get it at:

http://userweb.kernel.org/~akpm/mmotm/broken-out/alpha-fix-alsa-dma-mmap-crash.patch

It fixed up quite a number of sound playing applications that were  
causing kernel oops on my newer PWS600au (the older one still has  
problems that are of a completely different nature) and also fixed use  
of an M-Audio Revolution audio card on my XP1000.

The repeated small passages at the end of a short sound file still  
occurs with the es18xx driver on the newer PWS600au (and to a lesser  
extent on the Compaq XP1000).  Other sound drivers (cmipci, ice1724)  
do not exhibit the same anomalous symptoms so the problem is probably  
in the es18xx driver.

The older PWS600au fails to play sound at all and exhibits the  
behaviour you described in a recent message (machine gun like noises  
and the interrupts don't clock up at all) with the es18xx driver. I  
tried to put the C-Media audio card (which uses the cmipci driver)  
into this machine, but SRM reports on powerup that there is an  
"illegal" card installed (I hope the police don't turn up at my door)  
and that it must be removed to continue booting!!!  I tried setting  
pci_device_override to 1 in SRM, but that didn't help.  So I can't  
verify whether this is an es18xx specific problem or a more general  
alsa problem.

Now that the crashes due to "bad page state" errors are solved on both  
of my PWS600aus, maybe I should start re-applying the es18xx interrupt  
type patches that Tyson, et al., suggested and see if they now make a  
difference.  I will not be able to do this before the weekend.

Cheerz
Michael.