Re: [Libreboot] [Libreboot T60 from Gluglug] Sometimes my Qualcomm Atheros AR9285 Wireless Network Adapter drops the connection to never reestablish it again (until reboot)

[Daniel Tarrero]

Just to clarify:

in the file "/etc/modprobe.d/ath9k.conf":

options ath9k nohwcrypt=1
options ath9k btcoex_enable=0
options ath9k bt_ant_diversity=1
options ath9k ps_enable=0

in the file "/etc/default/grub":
(...)
GRUB_CMDLINE_LINUX="intel_iommu=off"

$ update-grub
$ echo "i have to believe!" && reboot

:)

El jue, 26-11-2015 a las 11:05 +0100, Daniel Tarrero escribió:
> Good morning dudes!
> 
> El jue, 26-11-2015 a las 00:41 -0600, Jorge Araya Navarro escribió:
> > Hope we can squash it!
> > --8<---------------cut here---------------start------------->8---
> > $ lsmod | grep ath
> > ath9k                 122880  0
> > ath9k_common           28672  1 ath9k
> > ath9k_hw              438272  2 ath9k_common,ath9k
> > ath                    24576  3 ath9k_common,ath9k,ath9k_hw
> > mac80211              565248  1 ath9k
> > cfg80211              409600  4 ath,ath9k_common,ath9k,mac80211
> > led_class              16384  2 ath9k,thinkpad_acpi
> > --8<---------------cut here---------------end--------------->8---
> 
> What i see here is that you use the ath9k kernel module/driver.
> We also see that it's a rather complex module; other modules actually
> depend on it, like ath, ath9k_hw, ath9k_common, mac80211, cfg80211 and
> led_class.
> 
> So... reload that is a pain in the ass ^^
> 
> $ modprobe -r led_class
> $ modprobe -r cfg80211
> $ modprobe -r mac80211
> $ modprobe -r ath9k_hw
> $ modprobe -r ath9k_common
> $ modprobe -r ath9k
> $ modprobe ath9k
> ... idem with: ath9k_common ath9k_hw mac80211 cfg80211 and led_class
> 
> If module is busy, or something like that, you usually can force the
> module/driver to unload with "-f", for example:
> 
> $ modprobe -rf ath9k
> 
> It's important that you get the module unloaded and loaded again.
> Despite the benefit of not having to reboot when it crashes, you also
> will be able to pass "module parameters" to it, on the fly, when you
> reload
> 
> Something like that:
> 
> $ modprobe ath9k debug=1
> 
> we will find it usefull later, keep on it:
> 
> > --8<---------------cut here---------------start------------->8---
> > $ dmesg | grep firmware
> > [  +0,424592] psmouse serio2: trackpoint: IBM TrackPoint firmware: 0x0e, 
> > buttons: 3/3
> > --8<---------------cut here---------------end--------------->8---
> 
> No weird/propietary/bogus firmware being loaded for your atheros, good
> news :)
> 
> Let's see the available module parameters:
> 
> > --8<---------------cut here---------------start------------->8---
> > $ modinfo ath9k
> > filename:       
> > /lib/modules/4.1.13-gnu-1-lts/kernel/drivers/net/wireless/ath/ath9k/ath9k.ko.gz
> > license:        Dual BSD/GPL
> > description:    Support for Atheros 802.11n wireless LAN cards.
> > author:         Atheros Communications
> > alias:          (...)
> > depends:        ath9k_hw,mac80211,ath9k_common,led-class,cfg80211,ath
> > intree:         Y
> > vermagic:       4.1.13-gnu-1-lts SMP mod_unload modversions 686 
> > parm:           debug:Debugging mask (uint)
> > parm:           nohwcrypt:Disable hardware encryption (int)
> > parm:           blink:Enable LED blink on activity (int)
> > parm:           btcoex_enable:Enable wifi-BT coexistence (int)
> > parm:           bt_ant_diversity:Enable WLAN/BT RX antenna diversity (int)
> > parm:           ps_enable:Enable WLAN PowerSave (int)
> > --8<---------------cut here---------------end--------------->8---
> 
> We see here those parameters:
> 
>       - "debug"
>       overkill, probably dumps a lot of information to /var/log/syslog, but
> also probably we wont understand a shit. U can give it a try, but dont
> leave it enabled as it will consume a lot of resources. Intended for
> debuggin the module.
> 
>       - "nohwcrypt"
>       disables hardware encryption, so it will be performed by CPU. If the
> encryption part of the chip is the buggy one, that can solve our problem
> with a little CPU cost)
> 
>       - "blink"
>       disables wifi led, yujuu!
> 
>       - "btcoex_enable"
>       enables bluetooth coexistence. Disabled by default, so nothing to
> scratch here.
> 
>       - "bt_ant_diversity"
>       thats fun to give a try. Wifi/bluetooth cards are shipped with 1,2 or 3
> antennas. So it can from share one antenna for all (bad idea) to use
> several antennas for one service (diversity, sounds good in order to
> improve signal and general performance, if we dont use bluetooth)
> 
>       - "ps_enable"
>       enables powersave. If your computer is set up to hibernate / suspend,
> that can be a parameter to test.
> 
> 
> 
> Here come two options: you can reload module (so you can test parameters
> on the fly), or not (so you have to reboot each time you want to change
> a parameter).
> 
> If you get to reload the module, pass the module parameters in the
> command line, following the module name, with modprobe:
> 
> $ modprobe ath9k nohwcrypt=1
> 
> If you can't reload it, the place you set it up to be catch on boot is
> in the files you'll find in "/etc/modprobe.d" directory. Just create a
> file there with content similar to these:
> 
> options ath9k nohwcrypt=1
> 
> You can do it with one command line, like that:
> 
> $ echo "options ath9k nohwcrypt=1" > /etc/modprobe.d/ath9k.conf
> 
> ... and reboot it in order to apply the changes.
> 
> 
> I recommend you to try the "most conservative" parameters we've talk
> about:
> 
> module parameters:
>       nohwcrypt=1
>       btcoex_enable=0
>       bt_ant_diversity=1
>       ps_enable=0
> 
> With that, the load for the wifi hardware will be minimal: encryption
> will be performed by cpu, bluetooth will be disabled, and it's bluetooth
> antenna (if it have one) will be used for wifi.
> 
> > --8<---------------cut here---------------start------------->8---
> > $ egrep '(vmx|svm)' /proc/cpuinfo
> > flags               : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
> > mca cmov clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc 
> > bts aperfmperf pni monitor vmx est tm2 xtpr pdcm dtherm
> > flags               : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
> > mca cmov clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc 
> > bts aperfmperf pni monitor vmx est tm2 xtpr pdcm dtherm
> > --8<---------------cut here---------------end--------------->8---
> 
> Your cpu have Hardware Virtualization support (VMX). That has cause
> problems in the past with atheros modules.
> 
> Try this kernel parameter on boot:
> 
>       intel_iommu=off
> 
> 
> 
> With all that applied, i run out of ideas! Give it a try and let us know
> if that improves your system stability :)
> 
> i go for a coffee truck =)
> regards,
> Dani
> 
> > 
> > 
> > El miércoles 25 de noviembre del 2015 a las 0823 horas, Daniel Tarrero 
> > escribió:
> > 
> > > Hi again!
> > >
> > > sorry to hear that :( we have to keep putting the stick in the hole till
> > > the bug comes out :)
> > >
> > > i have a couple questions and a tweak worth to try:
> > > - which module/firmware do you use? the kernel's ath9k module?
> > >   $ lsmod | grep ath
> > >   $ dmesg | grep firmware
> > >
> > > - which options does this module support?
> > >   $ modinfo ath9k
> > >
> > > - which processor do you have? has it virtualization supporT?
> > >   $ egrep '(vmx|svm)' /proc/cpuinfo
> > >
> > > ----------
> > > - virtualization tecnologies have cause this kind of conflicts in the
> > > past, so try this if you see output from the previous command:
> > >   kernel boot parameter "intel_iommu=off"
> > >
> > > - atheros driver tweaks: we will see which module options can we adjust
> > > from the modinfo command :)
> > >
> > >
> > > luck and regards!
> > > D
> > >
> > >
> > >
> > >   
> > >   
> > >
> > > El sáb, 21-11-2015 a las 15:19 -0600, Jorge Araya Navarro escribió:
> > >> Well, today the issue show his face again! :( You were right, the kernel 
> > >> flag don't solve this
> > >> problem. However, after rebooting my laptop, the connection is stable, I 
> > >> don't experience the
> > >> reconnection-every-60-seconds-phase anymore.
> > >> 
> > >> I don't remember pasting the exact error message I get when the issue 
> > >> appears, in any case, here it
> > >> is:
> > >> 
> > >> --8<---------------cut here---------------start------------->8---
> > >> [  +0,116708] ath: phy0: Chip reset failed
> > >> [  +0,000007] ath: phy0: Unable to reset channel, reset status -22
> > >> [  +0,080357] ath: phy0: DMA failed to stop in 10 ms AR_CR=0xffffffff 
> > >> AR_DIAG_SW=0xffffffff DMADBG_7=0xffffffff
> > >> [  +0,000016] ath: phy0: Could not stop RX, we could be confusing the 
> > >> DMA engine when we start RX up
> > >> --8<---------------cut here---------------end--------------->8---
> > >> 
> > >> I was unable to reload the `ath` module, something start again 
> > >> NetworkManager's service when I stop
> > >> it with `systemctl stop NetworkManager`, `systemctl list-dependencies 
> > >> NetworkManager` shows many
> > >> services that I don't believe all of them depend on NetworkManager's 
> > >> service.
> > >> 
> > >> typing `sudo iwconfig wlp2s0 power off` doesn't work because that 
> > >> feature isn't supported by my wifi
> > >> card. The sound works well except for some sound glitches, but that 
> > >> happens because systemd-journal uses a
> > >> lot of CPU registering the never ending error message (the one above).
> > >> 
> > >> Here is the information you requested, hope this sheds some light with 
> > >> this problem:
> > >> 
> > >> --8<---------------cut here---------------start------------->8---
> > >> $ sudo journalctl -b -1 | grep DMA
> > >> nov 21 12:26:57 abril.charola kernel:   DMA      [mem 
> > >> 0x0000000000001000-0x0000000000ffffff]
> > >> nov 21 12:26:57 abril.charola kernel:   DMA zone: 40 pages used for 
> > >> memmap
> > >> nov 21 12:26:57 abril.charola kernel:   DMA zone: 0 pages reserved
> > >> nov 21 12:26:57 abril.charola kernel:   DMA zone: 3999 pages, LIFO 
> > >> batch:0
> > >> # [...]
> > >> nov 21 14:29:06 abril.charola kernel: ath: phy0: Failed to stop TX DMA, 
> > >> queues=0x008!
> > >> nov 21 14:29:06 abril.charola kernel: ath: phy0: DMA failed to stop in 
> > >> 10 ms AR_CR=0xffffffff AR_DIAG_SW=0xffffffff DMADBG_7=0xffffffff
> > >> nov 21 14:29:06 abril.charola kernel: ath: phy0: Could not stop RX, we 
> > >> could be confusing the DMA engine when we start RX up
> > >> --8<---------------cut here---------------end--------------->8---
> > >> 
> > >> --8<---------------cut here---------------start------------->8---
> > >> $ lspci | grep -e Ethernet -e Network 
> > >> 01:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet 
> > >> Controller
> > >> 02:00.0 Network controller: Qualcomm Atheros AR9285 Wireless Network 
> > >> Adapter (PCI-Express) (rev 01)
> > >> --8<---------------cut here---------------end--------------->8---
> > >> 
> > >> --8<---------------cut here---------------start------------->8---
> > >> $ uname -a
> > >> Linux abril.charola 4.1.13-gnu-1-lts #1 SMP Sat Nov 14 09:15:27 UYT 2015 
> > >> i686 GNU/Linux
> > >> --8<---------------cut here---------------end--------------->8---
> > >> 
> > >> El lunes 16 de noviembre del 2015 a las 0340 horas, Daniel Tarrero 
> > >> escribió:
> > >> 
> > >> > Hi!
> > >> >
> > >> > This logs seem to me like an interrupt conflict, hardware failure, or
> > >> > unrecoverable state.
> > >> >
> > >> > I think that the kernel boot option "intremap" wont help you.
> > >> >
> > >> > Usually, remove and load again a module use to restablish it's
> > >> > functionallity (when succesfully performed). Of course, modules and
> > >> > kernel have a tree kind structure, so you have to unload its
> > >> > dependencies before unload a module.
> > >> >
> > >> > -----
> > >> > Things you can give a try:
> > >> >
> > >> > * Look for any other interesting messages during boot:
> > >> >
> > >> > $ dmesg | more
> > >> >
> > >> > ... and more concrete, boot messages about DMA:
> > >> >
> > >> > $ dmesg | grep DMA | more
> > >> >
> > >> > * Disable "suspend" mode of the card (maybe it enters suspension-mode
> > >> > and never come back: not all cards support suspension):
> > >> >
> > >> > $ sudo iwconfig wlan0 power off
> > >> >
> > >> > * I also would try to _disable_sound_card_ in BIOS, and see if that
> > >> > makes a difference with your Wifi crashes.
> > >> >
> > >> >
> > >> > ----------
> > >> > For more info:
> > >> >
> > >> > which wifi card you have?
> > >> >
> > >> > $ lspci
> > >> > $ lsusb
> > >> >
> > >> > which kernel you have?
> > >> >
> > >> > $ uname -a
> > >> >
> > >> > is this the propper list for that?
> > >> >
> > >> > probably not ^^
> > >> >
> > >> >
> > >> > good morning dudes!
> > >> > Dani
> > >> >
> > >> >
> > >> > El vie, 13-11-2015 a las 12:47 -0600, Jorge Araya Navarro escribió:
> > >> >> Yo! lol.
> > >> >> 
> > >> >> When this thing happens, I don't have anything playing sounds, so I'm
> > >> >> not sure if the sound card gets affected. I wonder if setting that
> > >> >> kernel flag will prevent this issue from happening. I also too wonder 
> > >> >> if
> > >> >> unloading and reloading the drivers will do something useful regarding
> > >> >> my issue.
> > >> >> 
> > >> >> I'm going to set the flag and came back here if something happens.
> > >> >> 
> > >> >> El viernes 13 de noviembre del 2015 a las 0534 horas, Daniel Tarrero 
> > >> >> escribió:
> > >> >> 
> > >> >> > Que pasa Jorge!!
> > >> >> >
> > >> >> > The soon i talk about interrupts, the soon somebody faces problems 
> > >> >> > using
> > >> >> > them!! maybe :)
> > >> >> >
> > >> >> > This seem to be a hardware communication problem. Did you read my 
> > >> >> > last
> > >> >> > two mails? they may bring some information related to this problems.
> > >> >> >
> > >> >> >>> Did you see the DMAR mapping Warning too during boot?? that can 
> > >> >> >>> have
> > >> >> > something to say here. The fact that a reboot use to solve it, 
> > >> >> > makes me
> > >> >> > think it can be an interrupt conflict.
> > >> >> >
> > >> >> > Your logs say: "module/driver is sending commands to hardware, and 
> > >> >> > it
> > >> >> > didnt respond as we expected"
> > >> >> >
> > >> >> > What can cause this? DMAR mess!!! and also hardware problems, like 
> > >> >> > loose
> > >> >> > of power, changes in hardware that derives in interrupt conflicts 
> > >> >> > like
> > >> >> > pluggin an e-sata, or faulty Atheros chip in the worse case.
> > >> >> >
> > >> >> > You can _force_ module unload (and also, you can
> > >> >> > _unload_dependent_modules_ first). Of course, you have to stop 
> > >> >> > software
> > >> >> > using this hardware too. Maybe something like can make your day:
> > >> >> >
> > >> >> > $ sudo service network-manager stop (stop software)
> > >> >> > $ sudo ifconfig whatever down (unload network)
> > >> >> > $ modprobe -n ath (see dependent modules)
> > >> >> > $ sudo modprobe -f whatever (unload dependencies first)
> > >> >> > $ sudo modprobe -f ath (unload module)
> > >> >> > $ sudo modprobe ath (reload module)
> > >> >> >
> > >> >> > and test!
> > >> >> > You should give some time to the commands to complete, and keep an 
> > >> >> > eye
> > >> >> > in syslog/dmesg to see resoults.
> > >> >> >
> > >> >> > Given that the problem flaps (come and go), i would also check 
> > >> >> > power and
> > >> >> > heat (maybe replace charger with a travel one if you have, and 
> > >> >> > place the
> > >> >> > laptop in a cold environment), and see if fault time changes.
> > >> >> >
> > >> >> > Also there is a previous warning with your sound card that can be
> > >> >> > related:
> > >> >> > snd_hda_intel 0000:00:1b.0: IRQ timing workaround is activated for 
> > >> >> > card
> > >> >> > #0
> > >> >> >
> > >> >> > Is your sound card working when this error happens? If not, we may 
> > >> >> > have
> > >> >> > found the hardware interrupt conflict. They can be using the same
> > >> >> > interrupt, and when sound gets "tweaked" the wifi goes crazy about 
> > >> >> > that
> > >> >> > delay in communications.
> > >> >> >
> > >> >> >
> > >> >> > Good luck!! Im waiting for your experiences! :)
> > >> >> >
> > >> >> > Regards,
> > >> >> > D
> > >> >> >
> > >> >> >
> > >> >> > El jue, 12-11-2015 a las 14:44 -0600, Jorge Araya Navarro escribió:
> > >> >> >> Hello!
> > >> >> >> 
> > >> >> >> I bought my Libreboot T60 from Gluglug in December of last year, 
> > >> >> >> and I'm very happy with a machine
> > >> >> >> which works with 100% Free Software!
> > >> >> >> 
> > >> >> >> Since a couple of months ago is happening something strange to my 
> > >> >> >> wifi card, I first thought the
> > >> >> >> issue was caused by a kernel update but I was wrong. What happens 
> > >> >> >> is that at any random moment every
> > >> >> >> many or so weeks the wifi will drop the connection to never 
> > >> >> >> re-establish it again, until reboot, and
> > >> >> >> after that sometimes the issue continues with the wifi card 
> > >> >> >> dropping the connection once every 60
> > >> >> >> seconds.
> > >> >> >> 
> > >> >> >> Yesterday this thing happened again, so I decided to fire Emacs 
> > >> >> >> and takes some notes and output with
> > >> >> >> org-mode. The first interesting thing is this from `dmesg`:
> > >> >> >> 
> > >> >> >> --8<---------------cut here---------------start------------->8---
> > >> >> >> nov 12 12:43:43 abril.charola kernel: snd_hda_intel 0000:00:1b.0: 
> > >> >> >> IRQ timing workaround is activated for card #0. Suggest a bigger 
> > >> >> >> bdl_pos_adj.
> > >> >> >> nov 12 12:43:44 abril.charola kernel: ath: phy0: Failed to stop TX 
> > >> >> >> DMA, queues=0x00a!
> > >> >> >> nov 12 12:43:44 abril.charola kernel: ath: phy0: DMA failed to 
> > >> >> >> stop in 10 ms AR_CR=0xffffffff AR_DIAG_SW=0xffffffff 
> > >> >> >> DMADBG_7=0xffffffff
> > >> >> >> nov 12 12:43:44 abril.charola kernel: ath: phy0: Could not stop 
> > >> >> >> RX, we could be confusing the DMA engine when we start RX up
> > >> >> >> nov 12 12:43:44 abril.charola kernel: ath: phy0: Chip reset failed
> > >> >> >> nov 12 12:43:44 abril.charola kernel: ath: phy0: Unable to reset 
> > >> >> >> channel, reset status -22
> > >> >> >> nov 12 12:43:44 abril.charola kernel: ath: phy0: DMA failed to 
> > >> >> >> stop in 10 ms AR_CR=0xffffffff AR_DIAG_SW=0xffffffff 
> > >> >> >> DMADBG_7=0xffffffff
> > >> >> >> nov 12 12:43:44 abril.charola kernel: ath: phy0: Could not stop 
> > >> >> >> RX, we could be confusing the DMA engine when we start RX up
> > >> >> >> nov 12 12:43:44 abril.charola kernel: ath: phy0: Chip reset failed
> > >> >> >> nov 12 12:43:44 abril.charola kernel: ath: phy0: Unable to reset 
> > >> >> >> channel, reset status -22
> > >> >> >> nov 12 12:43:44 abril.charola kernel: ath: phy0: DMA failed to 
> > >> >> >> stop in 10 ms AR_CR=0xffffffff AR_DIAG_SW=0xffffffff 
> > >> >> >> DMADBG_7=0xffffffff
> > >> >> >> nov 12 12:43:44 abril.charola kernel: ath: phy0: Could not stop 
> > >> >> >> RX, we could be confusing the DMA engine when we start RX up
> > >> >> >> nov 12 12:43:44 abril.charola kernel: ath: phy0: Chip reset failed
> > >> >> >> nov 12 12:43:44 abril.charola kernel: ath: phy0: Unable to reset 
> > >> >> >> channel, reset status -22
> > >> >> >> nov 12 12:43:44 abril.charola kernel: ath: phy0: DMA failed to 
> > >> >> >> stop in 10 ms AR_CR=0xffffffff AR_DIAG_SW=0xffffffff 
> > >> >> >> DMADBG_7=0xffffffff
> > >> >> >> nov 12 12:43:44 abril.charola kernel: ath: phy0: Could not stop 
> > >> >> >> RX, we could be confusing the DMA engine when we start RX up
> > >> >> >> nov 12 12:43:44 abril.charola kernel: ath: phy0: Chip reset failed
> > >> >> >> nov 12 12:43:44 abril.charola kernel: ath: phy0: Unable to reset 
> > >> >> >> channel, reset status -22
> > >> >> >> nov 12 12:43:44 abril.charola kernel: ath: phy0: DMA failed to 
> > >> >> >> stop in 10 ms AR_CR=0xffffffff AR_DIAG_SW=0xffffffff 
> > >> >> >> DMADBG_7=0xffffffff
> > >> >> >> nov 12 12:43:44 abril.charola kernel: ath: phy0: Could not stop 
> > >> >> >> RX, we could be confusing the DMA engine when we start RX up
> > >> >> >> nov 12 12:43:45 abril.charola kernel: ath: phy0: Chip reset failed
> > >> >> >> nov 12 12:43:45 abril.charola kernel: ath: phy0: Unable to reset 
> > >> >> >> channel, reset status -22
> > >> >> >> nov 12 12:43:45 abril.charola kernel: ath: phy0: DMA failed to 
> > >> >> >> stop in 10 ms AR_CR=0xffffffff AR_DIAG_SW=0xffffffff 
> > >> >> >> DMADBG_7=0xffffffff
> > >> >> >> nov 12 12:43:45 abril.charola kernel: ath: phy0: Could not stop 
> > >> >> >> RX, we could be confusing the DMA engine when we start RX up
> > >> >> >> nov 12 12:43:45 abril.charola kernel: ath: phy0: Chip reset failed
> > >> >> >> nov 12 12:43:45 abril.charola kernel: ath: phy0: Unable to reset 
> > >> >> >> channel, reset status -22
> > >> >> >> nov 12 12:43:45 abril.charola NetworkManager[445]: <warn>  
> > >> >> >> Connection disconnected (reason -4)
> > >> >> >> nov 12 12:43:45 abril.charola NetworkManager[445]: <info>  
> > >> >> >> (wlp2s0): supplicant interface state: completed -> disconnected
> > >> >> >> nov 12 12:43:45 abril.charola kernel: cfg80211: Exceeded CRDA call 
> > >> >> >> max attempts. Not calling CRDA
> > >> >> >> nov 12 12:43:45 abril.charola kernel: ath: phy0: DMA failed to 
> > >> >> >> stop in 10 ms AR_CR=0xffffffff AR_DIAG_SW=0xffffffff 
> > >> >> >> DMADBG_7=0xffffffff
> > >> >> >> nov 12 12:43:45 abril.charola kernel: ath: phy0: Could not stop 
> > >> >> >> RX, we could be confusing the DMA engine when we start RX up
> > >> >> >> nov 12 12:43:45 abril.charola NetworkManager[445]: <info>  
> > >> >> >> (wlp2s0): supplicant interface state: disconnected -> scanning
> > >> >> >> --8<---------------cut here---------------end--------------->8---
> > >> >> >> 
> > >> >> >> As I don't understand anything with such error messages, my guess 
> > >> >> >> is that it is something
> > >> >> >> serious. after trying to unload the modules related to my wifi 
> > >> >> >> driver (ath (which is impossible
> > >> >> >> because other modules requiring it are being use)) and typing 
> > >> >> >> `ifconfig wlp2s0 down` and what not, I
> > >> >> >> just gave up and restart my laptop. At some point journald 
> > >> >> >> register something interesting:
> > >> >> >> 
> > >> >> >> --8<---------------cut here---------------start------------->8---
> > >> >> >> nov 12 12:44:00 abril.charola kernel: irq 17: nobody cared (try 
> > >> >> >> booting with the "irqpoll" option)
> > >> >> >> nov 12 12:44:00 abril.charola kernel: CPU: 0 PID: 0 Comm: 
> > >> >> >> swapper/0 Not tainted 4.1.11-gnu-1-lts #1
> > >> >> >> nov 12 12:44:00 abril.charola kernel: Hardware name: LENOVO 
> > >> >> >> 1951F8G/1951F8G, BIOS CBET4000 79ETE7WW (2.27 ) 05/18/2015
> > >> >> >> nov 12 12:44:00 abril.charola kernel:  c1609907 4a9301f9 00000000 
> > >> >> >> f5035f54 c14a49ec f53d0e9c f5035f74 c10abbac
> > >> >> >> nov 12 12:44:00 abril.charola kernel:  c1575cc0 00000011 f5035f70 
> > >> >> >> f85611db f53d0e40 00000000 f5035f98 c10abf22
> > >> >> >> nov 12 12:44:00 abril.charola kernel:  c1329d4a 0003ab5e 00000000 
> > >> >> >> 4a9301f9 f53d0e40 c1676e00 00000000 f5035fd4
> > >> >> >> nov 12 12:44:00 abril.charola kernel: Call Trace:
> > >> >> >> nov 12 12:44:00 abril.charola kernel:  [<c14a49ec>] 
> > >> >> >> dump_stack+0x41/0x52
> > >> >> >> nov 12 12:44:00 abril.charola kernel:  [<c10abbac>] 
> > >> >> >> __report_bad_irq+0x2c/0xd0
> > >> >> >> nov 12 12:44:00 abril.charola kernel:  [<f85611db>] ? 
> > >> >> >> ath9k_hw_intrpend+0x5b/0x70 [ath9k_hw]
> > >> >> >> nov 12 12:44:00 abril.charola kernel:  [<c10abf22>] 
> > >> >> >> note_interrupt+0x212/0x250
> > >> >> >> nov 12 12:44:00 abril.charola kernel:  [<c1329d4a>] ? 
> > >> >> >> add_interrupt_randomness+0x16a/0x1a0
> > >> >> >> nov 12 12:44:00 abril.charola kernel:  [<c10a99a2>] 
> > >> >> >> handle_irq_event_percpu+0x122/0x190
> > >> >> >> nov 12 12:44:00 abril.charola kernel:  [<c10a99a2>] ? 
> > >> >> >> handle_irq_event_percpu+0x122/0x190
> > >> >> >> nov 12 12:44:00 abril.charola kernel:  [<c10a9a3a>] 
> > >> >> >> handle_irq_event+0x2a/0x50
> > >> >> >> nov 12 12:44:00 abril.charola kernel:  [<c10ac520>] ? 
> > >> >> >> handle_edge_irq+0xe0/0xe0
> > >> >> >> nov 12 12:44:00 abril.charola kernel:  [<c10ac589>] 
> > >> >> >> handle_fasteoi_irq+0x69/0x100
> > >> >> >> nov 12 12:44:00 abril.charola kernel:  [<c1004906>] 
> > >> >> >> handle_irq+0x56/0x90
> > >> >> >> nov 12 12:44:00 abril.charola kernel:  <IRQ>  [<c14aa60c>] 
> > >> >> >> do_IRQ+0x3c/0xd0
> > >> >> >> nov 12 12:44:00 abril.charola kernel:  [<c14a9c33>] 
> > >> >> >> common_interrupt+0x33/0x38
> > >> >> >> nov 12 12:44:00 abril.charola kernel:  [<c138a553>] ? 
> > >> >> >> cpuidle_enter_state+0x83/0x240
> > >> >> >> nov 12 12:44:00 abril.charola kernel:  [<c138a744>] 
> > >> >> >> cpuidle_enter+0x14/0x20
> > >> >> >> nov 12 12:44:00 abril.charola kernel:  [<c108fe89>] 
> > >> >> >> cpu_startup_entry+0x299/0x3a0
> > >> >> >> nov 12 12:44:00 abril.charola kernel:  [<c14a1f67>] 
> > >> >> >> rest_init+0x67/0x70
> > >> >> >> nov 12 12:44:00 abril.charola kernel:  [<c167eb51>] 
> > >> >> >> start_kernel+0x3c9/0x3e2
> > >> >> >> nov 12 12:44:00 abril.charola kernel:  [<c167e2e3>] 
> > >> >> >> i386_start_kernel+0x91/0x95
> > >> >> >> nov 12 12:44:00 abril.charola kernel: handlers:
> > >> >> >> nov 12 12:44:00 abril.charola kernel: [<f81083c0>] usb_hcd_irq 
> > >> >> >> [usbcore]
> > >> >> >> nov 12 12:44:00 abril.charola kernel: [<f860a890>] ath_isr [ath9k]
> > >> >> >> nov 12 12:44:00 abril.charola kernel: Disabling IRQ #17
> > >> >> >> --8<---------------cut here---------------end--------------->8---
> > >> >> >> 
> > >> >> >> Again, I don't know what it says but seems very serious. I'll 
> > >> >> >> attach the full logs in case what I
> > >> >> >> provide is not enough. Hope someone can help me with this.
> > >> >> >> 
> > >> >> >> P.S.: I haven't clean my laptop from dust since I bought it, and 
> > >> >> >> it seems it have some inside, this
> > >> >> >> sporadic issue can be caused by the dust, too.
> > >> >> >> 
> > >> >> 
> > >> 
> > 
> 
> 
>