New Kernel in Fedora 12

[RahulSundaram]

A plea for more testing at

https://www.redhat.com/archives/fedora-test-list/2009-October/msg00650.html

[SlowJet]

96 worked for /me but there my not be enough bits in rawhide for everything to show improvement.

Here is the current 97 and some koji bits. Just FYI

I works very good for Pent IV ht PAE 686.
Works good with newest xorg-x11-server 1.7.1
works good with newest xorg-x11-drv-intel
Speed seems a little better, video is a bit more solid and clear.

Pent III 800 mx nouveau a bit more clear, still nomodset used, icons still a bit over sized.

There is 1 or 2 audit avc's on xauth-iugigui type files when su - occurs, but still works.

dmesg - early on

dmesg render error detected, EIR: 0x00000010
[drm:i915_handle_error] *ERROR* EIR stuck: 0x00000010, masking
render error detected, EIR: 0x00000010
[drm] DAC-5: set mode 1280x1024 14
Console: switching to colour frame buffer device 160x64
fb0: inteldrmfb frame buffer device
registered panic notifier
[drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
dracut: Starting plymouth daemon

later on

[drm:drm_mode_rmfb] *ERROR* tried to remove a fb that we didn't own

Audit message (a read and a write)

Summary:

SELinux is preventing /usr/bin/xauth "write" access on .xauthAtVZkk.

Detailed Description:

SELinux denied access requested by xauth. It is not expected that this access is
required by xauth and this access may signal an intrusion attempt. It is also
possible that the specific version or configuration of the application is
causing it to require additional access.

Allowing Access:

You can generate a local policy module to allow this access - see FAQ
(http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Please file a bug
report.

Additional Information:

Source Context unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023
Target Context unconfined_u:object_r:admin_home_t:s0
Target Objects .xauthAtVZkk [ file ]
Source xauth
Source Path /usr/bin/xauth
Port <Unknown>
Host Ruthie-07.WinProxy
Source RPM Packages xorg-x11-xauth-1.0.2-7.fc12
Target RPM Packages
Policy RPM selinux-policy-3.6.32-32.fc12
Selinux Enabled True
Policy Type targeted
MLS Enabled True
Enforcing Mode Enforcing
Plugin Name catchall
Host Name Ruthie-07.WinProxy
Platform Linux Ruthie-07.WinProxy 2.6.31.5-96.fc12.i686.PAE
#1 SMP Fri Oct 23 19:39:36 EDT 2009 i686 i686
Alert Count 1
First Seen Mon 26 Oct 2009 02:31:50 AM PDT
Last Seen Mon 26 Oct 2009 02:31:50 AM PDT
Local ID a86e8e09-c988-4fdf-b09c-964546b04117
Line Numbers

Raw Audit Messages

node=Ruthie-07.WinProxy type=AVC msg=audit(1256549510.253:27736): avc: denied { write } for pid=3086 comm="xauth" name=".xauthAtVZkk" dev=dm-2 ino=4921 scontext=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file

node=Ruthie-07.WinProxy type=SYSCALL msg=audit(1256549510.253:27736): arch=40000003 syscall=33 success=no exit=-13 a0=bf8def27 a1=2 a2=bf8def27 a3=804e88c items=0 ppid=3078 pid=3086 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="xauth" exe="/usr/bin/xauth" subj=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 key=(null)

SJ
# uname -a
Linux Ruthie-07.WinProxy 2.6.31.5-97.fc12.i686.PAE #1 SMP Mon Oct 26 00:49:45 EDT 2009 i686 i686 i386 GNU/Linux
xorg-x11-drv-intel-2.9.1-1.fc12.i686
xorg-x11-server-Xorg-1.7.1-1.fc12.i686

[Dan]

Here's where the rubber meets the road, folks. The man is posting pleas for help testing things here.

You can't say he (or therefore the devs) never asked.








From here on in, I'll probably take a mighty dim view of the chronic complainers who didn't pony up.


Dan

[RahulSundaram]

Hi,

As always, please report bugs to http://bugzilla.redhat.com directly.

[Boricua]

Hi. F12 64 bit beta seems more stable than previous incarnations. I was forced to uninstall newest kernel 96 because it failed to show in grub. A new installation corrected the issue. It loads faster than kernel 56 and desktop seems to be performing more smoothly than before, albeit lag is still notable. Sounds are working better than ever. One of my main headaches from past - mail-notification - seems to be more stable than ever.
My main concern is that I lost synchronization ability between Jpilot and my Tungsten T. Under F10 and F11 64 bit it worked out of the box using ":usb" as connection port. Now it fails to communicate.
Otherwise and as already said, F12 64 bit looks remarkably stable.
I will post anything else I find down the road.
I forgot to mention this is a fresh install.

[CiaW]

My yum.log shows that it installed the new kernel:

Oct 24 15:24:02 Updated: kernel-firmware-2.6.31.5-96.fc12.noarch
Oct 24 15:25:19 Installed: kernel-2.6.31.5-96.fc12.x86_64

But it doesn't show up on my grub, and while it was installing I saw an error message go by, but I didn't note it and now I'm not sure if or where that message might be? I just tried yum upgrade kernel and it said no packages to upgrade.

Is there a way to re-install it and see what it says? Or is there a log where it might show up? I just checked yumex.conf and it shows yumdebuglevel=2 (I don't know what that means); but nothing about a location of a log?

Could or should I try to manually add the entries for the vmlinuz and initrd info in a revised grub.conf with the same root uuid as the kernel 2.6.31.1-56.fc12.x86_64, with the new kernel info and see if it boots?

[typerlc]

Here's where the rubber meets the road, folks. The man is posting pleas for help testing things here.

You can't say he (or therefore the devs) never asked.


From here on in, I'll probably take a mighty dim view of the chronic complainers who didn't pony up.


Dan

I was tempted to write something equally inflammatory, but will settle on ...

Fair enough to ask for testers, but is there any point when you don't react on the bug reports received.

I can confirm that https://bugzilla.redhat.com/show_bug.cgi?id=523905 *still* occurs with the latest updates pushed to the repos (including 2.6.31.5-96.fc12.i686.PAE).

[Demz]

they wont fix them cause Fedora isnt there " baby Server " where as Redhat Server is so they fix it in there only while you Guinee pigs help test other technology they will fix in Fedora

[JohnnyLinux]

Here's where the rubber meets the road, folks. The man is posting pleas for help testing things here.

You can't say he (or therefore the devs) never asked.

From here on in, I'll probably take a mighty dim view of the chronic complainers who didn't pony up.


Dan

You are completely right.
Sorry, I'm not testing it myself. Fedora is 'edgy' enough, can't imagine how much more 'dangerous' rawhide is.

[SlowJet]

No timmy, computers are not dangerous?
On the other, that dog of your may end up stealing your bike. :)

SJ

[Demz]

wrong SJ, computers are dangerous man :rolleyes:

[CiaW]

Update to my earlier message, apparently it's a bug in yumex:
https://bugzilla.redhat.com/show_bug.cgi?id=527528

An extra brain-cell kicked in, and I had the bright idea to un-install then re-install the kernel in yumex, and it came up with the error messages noted in the bugzilla, I decided to search there before posting it here. I just installed the new kernel in a terminal, so far so good -- it booted! I'll play with a few things on it tomorrow, since it's 10pm here and I'm going to call it a night.

One thing that did come up when I installed it was this:
Running Transaction
Installing : kernel-firmware-2.6.31.5-96.fc12.noarch 1/2
Installing : kernel-2.6.31.5-96.fc12.x86_64 2/2
W: Possible missing firmware ql8100_fw.bin for module qla2xxx.ko
W: Possible missing firmware ql2400_fw.bin for module qla2xxx.ko
W: Possible missing firmware ql2322_fw.bin for module qla2xxx.ko
W: Possible missing firmware ql2300_fw.bin for module qla2xxx.ko
W: Possible missing firmware ql2200_fw.bin for module qla2xxx.ko
W: Possible missing firmware ql2100_fw.bin for module qla2xxx.ko
W: Possible missing firmware aic94xx-seq.fw for module aic94xx.ko

Installed:
kernel.x86_64 0:2.6.31.5-96.fc12
In case it matters. If it's an item for bugzilla, let me know.

[GoinEasy9]

My 32 bit PAE kernel installed just fine, except that I also had possible missing firmware modules. But I was missing only 2. Don't remember which ones, sorry. Went on to go through as many apps as I could to test what I could and had no problems. Everything that was set up previously is still working as it was before.
If there is a specific list of things to try, I'd be more than happy to take my testing further.
I'm waiting for the akmods for nvidia drivers, I don't really want to clean up what the .run files install from the nvidia site. Besides, seeing what nouveau can do before installing the proprietary drivers is interesting also. Nouveau, btw, seems to be more stable than it was before, i.e., weird graphics on startup are gone, and transitions don't flicker and are smooth.

[AdamW]

please, for my sanity, when reporting problems that may be related to package installation please make it clear if you're using yumex, so I don't start panicking. :)

typerlc: you can't claim we didn't *respond* to your report. I triaged it, and Ben has looked at it and is working on fixing it. The fact we didn't fix it the next day proves only that we are human. My favourite way to explain the more general issue here is that, while it's true we may manage to fix only, say, 50% of reported bugs within a few months, that's a lot better than the percentage of *un*reported bugs we fix. :) It's not practical to promise perfection, so you'll note I never do. But we really do need the reports to know what's broken and, believe it or not, we do consider them important. You can take a look at the thrilling log of the seven hour long release blocker bug review from Friday if you want reassurance!

demz, if Red Hat wasn't interested in improving the quality of Fedora, they wouldn't be paying me to be a member of Red Hat's Fedora QA team, would they? In fact, Red Hat wouldn't *have* a Fedora QA team. Never mind all those people who work on Fedora who aren't Red Hat employees. Red Hat does not spend its time encouraging those people not to fix bugs in Fedora as part of its evil plot to make sure only Red Hat is worth using...

[leigh123linux]

The latest kernels seems quicker, I don't bother reporting any kernel bugs as they always tell me to remove the Nvidia driver first :( ( They can stuff it :) ).

[AdamW]

you'd only have to temporarily disable it. they can't tell from the logs whether it's still installed. =)

[AdamW]

and yes, it should be somewhat quicker, as the debugging stuff has been turned off between 56 and 96.

[leigh123linux]

you'd only have to temporarily disable it. they can't tell from the logs whether it's still installed. =)

Thanks for the info, where have they hidden the system log viewer , it seems to be missing?

[pankajp]

Hmm i've got a few problems with the new kernel on F12 on intel 965 laptop
1 > KMS did not start (saw the text progress bar on boot)
2 > Booting was definitely faster
3 > About graphics, just forget. I couldn't do anything on the new kernel. As i had gnome-shell enabled, nothing could be seen on the screen. Attaching a screenshot of that. (Will try again now after disabling gnome-shell)
4 > Switching to the text console (Ctrl-Alt-F2) was only possible once. Trying it again did not bring anything on the console.

EDIT: sorry for the noise. The problem was probably because i updated through yumex. I removed the kernel and reinstalled it again and the problem is gone now. (KMS is also working)

[diamond_ramsey]

and yes, it should be somewhat quicker, as the debugging stuff has been turned off between 56 and 96.

:) AdamW, the 96 kernel is working very smoothly for me. :)

