Peter Teoh wrote:
> On Mon, Jan 12, 2009 at 5:43 AM, Frank Thieme <[email protected]> wrote:
>> Unable to handle kernel NULL pointer dereference at virtual address 00000000
>> pgd = c349c000
>>
>
> my guess: some structures not properly initialized before accessing it?
>
Somewhat like that ist my guess, too. But I didn't see where...
>> Backtrace:
>> [<c0109a04>] (vsnprintf+0x0/0x5c8) from [<c012c698>]
>> (device_create+0x78/0xb4)
>> [<c012c624>] (device_create+0x4/0xb4) from [<bf000368>]
>> (init_module+0x14c/0x1f)
>>
This leads to vsnprintf which is called in the 2.6.22 and the 2.6.27
version...
> and because u mentioned it worked in later kernel, so why not take the
> diff between device_create() between the two kernel versions and
> analyze from there:
>
I looked there already. The only difference seemed to me the way the
kernel handles the "fmt, ..." args. In 2.6.22 all is handled in
device_create() whereas in 2.6.27 this is handled in device_create and
vsnprintf is called in device_create_vargs().
> my analysis is that both version have the same initialization in
> device_create() implementation except for
>
> dev->devt = devt;
> dev->class = class;
> dev->parent = parent;
> dev->release = device_create_release;
> dev_set_drvdata(dev, drvdata);=============> this is NOT done in
> 2.6.22.
>
> vsnprintf(dev->bus_id, BUS_ID_SIZE, fmt, args);
> retval = device_register(dev);
>
>
> So what if u add this into the 2.6.22 - does it solve the problem?
>
dev_set_drvdata() does
static inline void dev_set_drvdata(struct device *dev, void *data)
{
dev->driver_data = data;
}
this shouldn't do any difference in the vsnprintf() call, should it?
Bye...Frank
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to [email protected]
Please read the FAQ at http://kernelnewbies.org/FAQ
