lkml.org 
[lkml]   [2008]   [Mar]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [alsa-devel] [regression] 2.6.25-rc4 snd-es18xx broken on Alpha
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.



\
 
 \ /
  Last update: 2008-03-23 11:43    [W:0.132 / U:1.268 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site