Kernel rc7.git0.3

[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]

Originally Posted by 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."

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]

Originally Posted by 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?

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]

Originally Posted by 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.

Understood.

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

* http://koji.fedoraproject.org/koji/b...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..