1

I'm using a Realtek rtl8192eu chip. I spent ages trying to connect to my router. Eventually, I reloaded the rtl8xxxu module. That fixed it until next boot. Once again I had to do the same. This time I checked kernel messages specific to rtl8192eu. To my shock, the exact same messages appeared when I reloaded the module as when the system did. I just want to understand this behaviour. So, can anybody shed some light on this? A fix would be great, too, but I'd settle on an explanation since there are plenty quick 'n dirty tricks I could apply (although I seldom restart, my average uptime being weeks per PC).

Basic Info:

*. Debian Stable 9.5 (+ non-free).

*. Kernel: 4.9.0-7 (AMD64)

*. No other OS (so nothing to mess with the chip).

*. USB Unbranded Wifi Dongle with Realtek chip RTL8192EU.

*. Error message: "rtl8192eu_rx_iqk_path_b: Path B RX IQK failed!"

*. Scanning fails until reloading module.

*. Before reload: "Hardware modes: Master, Monitor, [blah, blah...] Software modes: Monitor." No mention of Managed.

Jay
  • 13
  • @Theophrastus Yes, systemd. Since Debian's official change. As far as that thread you linked, it's nearly verbatim. I modprobe -r the rtlxxxu module, then modprobe it, then it "just works" (which makes me nervous). I decided on auto-removing & auto-loading it at start. I just wondered about it technically. At least that thread mentioned a device ready delay. Thanks for that. Still confused why the error messages were the same. I guess "Realtek" should be an answer unto itself (I didn't choose it, I got it free). – Jay Sep 08 '18 at 16:16
  • related https://unix.stackexchange.com/questions/252210/wi-fi-problems-using-asus-usb-n13-adapter/252215 – Rui F Ribeiro Sep 08 '18 at 17:00

1 Answers1

0

I can shed some light on this, though I can't fully explain it. In

rtl8192eu_rx_iqk_path_b: Path B RX IQK failed

rx stands for "receive", and says something along the line "something unexpected happened, even though I should be able to receive something on this part of the hardware, it didn't work". In other words, the hardware ended up in a state that was not meant to happen, which is why everything after fails.

When you reload the module, you reinitialize the hardware, so now it's again in a good state. While the module initializes the hardware, it spits out some messages, and of course these will be the same each time (after all, it's doing the same stuff).

So now it will work, until whatever throws it into a bad state happens again.

To sum up, it's a driver bug: It's a situation the driver writers didn't think about, or don't handle correctly. You can file a bug report, and pray for an updated driver. That's about all you can do.

dirkt
  • 32,309