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

[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: [alsa-devel] [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Bob Tracy]

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.

-- 
------------------------------------------------------------------------
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 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: [alsa-devel] [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Rene Herman]

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

On 11-03-08 15:07, Bob Tracy wrote:

> Both native ALSA and emulated OSS playback are broken based on last 
> night's testing.  Just to rule out sound hardware issues, this morning I
> built a 2.6.25-rc4 kernel with OSS (sb driver), and that seems to be 
> working fine.

Okay... From your testing report:

>> $ 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.

This is behaviour consistent with the IRQ being dead ...

>> > $ 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.

... and this isn't. Worse yet, we have a conflicting report from Michael 
where things are fine while using aplay and I'm seeing nothing particularly 
suspicious recently. I suppose it used to work and I suppose the behaviour 
you are describing above is 100% repeatable?

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

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.

The most recent change to sound/isa/es18xx.c that's not utterly impossible 
to have made a difference is 1bc9eed379399484d3f5d5a0834674983969bc1, 
"es18xx: Enable wavetable input from ESS chips". I don't know if you're a 
GIT user. If you are, you can revert it simply with

$ git revert 1bc9eed3

If you're not a GIT user, applying the attached should work. Unlikely, but 
as said, we can try.

> 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

Okay. A and B seem to at least confirm it's not the 16-bit DMA.

Rene.

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

commit 8fa1de6349913b63d8ebfb27003b7045eeb9f12a
Author: Rene Herman <rene.herman@gmail.com>
Date:   Tue Mar 11 15:52:36 2008 +0100

    Revert "[ALSA] es18xx: Enable wavetable input from ESS chips"
    
    This reverts commit 1bc9eed379399484d3f5d5a0834674983969bc1e.

diff --git a/sound/isa/es18xx.c b/sound/isa/es18xx.c
index 90498e4..865ab1d 100644
--- a/sound/isa/es18xx.c
+++ b/sound/isa/es18xx.c
@@ -1441,8 +1441,6 @@ static int __devinit snd_es18xx_initialize(struct snd_es18xx *chip)
 		snd_es18xx_write(chip, 0xB2, 0x50);
 		/* Enable MPU and hardware volume interrupt */
 		snd_es18xx_mixer_write(chip, 0x64, 0x42);
-		/* Enable ESS wavetable input */
-		snd_es18xx_mixer_bits(chip, 0x48, 0x10, 0x10);
 	}
 	else {
 		int irqmask, dma1mask, dma2mask;

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: [alsa-devel] [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Michael Cree]

On 12/03/2008, at 7:08 AM, Bob Tracy wrote:

> 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)

Yes, the ESS1888 driver failed to work on Alpha about the 2.6.14 to  
2.6.16 kernel.   It came right with alsa release 1.0.13 (IIRC) and I  
have been running the ESS1888 driver on an Alpha XP1000 without  
problems for about a year.  I have been using mocp and mplayer on a  
fairly regular basis.  My Mplayer version uses the OSS interface by  
default.  Not sure, off-hand, what mocp is using.

For the last three months I have been playing with other sound cards  
(the quality of sound from the ESS1888 leaves a lot to be desired,  
imho) and haven't used the ESS1888 recently, so if a regression has  
been introduced after kernel 2.6.22 then it is likely I wouldn't see it.

