lkml.org 
[lkml]   [2008]   [Mar]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [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 */
\
 
 \ /
  Last update: 2008-03-24 19:17    [W:0.147 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site