I feel bad about bringing this one up because I honestly have no idea
*when* the driver quit working. (I don't always have a spare set of
speakers available for the Alpha). This literally could have been
broken for months...
Symptoms:
(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.
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
Here are the ALSA module options I've always had defined in
/etc/modprobe.d/sound:
alias snd-card-0 snd-es18xx
alias sound-slot-0 snd-es18xx
options snd-es18xx enable=1 isapnp=0 port=0x220 irq=5 dma1=1 dma2=5 mpu_port=0x330
--
------------------------------------------------------------------------
Bob Tracy | "I was a beta tester for dirt. They never did
[email protected] | get all the bugs out." - Steve McGrew on /.
------------------------------------------------------------------------
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...
Ivan.
Ivan Kokshaysky wrote:
> Sounds like a DMA screwup.
Agreed. There's a comment line near the top of the es18xx.c that has
been there for a *long* time:
Support for 16 bit DMA seems to be broken. I've no hardware
to tune it.
Supposedly with the ES1888, dma1 is for capture, dma2 is for playback.
dma2 == 5 is a 16-bit channel, yes? That could explain much...
As for the values "chosen" for dma1 and dma2, they are the ones that
keep showing up in the Alpha sound "howto" postings/documents. The
driver can cope with dma1 == dma2 by enforcing half-duplex mode in
software, but the OSS "sb" driver works fine with the indicated DMA
channel values. Besides, if the ES1888 is really capable of full-duplex
operation, a potential half-duplex workaround doesn't have much appeal.
> I wonder if it still works on x86 - perhaps you ought to ask ALSA folks.
I tried contacting the driver authors as indicated in the driver source
file. Christian Fischbach seems to have disappeared. Still waiting to
hear from Abramo Bagnara.
--
------------------------------------------------------------------------
Bob Tracy | "I was a beta tester for dirt. They never did
[email protected] | get all the bugs out." - Steve McGrew on /.
------------------------------------------------------------------------
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...
>
> 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.
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. More
onerously, my testing eventually ended in a complete system lock up!
I ran play (or was it aplay - sorry can't remember now) 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.
Cheerz
Michael.
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.
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.
--
------------------------------------------------------------------------
Bob Tracy | "I was a beta tester for dirt. They never did
[email protected] | get all the bugs out." - Steve McGrew on /.
------------------------------------------------------------------------
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.
--
------------------------------------------------------------------------
Bob Tracy | "I was a beta tester for dirt. They never did
[email protected] | get all the bugs out." - Steve McGrew on /.
------------------------------------------------------------------------
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:
> 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
[email protected] | get all the bugs out." - Steve McGrew on /.
------------------------------------------------------------------------
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.
--
------------------------------------------------------------------------
Bob Tracy | "I was a beta tester for dirt. They never did
[email protected] | get all the bugs out." - Steve McGrew on /.
------------------------------------------------------------------------
commit 8fa1de6349913b63d8ebfb27003b7045eeb9f12a
Author: Rene Herman <[email protected]>
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.
--
------------------------------------------------------------------------
Bob Tracy | "I was a beta tester for dirt. They never did
[email protected] | get all the bugs out." - Steve McGrew on /.
------------------------------------------------------------------------
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).
--
------------------------------------------------------------------------
Bob Tracy | "I was a beta tester for dirt. They never did
[email protected] | get all the bugs out." - Steve McGrew on /.
------------------------------------------------------------------------
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
[email protected] | get all the bugs out." - Steve McGrew on /.
------------------------------------------------------------------------
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.
--
------------------------------------------------------------------------
Bob Tracy | "I was a beta tester for dirt. They never did
[email protected] | get all the bugs out." - Steve McGrew on /.
------------------------------------------------------------------------
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
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
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
[email protected] | get all the bugs out." - Steve McGrew on /.
------------------------------------------------------------------------
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
[email protected] | get all the bugs out." - Steve McGrew on /.
------------------------------------------------------------------------
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
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)
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
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.
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
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.
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.
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.
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.
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.
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.
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 */
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.
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.
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 */
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
[email protected] | get all the bugs out." - Steve McGrew on /.
------------------------------------------------------------------------
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.
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
[email protected] | get all the bugs out." - Steve McGrew on /.
------------------------------------------------------------------------
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
[email protected] | get all the bugs out." - Steve McGrew on /.
------------------------------------------------------------------------
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:
>>>
>>> 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.
>>
> 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.
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.
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 <[email protected]>
---
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
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.
--
------------------------------------------------------------------------
Bob Tracy | "I was a beta tester for dirt. They never did
[email protected] | get all the bugs out." - Steve McGrew on /.
------------------------------------------------------------------------
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 Tracy | "I was a beta tester for dirt. They never did
[email protected] | get all the bugs out." - Steve McGrew on /.
------------------------------------------------------------------------
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.
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.
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
[email protected] | get all the bugs out." - Steve McGrew on /.
------------------------------------------------------------------------
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...
--
------------------------------------------------------------------------
Bob Tracy | "I was a beta tester for dirt. They never did
[email protected] | get all the bugs out." - Steve McGrew on /.
------------------------------------------------------------------------