Sorry, but I am not in a good position to do testing of the ESS1888 at  
the moment.  A week or so ago my system and home partitions shat  
themselves and I had to reinstall from 3 month old backups.  It has  
just happened again - two nights ago.  Don't know what is causing it -  
whether it is hardware fault (I can't find any disc block errors), the  
2.6.24.2 (and 2.6.24.3) kernels I had recently upgraded to, or the  
recent update from Debian testing, or the switch from the internal  
SCSI card and disc to an installed SATA card and disc that I did three  
months ago (though that one has worked for the first two and a half  
months without flaw).  Maybe I should start a new thread with a report  
of that just in case it is a kernel problem???

Michael.

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: [alsa-devel] [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Bob Tracy]

Rene Herman wrote:
> (Re: interrupts not being seen by es18xx)
> That is indeed what it soundeed like, or the first bit at least.
> 
> 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?

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.

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.

-- 
------------------------------------------------------------------------
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: 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

[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: [alsa-devel] [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 remove es1888_init from a Miata build omitted)

A quick followup...  Since we're in agreement this isn't a regression,
I've updated my working source tree to 2.6.25-rc5.  Built the new
kernel with the patch to omit es1888_init(), and as near as I can tell,
that function does nothing useful on the Miata platform.  At the very
least, not having it makes no difference to any of the ALSA drivers I've
tried: snd-sb8 still works great, and snd-es18xx is still broken in the
same way originally described at the beginning of this long thread.

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?

-- 
------------------------------------------------------------------------
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]

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

On Fri March 14 2008, Bob Tracy wrote:
> A quick followup...  Since we're in agreement this isn't a regression,
> I've updated my working source tree to 2.6.25-rc5.  Built the new
> kernel with the patch to omit es1888_init(), and as near as I can tell,
> that function does nothing useful on the Miata platform.  At the very
> least, not having it makes no difference to any of the ALSA drivers I've
> tried: snd-sb8 still works great, and snd-es18xx is still broken in the
> same way originally described at the beginning of this long thread.
>
> 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?

I actually ran into some problems with my Alpha, and I haven't managed to get 
get it full operational again yet.  I replaced the CPU fan, installed the new 
aboot, and left it trying to recover the filesystems.  It was an unhappy 
story all around -- damn that CMD646 chipset, I was under the impression that 
driver had acquired some recent fixups.  Anyway, if this succeeds, I'll try 
and compile up a new kernel with the patch when I get a chance.

With regard to the sound driver, the es18xx does endless looping on the first 
second or so of sound on my box (a PWS500au) unless I apply my patch, which 
just enables the alternative interupt detection code in the driver.  Even 
then, though, I believe it still only works in 8bit mode.

The sb8 driver also works for me.  For this reason, I basically decided to 
forget about my es18xx patch.  It doesn't get me anything the sb8 driver 
doesn't give me, and it forces me to keep compiling my own kernels.

Cheers!  -Tyson

PS:  The Debian 2.6.24 kernel actually panicked on me (instead of infinitely 
looping on the first second of sound) when I tried the stock es18xx driver.

-- 
 Tyson Whitehead  (-twhitehe at uwo.ca -- MC-)
 Computer Engineer                          Dept. of Applied Mathematics,
 Graduate Student- Applied Mathematics      University of Western Ontario,
 GnuPG Key ID# 0xF7666BFF                   London, Ontario, Canada

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Rene Herman]

On 15-03-08 02:18, Tyson Whitehead wrote:

> With regard to the sound driver, the es18xx does endless looping on the first 
> second or so of sound on my box (a PWS500au) unless I apply my patch, which 
> just enables the alternative interupt detection code in the driver.  Even 
> then, though, I believe it still only works in 8bit mode.

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

http://whitehead.apmaths.uwo.ca/~tyson/

which seems to be dead.

> The sb8 driver also works for me.  For this reason, I basically decided to 
> forget about my es18xx patch.  It doesn't get me anything the sb8 driver 
> doesn't give me, and it forces me to keep compiling my own kernels.
> 
> Cheers!  -Tyson
> 
> PS:  The Debian 2.6.24 kernel actually panicked on me (instead of infinitely 
> looping on the first second of sound) when I tried the stock es18xx driver.

Rene.

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

[Tyson Whitehead]

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

Rene Herman wrote:
> On 15-03-08 02:18, Tyson Whitehead wrote:
> 
> Could you attach that patch? Links I'm finding are to
> 
> http://whitehead.apmaths.uwo.ca/~tyson/
> 
> which seems to be dead.

Sorry about that.  I finally graduated.  : )

Cheers!  -Tyson

