Description of problem: I was trying to update Mageia-5-RC-x86_64 to kernel-3.19.7, but It takes forever to search the database for packages. Top tells me that RTWHALXT 100% of CPU time. What does it do? I used btrfs on all partitions. Could that be a problem. Could it be swapping? But why? Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Reproducible: Steps to Reproduce:
A re-boot did the trick (but still, why?). It is now updating 169 packages.
My Intel Compute Stick is now running kernel-3.19.7-desktop-1 with Wi-Fi working. According to Tom's Hardware it should also have Bluetooth......
Unfortunately: this morning RTWHALXT is again using all CPU power.
The WiFi connection is hanging, but this is not all. Monotoring network tells me that there are 3 udp connections established to remote port 123 of these addresses 78.156.103.10 77.66.33.146 195.234.155.123 nslookup 195.234.155.123 123.155.234.195.in-addr.arpa name = ntp.dvconsulting.dk 155.234.195.in-addr.arpa nameserver = ns10.skaarupaps.dk. 155.234.195.in-addr.arpa nameserver = ns11.skaarupaps.dk. whois ntp.dvconsulting.dk # Hello 87.104.6.180. Your session has been logged. # # Copyright (c) 2002 - 2015 by DK Hostmaster A/S # # Version: 2.0.2 No entries found for the selected source. This looks as an attack. I had the impression that chrony does not use ntp servers. By the way. Are you aware that mageia.org is graded F by ssllabs.com?
Too fast! whois dvconsulting.dk Registrant Handle: DCA300-DK Name: DV CONSULTING A/S Address: Strandvejen 100 Postalcode: 2900 City: Hellerup Country: DK Phone: +45 26707070 I am running top to look what happens. Maybe the driveris unstable.
It does not look good. I was running ping for more than an hour without problems. Then I installet traceroot with urpmi traceroot When it had finished, I started typing, an the screen froze. I had to turn off power and re-boot. After the reboot, the Wi-Fi did not come up again. I ran dmesg and journalctl -b. The outputs of these are attached.
Created attachment 6483 [details] dmesg output after re-boot
CC: (none) => bjarne.thomsen
Created attachment 6484 [details] journalctl -b output after re-boot Call Trace: [<ffffffff816c19da>] dump_stack+0x45/0x57 etc. etc.
RTWHALXT is part of the new wifi driver yes, and its a little bit of a mess right now and needs more work... I will look if there are more valid "safe" fixes to pull in...
CC: (none) => tmb
I have made some further tests of the Wi-Fi driver. Normally it works between 1 and 4 hours. Then the system freezes, and I have to use the power button to re-boot. But there has been sufficient time to update the system.
does the new kernel-3.19.8-1 work any better ?
I do not think so, but let be try again. The system now completely freezes. In principle it could be something else. Is there a way to use journalctl to trace what exactly happened before it froze, that is after a reboot? On the other hand, I have not seen it happen, if I remove the WiFi interface.
Actually, I had not updated to kernel-3.19.8-1 on the Compute Stick. This is now done, and ping has been running since 15:15. I did notice one thing that I had overlooked. It only finds my Asus EA-N66 access point. I also have a Cisco AP.
After 45min of running ping the screen is now frozen. Anything that I can do to figure out what happened?
So is it better or worse than before ? Is the Cisco AP a 2.4 or 5G one as for figuring out... When you reboot / start a new ping... open a second terminal window and as root run: journalctl -f to keep it tracking all logging That could maybe catch the oops / crash that happends
Created attachment 6523 [details] Error from drakroam during Wi-Fi configuration
Created attachment 6524 [details] lspcidrake -v lspcidrake -v after drakroam error.
Created attachment 6525 [details] journalctl for May 12 after crash and re-boot It only took a few minutes before it crashed. I included the log for this afternoon. I am not quite sure what to look for.
Are you really going th ship mga5 with an EOL kernel?
(In reply to Bjarne Thomsen from comment #19) > Are you really going th ship mga5 with an EOL kernel? Well kernels get EOL'ed pretty fast nowadays, 3.19.0 was released in February and is already EOL... If we were to upgrade now to 4.0, it would most likely delay the release of Mageia 5 until we've sorted out all the new issues, and eventually 4.0.x would likely also be EOL in 2-3 months. I guess the plan is to do a branch update sometimes after Mageia 5's release, and until then Thomas will likely backport fixes of the somewhat-longterm 3.18 branch.
This is OT for this bugreport... but... I/We will team up with Ubuntu kernel team as they too are using 3.19 ... Later on we will do a version bump to a newer kernel/mesa/... in order to properly support the upcoming Intel Skylake... By the looks of it, I think it will be ~4.2 that probably also will be the next -longterm kernel.
*** Bug 15789 has been marked as a duplicate of this bug. ***
This sounds good.
Assignee: bugsquad => tmbSource RPM: Mageia-5-RC-x86_64-DVD => kernelWhiteboard: (none) => MGA5TOO
Linux 4.0, Linux 4.1 Brings Performance Boosts For Some Intel Low-Power Hardware: For at least some Intel Bay Trail systems, the Linux 4.0 and Linux 4.1 kernels bring measurable performance improvements as shown by this latest round of Phoronix kernel benchmarking. http://www.phoronix.com/scan.php?page=article&item=linux-41-byt&num=1
We already carry some of the performance fixes, but yes. 4.1+ will improve things...
kernel 4.1.7 is now in updates testing, please try it out
Depends on: (none) => 16655
Indeed. Wi-Fi has now been working for more than 2 hours. I have surfed using firefox and downloaded IMAP mails in thunderbird. Finally, I downloaded a Mageia DVD-iso without any problems.
I am closing this report
Status: NEW => RESOLVEDResolution: (none) => FIXED