Created attachment 5663 [details]
dmesg file of the subject kernel

Created attachment 5664 [details]
result of command 'lspci -vv'

Created attachment 5665 [details]
result of 'cat /proc/cpuinfo'

Created attachment 5666 [details]
result of cat /proc/modules'

Created attachment 5667 [details]
result of both 'cat /proc/ioports' and 'cat /proc/iomem'

Created attachment 5668 [details]
result of 'cat /proc/scsi/scsi'

Created attachment 5669 [details]
journalctl -a of new kernel install and (after reboot) use

With the same kernel, on this system:

https://wiki.mageia.org/en/User:Marja/QA/Hardware#Lenovo_ThinkPad_L530
(But without the Ralink USB Wlan adapter, seeing it in the old lspcidrake -v output makes me suddenly remember I needed that one for two different access points on - only - this laptop, until I switched to NetworkManager)

I could switch to a text tty without problems, and the system didn't seem slow. The only problem was WLAN connection, which worked, but worked badly: watching a television stream worked near to not at all. Typing in my irssi session on my raspberry went almost as bad as if I was on a 3g network instead of on the same local network as the raspberry.

Rebooting with the previous kernel made the problems disappear.

I'll attach 
journalctl -a --since="2014-11-30 15:08:54" --until="2014-11-30 17:37:00" 2>&1 | tee kernel_3.18.0-0.rc6_journalctl-a from the moment I installed the new kernel, then some (re)boots using it until I finally gave up.

If this is unrelated to dvg's problem, then I'll clone this bug for whatever my issue with this kernel is. Just tell me :-)

CC: (none) => marja11

rc7.1 is perceived to be a little less slow, but still it is too slow for comfort.

Source RPM: kernel-3.18.0-0.rc6.1.mga5 => kernel-3.18.0-0.rc7.1.mga5
Summary: kernel-server-3.18.0-0.rc6.1 too slow for comfort => kernel-server-3.18.0-0.rc7.1 too slow for comfort

(In reply to Dick Gevers from comment #8)
> rc7.1 is perceived to be a little less slow, but still it is too slow for
> comfort.

Same here wrt the network problem. There might be a little improvement, but it is very far from good enough.

Hmm, I had missed that dvg was talking about kernel-server (I should better read the summary)
I was talking about the desktop one.

After the KDE updates, I accidentally booted into kernel-desktop-3.18.0-0.rc7.1 and did no longer see much of the problems I reported before. So whatever caused my bad network connection with that kernel, it is unlikely it was the new kernel itself.

Sorry: latest kernel has the same problem.

Source RPM: kernel-3.18.0-0.rc7.1.mga5 => kernel-3.18.0-0.rc7.2.mga5
Summary: kernel-server-3.18.0-0.rc7.1 too slow for comfort => kernel-server-3.18.0-0.rc7.2 too slow for comfort

@Dick: can you test if kernel-desktop behaves the same or not

And preferably with 3.18.0 final wich is currently building

I will try latest server and desktop as soon as I see them

I perceive some improvement, equally with desktop and kernel in 18-0.1 and tty's can now be accessed again. So yes, better.

But I still prefer the last 17: kernel-server-3.17.4-1 which is decidedly faster for me. 

I agree that 18-0.1 is getting closer to 17.4-1 in respect of speed (responsiveness), but I do notice still a marked difference.

Source RPM: kernel-3.18.0-0.rc7.2.mga5 => kernel-3.18.0-1.mga5
Summary: kernel-server-3.18.0-0.rc7.2 too slow for comfort => kernel-3.18.0-1 too slow for comfort

_Probably_totally_off_topic_

Sorry, but I don't have a clue against what to report:

The network issues I reported before still exist, after all, but now with the 3.17.4 kernel, too. A 5beta1 install (only tested with the new kernel!) has it, too.

On the first install, with NetworkManager, a second WLAN adapter won't work at all (forgot to check whether there is still an old line in a congfiguration file about disabling NM for it that didn't get overwritten when I re-added the adapter)

On the second install, without NetworkManager, the second WLAN adapter has the same problems as the first (so video streams don't come in smoothly and there are delays even with just ssh'ing into an irssi session on a local network server and typing a message).


Yesterday, after starting "mcc" on a remote Mga4 system I had ssh'ed into, my system here almost froze. That was with the new kernel, I hope to find time to try again with the 3.17.4 one.

Is it possible that a hardware issue outside the WLAN adapters causes problems with both?