Did a yum update and all's well. I have two systems running for about 13 hours...see attached screen captures of the top output for memory usage at about 977556KB and 1402928KB usage respectively. :)

No errors to report. :cool:

Hope this helps. ;)

[AdamW]

Thanks for the info, where have they hidden the system log viewer , it seems to be missing?

Er, not sure what system log viewer you mean. I use the one called 'less' :)

As a general rule, you can use repoquery to search for a tool you know the executable filename for.

[leigh123linux]

Er, not sure what system log viewer you mean. I use the one called 'less' :)

As a general rule, you can use repoquery to search for a tool you know the executable filename for.

That's if you can remember what it is called :(

It was gnome-system-log, it's seems to be missing ( or not shown in the menu ) in F12.

[cenomanien]

That's if you can remember what it is called :(

It was gnome-system-log, it's seems to be missing ( or not shown in the menu ) in F12.

It's a separate package now, I was looking for it some time ago.
http://koji.fedoraproject.org/koji/rpminfo?rpmID=1630530

[AdamW]

I was guessing that it'd be one of those, thanks for the info ceno!

[CiaW]

It's a separate package now, I was looking for it some time ago.
http://koji.fedoraproject.org/koji/rpminfo?rpmID=1630530

I was looking for it too. Thanks for the 411. I'll install it.

And it looks like there's a few updates to install too.

[Boricua]

With F12 64 bit I am getting some non requested logouts from the desktop to the login screen. It happened to me both with kernels 56 and 96, as well as with the most recent updates to gnome and xorg. It appears to be at random :confused:.

[AdamW]

that's probably X crashing, not a log out. Can you see if there's some /var/log/Xorg.*.log file with any error messages at the end, after it happens?

[Boricua]

that's probably X crashing, not a log out. Can you see if there's some /var/log/Xorg.*.log file with any error messages at the end, after it happens?

I checked Xorg.0.log and Xorg.9.log but found nothing suspicious. I will check again immediately after next crash. FWIW, I have an nvidia gforce 7500 running with nouveau. No special effects but metacity composite is active.

[AdamW]

you may need to boot to runlevel 3 and use 'startx' to get into X. That way, if it is X crashing, it won't automatically respawn and go back to gdm, it'll crash back to the console and you'll hopefully have console messages and an X log to explain what went wrong.

[typerlc]

I checked Xorg.0.log and Xorg.9.log but found nothing suspicious. I will check again immediately after next crash. FWIW, I have an nvidia gforce 7500 running with nouveau. No special effects but metacity composite is active.

How much effort are you willing to put in to this? If you are technically competent, and willing, there is a better way. It requires running gdb on your X server after it starts to trap the crash and extract debug information.

