On Fri, Nov 14, 2008 at 11:02 AM, Bob Copeland <me@xxxxxxxxxxxxxxx> wrote:
> On Fri, Nov 14, 2008 at 1:17 AM, Luis R. Rodriguez <mcgrof@xxxxxxxxx> wrote:
>> If our offsets are the same then its probably on line 791:
> [...]
>> 790 name = wiphy_dev(local->hw.wiphy)->driver->name;
>> 791 local->hw.workqueue = create_freezeable_workqueue(name);
>
> I agree, having looked at the objdump output. Hmm, maybe ->driver pointer
> is bad even though I can't see that happening. Dan, can you try adding a
> printk before line 790 to see if any of the pointers are null?
So I went back and added a few things to the original unpatched code
to see what was NULL pointering, just to be sure we were thinking
right. Here is the relevant code:
printk(KERN_DEBUG "wiphy_dev() : %p\n", wiphy_dev(local->hw.wiphy));
printk(KERN_DEBUG "driver : %p\n",
wiphy_dev(local->hw.wiphy)->driver);
printk(KERN_DEBUG "driver->name: %p\n",
wiphy_dev(local->hw.wiphy)->driver->name);
name = wiphy_dev(local->hw.wiphy)->driver->name;
local->hw.workqueue = create_freezeable_workqueue(name);
And the dmesg output:
ath5k_pci xxx: registered as ''
wiphy_dev() : b730b408
driver : 00000001
BUG: unalbe to handle kernel NULL pointer dereference at 00000001
So we bugged out on trying to print driver->name, which is the same
problem we would have hit in the 'name =' line.
-Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
