On 23-03-08 11:40, Michael Cree wrote:

quoted text
> 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.

quoted text
> 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.

quoted text
> 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.