I can provide more info if you want to attempt this. But it's not trivial, and it's easier (though not essential) if you have another PC that you can ssh from to login to the FC12 box.

[Boricua]

you may need to boot to runlevel 3 and use 'startx' to get into X. That way, if it is X crashing, it won't automatically respawn and go back to gdm, it'll crash back to the console and you'll hopefully have console messages and an X log to explain what went wrong.

I will try that tomorrow and report back.

[Boricua]

How much effort are you willing to put in to this? If you are technically competent, and willing, there is a better way. It requires running gdb on your X server after it starts to trap the crash and extract debug information.

I can provide more info if you want to attempt this. But it's not trivial, and it's easier (though not essential) if you have another PC that you can ssh from to login to the FC12 box.

Hmmm, sorry I am not at that level yet. I'm just an attorney who happens to love Fedora :rolleyes:. I will try however AdamW's suggestion and see what I can find. The last time a crash took place was this morning. Around 12 hours have passed without further incidents.

[asheguy79]

Faster booting, no problems after rebooting 5 times in a row and doing complete system shut down twice. All installs have gone smoothly as well as updates and removels.

[Boricua]

It just happened again, even after today's bunch of updates. I restarted the machine in level 3, logged in as root and started the X server. Then checked the xorg.9.log file and found the following lines at the very end, although I'm not sure if it's helpful :confused::
I) UnloadModule: "evdev"
(II) Sleep Button: Close
(II) UnloadModule: "evdev"
(II) Power Button: Close
(II) UnloadModule: "evdev"
(II) NOUVEAU(0): NVLeaveVT is called.
(II) NOUVEAU(0): Closed GPU channel 1

[JohnnyLinux]

It just happened again, even after today's bunch of updates. I restarted the machine in level 3, logged in as root and started the X server. Then checked the xorg.9.log file and found the following lines at the very end, although I'm not sure if it's helpful :confused::
I) UnloadModule: "evdev"
(II) Sleep Button: Close
(II) UnloadModule: "evdev"
(II) Power Button: Close
(II) UnloadModule: "evdev"
(II) NOUVEAU(0): NVLeaveVT is called.
(II) NOUVEAU(0): Closed GPU channel 1

