Hello. I noticed that the libertas driver causes a kernel oops in
more recent wireless-testing kernels (I am bisecting right now to
narrow this down). To reproduce, load the driver and run iwconfig,
causing lbs_get_freq() to be called.
So far I know that this problem doesn't exist at the 2.6.28-rc2 tag
(commit 0173a3265b228da319ceb9c1ec6a5682fd1b2d92) but I have seen it
in -rc7 and up through today's wireless-testing. It seems that
there's a regression somewhere after -rc2. I've reproduced this with
the USB hardware as well as an SDIO board.
[ 118.571205] BUG: unable to handle kernel paging request at 00001e01
[ 118.578500] IP: [<c81fddda>] lbs_get_freq+0x1a/0x160 [libertas]
[ 118.585417] *pde = 00000000
[ 118.588877] Oops: 0000 [#1]
[ 118.592092] last sysfs file: /sys/block/ram9/range
[ 118.592385] Modules linked in: usb8xxx libertas lib80211
[ 118.592385]
[ 118.592385] Pid: 2317, comm: iwconfig Not tainted (2.6.28-wl #65) Uknown
[ 118.592385] EIP: 0060:[<c81fddda>] EFLAGS: 00010293 CPU: 0
[ 118.592385] EIP is at lbs_get_freq+0x1a/0x160 [libertas]
[ 118.592385] EAX: 00000000 EBX: 00000000 ECX: c6891ef8 EDX: c6891e98
[ 118.592385] ESI: c6891ef8 EDI: c6891ef8 EBP: c7295000 ESP: c6891e10
[ 118.592385] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
[ 118.592385] Process iwconfig (pid: 2317, ti=c6890000 task=c7349880
task.ti=c6890000)
[ 118.592385] Stack:
[ 118.592385] c8201b4b c6891ef8 00000010 ffffffa1 00008b05 c038aa20
00000000 c03c691c
[ 118.592385] 00000000 c04bc7e0 c0301287 b7f01d70 c68ce000 c6895000
c04c8260 00000c04
[ 118.592385] c68c7b7c 00000000 c7295000 c6891ee8 c0300325 c6891ee8
c7295000 c6891ee8
[ 118.592385] Call Trace:
[ 118.592385] [<c8201b4b>] lbs_get_name+0x2b/0xb0 [libertas]
[ 118.592385] [<c038aa20>] ioctl_standard_call+0x60/0x3a0
[ 118.592385] [<c0301287>] netif_receive_skb+0x1d7/0x3e0
[ 118.592385] [<c0300325>] __dev_get_by_name+0x75/0x90
[ 118.592385] [<c0300325>] __dev_get_by_name+0x75/0x90
[ 118.592385] [<c038a687>] wext_handle_ioctl+0x157/0x230
[ 118.592385] [<c81fddc0>] lbs_get_freq+0x0/0x160 [libertas]
[ 118.592385] [<c03034c4>] dev_ioctl+0x304/0x4f0
[ 118.592385] [<c02ffdd2>] net_rx_action+0x92/0x140
[ 118.592385] [<c027ca89>] pty_write+0x39/0x60
[ 118.592385] [<c02f4280>] sock_ioctl+0x0/0x260
[ 118.592385] [<c017e27f>] vfs_ioctl+0x1f/0x70
[ 118.592385] [<c017e65b>] do_vfs_ioctl+0x24b/0x490
[ 118.592385] [<c011654e>] update_curr+0x13e/0x190
[ 118.592385] [<c0117fab>] set_next_entity+0x2b/0x70
[ 118.592385] [<c0397c64>] schedule+0x1b4/0x350
[ 118.592385] [<c017e906>] sys_ioctl+0x66/0x70
[ 118.592385] [<c0103cd2>] syscall_call+0x7/0xb
[ 118.592385] Code: e9 38 ff ff ff 8d b6 00 00 00 00 8d bf 00 00 00
00 56 89 ce 53 83 ec 0c 8b 98 a4 01 00 00 a1 80 19 22 c8 83 e0 21 83
f8 21 74 42 <0f> b6 8b 01 1e 00 00 31 d2 89 d8 e8 a6 fe ff ff 85 c0 0f
84 cd
[ 118.592385] EIP: [<c81fddda>] lbs_get_freq+0x1a/0x160 [libertas]
SS:ESP 0068:c6891e10
[ 118.594153] ---[ end trace f426cd49b2b378f4 ]---
Hmm, I do see the problem start at
29726d85d7b98558a8bc8e69b859bf12e1347f9f and after, but I don't think
that I'm right with my analysis, especially since the OOPS happens in
wext.c and the functions there (namely lbs_get_freq) use netdev->priv
directly. I apologize for the noise but there is still something
wrong here that I'm trying to understand better.
-Andrey
On Wed, Jan 7, 2009 at 6:37 PM, Andrey Yurovsky <[email protected]> wrote:
> The commit that caused this regression is
> 29726d85d7b98558a8bc8e69b859bf12e1347f9f "netdevice libertas: Fix
> directly reference of netdev->priv" by Wang Chen. It probably causes
> a problem with netdev->priv's offset and then we get a pointer
> dereference problem when lbs_get_freq() tries to use its priv data.
>
> -Andrey
>
> On Wed, Jan 7, 2009 at 4:58 PM, Andrey Yurovsky <[email protected]> wrote:
>> Hello. I noticed that the libertas driver causes a kernel oops in
>> more recent wireless-testing kernels (I am bisecting right now to
>> narrow this down). To reproduce, load the driver and run iwconfig,
>> causing lbs_get_freq() to be called.
>>
>> So far I know that this problem doesn't exist at the 2.6.28-rc2 tag
>> (commit 0173a3265b228da319ceb9c1ec6a5682fd1b2d92) but I have seen it
>> in -rc7 and up through today's wireless-testing. It seems that
>> there's a regression somewhere after -rc2. I've reproduced this with
>> the USB hardware as well as an SDIO board.
>>
>> [ 118.571205] BUG: unable to handle kernel paging request at 00001e01
>> [ 118.578500] IP: [<c81fddda>] lbs_get_freq+0x1a/0x160 [libertas]
>> [ 118.585417] *pde = 00000000
>> [ 118.588877] Oops: 0000 [#1]
>> [ 118.592092] last sysfs file: /sys/block/ram9/range
>> [ 118.592385] Modules linked in: usb8xxx libertas lib80211
>> [ 118.592385]
>> [ 118.592385] Pid: 2317, comm: iwconfig Not tainted (2.6.28-wl #65) Uknown
>> [ 118.592385] EIP: 0060:[<c81fddda>] EFLAGS: 00010293 CPU: 0
>> [ 118.592385] EIP is at lbs_get_freq+0x1a/0x160 [libertas]
>> [ 118.592385] EAX: 00000000 EBX: 00000000 ECX: c6891ef8 EDX: c6891e98
>> [ 118.592385] ESI: c6891ef8 EDI: c6891ef8 EBP: c7295000 ESP: c6891e10
>> [ 118.592385] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
>> [ 118.592385] Process iwconfig (pid: 2317, ti=c6890000 task=c7349880
>> task.ti=c6890000)
>> [ 118.592385] Stack:
>> [ 118.592385] c8201b4b c6891ef8 00000010 ffffffa1 00008b05 c038aa20
>> 00000000 c03c691c
>> [ 118.592385] 00000000 c04bc7e0 c0301287 b7f01d70 c68ce000 c6895000
>> c04c8260 00000c04
>> [ 118.592385] c68c7b7c 00000000 c7295000 c6891ee8 c0300325 c6891ee8
>> c7295000 c6891ee8
>> [ 118.592385] Call Trace:
>> [ 118.592385] [<c8201b4b>] lbs_get_name+0x2b/0xb0 [libertas]
>> [ 118.592385] [<c038aa20>] ioctl_standard_call+0x60/0x3a0
>> [ 118.592385] [<c0301287>] netif_receive_skb+0x1d7/0x3e0
>> [ 118.592385] [<c0300325>] __dev_get_by_name+0x75/0x90
>> [ 118.592385] [<c0300325>] __dev_get_by_name+0x75/0x90
>> [ 118.592385] [<c038a687>] wext_handle_ioctl+0x157/0x230
>> [ 118.592385] [<c81fddc0>] lbs_get_freq+0x0/0x160 [libertas]
>> [ 118.592385] [<c03034c4>] dev_ioctl+0x304/0x4f0
>> [ 118.592385] [<c02ffdd2>] net_rx_action+0x92/0x140
>> [ 118.592385] [<c027ca89>] pty_write+0x39/0x60
>> [ 118.592385] [<c02f4280>] sock_ioctl+0x0/0x260
>> [ 118.592385] [<c017e27f>] vfs_ioctl+0x1f/0x70
>> [ 118.592385] [<c017e65b>] do_vfs_ioctl+0x24b/0x490
>> [ 118.592385] [<c011654e>] update_curr+0x13e/0x190
>> [ 118.592385] [<c0117fab>] set_next_entity+0x2b/0x70
>> [ 118.592385] [<c0397c64>] schedule+0x1b4/0x350
>> [ 118.592385] [<c017e906>] sys_ioctl+0x66/0x70
>> [ 118.592385] [<c0103cd2>] syscall_call+0x7/0xb
>> [ 118.592385] Code: e9 38 ff ff ff 8d b6 00 00 00 00 8d bf 00 00 00
>> 00 56 89 ce 53 83 ec 0c 8b 98 a4 01 00 00 a1 80 19 22 c8 83 e0 21 83
>> f8 21 74 42 <0f> b6 8b 01 1e 00 00 31 d2 89 d8 e8 a6 fe ff ff 85 c0 0f
>> 84 cd
>> [ 118.592385] EIP: [<c81fddda>] lbs_get_freq+0x1a/0x160 [libertas]
>> SS:ESP 0068:c6891e10
>> [ 118.594153] ---[ end trace f426cd49b2b378f4 ]---
>>
>
The commit that caused this regression is
29726d85d7b98558a8bc8e69b859bf12e1347f9f "netdevice libertas: Fix
directly reference of netdev->priv" by Wang Chen. It probably causes
a problem with netdev->priv's offset and then we get a pointer
dereference problem when lbs_get_freq() tries to use its priv data.
-Andrey
On Wed, Jan 7, 2009 at 4:58 PM, Andrey Yurovsky <[email protected]> wrote:
> Hello. I noticed that the libertas driver causes a kernel oops in
> more recent wireless-testing kernels (I am bisecting right now to
> narrow this down). To reproduce, load the driver and run iwconfig,
> causing lbs_get_freq() to be called.
>
> So far I know that this problem doesn't exist at the 2.6.28-rc2 tag
> (commit 0173a3265b228da319ceb9c1ec6a5682fd1b2d92) but I have seen it
> in -rc7 and up through today's wireless-testing. It seems that
> there's a regression somewhere after -rc2. I've reproduced this with
> the USB hardware as well as an SDIO board.
>
> [ 118.571205] BUG: unable to handle kernel paging request at 00001e01
> [ 118.578500] IP: [<c81fddda>] lbs_get_freq+0x1a/0x160 [libertas]
> [ 118.585417] *pde = 00000000
> [ 118.588877] Oops: 0000 [#1]
> [ 118.592092] last sysfs file: /sys/block/ram9/range
> [ 118.592385] Modules linked in: usb8xxx libertas lib80211
> [ 118.592385]
> [ 118.592385] Pid: 2317, comm: iwconfig Not tainted (2.6.28-wl #65) Uknown
> [ 118.592385] EIP: 0060:[<c81fddda>] EFLAGS: 00010293 CPU: 0
> [ 118.592385] EIP is at lbs_get_freq+0x1a/0x160 [libertas]
> [ 118.592385] EAX: 00000000 EBX: 00000000 ECX: c6891ef8 EDX: c6891e98
> [ 118.592385] ESI: c6891ef8 EDI: c6891ef8 EBP: c7295000 ESP: c6891e10
> [ 118.592385] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
> [ 118.592385] Process iwconfig (pid: 2317, ti=c6890000 task=c7349880
> task.ti=c6890000)
> [ 118.592385] Stack:
> [ 118.592385] c8201b4b c6891ef8 00000010 ffffffa1 00008b05 c038aa20
> 00000000 c03c691c
> [ 118.592385] 00000000 c04bc7e0 c0301287 b7f01d70 c68ce000 c6895000
> c04c8260 00000c04
> [ 118.592385] c68c7b7c 00000000 c7295000 c6891ee8 c0300325 c6891ee8
> c7295000 c6891ee8
> [ 118.592385] Call Trace:
> [ 118.592385] [<c8201b4b>] lbs_get_name+0x2b/0xb0 [libertas]
> [ 118.592385] [<c038aa20>] ioctl_standard_call+0x60/0x3a0
> [ 118.592385] [<c0301287>] netif_receive_skb+0x1d7/0x3e0
> [ 118.592385] [<c0300325>] __dev_get_by_name+0x75/0x90
> [ 118.592385] [<c0300325>] __dev_get_by_name+0x75/0x90
> [ 118.592385] [<c038a687>] wext_handle_ioctl+0x157/0x230
> [ 118.592385] [<c81fddc0>] lbs_get_freq+0x0/0x160 [libertas]
> [ 118.592385] [<c03034c4>] dev_ioctl+0x304/0x4f0
> [ 118.592385] [<c02ffdd2>] net_rx_action+0x92/0x140
> [ 118.592385] [<c027ca89>] pty_write+0x39/0x60
> [ 118.592385] [<c02f4280>] sock_ioctl+0x0/0x260
> [ 118.592385] [<c017e27f>] vfs_ioctl+0x1f/0x70
> [ 118.592385] [<c017e65b>] do_vfs_ioctl+0x24b/0x490
> [ 118.592385] [<c011654e>] update_curr+0x13e/0x190
> [ 118.592385] [<c0117fab>] set_next_entity+0x2b/0x70
> [ 118.592385] [<c0397c64>] schedule+0x1b4/0x350
> [ 118.592385] [<c017e906>] sys_ioctl+0x66/0x70
> [ 118.592385] [<c0103cd2>] syscall_call+0x7/0xb
> [ 118.592385] Code: e9 38 ff ff ff 8d b6 00 00 00 00 8d bf 00 00 00
> 00 56 89 ce 53 83 ec 0c 8b 98 a4 01 00 00 a1 80 19 22 c8 83 e0 21 83
> f8 21 74 42 <0f> b6 8b 01 1e 00 00 31 d2 89 d8 e8 a6 fe ff ff 85 c0 0f
> 84 cd
> [ 118.592385] EIP: [<c81fddda>] lbs_get_freq+0x1a/0x160 [libertas]
> SS:ESP 0068:c6891e10
> [ 118.594153] ---[ end trace f426cd49b2b378f4 ]---
>
I've found the part of commit 29726d85d7b98558a8bc8e69b859bf12e1347f9f
that breaks libertas. The netdev macros portion of the patch is
indeed harmless but the OOPS happens when I don't back out the last
portion of the patch, described as:
"Different to readonly reference of netdev->priv, in this driver,
netdev->pri was changed. I use netdev->ml_priv to replace
netdev->priv."
The resulting lines in the patch are as follows and if I revert them
the driver works again. I am not familiar with ml_priv ("mid-layer
private") and what we're trying to accomplish by the above so, short
of reverting this portion of the patch, can someone place chime in on
what's going on here? The result is that our priv data gets corrupted
and then, when it's used by WEXT callbacks, we cause a kernel oops.
@@ -1378,7 +1378,7 @@ static int lbs_add_mesh(struct lbs_private *priv)
ret = -ENOMEM;
goto done;
}
- mesh_dev->priv = priv;
+ mesh_dev->ml_priv = priv;
priv->mesh_dev = mesh_dev;
mesh_dev->open = lbs_dev_open;
@@ -1591,7 +1591,7 @@ static int lbs_rtap_hard_start_xmit(struct
sk_buff *skb, struct net_device *dev)
static struct net_device_stats *lbs_rtap_get_stats(struct net_device *dev)
{
- struct lbs_private *priv = dev->priv;
+ struct lbs_private *priv = dev->ml_priv;
lbs_deb_enter(LBS_DEB_NET);
return &priv->stats;
}
@@ -1632,7 +1632,7 @@ static int lbs_add_rtap(struct lbs_private *priv)
rtap_dev->stop = lbs_rtap_stop;
rtap_dev->get_stats = lbs_rtap_get_stats;
rtap_dev->hard_start_xmit = lbs_rtap_hard_start_xmit;
- rtap_dev->priv = priv;
+ rtap_dev->ml_priv = priv;
SET_NETDEV_DEV(rtap_dev, priv->dev->dev.parent);
ret = register_netdev(rtap_dev);
On Thu, Jan 8, 2009 at 2:41 PM, Andrey Yurovsky <[email protected]> wrote:
> Ok, also the interface layers (ex: if_usb.c and if_sdio.c) were missed
> in that patch as well. I'm still getting the OOPS after making
> everyone use the macros consistently so I think there's something else
> going on that's corrupting our priv data.
>
> On Thu, Jan 8, 2009 at 2:35 PM, Dan Williams <[email protected]> wrote:
>> On Thu, 2009-01-08 at 11:41 -0800, Andrey Yurovsky wrote:
>>> Hi Dario. In my case I see the oops when iwconfig issues the
>>> SIOCGIWFREQ icotl and thus lbs_get_freq() is executed. Pulling out
>>> the CMD_802_11_GET_LOG doesn't change anything in this respect.
>>>
>>> Right now I am trying to understand why the functions in wext.c access
>>> priv with:
>>>
>>> struct lbs_private *priv = dev->priv;
>>
>> They probably just got forgotten or something during the conversion.
>> They should be using the same methods as everything else, really, since
>> it's just a netdev and they are trying to access the private driver
>> data.
>>
>> Dan
>>
>>> while the rest of the driver uses the netdev macros, for example:
>>>
>>> struct lbs_private *priv = netdev_priv(to_net_dev(dev));
>>>
>>> after the commit in question, or
>>>
>>> struct lbs_private *priv = to_net_dev(dev)->priv;
>>>
>>> before the commit in question. Converting the WEXT callbacks to use
>>> the netdev macros doesn't seem to solve the problem. Thanks,
>>>
>>> -Andrey
>>>
>>> On Wed, Jan 7, 2009 at 8:01 PM, Dario Vlah <[email protected]> wrote:
>>> > Hi Andrey,
>>> >
>>> > I ran into some trouble with the GET_LOG command on the jax10 device, which
>>> > happens to be called by iwconfig. Could that be related? What if you
>>> > disable the GET_LOG call?
>>> >
>>> > In my case issuing that command results in the firmware returning bogus
>>> > values such as negative buffer sizes which end up crashing the kernel.
>>> >
>>> > --dario
>>> >
>>> > On Wed, 7 Jan 2009, Andrey Yurovsky wrote:
>>> >
>>> >> Hmm, I do see the problem start at
>>> >> 29726d85d7b98558a8bc8e69b859bf12e1347f9f and after, but I don't think
>>> >> that I'm right with my analysis, especially since the OOPS happens in
>>> >> wext.c and the functions there (namely lbs_get_freq) use netdev->priv
>>> >> directly. I apologize for the noise but there is still something
>>> >> wrong here that I'm trying to understand better.
>>> >>
>>> >> -Andrey
>>> >>
>>> >> On Wed, Jan 7, 2009 at 6:37 PM, Andrey Yurovsky <[email protected]>
>>> >> wrote:
>>> >>>
>>> >>> The commit that caused this regression is
>>> >>> 29726d85d7b98558a8bc8e69b859bf12e1347f9f "netdevice libertas: Fix
>>> >>> directly reference of netdev->priv" by Wang Chen. It probably causes
>>> >>> a problem with netdev->priv's offset and then we get a pointer
>>> >>> dereference problem when lbs_get_freq() tries to use its priv data.
>>> >>>
>>> >>> -Andrey
>>> >>>
>>> >>> On Wed, Jan 7, 2009 at 4:58 PM, Andrey Yurovsky <[email protected]>
>>> >>> wrote:
>>> >>>>
>>> >>>> Hello. I noticed that the libertas driver causes a kernel oops in
>>> >>>> more recent wireless-testing kernels (I am bisecting right now to
>>> >>>> narrow this down). To reproduce, load the driver and run iwconfig,
>>> >>>> causing lbs_get_freq() to be called.
>>> >>>>
>>> >>>> So far I know that this problem doesn't exist at the 2.6.28-rc2 tag
>>> >>>> (commit 0173a3265b228da319ceb9c1ec6a5682fd1b2d92) but I have seen it
>>> >>>> in -rc7 and up through today's wireless-testing. It seems that
>>> >>>> there's a regression somewhere after -rc2. I've reproduced this with
>>> >>>> the USB hardware as well as an SDIO board.
>>> >>>>
>>> >>>> [ 118.571205] BUG: unable to handle kernel paging request at 00001e01
>>> >>>> [ 118.578500] IP: [<c81fddda>] lbs_get_freq+0x1a/0x160 [libertas]
>>> >>>> [ 118.585417] *pde = 00000000
>>> >>>> [ 118.588877] Oops: 0000 [#1]
>>> >>>> [ 118.592092] last sysfs file: /sys/block/ram9/range
>>> >>>> [ 118.592385] Modules linked in: usb8xxx libertas lib80211
>>> >>>> [ 118.592385]
>>> >>>> [ 118.592385] Pid: 2317, comm: iwconfig Not tainted (2.6.28-wl #65)
>>> >>>> Uknown
>>> >>>> [ 118.592385] EIP: 0060:[<c81fddda>] EFLAGS: 00010293 CPU: 0
>>> >>>> [ 118.592385] EIP is at lbs_get_freq+0x1a/0x160 [libertas]
>>> >>>> [ 118.592385] EAX: 00000000 EBX: 00000000 ECX: c6891ef8 EDX: c6891e98
>>> >>>> [ 118.592385] ESI: c6891ef8 EDI: c6891ef8 EBP: c7295000 ESP: c6891e10
>>> >>>> [ 118.592385] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
>>> >>>> [ 118.592385] Process iwconfig (pid: 2317, ti=c6890000 task=c7349880
>>> >>>> task.ti=c6890000)
>>> >>>> [ 118.592385] Stack:
>>> >>>> [ 118.592385] c8201b4b c6891ef8 00000010 ffffffa1 00008b05 c038aa20
>>> >>>> 00000000 c03c691c
>>> >>>> [ 118.592385] 00000000 c04bc7e0 c0301287 b7f01d70 c68ce000 c6895000
>>> >>>> c04c8260 00000c04
>>> >>>> [ 118.592385] c68c7b7c 00000000 c7295000 c6891ee8 c0300325 c6891ee8
>>> >>>> c7295000 c6891ee8
>>> >>>> [ 118.592385] Call Trace:
>>> >>>> [ 118.592385] [<c8201b4b>] lbs_get_name+0x2b/0xb0 [libertas]
>>> >>>> [ 118.592385] [<c038aa20>] ioctl_standard_call+0x60/0x3a0
>>> >>>> [ 118.592385] [<c0301287>] netif_receive_skb+0x1d7/0x3e0
>>> >>>> [ 118.592385] [<c0300325>] __dev_get_by_name+0x75/0x90
>>> >>>> [ 118.592385] [<c0300325>] __dev_get_by_name+0x75/0x90
>>> >>>> [ 118.592385] [<c038a687>] wext_handle_ioctl+0x157/0x230
>>> >>>> [ 118.592385] [<c81fddc0>] lbs_get_freq+0x0/0x160 [libertas]
>>> >>>> [ 118.592385] [<c03034c4>] dev_ioctl+0x304/0x4f0
>>> >>>> [ 118.592385] [<c02ffdd2>] net_rx_action+0x92/0x140
>>> >>>> [ 118.592385] [<c027ca89>] pty_write+0x39/0x60
>>> >>>> [ 118.592385] [<c02f4280>] sock_ioctl+0x0/0x260
>>> >>>> [ 118.592385] [<c017e27f>] vfs_ioctl+0x1f/0x70
>>> >>>> [ 118.592385] [<c017e65b>] do_vfs_ioctl+0x24b/0x490
>>> >>>> [ 118.592385] [<c011654e>] update_curr+0x13e/0x190
>>> >>>> [ 118.592385] [<c0117fab>] set_next_entity+0x2b/0x70
>>> >>>> [ 118.592385] [<c0397c64>] schedule+0x1b4/0x350
>>> >>>> [ 118.592385] [<c017e906>] sys_ioctl+0x66/0x70
>>> >>>> [ 118.592385] [<c0103cd2>] syscall_call+0x7/0xb
>>> >>>> [ 118.592385] Code: e9 38 ff ff ff 8d b6 00 00 00 00 8d bf 00 00 00
>>> >>>> 00 56 89 ce 53 83 ec 0c 8b 98 a4 01 00 00 a1 80 19 22 c8 83 e0 21 83
>>> >>>> f8 21 74 42 <0f> b6 8b 01 1e 00 00 31 d2 89 d8 e8 a6 fe ff ff 85 c0 0f
>>> >>>> 84 cd
>>> >>>> [ 118.592385] EIP: [<c81fddda>] lbs_get_freq+0x1a/0x160 [libertas]
>>> >>>> SS:ESP 0068:c6891e10
>>> >>>> [ 118.594153] ---[ end trace f426cd49b2b378f4 ]---
>>> >>>>
>>> >>>
>>> >>
>>> >> _______________________________________________
>>> >> libertas-dev mailing list
>>> >> [email protected]
>>> >> http://lists.infradead.org/mailman/listinfo/libertas-dev
>>> >>
>>> >
>>>
>>> _______________________________________________
>>> libertas-dev mailing list
>>> [email protected]
>>> http://lists.infradead.org/mailman/listinfo/libertas-dev
>>
>>
>