[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1233760607.15119.85.camel@desktop>
Date: Wed, 04 Feb 2009 07:16:47 -0800
From: Daniel Walker <dwalker@...o99.com>
To: Luca Olivetti <luca@...toso.org>
Cc: Ingo Molnar <mingo@...e.hu>, Greg KH <gregkh@...e.de>,
Mauro Carvalho Chehab <mchehab@...radead.org>,
linux-kernel@...r.kernel.org, Hans Verkuil <hverkuil@...all.nl>,
Janne Grunau <janne-dvb@...nau.be>
Subject: Re: [crash] af9005_usb_module_init(): BUG: unable to handle kernel
paging request at ff100000
On Wed, 2009-02-04 at 15:52 +0100, Luca Olivetti wrote:
> En/na Daniel Walker ha escrit:
> > On Tue, 2009-02-03 at 21:41 +0100, Luca Olivetti wrote:
> >
> >> No, I don't have 2.6.28, but I guess that maybe once usb_register is
> >> called the dvb-usb subsystem asynchronously (is that an smp system?)
> >> starts polling the remote before the rc_decode function pointer has been
> >> initialized.
> >> Could you try to initialize it to NULL before calling usb_register?
> >
> > What happens to the decode function when you have,
> >
> > CONFIG_DVB_USB_AF9005=y
> > CONFIG_DVB_USB_AF9005_REMOTE=n
> >
> > It seems that the decode function is defined inside,
> > drivers/media/dvb/dvb-usb/af9005-remote.c
> >
> > but that doesn't get compiled in the case above. It looks like you end
> > up with af9005_rc_decode being a function local weak symbol
> > (uninitialized) which then gets assigned to rc_decode .. I think the
> > crash actually happens on rc_keys_size which get assigned another
> > uninitialized local, and it gets de-referenced .
>
> Doesn't symbol_request return a NULL in such a case?
> At the time I didn't try the above configuration
> (CONFIG_DVB_USB_AF9005_REMOTE=n), but removed the compiled
> dvb-usb-af9005-remote.ko, and all was well (i.e. the symbol_request
> returned NULL and the remote handling was disabled).
I'm not sure what symbol request returns when CONFIG_MODULES=n .. Since
it basically drops symbol_request() into a macro , and you have externs
for all these functions .. Now that I look at it again, I'm not sure how
it compiles..
> > Here's a patch I compile tested, and I think it would fix the issue.
>
> But it'd break the alternative rc decoding module (not integrated in the
> kernel because it uses lirc):
>
> http://ventoso.org/luca/af9005/README.lirc
I guess that would have to be fix with another patch then ..
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists