On 12/06/2015 09:39 PM, Peter Wu wrote:
>>> While using the rtl8192cu driver in monitor mode, somehow 5G of memory
>>> was permanently lost (observable via the Available column in `free -m`).
>>>
>>> This issue has existed since the introduction of this driver in v2.6.x,
One more reason to switch
Peter Wu writes:
> Originally I had the Cc: stable line added, but the SubmittingPatches
> document seems to discourage that for networking. Added it again.
Yeah, stable wireless patches are handled differently from rest of the
networking subsystem. It would be great if somebody could update the
On 12/06/2015 03:39 PM, Peter Wu wrote:
On Sun, Dec 06, 2015 at 02:18:36PM -0600, Larry Finger wrote:
On 12/06/2015 11:57 AM, Peter Wu wrote:
Free skb for received frames with a wrong checksum.
While using the rtl8192cu driver in monitor mode, somehow 5G of memory
was permanently lost (observa
On Sun, Dec 06, 2015 at 02:18:36PM -0600, Larry Finger wrote:
> On 12/06/2015 11:57 AM, Peter Wu wrote:
> >Free skb for received frames with a wrong checksum.
> >
> >While using the rtl8192cu driver in monitor mode, somehow 5G of memory
> >was permanently lost (observable via the Available column i
On 12/06/2015 11:57 AM, Peter Wu wrote:
Free skb for received frames with a wrong checksum.
While using the rtl8192cu driver in monitor mode, somehow 5G of memory
was permanently lost (observable via the Available column in `free -m`).
Test scenario:
ip link set down wlan1
iw wlan1 s
Free skb for received frames with a wrong checksum.
While using the rtl8192cu driver in monitor mode, somehow 5G of memory
was permanently lost (observable via the Available column in `free -m`).
Test scenario:
ip link set down wlan1
iw wlan1 set type monitor
ip link set up wlan1
