Radom & frequent total crashes since upgrade to 19.04

[G.M.]

Hi,

I'm using an ASUS X751L laptop for several years with no (=a few manageable) problem(s).

Two weeks ago, I switched to Xunbuntu 19.04, by:
- changing the lines in the /etc/sources.list
- running apt-get dist-upgrade

Since then, the computer randomly totally freezes ~twice a day. Even after another dist-upgrade this morning...

When I say "totally freezes", I mean:
- Mouse is froozen, if there was sound playing (be it movie or music, played either with mplayer or vlc), then the last 1/2 second loops indefinitely
- CTRL-ALT-Fn do not work
- There's nothing in the logs: kern.log, syslog, dmesg... appart some garbage chars (like ^@^@^@...) that sometimes gets appended in syslog at crash time.
- Even when activated Magic SysReq (ALT-SysReq-RSEIUB) do not work
- Alt-SysReq 1 + Alt-SysReq t do not create anything in /var/crash (there are some files for qemu & xfce4-panel, that I already reported)
- Following https://wiki.ubuntu.com/Kernel/CrashdumpRecipe , I installed linux-crashdump, and verified it correctly sets the boot line option, but nothing gets created in /var/crash when computer crashes (apart a kexec_cmd file that simply lists the boot line args).
- Quick (2/3 sec) press on the power button does nothing
- Long (10 sec) press on the power button is the only way to regain control...
- I've tried to run Memtest86+ (even if I'm sure RAM is not the problem as it started occurring only after dist-upgrade to 19.04), but the system is UEFI, so option is not in the grub menu. I'll try to make a USB stick to test the RAM

FYI, the internal wifi card (rtl8723) has always caused troubles: HD write slowdowns, audio device locks, etc (from what I guess, it overfills some internal bus...). So I deactivate it at boot by removing the module, and I use another external Wifi dongle (rt2800usb)

$ uname -a
Linux gmuller-X751LAB 5.0.0-16-generic #17-Ubuntu SMP Wed May 15 10:52:21 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
# Note: crashes occurred also with 5.0.0-15

Does anyone has any hints/tips on how I could get more info & target where the problem comes from? because as-is the computer is just unusable...

In the attached log files, the crash occurred right before my manual reboot at 15:17:24

[G.M. (sexxxenator)]

Hi again,

So I tested the RAM with memtest86 (non free, but works on UEFI), there is no problem.

I tested kernel 5.0.0.17 => crashes also.

I manually installed 4.20.17-042017, it stayed alive almost a day, but then crashed also.

I dual booted to an old win10 that was present on the computer when I baught it ~5years ago, it worked perfectly. I upgraded it to win10-1903, it seems to work perfectly also: 48 hrs without a crash...

The problem does not seems to be in the hardware as I first thought, but somewhere in the (linux-ecosystem) software...

I hate M$ OSes, as they are clearly not designed by/for the user, but for making always more $$$, thus are very difficult to use/customize for a fluent day-to-day basis, but since it's the only woking OS for now on this machine, I'll stick to it.

It's a pitty GNU/Linux ecosystem has become so bloated that it is now of less quality than proprietary software... It was its only force against "the dark"...

I hope to find an empty usb stick in my stuff so that I can try my preferred OS (OpenBSD), and confirm that the problem is on the GNU/Linux side...

[Marc Deslauriers (mdeslaur)]

Thanks for taking the time to report this bug and helping to make Ubuntu better. We appreciate the difficulties you are facing, but this appears to be a "regular" (non-security) bug. I have unmarked it as a security issue since this bug does not show evidence of allowing attackers to cross privilege boundaries nor directly cause loss of data/privacy. Please feel free to report any other bugs you may find.

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1833474

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

[G.M. (sexxxenator)]

Hi all,

I've managed to track down where the problem comes from.

CONTEXT

- I use one of my neighbors' access point/portal to access internet (based on FON principle: https://en.wikipedia.org/wiki/Fon_(company)).

- Since the access point is not that close from my apartment, I baught and use an external Wifi adapter with a (supposed to be) 5DBi antenna. This is the exact following "ALFA" model:
https://www.dx.com/p/alfa-awus036nh-network-ralink-3070l-wifi-network-card-2000mw-alfa-wireless-wifi-usb-adapter-with-5dbi-antenna-white-2053330.html

- In order to be able to put this device outside my window, I plug it to my computer via a 2m USB armored cable, similar to this one (with the characteristic little bump / fuse?)
https://mpshop.tn/3035-thickbox_default/rallonge-usb-male-femelle.jpg
I tried with several cables (non-armored ones or longer cables, armored or not). All lead to kernel not recognizing the device or intermittent disconnection from the AP or disappearing of the device after a few minutes.

The chipset is apparently detected as a RaLink and the kernel tells me it uses the 'rt2870.bin' firmware:
[27393.587771] usb 1-1: new high-speed USB device number 6 using xhci_hcd
[27393.753513] usb 1-1: New USB device found, idVendor=148f, idProduct=3070, bcdDevice= 1.01
[27393.753519] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[27393.753523] usb 1-1: Product: 802.11 n WLAN
[27393.753526] usb 1-1: Manufacturer: Ralink
[27393.753528] usb 1-1: SerialNumber: 1.0
[27393.883944] usb 1-1: reset high-speed USB device number 6 using xhci_hcd
[27394.044554] ieee80211 phy2: rt2x00_set_rt: Info - RT chipset 3070, rev 0201 detected
[27394.055744] ieee80211 phy2: rt2x00_set_rf: Info - RF chipset 0005 detected
[27394.056214] ieee80211 phy2: Selected rate control algorithm 'minstrel_ht'
[27394.098722] rt2800usb 1-1:1.0 wlx000f0032e9c8: renamed from wlan0
[27394.150888] ieee80211 phy2: rt2x00lib_request_firmware: Info - Loading firmware file 'rt2870.bin'
[27394.150937] ieee80211 phy2: rt2x00lib_request_firmware: Info - Firmware detected - version: 0.36
[27395.779361] wlx000f0032e9c8: authenticate with e4:9e:12:cf:e8:09
[27395.790695] wlx000f0032e9c8: send auth to e4:9e:12:cf:e8:09 (try 1/3)
[27395.792593] wlx000f0032e9c8: authenticated
[27395.798527] wlx000f0032e9c8: associate with e4:9e:12:cf:e8:09 (try 1/3)
[27395.801965] wlx000f0032e9c8: RX AssocResp from e4:9e:12:cf:e8:09 (capab=0x401 status=0 aid=1)
[27395.804884] wlx000f0032e9c8: associated
[27395.805216] IPv6: ADDRCONF(NETDEV_CHANGE): wlx000f0032e9c8: link becomes ready

Under Linux (XUbuntu 19.04), everything works fine (detection of networks/connection to networks/upload&download), apart the fact that the computer totally freezes/crashes in less than 2 hours as soon as the ALFA device is plugin. When I use the computer without the ALFA device plugged, everything works fine (tested reaching a 12 days uptime!)

Under windows (10 1903) everything works fine whatever the conditions (there's no crashes, even with the ALFA device plugged, tested reaching 24hrs uptime - sorry, I'm not able to use Windows more than that ;)...).

So my (informed) guess is that there's a bug either...

[Kai-Heng Feng (kaihengfeng)]

Is the issue still present if the all packages are up to date?

[G.M. (sexxxenator)]

Hi,

I've been using the computer for a few days now after upgrading the whole system and it seems to be a lot more stable.

Thanks!

I would be glad to know what has changed (and also how to debug so drastic crashes) so that in the future I would not waste so mcuh time (and work) due to similar problems...