Re: [Alsa-devel] Re: 2.6.15-rt20, "bad page state", jackd

[Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU>]

On Fri, 2006-03-10 at 10:50 -0800, Fernando Lopez-Lezcano wrote:
> On Fri, 2006-03-10 at 16:08 +1100, Nick Piggin wrote:
> > Fernando Lopez-Lezcano wrote:
> > > On Fri, 2006-03-10 at 09:57 +1100, Nick Piggin wrote:
> > >>Fernando Lopez-Lezcano wrote:
> > >>Can you test with the latest mainline -git snapshot, or is it only
> > >>the -rt tree that causes the warnings?
> > > 
> > > I found something strange although I don't know why it happens yet:
> > > 
> > >   Fedora Core 4 kernel (2.6.15 + patches) works fine.
> > >   Fedora Core 4 kernel + -rt21, [ahem... sorry], works fine.
> > >   Fedora Core 4 kernel + -rt21 + alsa kernel modules from 1.0.10 or
> > >      1.0.11rc3, fails[*]
> > >   Plain vanilla 2.6.15 + -rt21, works fine
> > >   Plain vanilla 2.6.15 + -rt21 + alsa kernel modules from 1.0.10 or
> > >      1.0.11rc3, fails[*]
> > > 
> > > So, it looks like it is some weird interaction between kernel modules
> > > that were not compiled as part of the kernel and the kernel itself. The
> > > "updated" modules are installed in a separate location (not on top of
> > > the built in kernel modules) and are found before the ones in the kernel
> > > tree.
> > > 
> > > I have been building this combination for a long long time with no
> > > problems, I don't know what might have happened that changed things.
> > > 
> > > Could be:
> > > - configuration problems?
> > 
> > No. It shouldn't do this even if there is a configuration problem.
> > 
> > > - the alsa tree is somehow incompatible with the kernel alsa tree, is
> > >   that even possible?
> >
> > Yes. Most likely this. It should be fixed before the new ALSA code is
> > pushed upstream.
> > 
> > It is probably not so much a matter of somebody breaking the ALSA code
> > as that it hasn't been updated for the new kernel refcounting rules.
> 
> 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 just tested this and no, it is not the problem. I removed all
in-kernel modules that started with snd-* and reloaded alsa (making sure
that nothing remained loaded from the previous drivers): same problem.
It really starts to looks like it is an incompatibility between the
current alsa tree (outside of the kernel) and the current kernels. 

-- Fernando