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