[-- Attachment #2: alpha-alsa.patch --]
[-- Type: text/x-diff, Size: 402 bytes --]

--- sound/isa/es18xx.c~	2003-04-23 06:01:33.000000000 -0400
+++ sound/isa/es18xx.c	2003-06-24 15:14:25.000000000 -0400
@@ -736,10 +736,10 @@
 		/* Read Interrupt status */
 		status = inb(chip->ctrl_port + 6);
+#if 0
 	} else {
 		/* Read Interrupt status */
 		status = snd_es18xx_mixer_read(chip, 0x7f) >> 4;
-	}
-#if 0
-	else {
+#else
+	} else {
 		status = 0;
 		if (inb(chip->port + 0x0C) & 0x01)

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

[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

[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: [alsa-devel] [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Rene Herman]

On 29-03-08 07:42, Bob Tracy wrote:

>>> +#ifdef CONFIG_ALPHA
>>> +	if (!(status & (AUDIO1_IRQ | AUDIO2_IRQ))) {
>>> +		/* status = 0; */

> 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...

Okay. The thing that "fixed" Tyson was disabling mmap from the driver:

http://mailman.alsa-project.org/pipermail/alsa-devel/2008-March/006911.html

It landed him in the same situation as you though, where that "asskickd.wav" 
mono, 8-bit 11025 file you sent me shows the same behaviour you reported. 
This might imply you weren't using mmap to begin with. You have no horribly 
obsolete alsa userland, nor an /etc/asound.conf or ~/.asoundrc?

No change with "aplay -M"? If there is a change, you'd expect it to be 
Tyson's old behaviour which means blowing up the machine on subsequent 
plays, so be a bit careful...

This one needs answer so as to possibly pin things down to format:

http://mailman.alsa-project.org/pipermail/alsa-devel/2008-March/006914.html

Rene.

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

[Ivan Kokshaysky]

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?

Ivan.

--
alpha: fix ALSA DMA mmap crash

Make dma_alloc_coherent respect gfp flags (__GFP_COMP is one that
matters).

Signed-off-by: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
---
 arch/alpha/kernel/pci_iommu.c   |    8 +++++---
 include/asm-alpha/dma-mapping.h |    2 +-
 include/asm-alpha/pci.h         |    8 +++++++-
 3 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c
index 4e1c086..dd6e334 100644
--- a/arch/alpha/kernel/pci_iommu.c
+++ b/arch/alpha/kernel/pci_iommu.c
@@ -424,11 +424,13 @@ EXPORT_SYMBOL(pci_unmap_page);
    else DMA_ADDRP is undefined.  */
 
 void *
-pci_alloc_consistent(struct pci_dev *pdev, size_t size, dma_addr_t *dma_addrp)
+__pci_alloc_consistent(struct pci_dev *pdev, size_t size,
+		       dma_addr_t *dma_addrp, gfp_t gfp)
 {
 	void *cpu_addr;
 	long order = get_order(size);
-	gfp_t gfp = GFP_ATOMIC;
+
+	gfp &= ~GFP_DMA;
 
 try_again:
 	cpu_addr = (void *)__get_free_pages(gfp, order);
@@ -458,7 +460,7 @@ try_again:
 
 	return cpu_addr;
 }
-EXPORT_SYMBOL(pci_alloc_consistent);
+EXPORT_SYMBOL(__pci_alloc_consistent);
 
 /* Free and unmap a consistent DMA buffer.  CPU_ADDR and DMA_ADDR must
    be values that were returned from pci_alloc_consistent.  SIZE must
diff --git a/include/asm-alpha/dma-mapping.h b/include/asm-alpha/dma-mapping.h
index 75a1aff..db351d1 100644
--- a/include/asm-alpha/dma-mapping.h
+++ b/include/asm-alpha/dma-mapping.h
@@ -11,7 +11,7 @@
 #define dma_unmap_single(dev, addr, size, dir)		\
 		pci_unmap_single(alpha_gendev_to_pci(dev), addr, size, dir)
 #define dma_alloc_coherent(dev, size, addr, gfp)	\
-		pci_alloc_consistent(alpha_gendev_to_pci(dev), size, addr)
+	      __pci_alloc_consistent(alpha_gendev_to_pci(dev), size, addr, gfp)
 #define dma_free_coherent(dev, size, va, addr)		\
 		pci_free_consistent(alpha_gendev_to_pci(dev), size, va, addr)
 #define dma_map_page(dev, page, off, size, dir)		\
diff --git a/include/asm-alpha/pci.h b/include/asm-alpha/pci.h
index d5b10ef..d31fd49 100644
--- a/include/asm-alpha/pci.h
+++ b/include/asm-alpha/pci.h
@@ -76,7 +76,13 @@ extern inline void pcibios_penalize_isa_irq(int irq, int active)
    successful and sets *DMA_ADDRP to the pci side dma address as well,
    else DMA_ADDRP is undefined.  */
 
-extern void *pci_alloc_consistent(struct pci_dev *, size_t, dma_addr_t *);
+extern void *__pci_alloc_consistent(struct pci_dev *, size_t,
+				    dma_addr_t *, gfp_t);
+static inline void *
+pci_alloc_consistent(struct pci_dev *dev, size_t size, dma_addr_t *dma)
+{
+	return __pci_alloc_consistent(dev, size, dma, GFP_ATOMIC);
+}
 
 /* Free and unmap a consistent DMA buffer.  CPU_ADDR and DMA_ADDR must
    be values that were returned from pci_alloc_consistent.  SIZE must

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]

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: [alsa-devel] [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Bob Tracy]

I'll try the below when I get back from my business trip (in approx.
two weeks).  Apologies for the inconvenience, but the Alpha hardly
qualifies as a laptop :-).  If someone else with a Miata (or other
Alpha with the ES1888 sound device) cares to give this a try, I *will*
be keeping up with my e-mail.

--Bob

Rene Herman wrote:
> 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.
> 

> 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

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

[Michael Cree]

On 18/03/2008, at 4:24 PM, Bob Tracy wrote:

> I'll try the below when I get back from my business trip (in approx.
> two weeks).  Apologies for the inconvenience, but the Alpha hardly
> qualifies as a laptop :-).  If someone else with a Miata (or other
> Alpha with the ES1888 sound device) cares to give this a try, I *will*
> be keeping up with my e-mail.

I should be able to give this a go over Easter on a PWS500au, which,  
IIRC, is a miata system.

As an aside, I have been using the ESS1888 on my XP1000 (in between  
system partition corruptions and restoring the system three times - I  
suspect a failing controller card which I have now removed) through  
the OSS interface for a couple of weeks without problems.  This is  
indicative that the ESS1888 problem may be specific to certain Alpha  
models.

Michael.

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

[Michael Cree]

Michael Cree wrote:
> On 18/03/2008, at 4:24 PM, Bob Tracy wrote:
> 
>> I'll try the below when I get back from my business trip (in approx.
>> two weeks).  Apologies for the inconvenience, but the Alpha hardly
>> qualifies as a laptop :-).  If someone else with a Miata (or other
>> Alpha with the ES1888 sound device) cares to give this a try, I *will*
>> be keeping up with my e-mail.
> 
> I should be able to give this a go over Easter on a PWS500au, which, 
> IIRC, is a miata system.

I have been able to run some tests.  BTW, it is a PWS600au I have.  It 
has an ES1887 sound chip.  The most important result is that it is not 
only the snd-es18xx driver that fails (often leading to complete system 
lockups) but I also installed a CM8738 based sound card and use of the 
snd-cmipci driver exhibits exactly the same symptoms as the snd-es18xx 
driver.  Both of these drivers work find on the Compaq XP1000.

I am testing with the 2.6.24.3 kernel.  On the PWS600au I have compiled 
the kernel for the miata system and selected the EV56 cpu option.  On 
the XP1000 I have compiled the kernel for a DP264 system and with the 
EV67 cpu option.  In response to an earlier question by Rene I note that 
arch/alpha/kernel/es1888.o is added in as a built in object by both systems.

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).

On the PWS600au I have been running aplay on a two minute or so long wav 
file (because that is what I have on that system and couldn't be 
bothered searching for short files like what Bob was having troubles 
with).  I can play the file once (using aplay) without any problem. 
When I attempt to the play the file the second time all hell breaks 
lose, sometimes with a variety of pops and whistles out the sound card, 
and the system crashes or just completely freezes.  Occasionally a 
kernel oops makes it into the logs.  This happens for both sound drivers 
(es18xx driver into the ES1887 and the cmipci driver into the CM8738 
sound card).

I applied the patches of Rene (es18xx-trial-and-error.diff) and the 
patch provided by Takashi (with the #ifdef CONFIG_ALPHA detection). 
Similar behaviour as before.  First time playing the sound file works 
and on attempting to play the sound file for the second time the system 
crashes and locks up.  (The es18xx-trial... patch produces no sound and 
interrupts do not clock up in /proc/interrupts.  The crash on second 
time of playing a sound file still occurs).

The same behaviour as above also occurs with running the speaker-test 
program.

I therefore think we are looking in the wrong place if we are looking at 
the es18xx driver!

An example of the kernel oops that occurs on running aplay for the 
second time (actually it was third time in this particular trial - the 
second time just lead to a segmentation violation) follows:

Unable to handle kernel paging request at virtual address 0000000000100100
aplay(2125): Oops 0
pc = [<fffffc000035bd80>]  ra = [<fffffc000035bcac>]  ps = 0007    Not 
tainted
pc is at get_page_from_freelist+0x1b0/0x4d0
ra is at get_page_from_freelist+0xdc/0x4d0
v0 = 0000000000000000  t0 = 0000000000000000  t1 = 0000000000100100
t2 = 0000000000000000  t3 = fffffc0000b2ab38  t4 = 0000000000100000
t5 = 0000000000000001  t6 = 0000000000000002  t7 = fffffc0021ba4000
s0 = fffffc00006ea028  s1 = 00000000001000d8  s2 = fffffc00006ea018
s3 = 0000000000000002  s4 = fffffc00006e9fe8  s5 = 0000000000000000
s6 = 0000000000000001
a0 = 0000000000000007  a1 = 0000000000000000  a2 = 00000000000001dd
a3 = 0000000000000000  a4 = 0000000000000044  a5 = 0000000000000002
t8 = 000000000000001f  t9 = 000002000009cd54  t10= 000000000001fee0
t11= 0000000000000010  pv = fffffc000035c5d0  at = 0000000000000000
gp = fffffc000071c598  sp = fffffc0021ba7c50
Trace:
[<fffffc000035c64c>] __alloc_pages+0x7c/0x450
[<fffffc0000369ff0>] handle_mm_fault+0x470/0x6e0
[<fffffc0000380610>] vfs_read+0xc0/0x190
[<fffffc0000369fcc>] handle_mm_fault+0x44c/0x6e0
[<fffffc000031f604>] do_page_fault+0x2d4/0x490
[<fffffc0000310bdc>] entMM+0x9c/0xc0
[<fffffc00003806a0>] vfs_read+0x150/0x190
[<fffffc000

(and dmesg failed at this point as the system crashed.)


The following example was playing through the cmipci sound driver and 
copied from the system log (since the system locked up before I ran dmesg):

Mar 23 22:24:38 aleph kernel: Kernel bug at mm/mmap.c:2054
Mar 23 22:24:38 aleph kernel: aplay(2604): Kernel Bug 1
Mar 23 22:24:38 aleph kernel: pc = [<fffffc000036cba4>]  ra = 
[<fffffc000036cb68>]  ps = 0000    Not tainted
Mar 23 22:24:38 aleph kernel: pc is at exit_mmap+0x134/0x150
Mar 23 22:24:38 aleph kernel: ra is at exit_mmap+0xf8/0x150
Mar 23 22:24:38 aleph kernel: v0 = 0000000000000000  t0 = 
0000000000000002  t1 = 0000000000000041
Mar 23 22:24:38 aleph kernel: t2 = 0000000000000040  t3 = 
fffffc002300c600  t4 = 0000000000000008
Mar 23 22:24:38 aleph kernel: t5 = fffffc00001da000  t6 = 
0000000000000000  t7 = fffffc001a34c000
Mar 23 22:24:38 aleph kernel: a0 = 0000000000000000  a1 = 
fffffc002300c400  a2 = 0000000000000000
Mar 23 22:24:38 aleph kernel: a3 = 0000000000000000  a4 = 
0000000000000000  a5 = 0000000000000000
Mar 23 22:24:38 aleph kernel: t8 = 0000000000000000  t9 = 
000000684d5720ff  t10= d000000000000000
Mar 23 22:24:38 aleph kernel: t11= 0000000000002000  pv = 
fffffc000037c0b0  at = 0000000000000002
Mar 23 22:24:38 aleph kernel: gp = fffffc000071c598  sp = fffffc001a34fbe8
Mar 23 22:24:38 aleph kernel: Trace:
Mar 23 22:24:38 aleph kernel: [<fffffc0000325e4c>] mmput+0x5c/0x100
Mar 23 22:24:38 aleph kernel: [<fffffc000032a500>] exit_mm+0xc0/0x180
Mar 23 22:24:38 aleph kernel: [<fffffc000032b63c>] do_exit+0x16c/0x950
Mar 23 22:24:38 aleph kernel: [<fffffc000032be64>] do_group_exit+0x44/0xc0
Mar 23 22:24:38 aleph kernel: [<fffffc000033677c>] 
get_signal_to_deliver+0x2fc/0x450
Mar 23 22:24:38 aleph kernel: [<fffffc0000316874>] 
do_notify_resume+0xb4/0x570
Mar 23 22:24:38 aleph kernel: [<fffffc00003110cc>] work_pending+0x5c/0x70
Mar 23 22:24:38 aleph kernel: [<fffffc0000334c40>] 
__sigqueue_alloc+0x40/0xc0
Mar 23 22:24:38 aleph kernel: [<fffffc0000390480>] do_ioctl+0x30/0x90
Mar 23 22:24:38 aleph kernel: [<fffffc0000335634>] 
specific_send_sig_info+0xd4/0x110
Mar 23 22:24:38 aleph kernel: [<fffffc000033577c>] force_sig_info+0x8c/0xe0
Mar 23 22:24:38 aleph kernel: [<fffffc0000310bdc>] entMM+0x9c/0xc0
Mar 23 22:24:38 aleph kernel:
Mar 23 22:24:38 aleph kernel: Code: a77df570  6b5b497f  27ba003b 
23bdfa04  c3ffffec  00000081 <00000806> 00609c4a
Mar 23 22:24:38 aleph kernel: Fixing recursive fault but reboot is needed!


Hope the above gives food for thought.

Michael.

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

[Rene Herman]

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

On 23-03-08 11:40, Michael Cree wrote:

> I have been able to run some tests.  BTW, it is a PWS600au I have.  It 
> has an ES1887 sound chip.  The most important result is that it is not 
> only the snd-es18xx driver that fails (often leading to complete system 
> lockups) but I also installed a CM8738 based sound card and use of the 
> snd-cmipci driver exhibits exactly the same symptoms as the snd-es18xx 
> driver.  Both of these drivers work find on the Compaq XP1000.
> 
> I am testing with the 2.6.24.3 kernel.  On the PWS600au I have compiled 
> the kernel for the miata system and selected the EV56 cpu option.  On the
> XP1000 I have compiled the kernel for a DP264 system and with the EV67
> cpu option.  In response to an earlier question by Rene I note that 
> arch/alpha/kernel/es1888.o is added in as a built in object by both 
> systems.
> 
> 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

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.

> On the PWS600au I have been running aplay on a two minute or so long wav 
> file (because that is what I have on that system and couldn't be 
> bothered searching for short files like what Bob was having troubles 
> with).  I can play the file once (using aplay) without any problem. When 
> I attempt to the play the file the second time all hell breaks lose, 
> sometimes with a variety of pops and whistles out the sound card, and 
> the system crashes or just completely freezes.  Occasionally a kernel 
> oops makes it into the logs.  This happens for both sound drivers 
> (es18xx driver into the ES1887 and the cmipci driver into the CM8738 
> sound card).
> 
> I applied the patches of Rene (es18xx-trial-and-error.diff) and the 
> patch provided by Takashi (with the #ifdef CONFIG_ALPHA detection). 
> Similar behaviour as before.  First time playing the sound file works 
> and on attempting to play the sound file for the second time the system 
> crashes and locks up.  (The es18xx-trial... patch produces no sound and 
> interrupts do not clock up in /proc/interrupts.  The crash on second 
> time of playing a sound file still occurs).

Thanks, that was of no use at all then; it was a bit optimistic indeed...

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.

> The same behaviour as above also occurs with running the speaker-test 
> program.
> 
> I therefore think we are looking in the wrong place if we are looking at 
> the es18xx driver!
> 
> An example of the kernel oops that occurs on running aplay for the 
> second time (actually it was third time in this particular trial - the 
> second time just lead to a segmentation violation) follows:
> 
> Unable to handle kernel paging request at virtual address 0000000000100100
> aplay(2125): Oops 0
> pc = [<fffffc000035bd80>]  ra = [<fffffc000035bcac>]  ps = 0007    Not 
> tainted
> pc is at get_page_from_freelist+0x1b0/0x4d0
> ra is at get_page_from_freelist+0xdc/0x4d0
> v0 = 0000000000000000  t0 = 0000000000000000  t1 = 0000000000100100
> t2 = 0000000000000000  t3 = fffffc0000b2ab38  t4 = 0000000000100000
> t5 = 0000000000000001  t6 = 0000000000000002  t7 = fffffc0021ba4000
> s0 = fffffc00006ea028  s1 = 00000000001000d8  s2 = fffffc00006ea018
> s3 = 0000000000000002  s4 = fffffc00006e9fe8  s5 = 0000000000000000
> s6 = 0000000000000001
> a0 = 0000000000000007  a1 = 0000000000000000  a2 = 00000000000001dd
> a3 = 0000000000000000  a4 = 0000000000000044  a5 = 0000000000000002
> t8 = 000000000000001f  t9 = 000002000009cd54  t10= 000000000001fee0
> t11= 0000000000000010  pv = fffffc000035c5d0  at = 0000000000000000
> gp = fffffc000071c598  sp = fffffc0021ba7c50
> Trace:
> [<fffffc000035c64c>] __alloc_pages+0x7c/0x450
> [<fffffc0000369ff0>] handle_mm_fault+0x470/0x6e0
> [<fffffc0000380610>] vfs_read+0xc0/0x190
> [<fffffc0000369fcc>] handle_mm_fault+0x44c/0x6e0
> [<fffffc000031f604>] do_page_fault+0x2d4/0x490
> [<fffffc0000310bdc>] entMM+0x9c/0xc0
> [<fffffc00003806a0>] vfs_read+0x150/0x190
> [<fffffc000
> 
> (and dmesg failed at this point as the system crashed.)
> 
> 
> The following example was playing through the cmipci sound driver and 
> copied from the system log (since the system locked up before I ran dmesg):
> 
> Mar 23 22:24:38 aleph kernel: Kernel bug at mm/mmap.c:2054
> Mar 23 22:24:38 aleph kernel: aplay(2604): Kernel Bug 1
> Mar 23 22:24:38 aleph kernel: pc = [<fffffc000036cba4>]  ra = 
> [<fffffc000036cb68>]  ps = 0000    Not tainted
> Mar 23 22:24:38 aleph kernel: pc is at exit_mmap+0x134/0x150
> Mar 23 22:24:38 aleph kernel: ra is at exit_mmap+0xf8/0x150
> Mar 23 22:24:38 aleph kernel: v0 = 0000000000000000  t0 = 
> 0000000000000002  t1 = 0000000000000041
> Mar 23 22:24:38 aleph kernel: t2 = 0000000000000040  t3 = 
> fffffc002300c600  t4 = 0000000000000008
> Mar 23 22:24:38 aleph kernel: t5 = fffffc00001da000  t6 = 
> 0000000000000000  t7 = fffffc001a34c000
> Mar 23 22:24:38 aleph kernel: a0 = 0000000000000000  a1 = 
> fffffc002300c400  a2 = 0000000000000000
> Mar 23 22:24:38 aleph kernel: a3 = 0000000000000000  a4 = 
> 0000000000000000  a5 = 0000000000000000
> Mar 23 22:24:38 aleph kernel: t8 = 0000000000000000  t9 = 
> 000000684d5720ff  t10= d000000000000000
> Mar 23 22:24:38 aleph kernel: t11= 0000000000002000  pv = 
> fffffc000037c0b0  at = 0000000000000002
> Mar 23 22:24:38 aleph kernel: gp = fffffc000071c598  sp = fffffc001a34fbe8
> Mar 23 22:24:38 aleph kernel: Trace:
> Mar 23 22:24:38 aleph kernel: [<fffffc0000325e4c>] mmput+0x5c/0x100
> Mar 23 22:24:38 aleph kernel: [<fffffc000032a500>] exit_mm+0xc0/0x180
> Mar 23 22:24:38 aleph kernel: [<fffffc000032b63c>] do_exit+0x16c/0x950
> Mar 23 22:24:38 aleph kernel: [<fffffc000032be64>] do_group_exit+0x44/0xc0
> Mar 23 22:24:38 aleph kernel: [<fffffc000033677c>] 
> get_signal_to_deliver+0x2fc/0x450
> Mar 23 22:24:38 aleph kernel: [<fffffc0000316874>] 
> do_notify_resume+0xb4/0x570
> Mar 23 22:24:38 aleph kernel: [<fffffc00003110cc>] work_pending+0x5c/0x70
> Mar 23 22:24:38 aleph kernel: [<fffffc0000334c40>] 
> __sigqueue_alloc+0x40/0xc0
> Mar 23 22:24:38 aleph kernel: [<fffffc0000390480>] do_ioctl+0x30/0x90
> Mar 23 22:24:38 aleph kernel: [<fffffc0000335634>] 
> specific_send_sig_info+0xd4/0x110
> Mar 23 22:24:38 aleph kernel: [<fffffc000033577c>] force_sig_info+0x8c/0xe0
> Mar 23 22:24:38 aleph kernel: [<fffffc0000310bdc>] entMM+0x9c/0xc0
> Mar 23 22:24:38 aleph kernel:
> Mar 23 22:24:38 aleph kernel: Code: a77df570  6b5b497f  27ba003b 
> 23bdfa04  c3ffffec  00000081 <00000806> 00609c4a
> Mar 23 22:24:38 aleph kernel: Fixing recursive fault but reboot is needed!
> 
> 
> Hope the above gives food for thought.
> 
> Michael.

Yes, thanks for the testing. There's an mmap in that last oops again at least...

Rene.


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

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 */

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: [alsa-devel] [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Rene Herman]

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

On 25-03-08 00:56, Michael Cree wrote:

> 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.

Thanks much for the quick reply. That's good to hear. As indicated, Bob 
seemed to be experiencing something else but this is pretty fundamental so 
I'll not try to comment on his case any further until he's had a chance to 
test this as well.

Takashi -- over to you for Michael's issue? His PWS600AU (MIATA) system 
soils itself badly when using SNDRV_PCM_INFO_MMAP. His XP1000 works fine and 
I haven't the faintest clue if switching on CONFIG_ALPHA_MIATA is the proper 
switch, nor if outright disabling mmap is the correct approach. The patch 
that works for him is attached again for reference.

The way this does the disabling also implies disabling SNDRV_PCM_INFO_IOMEM 
by the way...

> 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.

$ sox foo.wav -t alsa hw

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

> 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.

Given that it fixes es18xx and cmipci on the PWS600au and that those worked 
without trouble on the XP1000, you'd _expect_ not, but the OOPs you posted 
before seemed to indicate that it stands a fair chance afer all.

Rene.

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

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 */

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

[Michael Cree]

Rene Herman wrote:

>> 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.
> 
> $ sox foo.wav -t alsa hw

Hmmm :-/  So obvious now that you mention it.

> 
> 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.

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?

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.

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]

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

[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: [alsa-devel] [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

[Michael Cree]

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.

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

[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: [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: [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

[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.