Re: [alsa-devel] [regression] 2.6.25-rc4 snd-es18xx broken on Alpha
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.
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
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.
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.
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
On 10-03-08 18:14, Takashi Iwai wrote:
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?
Could've sworn...
The bug seems not present on x86. I'm testing with a ES1968 and ES1898 (his is a 18888) and playback through ALSA native nor OSS emulation is giving me trouble up to now.
Bob? How short are "short" wav files by the way?
Rene.
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.
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.
Rene Herman wrote:
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...
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.
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.
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;
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.
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.
Michael Cree wrote:
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.
Nod. I take it things were working for you at least as recently as 2.6.22, then. I can try that version and see if it works for me. My situation is that I can't swear I've tried anything involving ALSA on the Alpha since 2.6.16 until recently, so I'm not sure this is really a regression in my case.
Because I threatened to do it :-), I built a 2.6.25-rc4+iommu_patch kernel with both the snd-es18xx and snd-sb8 modules available. As hoped (expected?), the snd-sb8 driver works fine. This would imply the problem is at least somewhat specific to the es18xx driver, and that the underlying ALSA infrastructure is reasonably healthy (notice that I intentionally avoided saying it was "sound" -- sorry, I never could pass on low-hanging fruit).
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.
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.
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.
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.
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
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).
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.
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
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;
irqmask = 1;
irqmask = 0x5; break;
irqmask = 2;
irqmask = 0xa; break;
irqmask = 3;
irqmask = 0xf; break;@@ -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);@@ -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
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.
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.
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.
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 */
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.
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.
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 */
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:
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.
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:
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.
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 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.
Rene Herman wrote:
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:
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.
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
Exactly the same as without the -w option. (BTW, I would've never have guessed the -w option; my man file has -2 for conversion to 16 bit.)
$ sox asskickd.wav -w -r 44100 -t alsa hw
The words "current event" are no longer repeated at the end of playing. There is a click at the end of playing - hard to know whether it started to repeat something or whether it is truly at the end of the sound file.
$ sox asskickd.wav -w -r 44100 -c 2 -t alsa hw
Repeats the "al" bit of the last word "pal" at the end of playing.
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...
I have another PWS600au - a little older than the one I was testing on. It is slightly different in that its scsi controller is a separate board in a PCI slot, rather than on the motherboard. Also has an ESS1888 rather than an ESS1887. Just installed the same OS and kernel on it.
Tried playing sound. What a mess. Crashes with mmap on. Installed the patch turning off mmap. Just produces buzzes and fart noises whatever sound file I try to play; both with aplay and sox.
Michael.
On 25-03-08 01:29, Rene Herman wrote:
On 25-03-08 00:56, Michael Cree wrote:
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.
Oh, by the way, note that it only disabled mmap for CONFIG_ALPHA_MIATA due to your report of es18xx working fine on the XP1000, so you'll have to change that to CONFIG_ALPHA_DP264 for the XP1000 to actually test it there:
(or just delete SNDRV_PCM_INFO_MMAP from the info structures in the driver as Takashi earlier instructed)
Rene.
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_DP264 +#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 */
Rene Herman wrote:
(...) 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.
(...)
(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. Aborted by signal Aborted...
The ES18xx IRQ (5) is still not seeing any interrupt activity.
I *think* the only thing I haven't tried is Rene's patch that plays around with the irqmask (es18xx_trial_and_error). I'll give that a shot and report back as soon as possible.
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.
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.
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.
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...
(es18xx_trial_and_error)
As distributed, no change: still not seeing any activity on IRQ 5. I'll play around with it some over the next day or so.
Observed: the alsa "snd-sb8" driver works fine. Question: how does IRQ setup differ between the sb8 and the es18xx drivers? If I can find some time, I'll try to figure that out...
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?
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.
At Fri, 14 Mar 2008 21:18:19 -0400, Tyson Whitehead wrote:
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.
I vaguely remember about the patch... The patch below was on my local tree but never pushed because of lack of testing. Does it work for you?
Even then, though, I believe it still only works in 8bit mode.
Maybe the problem is in a different place, then...
thanks,
Takashi
---
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)
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; */@@ -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.
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; */@@ -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...
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.
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
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.
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
I'll be trying that just a little later today, as in, sometime in the next half hour or so.
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?
I don't have either of the two files mentioned above. As far as the alsa userland, I would think it's all "reasonably" current. I'm running Debian "Etch" fully patched/updated. I'll normally refrain from running things in the "unstable" or "experimental" categories unless something is broken in the "stable" tree that isn't getting fixed (e.g., a libc problem). Beyond that, I also tend to run the latest kernels to make sure we (the community) get an early warning if there are problems with kernel updates/changes on the Alpha architecture. Because it's a reasonably small list, here is the relevant "dpkg -l" output for alsa packages:
Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-==================================-====================================-================================================================ ii alsa-base 1.0.13-5etch1 ALSA driver configuration files ii alsa-oss 1.0.12-1 ALSA wrapper for OSS applications ii alsa-utils 1.0.13-2 ALSA utilities ii alsaplayer-alsa 0.99.76-9 PCM player designed for ALSA (ALSA output module) ii alsaplayer-common 0.99.76-9 PCM player designed for ALSA (common files) ii alsaplayer-esd 0.99.76-9 PCM player designed for ALSA (EsounD output module) ii alsaplayer-gtk 0.99.76-9 PCM player designed for ALSA (GTK version) ii gstreamer0.10-alsa 0.10.10-4 GStreamer plugin for ALSA ii libasound2 1.0.13-2 ALSA library ii linux-sound-base 1.0.13-5etch1 base package for ALSA and OSS sound systems
No change with "aplay -M"? (and) 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
Reported on the results of the various "sox" tests in that article last night.
For all of the above, I need to mention I am/was running an unpatched 2.6.25-rc7 kernel. "cat /proc/interrupts" shows absolutely no interrupt activity for the ES1888. Here's the current and complete output for an uptime of 1 day, 14:14:
1: 10718 XT-PIC i8042 2: 0 XT-PIC cascade 4: 1 XT-PIC serial 5: 0 XT-PIC +ES18xx 8: 140919958 RTC +timer 12: 13965 XT-PIC i8042 14: 1231903 XT-PIC ide0 18: 0 PYXIS halt-switch 22: 0 PYXIS timer-cascade 23: 0 PYXIS isa-cascade 24: 116344 PYXIS eth0 32: 14938196 PYXIS radeon@pci:0000:00:0c.0 40: 417084 PYXIS qla1280 ERR: 0
Ok. Let me boot on the kernel with the "miata_no_mmap" patch and give that a spin. I'll report back shortly.
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.
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
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.
On Wednesday, 12 of March 2008, Rene Herman wrote:
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.
Done.
Thanks, Rafael
Michael Cree wrote:
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.
After thinking about this more, I am wondering if the appearance of the ESS1888 not working then coming right at about the 1.0.13 alsa release is an artefact of when I shifted from mainly using the PWS600au to mainly using the XP1000, and then trying out the es18xx driver at some stage, finding it works on the XP1000, but forgetting that it was on the PWS600au that it didn't work. It's in the distant past now and memory is getting hazy...
Michael.
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
participants (7)
-
Ivan Kokshaysky -
Michael Cree -
Rafael J. Wysocki -
rct＠frus.com -
Rene Herman -
Takashi Iwai -
Tyson Whitehead