Re: [mac80211_hwsim] BUG: unable to handle kernel paging request at ce1db404

From: Krishna Chaitanya
Date: Wed Mar 12 2014 - 16:45:54 EST


On Wed, Mar 12, 2014 at 11:04 PM, Martin Pitt <martin.pitt@xxxxxxxxxx> wrote:
>
> Fengguang Wu [2014-03-08 20:11 +0800]:
> > [ 4.429993] mac80211_hwsim: ieee80211_register_hw failed (-2)
> > [...]
> > [ 4.431924] [<c12377de>] get_device+0xf/0x17
> > [ 4.431924] [<c123a165>] driver_detach+0x38/0x8f
> > [ 4.431924] [<c1239433>] bus_remove_driver+0x53/0x66
> > [ 4.431924] [<c123a535>] driver_unregister+0x38/0x3d
> > [ 4.431924] [<c123b3aa>] platform_driver_unregister+0xb/0xd
> > [ 4.431924] [<c1c4ac9f>] init_mac80211_hwsim+0x3a5/0x3b6
>
>
> So that first message is from
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/wireless/mac80211_hwsim.c?id=9ea927748#n2428
>
> At this point we registered the platform driver and the class, and it
> should have created two devices (at least for the default radios=2).
> What's odd is that I don't see this printk in your kernel log:
>
> mac80211_hwsim: Initializing radio %d
>
> If for some reasons "radio" is 0, it would not show this and not
> initialize data->dev, but then you shouldn't get to
> ieee80211_register_hw() either as it's in the same loop. So that's a
> bit of a mystery to me.
>
> On failure, above ieee80211_register_hw() jumps to the cleanup:
>
> | failed_hw:
> | device_unregister(data->dev);
> | failed_drvdata:
> | ieee80211_free_hw(hw);
> | failed:
> | mac80211_hwsim_free();
> | failed_unregister_driver:
> | driver_unregister(&mac80211_hwsim_driver);
> | return err;
> | }
>
>
> The mac80211_hwsim_free() function again calls
> device_unregister(data->dev) for a list (not sure which, I'm not
> certain how to interpret
>
> list_for_each_entry_safe(data, tmpdata, &tmplist, list)
>
> ) Could that be the double free causing the memory corruption?
>
> If you are in a position to do quick builds and tests, does the crash
> go away with this?
>
> printk(KERN_DEBUG "mac80211_hwsim: device_bind_driver failed (%d)\n",
> err);
> - goto failed_hw;
> + goto failed_drvdata;
> }
>
> (I'm not claiming that this is correct, just taking a stab at
> understanding what happens) If not, does it go away with changing the
> goto to failed_unregister_driver()?
>
>From the logs it looks like "rate_control_alloc" is failed,
causing ieee80211_register_hw to fail triggering the crash.
what RC are u using? Default should be minstrel, i dont see
a reason for rc alloc to fail (remote reason kmalloc failure),
so did you disable RC completely? No prints either w.r.t RC either in
dmesg?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/