Kernel rc7.git0.3

[jakebpg]

Anyone else have trouble with this kernel?

Man it slowed my laptop down to a crawl, Scrolling Firefox is like working on an i386 60Mhz processor. I had to boot into the rc6 kernel because the slow down was unbearable!

[hostace]

This is ok. Because debugging in kernel was on for debug the bugs. Just wait for the next kernel release, it's will be ok.

[jakebpg]

This is ok. Because debugging in kernel was on for debug the bugs. Just wait for the next kernel release, it's will be ok.

I know I was just wondering how many people saw this horrible slow down and if it was as bad on their machine as it is on mine.

I moved to the alpha release because I had so many problems with F16 that it wasn't even funny!

And after testing some of the F17 nightlies on a USB drive I use for backups decided it was in much better shape for my machine then F16 and worked perfectly so I installed the alpha when it was released!

I don't mind helping debugging fedora as long as it doesn't make my laptop crawl like a snail trying to get across a hot piece of concrete!

[hostace]

This is not for users. Thi i for testers (testing purpose). This is temporary action. You may use the rc6 kernel. Just note, that F17 is not production-ready (but I'm using it on my laptop, because F16 have no some feachures, which introdused in F17). Debugging is needed for developers - they need understand what's happen, and how to fix the bugs. I think, in next kernel release all will be ok. You must understand, that it's only release candidate of kernel and it have some problems, which must be fixed.

---------- Post added at 08:12 PM ---------- Previous post was at 07:52 PM ----------

In other cae you may manually install this kernel for now: http://koji.fedoraproject.org/koji/buildinfo?buildID=306717 - this is same kernel with disable debugging options. Pleae note, that you must install also kernel-tools package and probably kernel-headers. You can see which package you need to update with rpm -qa | grep kernel

[jakebpg]

This is not for users. Thi i for testers (testing purpose). This is temporary action. You may use the rc6 kernel. Just note, that F17 is not production-ready (but I'm using it on my laptop, because F16 have no some feachures, which introdused in F17). Debugging is needed for developers - they need understand what's happen, and how to fix the bugs. I think, in next kernel release all will be ok. You must understand, that it's only release candidate of kernel and it have some problems, which must be fixed.

I know exactly what Alpha means. And I do report all the bugs that pop-up. But this new kernel isn't going to run on my laptop. It's like I said running at snails pace.

Like I said I don't mind testing the software because it helps all who will be using F17 when the final release comes out.

Without testers a rock solid release would not be possible because the devs do not have enough time or machines to discover all the bugs that may or may not pop up during daily use.

[hostace]

I'm added to my post some stuff. Please read it. You may download other kernel from koji build sytem.

[jakebpg]

I'm added to my post some stuff. Please read it. You may download other kernel from koji build sytem.

I already have that build on my test drive. Haven't had the time to test it yet.

What I've been doing since I installed the alpha is when updates show up in the task bar I ignore them on the laptop drive, reboot to the USB drive download and test them there so as not to mess up what is working on the laptop. But this morning I didn't do that though, wasn't really paying attention at the time because of a distraction and just clicked OK. After it was almost done it was to late to cancel, so just rebooted to see what changed and if I needed to drop back to the preupdate system. Everything works fine except for the kernel, so rebooted into rc6 and now its back to normal.

I do still have to update my test drive and run on that for awhile and if anything pops up then I'll submit the bugs as I normally do.

Thanks for answering the post though.

[DBelton]

both the rc6 and rc7 kernels don't work here on my system. Keep filling up my log with errors. The rc5 kernel works fine, though.

This is what I get thrown to my log...


Mar 14 10:32:56 tower20 kernel: [23048.955370] Disabling IRQ 23
Mar 14 10:32:56 tower20 kernel: [23048.965055] Polling IRQ 23
Mar 14 10:32:57 tower20 kernel: [23050.030055] Reenabling IRQ 23
Mar 14 10:32:57 tower20 kernel: [23050.455380] Disabling IRQ 23
Mar 14 10:32:57 tower20 kernel: [23050.465036] Polling IRQ 23
Mar 14 10:32:58 tower20 kernel: [23051.506055] Reenabling IRQ 23
Mar 14 10:33:00 tower20 kernel: [23053.418504] Disabling IRQ 23
Mar 14 10:33:00 tower20 kernel: [23053.428029] Polling IRQ 23
Mar 14 10:33:01 tower20 kernel: [23054.522041] Reenabling IRQ 23
Mar 14 10:33:02 tower20 kernel: [23054.955367] Disabling IRQ 23
Mar 14 10:33:02 tower20 kernel: [23054.965064] Polling IRQ 23
Mar 14 10:33:03 tower20 kernel: [23055.981040] Reenabling IRQ 23
Mar 14 10:33:08 tower20 kernel: [23061.455399] Disabling IRQ 23
Mar 14 10:33:08 tower20 kernel: [23061.465045] Polling IRQ 23
Mar 14 10:33:09 tower20 kernel: [23062.516039] Reenabling IRQ 23
Mar 14 10:33:56 tower20 kernel: [23109.455206] Disabling IRQ 23
Mar 14 10:33:56 tower20 kernel: [23109.465053] Polling IRQ 23
Mar 14 10:33:57 tower20 kernel: [23110.487068] Reenabling IRQ 23


As you can see, all of those messages were written in about 1 minute. Just think how large the log file gets after running for hours, or days... And how much it slows down the system to write all of them.

[hostace]

Probably you need add option quiet irqpoll to the kernel options at boot into grub configuration. It will be fixed in further updates, I think. FC15 and FC16 kernels are fixed, some releases ago they also has some problem.

[mmix]

screen resolution: 1920x1080 -> 1024x768
nouveau driver: bad -> good

[AdamW]

dbelton: I doubt that writing those logs slows the system down at all. there's only three messages written every few seconds. sounds like a lot to a human but it's piddling to a program.

However, I suspect the messages relate to this change in the kernel changelog:

* Thu Mar 01 2012 Dave Jones <davej@redhat.com>
- temporarily switch to low-performance polling IRQ mode when unexpected IRQs occur.

so writing the messages isn't slowing things down, but 'switch to low-performance polling IRQ mode' sure could be.

I wonder if this is to do with your problematic Wacom tablet? If you unplug that, does this mess go away?

[PaulAlesius]

I agree, they should at least inform the people that this makes the OS unusable. I tried creating a bug report https://bugzilla.redhat.com/show_bug.cgi?id=802091
sadly they didn't think it's necessary to inform other than kernel hackers of what makes the thing unusably slow.

[DBelton]

dbelton: I doubt that writing those logs slows the system down at all. there's only three messages written every few seconds. sounds like a lot to a human but it's piddling to a program.

However, I suspect the messages relate to this change in the kernel changelog:

* Thu Mar 01 2012 Dave Jones <davej@redhat.com>
- temporarily switch to low-performance polling IRQ mode when unexpected IRQs occur.

so writing the messages isn't slowing things down, but 'switch to low-performance polling IRQ mode' sure could be.

I wonder if this is to do with your problematic Wacom tablet? If you unplug that, does this mess go away?


No, Get the same thing with the wacom tablet unplugged.

I am suspecting it's more to do with the logitech mouse drivers, and causing my flaky mouse issues.



Mar 14 18:02:57 tower20 kernel: [ 4.202601] usb 2-2.3: new full-speed USB device number 3 using uhci_hcd
Mar 14 18:02:57 tower20 kernel: [ 4.338643] usb 2-2.3: New USB device found, idVendor=046d, idProduct=c52b
Mar 14 18:02:57 tower20 kernel: [ 4.338727] usb 2-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Mar 14 18:02:57 tower20 kernel: [ 4.338836] usb 2-2.3: Product: USB Receiver
Mar 14 18:02:57 tower20 kernel: [ 4.338900] usb 2-2.3: Manufacturer: Logitech
Mar 14 18:02:57 tower20 kernel: [ 4.389581] logitech-djreceiver 0003:046D:C52B.0003: hiddev0,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:1d.0-2.3/input2
Mar 14 18:02:57 tower20 kernel: [ 4.389754] ------------[ cut here ]------------
Mar 14 18:02:57 tower20 kernel: [ 4.389824] WARNING: at lib/dma-debug.c:930 check_for_stack+0xa9/0xf0()
Mar 14 18:02:57 tower20 kernel: [ 4.389897] Hardware name: MS-7529
Mar 14 18:02:57 tower20 kernel: [ 4.389961] uhci_hcd 0000:00:1d.0: DMA-API: device driver maps memory fromstack [addr=ffff880121a27c01]
Mar 14 18:02:57 tower20 kernel: [ 4.390086] Modules linked in: hid_logitech_dj(+)
Mar 14 18:02:57 tower20 kernel: [ 4.390194] Pid: 107, comm: udevd Not tainted 3.3.0-0.rc5.git3.1.fc17.x86_64 #1
Mar 14 18:02:57 tower20 kernel: [ 4.390293] Call Trace:
Mar 14 18:02:57 tower20 kernel: [ 4.390355] [<ffffffff81060d6f>] warn_slowpath_common+0x7f/0xc0
Mar 14 18:02:57 tower20 kernel: [ 4.390422] [<ffffffff81060e66>] warn_slowpath_fmt+0x46/0x50
Mar 14 18:02:57 tower20 kernel: [ 4.390488] [<ffffffff8133ef89>] check_for_stack+0xa9/0xf0
Mar 14 18:02:57 tower20 kernel: [ 4.390554] [<ffffffff8133f6da>] debug_dma_map_page+0xea/0x150
Mar 14 18:02:57 tower20 kernel: [ 4.390622] [<ffffffff8148754b>] usb_hcd_map_urb_for_dma+0x54b/0x5d0
Mar 14 18:02:57 tower20 kernel: [ 4.390695] [<ffffffff810285df>] ? save_stack_trace+0x2f/0x50
Mar 14 18:02:57 tower20 kernel: [ 4.390762] [<ffffffff8148785d>] usb_hcd_submit_urb+0x28d/0x870
Mar 14 18:02:57 tower20 kernel: [ 4.390829] [<ffffffff81488ad0>] usb_submit_urb+0xf0/0x3b0
Mar 14 18:02:57 tower20 kernel: [ 4.390895] [<ffffffff81489dd2>] usb_start_wait_urb+0x82/0x1a0
Mar 14 18:02:57 tower20 kernel: [ 4.390962] [<ffffffff81488efe>] ? usb_alloc_urb+0x1e/0x50
Mar 14 18:02:57 tower20 kernel: [ 4.391042] [<ffffffff8148a15e>] usb_control_msg+0xde/0x140
Mar 14 18:02:57 tower20 kernel: [ 4.391109] [<ffffffff81235712>] ? sysfs_add_file+0x12/0x20
Mar 14 18:02:57 tower20 kernel: [ 4.391176] [<ffffffff8152c712>] usbhid_output_raw_report+0xd2/0x100
Mar 14 18:02:57 tower20 kernel: [ 4.391247] [<ffffffffa0000661>] logi_dj_recv_send_report.isra.7+0x21/0x50 [hid_logitech_dj]
Mar 14 18:02:57 tower20 kernel: [ 4.391352] [<ffffffffa00006e1>] logi_dj_recv_switch_to_dj_mode.constprop.13+0x51/0x70 [hid_logitech_dj]
Mar 14 18:02:57 tower20 kernel: [ 4.391457] [<ffffffffa0001268>] logi_dj_probe+0x238/0x3dc [hid_logitech_dj]
Mar 14 18:02:57 tower20 kernel: [ 4.391526] [<ffffffff8169dc9b>] ? _raw_spin_unlock+0x2b/0x50
Mar 14 18:02:57 tower20 kernel: [ 4.391592] [<ffffffff81522b8d>] hid_device_probe+0xbd/0x140
Mar 14 18:02:57 tower20 kernel: [ 4.391660] [<ffffffff81412236>] driver_probe_device+0x96/0x2f0
Mar 14 18:02:57 tower20 kernel: [ 4.391727] [<ffffffff8141253b>] __driver_attach+0xab/0xb0
Mar 14 18:02:57 tower20 kernel: [ 4.392309] [<ffffffff81412490>] ? driver_probe_device+0x2f0/0x2f0
Mar 14 18:02:57 tower20 kernel: [ 4.392377] [<ffffffff81410435>] bus_for_each_dev+0x55/0x90
Mar 14 18:02:57 tower20 kernel: [ 4.392443] [<ffffffffa0006000>] ? 0xffffffffa0005fff
Mar 14 18:02:57 tower20 kernel: [ 4.392506] [<ffffffff81411d1e>] driver_attach+0x1e/0x20
Mar 14 18:02:57 tower20 kernel: [ 4.392569] [<ffffffff81411a28>] bus_add_driver+0x1b8/0x2b0
Mar 14 18:02:57 tower20 kernel: [ 4.392632] [<ffffffffa0006000>] ? 0xffffffffa0005fff
Mar 14 18:02:57 tower20 kernel: [ 4.392695] [<ffffffff81412d17>] driver_register+0x77/0x160
Mar 14 18:02:57 tower20 kernel: [ 4.392758] [<ffffffffa0006000>] ? 0xffffffffa0005fff
Mar 14 18:02:57 tower20 kernel: [ 4.392822] [<ffffffff8151ff56>] __hid_register_driver+0x66/0xa0
Mar 14 18:02:57 tower20 kernel: [ 4.392887] [<ffffffffa0006047>] logi_dj_init+0x47/0x1000 [hid_logitech_dj]
Mar 14 18:02:57 tower20 kernel: [ 4.392956] [<ffffffff8100212a>] do_one_initcall+0x12a/0x180
Mar 14 18:02:57 tower20 kernel: [ 4.393037] [<ffffffff810dad26>] sys_init_module+0x1146/0x2260
Mar 14 18:02:57 tower20 kernel: [ 4.393106] [<ffffffff816a68e9>] system_call_fastpath+0x16/0x1b
Mar 14 18:02:57 tower20 kernel: [ 4.393173] ---[ end trace 3798f598e1e0d0b4 ]---


Now the end result of that issue could very well be what is causing the issues with the wacom tablet, too.

(Note the error above is from the rc5 kernel. The error disappeared with the rc6 kernel and the "polling" IRQ messages started. With the rc7 kernel, I get both :( )

The rc5 and older kernels are usable, the rc6 and newer kernels are not due to very slow performance. This is hardware that works flawlessly with F16 and all older releases. (Well, I did have to manually build the wacom kernel module up until F15)

[hostace]

Do you tried quiet irqpoll ?

[DBelton]

why would I try the irqpoll option when that is what is getting set? It wouldn't do any good. (And I never run with the quiet option.)

Things worked fine until the rc6 release. The 3.2 kernels worked great. The 3.3 kernels gave me the "WARNING: at lib/dma-debug.c:930 check_for_stack+0xa9/0xf0()" warning above, but still worked properly up to rc5, and with rc6 started really acting bad. So, I do suspect it is due to the change they put in to switch to irq polling when it encounters

Also, my mouse will randomly disappear completely using the rc6 and rc7 kernels, and I can't get the mouse back without doing a reboot.

Edit:

Adam, my wacom issues are strictly in GDM and Gnome. The tablet works fine, and I don't get any errors if I use KDM or switch to KDE, LXDE, or XFCE. No kernel issues, just Gnome and GDM have issues with it.

If I have it plugged in when I start Gnome, it goes into a crash loop and finally it errors out due to respawning the gnome-settings-daemon to fast.

It really fits Einstein's definition of insanity, though...

"Insanity: doing the same thing over and over again and expecting different results."

[PaulAlesius]

For me the rc7 kernel fixed the mouse, or touchpad, before I didn't seem to be able to configure the sensitivity.

[DBelton]

I am starting to think the issue is in the logitech module and not with the kernel itself. I wonder if I could grab the logitech module from an older kernel that didn't give me problems, build it for the rc7 kernel, and see if it fixes the issues in the rc7 kernel.

I may try that this weekend if they don't fix it before then.

It may work unless the issue with the logitech module was actually caused by a change in the kernel itself.

[hostace]

why would I try the irqpoll option when that is what is getting set? It wouldn't do any good. (And I never run with the quiet option.)
If you're not a developer - try this option and do not hurt the surrounding brain. This option only disables the extra messages in the log, no more than that. This is helpful in your case.

[DBelton]

not helpful at all in my case. I WANT to see the extra messages because I am a developer. In this case, the extra message point to an ERROR that should be fixed, NOT hidden.

Hiding error messages doesn't make the error go away.

[hostace]

In the future release this option will be turned to on by default, so this messages will be only in testing stage. About the dma bug - this is because kernel needs to rebase of drivers. You must file the bug with abrt to redhat bugzilla. It will be fixed in the new kernel releases.

---------- Post added at 12:23 AM ---------- Previous post was at 12:22 AM ----------


Hiding error messages doesn't make the error go away
Messages about polling irq's is only informational. It's not the error.

---------- Post added at 12:38 AM ---------- Previous post was at 12:23 AM ----------

Probably tou have this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=802098

[DBelton]

the bug was filed with the rc5 kernel in bugzilla, on the 25th of February, 2 kernels have been released since then without it being fixed.

The quiet option will NOT be set by default on my system here, since I already have it turned off, and future updates will NOT change what I already have set.

Now if it needs a rebase of the drivers as you mentioned, then it is up to the kernel developers to do it, until it is done, then it is an error.

The irqpoll option is for systems with badly broken firmware, and makes it so that the kernel can run on them. This system doesn't have badly broken firmware and the 3.3 rc6 kernel is the first to even think it.

So, the irqpoll option is NOT necessary on this system, but they arbitrarily set it anyway. That is an ERROR.

Edit:

Also, with the type of message that the Disabling, Reenabling and Polling IRQ messages are, they would still be shown even with the quiet option set.

[hostace]

In the future release this option will be turned to on by default
This is my mistake, sorry.

So, the irqpoll option is NOT necessary on this system, but they arbitrarily set it anyway. That is an ERROR.
yes. This is the error in kernel. BUT: now in't option is nessessary for your system intil this error fixed.

[DBelton]

no, the irqpoll option is not necessary until the error is fixed.

Running an older kernel is necessary. The newer kernels are not an option since they are broken.

When they fix the issue, then a newer kernel may be an option.

[jakebpg]

why would I try the irqpoll option when that is what is getting set? It wouldn't do any good. (And I never run with the quiet option.)

Things worked fine until the rc6 release. The 3.2 kernels worked great. The 3.3 kernels gave me the "WARNING: at lib/dma-debug.c:930 check_for_stack+0xa9/0xf0()" warning above, but still worked properly up to rc5, and with rc6 started really acting bad. So, I do suspect it is due to the change they put in to switch to irq polling when it encounters

Also, my mouse will randomly disappear completely using the rc6 and rc7 kernels, and I can't get the mouse back without doing a reboot.

Edit:

Adam, my wacom issues are strictly in GDM and Gnome. The tablet works fine, and I don't get any errors if I use KDM or switch to KDE, LXDE, or XFCE. No kernel issues, just Gnome and GDM have issues with it.


If I have it plugged in when I start Gnome, it goes into a crash loop and finally it errors out due to respawning the gnome-settings-daemon to fast.

It really fits Einstein's definition of insanity, though...

"Insanity: doing the same thing over and over again and expecting different results."

Me thinks it's giving you a hint, Don't use Gnome!

KDE is much better anyhow, easier to work with, much more intuitive and easily configured to the users likings, not to mention customizing through hacks!

[AdamW]

dbelton: GNOME has added some kind of specific support for Wacom tablets recently. I skimmed the details because I don't *have* one, but I know they did something with them. So I rather suspect that's what's crashing for you. Have you filed the crash?

[Apostate]

kernel-3.3.0-0.rc7.git0.3.fc17.x86_64 giving me constant high cpu usage.

Gone back to kernel-3.3.0-0.rc6.git0.2.fc17.x86_64 which runs stable on my system.

[DBelton]

dbelton: GNOME has added some kind of specific support for Wacom tablets recently. I skimmed the details because I don't *have* one, but I know they did something with them. So I rather suspect that's what's crashing for you. Have you filed the crash?


Yes, I reported it on the 3rd of March, but like just about all other bugs I have filed against Gnome, no response.

https://bugzilla.redhat.com/show_bug.cgi?id=799667

And I agree with you. I believe the problem is caused by the recent changes to the wacom settings app in system settings. I had no issues at all with it in F16 and F15. (F14 and earlier I did have to build my own kernel module).

The tablet still works fine, even in Gnome. I just get the crash in gnome-settings-daemon and gnome-control-center when I plug it in or try to open the wacom settings. Plus it keeps gnome shell from starting if it is plugged in when I try to start up gnome. Just goes into a crash loop and then fails due to it respawning too quickly.

[diamond_ramsey]

kernel-3.3.0-0.rc7.git0.3.fc17.x86_64 giving me constant high cpu usage.

Gone back to kernel-3.3.0-0.rc6.git0.2.fc17.x86_64 which runs stable on my system.

Understood.

FYI, there is a kernel-3.3.0-1.fc17 now available at:

* http://koji.fedoraproject.org/koji/buildinfo?buildID=307989

By the way, what kind of system configuration in resources do you have for your fc17 system? :)

[DBelton]

well, the 3.3.0-1.fc17.x86_64 kernel in koji sure fixed my problems with the kernels that I was referring to above :)

I think my problems with the kernels was due to several issues, plus having the debugging code turned on as well. The logitech dma error disappeared when the debugging code was turned off, and I think it was caused by some of the debug buffers being full, but not sure.

The Disabling IRQ 23 , etc... has now been resolved, I believe it was when they restricted it to just the buggy ASM108x PCI Bridges that it fixed my issues. (This machine has an Intel ICH7 not a ASM108x)

[tkalfaoglu]

I reported the same issues of sluggishness of these kernels, in fact, I compiled my own..
The distributed version is so slow you have to wait for popups to close..

[AdamW]

dbelton: looks like we're getting somewhere with your wacom crash, now.

[DBelton]

I just looked at the bug report... Looks promising!

I would test it out now, but I don't have this box set up to build rpms with. I don't know how just compiling the gnome-settings-daemon and slapping it in would work. (also, as he stated, it would have to be patched in gnome-control-center as well)