Messages in this thread Patch in this message | | | Date | Mon, 24 Mar 2008 19:15:59 +0100 | From | Rene Herman <> | Subject | Re: [alsa-devel] [regression] 2.6.25-rc4 snd-es18xx broken on Alpha |
| |
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 */ | |