I'm waiting to see how the experts diagnose this... especially because of this other thread :D

http://forums.fedoraforum.org/showthread.php?t=232850

I'm gonna go get me some cookies and vodka, and just enjoy the show. OR The problem has nothing to do with what is on my mind, nevertheless I'm still curious.

[AdamW]

Um, we don't want you to restart X after the crash happens. The point of booting to runlevel 3 is to *avoid* X starting up again, so that the X log is from the crash. Every time X starts, it overwrites the log file, losing the potentially useful information within :)

What I want you to do is boot to runlevel 3, startx, then use it normally and wait for the problem to happen. Hopefully when the problem happens it will dump you back at the console where you ran startx and leave you there. Ideally there'll be some juicy messages on the console indicating what went wrong, and possibly the same / more messages in /var/log/Xorg.*.log . Is that clearer now? Sorry to be unclear :)

[Boricua]

Um, we don't want you to restart X after the crash happens. The point of booting to runlevel 3 is to *avoid* X starting up again, so that the X log is from the crash. Every time X starts, it overwrites the log file, losing the potentially useful information within :)

What I want you to do is boot to runlevel 3, startx, then use it normally and wait for the problem to happen. Hopefully when the problem happens it will dump you back at the console where you ran startx and leave you there. Ideally there'll be some juicy messages on the console indicating what went wrong, and possibly the same / more messages in /var/log/Xorg.*.log . Is that clearer now? Sorry to be unclear :)

Ahh, ok, my bad. I am actually running the machine starting in level 3 and then executed startx. Message clear :). I hope to bring something juicier next time :cool:.

[DCOH]

Finally installed F12 last night so far not the best of the installs first tried to upgrade F11 using i386 DVD install went fine reboot to black screen. Next reinstalled using LiveCD i686 all ok updated with package manager installed the 96 kernel.
This morning went to get on computer when came off screensaver crashed and rebooted to a non ending return to login screen. Can login only using 56 kernel.
Logins with the nouveau driveris crazy first screen is 1280x1024 right, then jumps to 1024x768 left when you login before desktop the background is in four sections to the right.
This is my 8th Fedora and so far the most trouble. system sounds are screeches, must have put a ghost in.

Computer:
PCchips M848a motherboard
Nvidia GeForce 6200 video
Ram 1.5 gigs.
Everything worked fine in F11

Problem solved backgrounds I was using overloaded video drivers.

[troyatlarge]

Today I am loading multiple operating systems and having a large data partition which can be loaded from all systems. I would very much like to help here by loading this new Fedora. Is it ok to do so - I mean if something goes south I won't need to worry about losing important data in my data partition will I???

[CiaW]

Hi Troy,

when I installed using the live cd (x86_64) it defaulted to wanting to overwrite the current linux OS (CentOS) and use the whole drive; but it did have an option for custom layout which I selected. It had the 'default' LVM using the whole drive which I deleted and then selected 'restore' which made it look at and show the current partitioning setup. I selected /dev/sda6 for /boot and sda7 for / (not even giving it the format option) and it installed just fine. My shared partition is sda5 -- it was not overwritten.

After you delete the LVM it wants to create, after selecting custom layout, select 'restore' so you don't have to muck around with defining the partitions you already have. It should work...

[troyatlarge]

Thanks - I'll give it a try (I tried earlier to load Fedora 12 Alpha, early on, and couldn't get it to load at all - probably better by now).

[Boricua]

Um, we don't want you to restart X after the crash happens. The point of booting to runlevel 3 is to *avoid* X starting up again, so that the X log is from the crash. Every time X starts, it overwrites the log file, losing the potentially useful information within :)

What I want you to do is boot to runlevel 3, startx, then use it normally and wait for the problem to happen. Hopefully when the problem happens it will dump you back at the console where you ran startx and leave you there. Ideally there'll be some juicy messages on the console indicating what went wrong, and possibly the same / more messages in /var/log/Xorg.*.log . Is that clearer now? Sorry to be unclear :)

