Takashi and other gurus in alsa-devel, any comments on this? The
original problem - not quoted in this email - is that when I stop jackd
in the affected configurations I get errors similar to this one:
Bad page state at __free_pages_ok (in process 'jackd', page c1013ce0)
flags:0x00000414 mapping:00000000 mapcount:0 count:0
Backtrace:
[<c015947d>] bad_page+0x7d/0xc0 (8)
[<c01598fd>] __free_pages_ok+0x9d/0x180 (36)
[<c015a5ac>] __pagevec_free+0x3c/0x50 (40)
[<c015db47>] release_pages+0x127/0x1a0 (16)
[<c016c93d>] free_pages_and_swap_cache+0x7d/0xc0 (80)
[<c01681ae>] unmap_region+0x13e/0x160 (28)
[<c0168461>] do_munmap+0xe1/0x120 (48)
[<c01684df>] sys_munmap+0x3f/0x60 (32)
[<c01034a1>] syscall_call+0x7/0xb (16)
Trying to fix it up, but a reboot is needed
One other thing occurred to me (not tested yet)
- userspace regression in the module load code (so that in the end
modules from the in kernel tree get mixed with modules coming from the
externally compiled alsa tree). Very unlikely, I think, I could test for
this by removing the in kernel modules temporarily.
I have problems in both:
snd-ice1712 (midiman delta 66)
snd-hdsp (rme hdsp)
but this seems to work fine:
snd-echo3g (gina3g)
The interesting thing is that the one that works (snd-echo3g) has no
counterpat in the in kernel alsa tree - that is, only exists in the
add-on modules compiled externally. Coincidence?
-- Fernando