Or maybe I should first try a nonfree 5beta1 install with nonfree drivers, but without updates?

I do see very many lines of this now, on the first cauldron I had problems with after updating to a 3.18 kernel: 

Dec 11 14:45:28 DenkBlok3Cauldron5a1 kernel: rtl8192c_common:rtl92c_fill_h2c_cmd(): return H2C cmd because of Fw download fail!!!

(This time booted with the new kernel)

(In reply to Marja van Waes from comment #17)
> I do see very many lines of this now, on the first cauldron I had problems
> with after updating to a 3.18 kernel: 
> 
> Dec 11 14:45:28 DenkBlok3Cauldron5a1 kernel:
> rtl8192c_common:rtl92c_fill_h2c_cmd(): return H2C cmd because of Fw download
> fail!!!
> 
> (This time booted with the new kernel)

Do you have nonfree firmwares installed ?

[marja@DenkBlok3Cauldron5a1 ~]$ rpm -qa |grep nonfree
kernel-firmware-nonfree-20141106-1.mga5.nonfree
microcode-0.20140913-4.mga5.nonfree
iwlwifi-agn-ucode-20141106-1.mga5.nonfree
flash-player-plugin-11.2.202.425-1.mga5.nonfree
ralink-firmware-20141106-1.mga5.nonfree
bluez-firmware-1.2-12.mga5.nonfree
rtlwifi-firmware-20141106-1.mga5.nonfree
radeon-firmware-20141106-1.mga5.nonfree
[marja@DenkBlok3Cauldron5a1 ~]$ 

I don't see the same error message now, and wlan works fine, after starting with the old kernel
[marja@DenkBlok3Cauldron5a1 ~]$ uname -r
3.17.4-desktop-1.mga5
[marja@DenkBlok3Cauldron5a1 ~]$

I'll add the "uname -r" output every time now, to make sure I booted with the kernel I think I booted with.

after rebooting 

[marja@DenkBlok3Cauldron5a1 ~]$ uname -r
3.18.0-desktop-1.mga5
[marja@DenkBlok3Cauldron5a1 ~]$ 

The lines appear again:
Dec 11 15:12:05 DenkBlok3Cauldron5a1 kernel: rtl8192c_common:rtl92c_fill_h2c_cmd(): return H2C cmd because of Fw download fail!!!
Dec 11 15:12:07 DenkBlok3Cauldron5a1 kernel: rtl8192c_common:rtl92c_fill_h2c_cmd(): return H2C cmd because of Fw download fail!!!

I do *not* have this problem on another laptop with intel wifi card.


The one with the problem, has the same issue with the 2nd round pre-5beta2 KDE Live DVD

journalctl -f did hung and had to be restarted to show the related errors.

Whiteboard: (none) => 5beta2

however, on the same laptop, a Ralink 802.11 n WLAN adapter
( rt2800usb  : Ralink|802.11 n WLAN (vendor:7392 device:7711) )
won't work at all with the 3.18.0 desktop kernel, but it works fine with the 3.17.4 desktop kernel.

with 3.18.0 I saw this:

dec 13 22:51:49 localhost kernel: ieee80211 phy1: rt2x00usb_vendor_request: Error - Vendor Request 0x06 failed for offset 0x0404 with error -71
dec 13 22:51:49 localhost kernel: ieee80211 phy1: rt2800_wait_bbp_ready: Error - BBP register access failed, aborting
dec 13 22:51:49 localhost kernel: ieee80211 phy1: rt2800usb_set_device_state: Error - Device failed to enter state 4 (-5)

The above errors for the Ralink were with the KDE Live DVD

On an existing cauldron install (the same one where that WLAN adapter works fine with the old kernel), I see an avalanche of:
Dec 13 23:29:08 DenkBlok3Cauldron5a1_EFI NetworkManager[834]: <error> [1418509748.883984] [supplicant-manager/nm-supplicant-interface.c:856] interface_add_cb(): (wlp0s20u2): error adding interface: wpa_supplicant couldn't grab this interface.

The wlp0s20u2 is the Ralink

Latest today, regret I have to say as earlier:

I perceive some improvement with 18-0.2. So yes, better.

But I still prefer the last 17: kernel-server-3.17.4-1 which is decidedly faster for me. 

I agree that 18-0.2 is getting closer to 17.4-1 in respect of speed (responsiveness), but I do notice still a marked difference.

Summary: kernel-3.18.0-1 too slow for comfort => kernel-3.18.0-2 too slow for comfort
Source RPM: kernel-3.18.0-1.mga5 => kernel-3.18.0-2.mga5

@Dick, does it change it anything if you add:

scsi_mod.use_blk_mq=0

to kernel command line ?

@tmb: sorry no, adding "scsi_mod.use_blk_mq=0" to boot paramater does not show any change.

[marja@DenkBlok3Cauldron5a1_EFI ~]$ uname -r
3.18.0-desktop-2.mga5
[marja@DenkBlok3Cauldron5a1_EFI ~]$ 

for the 
rtl8192ce       : Realtek Semiconductor Co., Ltd.|RTL8188CE 802.11b/g/n WiFi Adapter [NETWORK_OTHER] (vendor:10ec device:8176 subv:10ec subd:8195) (rev: 01)


I still get 
Dec 14 20:05:41 DenkBlok3Cauldron5a1_EFI kernel: rtl8192c_common:rtl92c_fill_h2c_cmd(): return H2C cmd because of Fw download fail!!!
Dec 14 20:05:43 DenkBlok3Cauldron5a1_EFI kernel: rtl8192c_common:rtl92c_fill_h2c_cmd(): return H2C cmd because of Fw download fail!!!


and it still works just as badly


Sorry :-(

(In reply to Marja van Waes from comment #27)
> [marja@DenkBlok3Cauldron5a1_EFI ~]$ uname -r
> 3.18.0-desktop-2.mga5
> [marja@DenkBlok3Cauldron5a1_EFI ~]$ 
> 

Didn't log out, but plugged in the USB wlan adapter that wouldn't work with this kernel before, so this one:
rt2800usb       : Ralink|802.11 n WLAN (vendor:7392 device:7711)
and disabled the on board one.

At first it worked, but not very well, it resembled the Realtek one.

I didn't catch a repeating error when it still worked.

After that, there came the following error, endlessly repeated, and I had no more connection:

Dec 14 20:21:25 DenkBlok3Cauldron5a1_EFI kernel: ieee80211 phy1: rt2x00usb_watchdog_tx_dma: Warning - TX queue 2 DMA timed out, invoke forced forced reset
Dec 14 20:21:26 DenkBlok3Cauldron5a1_EFI kernel: ieee80211 phy1: rt2x00usb_watchdog_tx_dma: Warning - TX queue 2 DMA timed out, invoke forced forced reset
Dec 14 20:21:27 DenkBlok3Cauldron5a1_EFI kernel: ieee80211 phy1: rt2x00usb_watchdog_tx_dma: Warning - TX queue 2 DMA timed out, invoke forced forced reset
Dec 14 20:21:28 DenkBlok3Cauldron5a1_EFI kernel: ieee80211 phy1: rt2x00usb_watchdog_tx_dma: Warning - TX queue 2 DMA timed out, invoke forced forced reset

(In reply to Dick Gevers from comment #26)
> @tmb: sorry no, adding "scsi_mod.use_blk_mq=0" to boot paramater does not
> show any change.

That actually makes me happy, as I can keep the new improved block scheduler active :)

As for your problem, it might be the mm bug that is still being tracked / figured out...

(In reply to Marja van Waes from comment #27)
> [marja@DenkBlok3Cauldron5a1_EFI ~]$ uname -r
> 3.18.0-desktop-2.mga5
> [marja@DenkBlok3Cauldron5a1_EFI ~]$ 
> 
> for the 
> rtl8192ce       : Realtek Semiconductor Co., Ltd.|RTL8188CE 802.11b/g/n WiFi
> Adapter [NETWORK_OTHER] (vendor:10ec device:8176 subv:10ec subd:8195) (rev:
> 01)
> 
> 
> I still get 
> Dec 14 20:05:41 DenkBlok3Cauldron5a1_EFI kernel:
> rtl8192c_common:rtl92c_fill_h2c_cmd(): return H2C cmd because of Fw download
> fail!!!
> Dec 14 20:05:43 DenkBlok3Cauldron5a1_EFI kernel:
> rtl8192c_common:rtl92c_fill_h2c_cmd(): return H2C cmd because of Fw download
> fail!!!
> 
> 
> and it still works just as badly
> 
> 
> Sorry :-(

This is really a different bug that could have had it's own bugreport, but no need for now as I now have found the fix for it.... Seems upstream forgot some more fixes during fw management conversion...

I will merge the fix now so it will be part of next kernel build

(In reply to Thomas Backlund from comment #30)
> (In reply to Marja van Waes from comment #27)

> 
> This is really a different bug that could have had it's own bugreport, but
> no need for now as I now have found the fix for it.... Seems upstream forgot
> some more fixes during fw management conversion...
> 
> I will merge the fix now so it will be part of next kernel build

2x thanks :-)

(In reply to Marja van Waes from comment #31)
> (In reply to Thomas Backlund from comment #30)
> > (In reply to Marja van Waes from comment #27)
> 
> > 
> > This is really a different bug that could have had it's own bugreport, but
> > no need for now as I now have found the fix for it.... Seems upstream forgot
> > some more fixes during fw management conversion...
> > 
> > I will merge the fix now so it will be part of next kernel build
> 
> 2x thanks :-)

So, 3.18.1-1 is out, does it work any better ?

(In reply to Thomas Backlund from comment #32)

> 
> So, 3.18.1-1 is out, does it work any better ?

[marja@DenkBlok3Cauldron5a1_EFI ~]$ uname -r
3.18.1-desktop-1.mga5
[marja@DenkBlok3Cauldron5a1_EFI ~]$ lspcidrake -v | grep 802.11
rtl8192ce       : Realtek Semiconductor Co., Ltd.|RTL8188CE 802.11b/g/n WiFi Adapter [NETWORK_OTHER] (vendor:10ec device:8176 subv:10ec subd:8195) (rev: 01)
[marja@DenkBlok3Cauldron5a1_EFI ~]$ 

for the Realtek, it works lots better, even after ssh'ing from a remote network into my irssi session I don't see any delays when typing messages, the "Fw download fail!!!" error is gone and surfing the internet works fine.


I'll try the Ralink USB wlan adapter later (maybe not before I'm home)

No better for me, I'm afraid. If I compare last 17 and the 18's:

when swirling a spoon through liquid, 17's are like going through water and 18's are like going through a thick syrup...

Summary: kernel-3.18.0-2 too slow for comfort => kernel-3.18.1-1 too slow for comfort
Source RPM: kernel-3.18.0-2.mga5 => kernel-3.18.1-1.mga5

@Dick, can you provide dmesg from the 3.18.1-1 and one from the working 3.17...

(In reply to Marja van Waes from comment #33)
> (In reply to Thomas Backlund from comment #32)
> 
> > 
> > So, 3.18.1-1 is out, does it work any better ?
> 

> 
> I'll try the Ralink USB wlan adapter later (maybe not before I'm home)

Forget about the Ralink!

Using the new kernel doesn't work too well with the WAP where I am now, *but*:
this time, after rebooting into the _3.17_ kernel, and disabling the on board card, there is no wlan at all.

[marja@DenkBlok3Cauldron5a1_EFI BlueHD]$ uname -r
3.17.4-desktop-1.mga5
[marja@DenkBlok3Cauldron5a1_EFI BlueHD]$

And in journalctl -f and endless amount of:
Dec 16 14:32:17 DenkBlok3Cauldron5a1_EFI NetworkManager[854]: <error> [1418736737.581199] [supplicant-manager/nm-supplicant-interface.c:856] interface_add_cb(): (wlp0s20u2): error adding interface: wpa_supplicant couldn't grab this interface.

Anyway, I'm glad the on board WLAN adapter card works well, now :-)

Created attachment 5712 [details]
dmesg of 18.1-1

of course

Created attachment 5713 [details]
dmesg of 17.4-1

Not improved with new kernel.

Summary: kernel-3.18.1-1 too slow for comfort => kernel-3.18.1-2 too slow for comfort
Source RPM: kernel-3.18.1-1.mga5 => kernel-3.18.1-2.mga5

Same again. Sorry

Source RPM: kernel-3.18.1-2.mga5 => kernel-3.18.1-3.mga5
Summary: kernel-3.18.1-2 too slow for comfort => kernel-3.18.1-3 too slow for comfort

Still the same.

Summary: kernel-3.18.1-3 too slow for comfort => kernel-3.18.1-4 too slow for comfort
Source RPM: kernel-3.18.1-3.mga5 => kernel-3.18.1-4.mga5

Still the same

Summary: kernel-3.18.1-4 too slow for comfort => kernel-3.18.2-1 too slow for comfort
Source RPM: kernel-3.18.1-4.mga5 => kernel-3.18.2-1.mga5

Sorry: same.

Source RPM: kernel-3.18.2-1.mga5 => kernel-3.18.3-1.mga5
Summary: kernel-3.18.2-1 too slow for comfort => kernel-3.18.3-1 too slow for comfort

Same again.

Source RPM: kernel-3.18.3-1.mga5 => kernel-3.18.3-2.mga5
Summary: kernel-3.18.3-1 too slow for comfort => kernel-3.18.3-2 too slow for comfort

Sorry: same again.

Summary: kernel-3.18.3-2 too slow for comfort => kernel-3.19.0-0.rc7.2 too slow for comfort
Source RPM: kernel-3.18.3-2.mga5 => kernel-3.19.0-0.rc7.2.mga5

Still valid.

Source RPM: kernel-3.19.0-0.rc7.2.mga5 => kernel-3.19.0-1.mga5
Summary: kernel-3.19.0-0.rc7.2 too slow for comfort => kernel-3.19.0-1 too slow for comfort

Just to be sure, I used the new kernel for several hours today. But it is not really bearable. If this were the standard now I would say: it is time to buy a new computer. Except now I know it does work well with kernel-server-3.17.4-1.

Summary: kernel-3.19.0-1 too slow for comfort => kernel-3.19.0-2 too slow for comfort
Source RPM: kernel-3.19.0-1.mga5 => kernel-3.19.0-2.mga5

@Dick

Can you add dmesg from 3.19 too so I can see if it behaves any differently

Created attachment 5941 [details]
dmesg of kernel-server-3.19.0-2

Sure. Attached.

Same.

Summary: kernel-3.19.0-2 too slow for comfort => kernel-3.19.0-3 too slow for comfort
Source RPM: kernel-3.19.0-2.mga5 => kernel-3.19.0-3.mga5

As before.

Summary: kernel-3.19.0-3 too slow for comfort => kernel-3.19.0-4 too slow for comfort
Source RPM: kernel-3.19.0-3.mga5 => kernel-3.19.0-4.mga5

@Dick

Do you still have issues with 
tty1 with [ alt + ctrl + function key ]
on kernel 3.19.0-4 ?

Do you have an nVIDIA graphics card?

On my notebook with nVIDIA GeForce GT650M and Mageia 5 beta 3 with kernel 3.19.0-desktop-4 I get a black screen when pressing CTRL-ALT-F2. But when I type it actually works, but it is not visible. CTRL-ALT-F1 goes back to KDE.

CC: (none) => bert.ram.aerts

My experiments to solve the issue can be found in the Mageia Forum
https://forums.mageia.org/en/viewtopic.php?f=15&t=9041&sid=52c8f9180e96aa396e1773c546b9fb8a

CONFIG_X86_SYSFB=y
http://gentoo-en.vfose.ru/wiki/UEFI#Kernel_Options
Would setting this kernel config flag be a solution for the tty issue ?

Applies to latest kernel. 

To: bert.ram.aerts@gmail.com per #c52: the other tty's can be reached okay here, no problem.

Summary: kernel-3.19.0-4 too slow for comfort => kernel-3.19.0-5 too slow for comfort
Source RPM: kernel-3.19.0-4.mga5 => kernel-3.19.0-5.mga5
Whiteboard: 5beta2 => 5rc

Same.

Summary: kernel-3.19.0-5 too slow for comfort => kernel-3.19.0-6 too slow for comfort
Source RPM: kernel-3.19.0-5.mga5 => kernel-3.19.0-6.mga5

Same again.

Summary: kernel-3.19.0-6 too slow for comfort => kernel-3.19.1-1 too slow for comfort
Source RPM: kernel-3.19.0-6.mga5 => kernel-3.19.1-1.mga5

Tried it for a few days, and there is surely improvement since this was first reported, but it is still not as good an instant response as with kernel 3.17.4-1.mga5

Summary: kernel-3.19.1-1 too slow for comfort => kernel-3.19.1-2 too slow for comfort
Source RPM: kernel-3.19.1-1.mga5 => kernel-3.19.1-2.mga5

Same again.

Summary: kernel-3.19.1-2 too slow for comfort => kernel-3.19.2-1 too slow for comfort
Source RPM: kernel-3.19.1-2.mga5 => kernel-3.19.2-1.mga5

With 3.19.2-2 I am happy it is as good as 3.17*.

Thank you!

Status: NEW => RESOLVED
Resolution: (none) => FIXED