Re: [alsa-devel] [regression] 2.6.25-rc4 snd-es18xx broken on Alpha
rct wrote:
Rene Herman wrote:
Okay, and applying the attached just makes your sound completely dead in the water? (patch to remove es1888_init from a Miata build omitted)
I'll try a build with the old OSS "sb" driver, and if that works ok, we may be able to do away with es1888_init() on the Miata. Tyson -- I think you have a Miata if I'm remembering correctly: can you confirm these observations?
Quick followup: OSS "sb" driver works fine without es1888_init().
Bob Tracy wrote:
rct wrote:
Rene Herman wrote:
Okay, and applying the attached just makes your sound completely dead in the water? (patch to remove es1888_init from a Miata build omitted)
I'll try a build with the old OSS "sb" driver, and if that works ok, we may be able to do away with es1888_init() on the Miata. Tyson -- I think you have a Miata if I'm remembering correctly: can you confirm these observations?
Quick followup: OSS "sb" driver works fine without es1888_init().
Okay. I finally got everything tested on my Miata. Unless I missed something, the es1888_init routine only gets compiled in with CONFIG_ALPHA_MIATA. As I've been using the debian generic kernel (i.e., CONFIG_ALPHA_GENERIC), I have never relied on this routine for anything.
I did discover, however, when I compiled my own kernel (2.6.25-rc5) with CONFIG_ALPHA_MIATA, things stopped working. Specifically, I no longer got any interupts (with or without the es1888_init patch and with or without the alternative es188xx interupt patch) associated with either the builtin sound card (es1888) or the IDE controller (CMD646).
With CONFIG_ALPHA_GENERIC I only get one interupt with the es18xx driver unless I applied to "alternative interupt" handling code. Further, sometime between 2.6.14 and 2.6.16, mpg321 (using the alsa driver) started generating "Bad page state in process 'mpg321' ... Trying to fix it up, but a reboot is needed" kernel messages.
The machine would continue to operate okay though. However, somewhere between 2.6.16 and 2.6.24, it also started crashing very shortly thereafter, giving the following backtrace: free_pages_check, free_hot_cold_pages, put_pages, free_page_and_swap_cache, unmap_cmas, unmap_region, default_wake_function, do_munmap, sys_munmap, entSys.
Hope this helps.
Cheers! -Tyson
On 01-04-08 20:07, Tyson Whitehead wrote:
Hope this helps.
Not really no. A lot of data has come in by now and I'll try to sort through it trying to distill some sense out of it all later but throwing my hands up in the air and finding some older Alpha system to urinate on sounds about as good an idea as any at the moment.
Rene.
On 01-04-08 20:07, Tyson Whitehead wrote:
Hope this helps.
Not really no. A lot of data has come in by now and I'll try to sort through it trying to distill some sense out of it all later but throwing my hands up in the air and finding some older Alpha system to urinate on sounds about as good an idea as any at the moment.
Rene.
On 01-04-08 20:07, Tyson Whitehead wrote:
Hope this helps.
Not really no. A lot of data has come in by now and I'll try to sort through it trying to distill some sense out of it all later but throwing my hands up in the air and finding some older Alpha system to urinate on sounds about as good an idea as any at the moment.
Rene.
Rene Herman wrote:
On 01-04-08 20:34, Rene Herman wrote:
On 01-04-08 20:07, Tyson Whitehead wrote:
Hope this helps.
Not really no.
Sorry for the multiple copies; my ISP is crashing again.
Rene.
And here I was, thinking you were giving us a *really* strong hint that you would like one of us to ship you an Alpha to play with :-).
Tyson Whitehead wrote:
Okay. I finally got everything tested on my Miata. Unless I missed something, the es1888_init routine only gets compiled in with CONFIG_ALPHA_MIATA.
The current arch/alpha/kernel/Makefile build logic shows es1888.o built as part of CONFIG_ALPHA_GENERIC, but if that option isn't enabled, then enabling any of the following configuration options will cause es1888.o to be built:
CONFIG_ALPHA_DP264 CONFIG_ALPHA_SHARK CONFIG_ALPHA_MIATA
As I've been using the debian generic kernel (i.e., CONFIG_ALPHA_GENERIC), I have never relied on this routine for anything.
I did discover, however, when I compiled my own kernel (2.6.25-rc5) with CONFIG_ALPHA_MIATA, things stopped working. Specifically, I no longer got any interupts (with or without the es1888_init patch and with or without the alternative es188xx interupt patch) associated with either the builtin sound card (es1888) or the IDE controller (CMD646).
Interesting. I *seldom* use the Debian generic kernel. It's available, and I install updated versions when they are released, but all of my testing has been with kernels built from the standard kernel.org sources with CONFIG_ALPHA_MIATA enabled.
With CONFIG_ALPHA_GENERIC I only get one interupt with the es18xx driver unless I applied to "alternative interupt" handling code. Further, sometime between 2.6.14 and 2.6.16, mpg321 (using the alsa driver) started generating "Bad page state in process 'mpg321' ... Trying to fix it up, but a reboot is needed" kernel messages.
This is consistent with what I remember you reporting when we were looking at this back in the 2.6.14 timeframe. I was reporting the "bad page state" problems with 2.6.22-rc6 and -rc7. In my case, the trigger was a different application, but only happened when snd_es18xx was loaded. Hugh Dickins suggested it was a regression introduced in 2.6.15 that I had managed to successfully avoid tripping on :-). The analysis went something like this:
sound/isa/es18xx.c: snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV, ... led us to sound/core/memalloc.c: res = dma_alloc_coherent(dev, PAGE_SIZE << pg, dma, gfp_flags); where __GFP_COMP was carefully included in gfp_flags to avoid the kinds of problems I was seeing (replacing the pre-2.6.15 use of PageReserved).
Hugh said we could blame him or Nick for removing the special PageReserved usage, or the Alpha for ignoring gfp_flags in the following:
#define dma_alloc_coherent(dev, size, addr, gfp) \ pci_alloc_consistent(alpha_gendev_to_pci(dev), size, addr)
The workaround (until the official patch was issued) was a small patch against arch/alpha/kernel/pci_iommu.c:pci_alloc_consistent() that replaced "gfp_t gfp = GFP_ATOMIC;" with "gfp_t gfp = GFP_ATOMIC|__GFP_COMP;". That eliminated the "bad page state" errors for me, and I don't recall what the official patch was.
On 2/04/2008, at 9:26 AM, Bob Tracy wrote:
Hugh said we could blame him or Nick for removing the special PageReserved usage, or the Alpha for ignoring gfp_flags in the following:
#define dma_alloc_coherent(dev, size, addr, gfp) \ pci_alloc_consistent(alpha_gendev_to_pci(dev), size, addr)
The workaround (until the official patch was issued) was a small patch against arch/alpha/kernel/pci_iommu.c:pci_alloc_consistent() that replaced "gfp_t gfp = GFP_ATOMIC;" with "gfp_t gfp = GFP_ATOMIC| __GFP_COMP;". That eliminated the "bad page state" errors for me, and I don't recall what the official patch was.
The official patch has just been uploaded to the -mm kernel. Get it at:
http://userweb.kernel.org/~akpm/mmotm/broken-out/alpha-fix-alsa-dma-mmap-cra...
It fixed up quite a number of sound playing applications that were causing kernel oops on my newer PWS600au (the older one still has problems that are of a completely different nature) and also fixed use of an M-Audio Revolution audio card on my XP1000.
The repeated small passages at the end of a short sound file still occurs with the es18xx driver on the newer PWS600au (and to a lesser extent on the Compaq XP1000). Other sound drivers (cmipci, ice1724) do not exhibit the same anomalous symptoms so the problem is probably in the es18xx driver.
The older PWS600au fails to play sound at all and exhibits the behaviour you described in a recent message (machine gun like noises and the interrupts don't clock up at all) with the es18xx driver. I tried to put the C-Media audio card (which uses the cmipci driver) into this machine, but SRM reports on powerup that there is an "illegal" card installed (I hope the police don't turn up at my door) and that it must be removed to continue booting!!! I tried setting pci_device_override to 1 in SRM, but that didn't help. So I can't verify whether this is an es18xx specific problem or a more general alsa problem.
Now that the crashes due to "bad page state" errors are solved on both of my PWS600aus, maybe I should start re-applying the es18xx interrupt type patches that Tyson, et al., suggested and see if they now make a difference. I will not be able to do this before the weekend.
Cheerz Michael.
participants (5)
-
Michael Cree -
rct＠frus.com -
Rene Herman -
Rene Herman -
Tyson Whitehead