Hi AdamW. After several days starting the machine in runlevel 3, I can report that I was not bumped back to the console. What I got (on two occasions) was a Black Screen of Death of sorts. The computer freezes with a black screen and no response, forcing me to execute a manual hard reboot. Didn't found anything significant in the xorg.log. Hope this helps for something.

[AdamW]

francisco: can you be more specific about "Didn't found anything significant in the xorg.log"? After hitting the BSOD, did you reboot back to runlevel 3 and check /var/log/Xorg.0.log *before* starting X again?

[Boricua]

francisco: can you be more specific about "Didn't found anything significant in the xorg.log"? After hitting the BSOD, did you reboot back to runlevel 3 and check /var/log/Xorg.0.log *before* starting X again?

Nope, I let it go directly to runlevel 5 and found the same normal stuff as before. But I will start again with runlevel 3 from now on and check the log after the next BSOD :cool:.

[AdamW]

every time X starts up, the log gets overwritten; so yep, if you boot back to runlevel 5, the log will get overwritten by a boring log from the new - so far working - startup :). So indeed you have to boot back to runlevel 3 after you hit the problem, so you can take a copy of the Xorg.0.log from the failure, before it gets overwritten.

[brunson]

Did the feature which makes a backup of the previous Xorg log get disabled or removed in F12?
ebrunsonlx(/var/log)$ ls -lrt Xorg.0*
-rw-r--r-- 1 root root 16269 2009-10-29 10:57 Xorg.0.log.old
-rw-r--r-- 1 root root 16370 2009-10-30 10:16 Xorg.0.log

[AdamW]

that's always seemed rather erratic to me, I'm not sure in what circumstances it gets created and what it doesn't. I try to avoid relying on it.

[brunson]

Understandable.

[Boricua]

Just to let know that my system seems stable. No further crashes to report.

[Boricua]

As I pointed out in my first post, the other problem I have with F12 is lack of sync between my Tungsten T and my computer. I just found out the permissions issue seems to be back, because I was able to sync Jpilot as root. As I recall, the last incarnation of Fedora with this permissions issue was F9, in which you have to create new udev rules. F10 and F11 sync out of the box for me. So, I don't know if this is worth filing a bug report (I already checked and found nothing to the point), or just wait for the next kernel to see if this gets fixed (I am already running new kernel 5-115 and the issue remains). Any hints appreciated :).

[CiaW]

The 2.6.31.5-115.fc12.x86_64 kernel from yesterday's update caused some problems for me, I was glad to see a new kernel today. Of course, I didn't realize how problematic until I started downloading the new kernel. I was downloading it in a (ctrl-alt F4) terminal window, and when I (alt-F1) back to my desktop, my desktop was locked up hard. I could see the desktop, but I couldn't do anything. I couldn't even get back to the terminal window, but I could tell by my modem indicator lights that it was still downloading, so I let it finish and waited for what sounded like the hard drive finished installing, etc. to do a hard reboot.

Last night, I had a similar situation, it went to screensaver while I was out of the room for a few minutes, but apparently the screensaver also got locked up -- it was mostly a desktop screen with a tiny fedora bubble and some black squares, and I had to do a hard reboot then too. Hopefully the newest and shiniest kernel 2.6.31.5-117.fc12.x86_64 will be happy. If not, I'll be back to report and/or file a bugzilla.

I don't know if it was a Xorg issue, or plymouth, or ?? In my system logs I have a Xorg.9.log and an Xorg.0.log -- the 9 one is the previous boot. I'll save it just in case. I'm using the nouveau drivers rather than Nvidia drivers.

[Demz]

upload that log to the forum Xorg.9.log log ..but how many kernels you got installed?

[typerlc]

when I (alt-F1) back to my desktop, my desktop was locked up hard. I could see the desktop, but I couldn't do anything. I couldn't even get back to the terminal window.

this is very similar to my symptoms which were fixed with the latest X server v1.7.1. If you aren't running this version, then I'd suggest you update manually or wait for it to be released officially.

[AdamW]

I'm gonna close this thread because the kernel in question is prehistoric now ;)

I'll open a new one asking people to test the latest new hotness shortly.