I was unloading ALSA (modular) when I got this lovely oops:
(linux-2.5.47)
Unable to handle kernel paging request at virtual address e08c0418
printing eip:
e08c0418
*pde = 015dc067
*pte = 00000000
Oops: 0000
ide-cd cdrom snd-timer snd-ac97-codec snd
CPU: 0
EIP: 0060:[<e08c0418>] Not tainted
EFLAGS: 00210286
EIP is at E __insmod_snd-timer_S.data_L216+0xaeb8/0xd8 [snd-timer]
eax: e08c0418 ebx: de880ec0 ecx: e08b5578 edx: e08b5564
esi: de880fa0 edi: de880ec0 ebp: e08b5578 esp: c4893f60
ds: 0068 es: 0068 ss: 0068
Process rmmod (pid: 4554, threadinfo=c4892000 task=cd239980)
Stack: e08b2dd2 de880ec0 e08b5578 e08b2f8b de880ec0 dfd95878 e08b2000 ce1f0000
e08b2000 e08b3ebb de880ec0 fffffff0 c011aab7 fffffff0 e08b2000 ce1f0000
bfffebd8 c0119ee0 e08b2000 00000000 c4892000 00000001 bfffebd8 bfffebd8
Call Trace:
[<e08b2dd2>] snd_timer_free+0x12/0x24 [snd-timer]
[<e08b5578>] register_mutex+0x0/0x14 [snd-timer]
[<e08b2f8b>] snd_timer_unregister+0x93/0x9c [snd-timer]
[<e08b3ebb>] cleanup_module+0x2b/0x65 [snd-timer]
[<c011aab7>] free_module+0x17/0xc0
[<c0119ee0>] sys_delete_module+0x124/0x27c
[<c0108943>] syscall_call+0x7/0xb
Kernel config attached.
--
Taral <[email protected]>
This message is digitally signed. Please PGP encrypt mail to me.
"Pretty please with dollars on top?" -- Me
On Mon, 18 Nov 2002, Taral wrote:
> I was unloading ALSA (modular) when I got this lovely oops:
> (linux-2.5.47)
Looks like you loaded ens137x.c and then that driver got unloaded leaving
the callback still valid, then the core timer code decided to walk off a
cliff using that pointer.
0xc0365322 is in snd_timer_free (sound/core/timer.c:676).
671 static int snd_timer_free(snd_timer_t *timer)
672 {
673 snd_assert(timer != NULL, return -ENXIO);
674 if (timer->private_free)
675 timer->private_free(timer);
676 snd_magic_kfree(timer);
677 return 0;
678 }
The problem seems to be a sort of chicken/egg case? We can't rely on
modules being around even with this inter dependency case.
Zwane
--
function.linuxpower.ca
On Mon, 18 Nov 2002, Zwane Mwaikambo wrote:
> Looks like you loaded ens137x.c and then that driver got unloaded leaving
> the callback still valid, then the core timer code decided to walk off a
> cliff using that pointer.
Not really the case, probably from pcm code.
> 0xc0365322 is in snd_timer_free (sound/core/timer.c:676).
> 671 static int snd_timer_free(snd_timer_t *timer)
> 672 {
> 673 snd_assert(timer != NULL, return -ENXIO);
> 674 if (timer->private_free)
> 675 timer->private_free(timer);
> 676 snd_magic_kfree(timer);
> 677 return 0;
> 678 }
>
> The problem seems to be a sort of chicken/egg case? We can't rely on
> modules being around even with this inter dependency case.
Perhaps driver specific code should be doing as much of their own cleanup
as possible. I'm still wondering how this managed to unload without that
getting run, unless its a simple case of forgetting a failure path.
Zwane
--
function.linuxpower.ca
On Mon, Nov 18, 2002 at 04:07:17AM -0500, Zwane Mwaikambo wrote:
> Looks like you loaded ens137x.c and then that driver got unloaded leaving
> the callback still valid, then the core timer code decided to walk off a
> cliff using that pointer.
I don't have ens137x.c compiled, much less loaded. What makes you think
this?
--
Taral <[email protected]>
This message is digitally signed. Please PGP encrypt mail to me.
"Pretty please with dollars on top?" -- Me
On Mon, 18 Nov 2002, Taral wrote:
> On Mon, Nov 18, 2002 at 04:07:17AM -0500, Zwane Mwaikambo wrote:
> > Looks like you loaded ens137x.c and then that driver got unloaded leaving
> > the callback still valid, then the core timer code decided to walk off a
> > cliff using that pointer.
>
> I don't have ens137x.c compiled, much less loaded. What makes you think
> this?
It was a guess, i presumed you were using one of the ac97 cards. Anyway
it's irrelevant right now. You could of course make your problem report
more descriptive wrt to what you loaded/unloaded, which order etc, so that
reproducing and walking through the code paths is easier.
Zwane
--
function.linuxpower.ca