Bug 206112 - [rtwn] Under heavy load, "can't map mbuf (error 12)" arises
Summary: [rtwn] Under heavy load, "can't map mbuf (error 12)" arises
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: wireless (show other bugs)
Version: CURRENT
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-wireless (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-01-10 19:06 UTC by evil.lombo
Modified: 2016-09-02 17:54 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description evil.lombo 2016-01-10 19:06:49 UTC
Hi,

I'm testing the rtwn module and under heavy usage (e.g. video streaming) or a high number of active connections (e.g. multiple browser tabs or P2P), the interface stops responding in a few minutes and the following message spams multiple times on the system message buffer.

rtwn0: can't map mbuf (error: 12) 

where 12 I assume it's the error number of ENOMEM.

ifconfig wlan0 down and ifconfig wlan0 up does not reset the interface and the card still not respond. A full reboot of the machine fixes it.

When those messages appear, trying to resume the stream from the application issues a kernel panic while trying to unload the module results in a machine freeze.

I'll take the crash dump, if it's necessary.

With light usage, I can't get the issue.

(I don't know if this relates to the performance issue I have with the module. The speed seems capped to around 1/3 rather than the full 54mbps rate I got using the ndis wrapper. I'm opening a separate bug report for that.)

Which information are needed?

Thanks,

Simone
Comment 1 evil.lombo 2016-01-26 20:30:36 UTC
A little strange news.

The issue seems arises when the laptop is booted after few hours of being shut down and it's related to the performance issue I cited; I need to reboot the machine twice (!) to get nice performance and not getting the error.

I have put three firmware reset in a row in the if_rtwn.c and doubled the wait time before accessing to the registry after the reset and now the card is usable after a fresh boot.

I'll test if it is sufficient to keep the wait state longer in the next days or it needs a "triple" firmware reset.

Simone
Comment 2 Felix Palmen freebsd_committer freebsd_triage 2016-03-27 12:19:30 UTC
Hi Simone,
as I'm experiencing the exact same issue here, are there any news? And, could you please show the patch making it work for you?

TIA, Felix
Comment 3 Andriy Voskoboinyk freebsd_committer freebsd_triage 2016-06-20 22:58:32 UTC
Hi,

Is it still reproducible after r302035?
Comment 4 Andriy Voskoboinyk freebsd_committer freebsd_triage 2016-09-02 17:54:37 UTC
Should be fixed in r302035.