I tried 3.8.0-0.rc5.git2.1.fc19 on three systems. One without X, one using an rv530 based video card and one using an rv280 based video card. The system using the rv280 based card has either extremely slow graphics or busted graphics. The other two seem to function normally. On the rv280 based system it takes longer than normal to sort of get the gdm screen up. It comes up without the background graphic and when I click on the user it doesn't seem to return a password prompt in a reasonable time. C-A-F2 still works and I can use a vt normally. In one case when I switched back I saw the background image. So it may be that video is just running really slow.
Things work OK with 3.8.0-0.rc5.git1.1.fc19.
When there is a nodebug version of that kernel out, I'll try it to see if it is the ATOMIC_SLEEP debugging or some other change in the kernel causing the problem.
On Wed, 2013-01-30 at 22:46 -0600, Bruno Wolff III wrote:
I tried 3.8.0-0.rc5.git2.1.fc19 on three systems. One without X, one using an rv530 based video card and one using an rv280 based video card. The system using the rv280 based card has either extremely slow graphics or busted graphics. The other two seem to function normally. On the rv280 based system it takes longer than normal to sort of get the gdm screen up. It comes up without the background graphic and when I click on the user it doesn't seem to return a password prompt in a reasonable time. C-A-F2 still works and I can use a vt normally. In one case when I switched back I saw the background image. So it may be that video is just running really slow.
Things work OK with 3.8.0-0.rc5.git1.1.fc19.
When there is a nodebug version of that kernel out, I'll try it to see if it is the ATOMIC_SLEEP debugging or some other change in the kernel causing the problem.
Sorry, there was a koji hiccup and the previous build failed (they take a very long time). I restarted the build a few hours ago, but it is not complete yet, and I need to get some sleep. I will push the nodebug builds in 8 hours or so.
Justin
On Thu, Jan 31, 2013 at 00:07:16 -0600, "Justin M. Forbes" jforbes@redhat.com wrote:
Sorry, there was a koji hiccup and the previous build failed (they take a very long time). I restarted the build a few hours ago, but it is not complete yet, and I need to get some sleep. I will push the nodebug builds in 8 hours or so.
There's no hurry. The older kernel is working fine and I expect the issue is most likely not the debuging option. It's just something I wanted to try before doing a real bug report.
On Wed, Jan 30, 2013 at 22:46:55 -0600, Bruno Wolff III bruno@wolff.to wrote:
I tried 3.8.0-0.rc5.git2.1.fc19 on three systems. One without X, one using an rv530 based video card and one using an rv280 based video card. The system using the rv280 based card has either extremely slow graphics or busted graphics. The other two seem to function normally. On the rv280 based system it takes longer than normal to sort of get the gdm screen up. It comes up without the background graphic and when I click on the user it doesn't seem to return a password prompt in a reasonable time. C-A-F2 still works and I can use a vt normally. In one case when I switched back I saw the background image. So it may be that video is just running really slow.
Things work OK with 3.8.0-0.rc5.git1.1.fc19.
When there is a nodebug version of that kernel out, I'll try it to see if it is the ATOMIC_SLEEP debugging or some other change in the kernel causing the problem.
I did some more testing on this. It doesn't appear to be debug related as things still don't work with 3.8.0-0.rc5.git2.2.fc19. Things also don't work with 3.8.0-0.rc5.git3.1.fc19. I'll test rc6 once the build finishes.
I noticed that the rtkit-daemon service fails to start on the same kernels that I have X problems with.
I started the graphical.target on the system that I normally don't, and found that gdm/shell fails when using the same problem kernels (Though gdm has some other issue with entering the password with 3.8.0-0.rc5.git1.1.fc19. But that problem may go back a long way as I don't normally use graphical logins.) and that rtkit-daemon also has issues there. This machine has an nv28 based video card.
The systems that have problems are both i686 (anthlon MP and an old Xeon) and the machine without problems is x86_64 (xeon). So it is looking more like an i686 issue, rather than a video driver issue.
I also checked that 3.8.0-0.rc5.git1.1.fc19 was built with gcc 4.8, so it probably isn't an issue with the change from gcc 4.7 to 4.8.
I am still seeing the problem with 3.8.0-0.rc6.git0.1.fc19.i686.
I am still having the issue with rtkit-daemon not starting on i686 with 3.8.0-0.rc6.git1.1.fc19.i686.PAE.
I did discover the GUI issue was gnome waiting on the rtkit-daemon. Once it times out (once during login and another time when my session starts up), things seem to work OK.
Here is some more information on the failure: -- Unit rtkit-daemon.service has begun starting up. Feb 04 17:32:47 bruno.wolff.to systemd[16899]: Failed at step NETWORK spawning / usr/libexec/rtkit-daemon: Invalid argument -- Subject: Process /usr/libexec/rtkit-daemon could not be executed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Documentation: http://www.freedesktop.org/wiki/Software/systemd/catalog/64125 7651c1b4ec9a8624d7a40a9e1e7
On Mon, Feb 04, 2013 at 05:34:04PM -0600, Bruno Wolff III wrote:
I am still having the issue with rtkit-daemon not starting on i686 with 3.8.0-0.rc6.git1.1.fc19.i686.PAE.
I did discover the GUI issue was gnome waiting on the rtkit-daemon. Once it times out (once during login and another time when my session starts up), things seem to work OK.
Here is some more information on the failure: -- Unit rtkit-daemon.service has begun starting up. Feb 04 17:32:47 bruno.wolff.to systemd[16899]: Failed at step NETWORK spawning / usr/libexec/rtkit-daemon: Invalid argument -- Subject: Process /usr/libexec/rtkit-daemon could not be executed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Documentation: http://www.freedesktop.org/wiki/Software/systemd/catalog/64125 7651c1b4ec9a8624d7a40a9e1e7 --
-- The process /usr/libexec/rtkit-daemon could not be executed and failed.
-- The error number returned while executing this process is 22. Feb 04 17:32:47 bruno.wolff.to systemd[1]: rtkit-daemon.service: main process ex ited, code=exited, status=225/NETWORK Feb 04 17:32:47 bruno.wolff.to systemd[1]: Failed to start RealtimeKit Schedulin g Policy Service. -- Subject: Unit rtkit-daemon.service has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Documentation: http://www.freedesktop.org/wiki/Software/systemd/catalog/be02c f6855d2428ba40df7e9d022f03d --
-- Unit rtkit-daemon.service has failed.
-- The result is failed.
All that says is rtkit-daemon got EINVAL for something. You'd need to see what arguments it's passed and maybe get an strace.
If this is happening in the initrafms, does a "working" kernel have a different version of systemd or rtkit in its initramfs? You might want to bring this up on the devel list as well.
josh
On Mon, Feb 04, 2013 at 18:48:40 -0500, Josh Boyer jwboyer@redhat.com wrote:
All that says is rtkit-daemon got EINVAL for something. You'd need to see what arguments it's passed and maybe get an strace.
If this is happening in the initrafms, does a "working" kernel have a different version of systemd or rtkit in its initramfs? You might want to bring this up on the devel list as well.
I think it is happening after the root pivot, but I had updated the 3.8.0-0.rc5.git1.1.fc19.i686 initramfs to check for an initramfs issue. If I didn't screw that up, then the initramfs isn't the problem, since 3.8.0-0.rc5.git1.1.fc19.i686 still worked normally after doing that.
On Mon, Feb 04, 2013 at 18:48:40 -0500, Josh Boyer jwboyer@redhat.com wrote:
If this is happening in the initrafms, does a "working" kernel have a different version of systemd or rtkit in its initramfs? You might want to bring this up on the devel list as well.
It looks like someone else is seeing this and filed bug 907576 against rtkit. That seems like a reasonable place to discuss what is happening for now. We can go back to the kernel once we have a better idea where to look.
On Mon, Feb 04, 2013 at 18:48:40 -0500, Josh Boyer jwboyer@redhat.com wrote:
All that says is rtkit-daemon got EINVAL for something. You'd need to see what arguments it's passed and maybe get an strace.
Turning off the private network systemd feature for rtkit-daemon seems to work around the problem. Maybe there is an issue with namespaces on i686 systems?
On Tue, Feb 05, 2013 at 10:33:13PM -0600, Bruno Wolff III wrote:
On Mon, Feb 04, 2013 at 18:48:40 -0500, Josh Boyer jwboyer@redhat.com wrote:
All that says is rtkit-daemon got EINVAL for something. You'd need to see what arguments it's passed and maybe get an strace.
Turning off the private network systemd feature for rtkit-daemon seems to work around the problem. Maybe there is an issue with namespaces on i686 systems?
Namespaces are disabled on 32-bit. I only enabled them for the CRIU feature on x86_64.
josh
On Wed, Feb 06, 2013 at 08:39:00 -0500, Josh Boyer jwboyer@redhat.com wrote:
On Tue, Feb 05, 2013 at 10:33:13PM -0600, Bruno Wolff III wrote:
On Mon, Feb 04, 2013 at 18:48:40 -0500, Josh Boyer jwboyer@redhat.com wrote:
All that says is rtkit-daemon got EINVAL for something. You'd need to see what arguments it's passed and maybe get an strace.
Turning off the private network systemd feature for rtkit-daemon seems to work around the problem. Maybe there is an issue with namespaces on i686 systems?
Namespaces are disabled on 32-bit. I only enabled them for the CRIU feature on x86_64.
It's odd that systemd seemed to handle that with earlier kernels, but doesn't now. I'll recommend that the rtkit-daemon bug get refiled against systed, since that's where handling privatenetwork when it isn't available should be done.
At the very least a more informative error message would be nice.
Thanks.
On Wed, Feb 06, 2013 at 08:39:00 -0500, Josh Boyer jwboyer@redhat.com wrote:
On Tue, Feb 05, 2013 at 10:33:13PM -0600, Bruno Wolff III wrote:
On Mon, Feb 04, 2013 at 18:48:40 -0500, Josh Boyer jwboyer@redhat.com wrote:
All that says is rtkit-daemon got EINVAL for something. You'd need to see what arguments it's passed and maybe get an strace.
Turning off the private network systemd feature for rtkit-daemon seems to work around the problem. Maybe there is an issue with namespaces on i686 systems?
Namespaces are disabled on 32-bit. I only enabled them for the CRIU feature on x86_64.
I tested 3.8.0-0.rc6.git3.3.fc19.i686.PAE which has them enabled and it solves rtkit issue. This kernels feels a bit slower than the previous ones. But it's hard to be sure as gnome is messed up for me with today's updates.
kernel@lists.fedoraproject.org
-
Bruno Wolff III -
Josh Boyer -
Justin Forbes