3.16.0-0.rc1.git4.1.fc21.i686 #1 Not tainted
LightDM, SDDM, GDM are failing. Interestingly, there are no errors in Xorg.0.log, (II) NOUVEAU(0): Output DVI-I-1 connected startx works for user and startxfce4 for root. :)
journal: systemd[1]: Starting Light Display Manager... systemd[1]: Started Light Display Manager. systemd[1]: lightdm.service: main process exited, code=killed, status=11/SEGV systemd[1]: Unit lightdm.service entered failed state. systemd[1]: lightdm.service holdoff time over, scheduling restart. systemd[1]: Stopping Light Display Manager... systemd[1]: Starting Light Display Manager... systemd[1]: Started Light Display Manager. systemd[1]: lightdm.service: main process exited, code=killed, status=11/SEGV systemd[1]: Unit lightdm.service entered failed state. systemd[1]: lightdm.service holdoff time over, scheduling restart. systemd[1]: Stopping Light Display Manager... systemd[1]: Starting Light Display Manager... systemd[1]: Started Light Display Manager. systemd[1]: lightdm.service: main process exited, code=killed, status=11/SEGV systemd[1]: Unit lightdm.service entered failed state. systemd[1]: lightdm.service holdoff time over, scheduling restart. systemd[1]: Stopping Light Display Manager... systemd[1]: Starting Light Display Manager... systemd[1]: Started Light Display Manager. systemd[1]: lightdm.service: main process exited, code=killed, status=4/ILL systemd[1]: Unit lightdm.service entered failed state. systemd[1]: lightdm.service holdoff time over, scheduling restart. systemd[1]: Stopping Light Display Manager... systemd[1]: Starting Light Display Manager... systemd[1]: Started Light Display Manager. systemd[1]: lightdm.service: main process exited, code=killed, status=11/SEGV systemd[1]: Unit lightdm.service entered failed state. systemd[1]: lightdm.service holdoff time over, scheduling restart. systemd[1]: Stopping Light Display Manager... systemd[1]: Starting Light Display Manager... systemd[1]: lightdm.service start request repeated too quickly, refusing to start. systemd[1]: Failed to start Light Display Manager. systemd[1]: Unit lightdm.service entered failed state.
lightdm[1863] bad frame in sigreturn frame:bf8231bc ip:b7506000 sp:bf8232ac orax:ffffffff in libglib-2.0.so.0.4100.0[b7506000+1000] lightdm[1898] bad frame in sigreturn frame:bfb8e4fc ip:7c sp:0 orax:ffffffff in lightdm[8048000+38000] lightdm[1910] bad frame in sigreturn frame:bfc49f3c ip:7c sp:0 orax:ffffffff in lightdm[8048000+38000] lightdm[1934] bad frame in sigreturn frame:bf96b0fc ip:7c sp:0 orax:ffffffff in lightdm[8048000+38000]
# rpm -qf /usr/lib/libglib-2.0.so.0.4100.0 glib2-2.41.0-2.fc21.i686
systemctl[1135]: segfault at b70000cc ip b77421cd sp bfd7a060 error 4 in systemctl[b76f4000+9c000] systemctl[1143]: segfault at b80000cc ip b779e1cd sp bf97d7f0 error 4 in systemctl[b7750000+9c000] systemctl[1152]: segfault at b80000cc ip b77431cd sp bf9be350 error 4 in systemctl[b76f5000+9c000] systemctl[1160]: segfault at b90000cc ip b778d1cd sp bfd62c10 error 4 in systemctl[b773f000+9c000] systemctl[1169]: segfault at b90000cc ip b76f81cd sp bf83fcf0 error 4 in systemctl[b76aa000+9c000] systemctl[1177]: segfault at b70000cc ip b77281cd sp bfbafcf0 error 4 in systemctl[b76da000+9c000] systemctl[1185]: segfault at b90000cc ip b77361cd sp bff6a680 error 4 in systemctl[b76e8000+9c000] systemctl[1193]: segfault at b70000cc ip b77001cd sp bff62eb0 error 4 in systemctl[b76b2000+9c000] systemctl[1201]: segfault at b80000cc ip b76e31cd sp bf943bf0 error 4 in systemctl[b7695000+9c000] systemctl[1209]: segfault at b90000cc ip b76bb1cd sp bfd088c0 error 4 in systemctl[b766d000+9c000] systemctl[1217]: segfault at b80000cc ip b77a91cd sp bfe9c470 error 4 in systemctl[b775b000+9c000] systemctl[1225]: segfault at b90000cc ip b773d1cd sp bfc7dd90 error 4 in systemctl[b76ef000+9c000]
Selinux is not an issue. Downgrade of glib2 doesn't help. Building and installing newer versions of systemd and lightdm doesn't help also. All this doesn't happen with 3.15.0-1.fc21.i686! Something is strange with that turtle. :)
poma
On 22.06.2014 04:34, poma wrote:
3.16.0-0.rc1.git4.1.fc21.i686 #1 Not tainted
LightDM, SDDM, GDM are failing. Interestingly, there are no errors in Xorg.0.log, (II) NOUVEAU(0): Output DVI-I-1 connected startx works for user and startxfce4 for root. :)
journal: systemd[1]: Starting Light Display Manager... systemd[1]: Started Light Display Manager. systemd[1]: lightdm.service: main process exited, code=killed, status=11/SEGV systemd[1]: Unit lightdm.service entered failed state. systemd[1]: lightdm.service holdoff time over, scheduling restart. systemd[1]: Stopping Light Display Manager... systemd[1]: Starting Light Display Manager... systemd[1]: Started Light Display Manager. systemd[1]: lightdm.service: main process exited, code=killed, status=11/SEGV systemd[1]: Unit lightdm.service entered failed state. systemd[1]: lightdm.service holdoff time over, scheduling restart. systemd[1]: Stopping Light Display Manager... systemd[1]: Starting Light Display Manager... systemd[1]: Started Light Display Manager. systemd[1]: lightdm.service: main process exited, code=killed, status=11/SEGV systemd[1]: Unit lightdm.service entered failed state. systemd[1]: lightdm.service holdoff time over, scheduling restart. systemd[1]: Stopping Light Display Manager... systemd[1]: Starting Light Display Manager... systemd[1]: Started Light Display Manager. systemd[1]: lightdm.service: main process exited, code=killed, status=4/ILL systemd[1]: Unit lightdm.service entered failed state. systemd[1]: lightdm.service holdoff time over, scheduling restart. systemd[1]: Stopping Light Display Manager... systemd[1]: Starting Light Display Manager... systemd[1]: Started Light Display Manager. systemd[1]: lightdm.service: main process exited, code=killed, status=11/SEGV systemd[1]: Unit lightdm.service entered failed state. systemd[1]: lightdm.service holdoff time over, scheduling restart. systemd[1]: Stopping Light Display Manager... systemd[1]: Starting Light Display Manager... systemd[1]: lightdm.service start request repeated too quickly, refusing to start. systemd[1]: Failed to start Light Display Manager. systemd[1]: Unit lightdm.service entered failed state.
lightdm[1863] bad frame in sigreturn frame:bf8231bc ip:b7506000 sp:bf8232ac orax:ffffffff in libglib-2.0.so.0.4100.0[b7506000+1000] lightdm[1898] bad frame in sigreturn frame:bfb8e4fc ip:7c sp:0 orax:ffffffff in lightdm[8048000+38000] lightdm[1910] bad frame in sigreturn frame:bfc49f3c ip:7c sp:0 orax:ffffffff in lightdm[8048000+38000] lightdm[1934] bad frame in sigreturn frame:bf96b0fc ip:7c sp:0 orax:ffffffff in lightdm[8048000+38000]
# rpm -qf /usr/lib/libglib-2.0.so.0.4100.0 glib2-2.41.0-2.fc21.i686
systemctl[1135]: segfault at b70000cc ip b77421cd sp bfd7a060 error 4 in systemctl[b76f4000+9c000] systemctl[1143]: segfault at b80000cc ip b779e1cd sp bf97d7f0 error 4 in systemctl[b7750000+9c000] systemctl[1152]: segfault at b80000cc ip b77431cd sp bf9be350 error 4 in systemctl[b76f5000+9c000] systemctl[1160]: segfault at b90000cc ip b778d1cd sp bfd62c10 error 4 in systemctl[b773f000+9c000] systemctl[1169]: segfault at b90000cc ip b76f81cd sp bf83fcf0 error 4 in systemctl[b76aa000+9c000] systemctl[1177]: segfault at b70000cc ip b77281cd sp bfbafcf0 error 4 in systemctl[b76da000+9c000] systemctl[1185]: segfault at b90000cc ip b77361cd sp bff6a680 error 4 in systemctl[b76e8000+9c000] systemctl[1193]: segfault at b70000cc ip b77001cd sp bff62eb0 error 4 in systemctl[b76b2000+9c000] systemctl[1201]: segfault at b80000cc ip b76e31cd sp bf943bf0 error 4 in systemctl[b7695000+9c000] systemctl[1209]: segfault at b90000cc ip b76bb1cd sp bfd088c0 error 4 in systemctl[b766d000+9c000] systemctl[1217]: segfault at b80000cc ip b77a91cd sp bfe9c470 error 4 in systemctl[b775b000+9c000] systemctl[1225]: segfault at b90000cc ip b773d1cd sp bfc7dd90 error 4 in systemctl[b76ef000+9c000]
Selinux is not an issue. Downgrade of glib2 doesn't help. Building and installing newer versions of systemd and lightdm doesn't help also. All this doesn't happen with 3.15.0-1.fc21.i686! Something is strange with that turtle. :)
3.16.0-0.rc2.git0.1.fc21.i686 #1 Not tainted systemd-214-3.gita900b82.20140622.fc21.i686
lightdm[2262] bad frame in sigreturn frame:bfbe133c ip:7c sp:0 orax:ffffffff in lightdm[8048000+38000] lightdm[2277] bad frame in sigreturn frame:bff2087c ip:5ec sp:0 orax:ffffffff in lightdm[8048000+38000] systemd-journald[346]: Received request to flush runtime journal from PID 1 systemd[1]: Unit lightdm.service entered failed state.
[+0.00s] DEBUG: Starting Light Display Manager 1.11.3, UID=0 PID=2074 lightdm.service: main process exited, code=killed, status=4/ILL Unit lightdm.service entered failed state. lightdm.service holdoff time over, scheduling restart.
lightdm.service: main process exited, code=killed, status=4/ILL Unit lightdm.service entered failed state. lightdm.service holdoff time over, scheduling restart.
lightdm.service: main process exited, code=killed, status=11/SEGV Unit lightdm.service entered failed state. lightdm.service holdoff time over, scheduling restart.
lightdm.service: main process exited, code=killed, status=11/SEGV Unit lightdm.service entered failed state. lightdm.service holdoff time over, scheduling restart.
lightdm.service: main process exited, code=killed, status=11/SEGV Unit lightdm.service entered failed state. lightdm.service holdoff time over, scheduling restart.
lightdm.service holdoff time over, scheduling restart. Stopping Light Display Manager... Starting Light Display Manager... lightdm.service start request repeated too quickly, refusing to start. Failed to start Light Display Manager. Unit lightdm.service entered failed state.
Not only LightDM, but all tested display managers refuse to work. There might be a general strike on i686 avenue. :) F.I.S.T.
However a strikebreakers (sometimes derogatorily called a scab, blackleg, Klegg, or knobstick) startx & 'startxfce4-non-graphical' i.e. /usr/libexec/Xorg.bin at multi-user.target works for both, user & root.
This happens specifically with 3.16.x.i686 but not with 3.16.x.x86_64 on the same machine, in the same factory. :) The latter are probably well paid. Hi-Fi!
poma
On Mon, 2014-06-23 at 05:03 +0200, poma wrote:
Not only LightDM, but all tested display managers refuse to work. There might be a general strike on i686 avenue. :)
Already reported, diagnosed and fixed upstream. https://bugzilla.redhat.com/show_bug.cgi?id=1110968 . I expect jwb will backport the patch on Monday.
On 06/23/2014 06:28 AM, Adam Williamson wrote:
On Mon, 2014-06-23 at 05:03 +0200, poma wrote:
Not only LightDM, but all tested display managers refuse to work. There might be a general strike on i686 avenue. :)
Already reported, diagnosed and fixed upstream. https://bugzilla.redhat.com/show_bug.cgi?id=1110968 . I expect jwb will backport the patch on Monday.
Thanks for info. Yeah, as Lubomir stated "vdso=0" works with broken ones, and 3.16.0-0.rc2.git0.3.fc21.i686 PASSED
BTW, Adam, there are people running & testing Rawhide on i686! :)
poma
On Mon, Jun 23, 2014 at 19:13:36 +0200, poma pomidorabelisima@gmail.com wrote:
BTW, Adam, there are people running & testing Rawhide on i686! :)
Yes, and I am backlogged getting bugs filed for issues I am having. I have at least two different problems with 3.16 kernels that make them unusable for me.
There might be a problem with systemd creating init files for a bunch of services, since I am now seeing some services attempt to start at boot, that I can't disable.
I also seem to have a selinux problem blocking consolekit so that sound doesn't work in enforcing mode.
So far I am just working on the kernel change that seems to have md being more picky about md raid1 superblocks and just doing workarounds for the rest.
On 06/23/2014 07:36 PM, Bruno Wolff III wrote:
On Mon, Jun 23, 2014 at 19:13:36 +0200, poma pomidorabelisima@gmail.com wrote:
BTW, Adam, there are people running & testing Rawhide on i686! :)
Yes, and I am backlogged getting bugs filed for issues I am having. I have at least two different problems with 3.16 kernels that make them unusable for me.
There might be a problem with systemd creating init files for a bunch of services, since I am now seeing some services attempt to start at boot, that I can't disable.
I also seem to have a selinux problem blocking consolekit so that sound doesn't work in enforcing mode.
So far I am just working on the kernel change that seems to have md being more picky about md raid1 superblocks and just doing workarounds for the rest.
I don't use ConsoleKit, nor do I need it. And is it supposed to be depreciated & outdated?
You're talking about systemd-214-3.fc21(2014-06-23), right?
I'm spinning md1, what worries you there?
poma
On Mon, Jun 23, 2014 at 20:10:32 +0200, poma pomidorabelisima@gmail.com wrote:
You're talking about systemd-214-3.fc21(2014-06-23), right?
systemd-214-2.fc21
I haven't tested systemd-214-3.fc21 yet to see if the problem is still there.
I'm spinning md1, what worries you there?
On 23.06.2014 20:44, Bruno Wolff III wrote:
On Mon, Jun 23, 2014 at 20:10:32 +0200, poma pomidorabelisima@gmail.com wrote:
You're talking about systemd-214-3.fc21(2014-06-23), right?
systemd-214-2.fc21
I haven't tested systemd-214-3.fc21 yet to see if the problem is still there.
I'm spinning md1, what worries you there?
# mdadm --examine /dev/sd[az][0-9]|grep 'Level|'^\ *State''|awk '{print $1,$3,$4}'|sort|uniq Raid : raid1 State clean
# uname -r 3.16.0-0.rc2.git0.1.fc21.x86_64
poma
On Mon, 2014-06-23 at 12:36 -0500, Bruno Wolff III wrote:
On Mon, Jun 23, 2014 at 19:13:36 +0200, poma pomidorabelisima@gmail.com wrote:
BTW, Adam, there are people running & testing Rawhide on i686! :)
Yes, and I am backlogged getting bugs filed for issues I am having. I have at least two different problems with 3.16 kernels that make them unusable for me.
There might be a problem with systemd creating init files for a bunch of services, since I am now seeing some services attempt to start at boot, that I can't disable.
systemd doesn't just 'create init files', I don't think. It *does* have a concept of dependencies, which could account for this effect.
What services exactly are you talking about?
I also seem to have a selinux problem blocking consolekit so that sound doesn't work in enforcing mode.
What desktop are you using? It'd be good if you could file the bug for this, filing SELinux denials via sealert is pretty fast.
So far I am just working on the kernel change that seems to have md being more picky about md raid1 superblocks and just doing workarounds for the rest.
All 3.16 kernels before 3.16.0-0.rc2.git0.1 are just fundamentally broken on i686, I think, unless you pass 'vdso=0'. I wouldn't bother messing with anything unless you're using the rc2 kernel, or passing vdso=0.
On Mon, Jun 23, 2014 at 11:34:53 -0700, Adam Williamson awilliam@redhat.com wrote:
systemd doesn't just 'create init files', I don't think. It *does* have a concept of dependencies, which could account for this effect.
Something is creating ones during boot since about a month ago. They are in a scratch location that gets recreated each boot.
What services exactly are you talking about?
Plague is one example.
I also seem to have a selinux problem blocking consolekit so that sound doesn't work in enforcing mode.
What desktop are you using? It'd be good if you could file the bug for this, filing SELinux denials via sealert is pretty fast.
XFCE.
So far I am just working on the kernel change that seems to have md being more picky about md raid1 superblocks and just doing workarounds for the rest.
All 3.16 kernels before 3.16.0-0.rc2.git0.1 are just fundamentally broken on i686, I think, unless you pass 'vdso=0'. I wouldn't bother messing with anything unless you're using the rc2 kernel, or passing vdso=0.
I'll be testing that shortly on x86_64 and on i686 tonight. But I am seeing two different problems and I'd be surprised if either was that problem. I suspect I am not getting far enough into the boot to see that problem.
The one affecting raid has been filed. The other one is a crash early in boot, and I thought I had heard there were some nouveau regressions and that could affect that machine. I need to get netconsole setup again to capture the crash dump, but have given it lower priority because it seems like something others are likely to run into. The raid thing is weird in that it affects only one of my raid devices. And there may be something odd about the superblock, that gets checked more carefully in 3.16, than 3.15. Though I didn't see any commits that indicated a change in md raid superblock checking recently. I have an upstream bug filed for that as well.
On Mon, Jun 23, 2014 at 13:52:10 -0500, Bruno Wolff III bruno@wolff.to wrote:
On Mon, Jun 23, 2014 at 11:34:53 -0700, Adam Williamson awilliam@redhat.com wrote:
All 3.16 kernels before 3.16.0-0.rc2.git0.1 are just fundamentally broken on i686, I think, unless you pass 'vdso=0'. I wouldn't bother messing with anything unless you're using the rc2 kernel, or passing vdso=0.
I'll be testing that shortly on x86_64 and on i686 tonight. But I am seeing two different problems and I'd be surprised if either was that problem. I suspect I am not getting far enough into the boot to see that problem.
3.16.0-0.rc2.git0.1 is pretty broken too. I am definitely seeing two other issues.
The one affecting raid has been filed. The other one is a crash early
It looks like this one might be elsewhere in the I/O stack. When I got a live image to boot, dd reported /dev/sda3 as zero size which would explain why the superblock was bad. blkid returned info about the device so this seems really odd. And it only seems to happen on this one partition.
On Tue, 2014-06-24 at 19:48 -0500, Bruno Wolff III wrote:
On Mon, Jun 23, 2014 at 13:52:10 -0500, Bruno Wolff III bruno@wolff.to wrote:
On Mon, Jun 23, 2014 at 11:34:53 -0700, Adam Williamson awilliam@redhat.com wrote:
All 3.16 kernels before 3.16.0-0.rc2.git0.1 are just fundamentally broken on i686, I think, unless you pass 'vdso=0'. I wouldn't bother messing with anything unless you're using the rc2 kernel, or passing vdso=0.
I'll be testing that shortly on x86_64 and on i686 tonight. But I am seeing two different problems and I'd be surprised if either was that problem. I suspect I am not getting far enough into the boot to see that problem.
3.16.0-0.rc2.git0.1 is pretty broken too. I am definitely seeing two other issues.
Well, it's a pretty early one, so this isn't surprising. The 'special' thing about the vdso bug is it was, AFAICT, more or less a complete showstopper for the i686 kernel, regardless of hardware: it happened on any system you tried to boot an i686 kernel on.
The one affecting raid has been filed. The other one is a crash early
It looks like this one might be elsewhere in the I/O stack. When I got a live image to boot, dd reported /dev/sda3 as zero size which would explain why the superblock was bad. blkid returned info about the device so this seems really odd. And it only seems to happen on this one partition.
Yup, file the bugs and hopefully they'll be fixed rapidly :)
On Wed, Jun 25, 2014 at 3:24 AM, Adam Williamson awilliam@redhat.com wrote:
On Tue, 2014-06-24 at 19:48 -0500, Bruno Wolff III wrote:
On Mon, Jun 23, 2014 at 13:52:10 -0500, Bruno Wolff III bruno@wolff.to wrote:
On Mon, Jun 23, 2014 at 11:34:53 -0700, Adam Williamson awilliam@redhat.com wrote:
All 3.16 kernels before 3.16.0-0.rc2.git0.1 are just fundamentally broken on i686, I think, unless you pass 'vdso=0'. I wouldn't bother messing with anything unless you're using the rc2 kernel, or passing vdso=0.
I'll be testing that shortly on x86_64 and on i686 tonight. But I am seeing two different problems and I'd be surprised if either was that problem. I suspect I am not getting far enough into the boot to see that problem.
3.16.0-0.rc2.git0.1 is pretty broken too. I am definitely seeing two other issues.
Well, it's a pretty early one, so this isn't surprising. The 'special' thing about the vdso bug is it was, AFAICT, more or less a complete showstopper for the i686 kernel, regardless of hardware: it happened on any system you tried to boot an i686 kernel on.
The one affecting raid has been filed. The other one is a crash early
It looks like this one might be elsewhere in the I/O stack. When I got a live image to boot, dd reported /dev/sda3 as zero size which would explain why the superblock was bad. blkid returned info about the device so this seems really odd. And it only seems to happen on this one partition.
Yup, file the bugs and hopefully they'll be fixed rapidly :)
We're seeing the same issue with ARM booting, we filed bug 1109603 [1] but it's some what intermittent.
Peter
On 2014-06-23 11:34 (GMT-0700) Adam Williamson composed:
All 3.16 kernels before 3.16.0-0.rc2.git0.1 are just fundamentally broken on i686, I think, unless you pass 'vdso=0'. I wouldn't bother messing with anything unless you're using the rc2 kernel, or passing vdso=0.
That doesn't help here:
root=/dev/sda17 ipv6.disable=1 net.ifnames=0 KEYTABLE=us noplymouth selinux=0 noresume splash=verbose vga=791 video=1024x768@60 3 vdso=0
With Kernel 3.16.0-0.rc1.git4.1.fc21.i686+PAE on i865G I have to use telnet or ssh. Otherwise when init seems near completion, the screen goes black and stays that way. I commented in someone else's bug (and got scolded): https://bugzilla.redhat.com/show_bug.cgi?id=1104371
On 2014-06-23 17:07 (GMT-0400) Felix Miata composed:
On 2014-06-23 11:34 (GMT-0700) Adam Williamson composed:
All 3.16 kernels before 3.16.0-0.rc2.git0.1 are just fundamentally broken on i686, I think, unless you pass 'vdso=0'. I wouldn't bother messing with anything unless you're using the rc2 kernel, or passing vdso=0.
That doesn't help here:
root=/dev/sda17 ipv6.disable=1 net.ifnames=0 KEYTABLE=us noplymouth selinux=0 noresume splash=verbose vga=791 video=1024x768@60 3 vdso=0
With Kernel 3.16.0-0.rc1.git4.1.fc21.i686+PAE on i865G I have to use telnet or ssh. Otherwise when init seems near completion, the screen goes black and stays that way. I commented in someone else's bug (and got scolded): https://bugzilla.redhat.com/show_bug.cgi?id=1104371
No improvement with Kernel 3.16.0-0.rc2.git0.1.fc21.i686+PAE with or without vdso=0.
On 24.06.2014 21:56, Felix Miata wrote:
On 2014-06-23 17:07 (GMT-0400) Felix Miata composed:
On 2014-06-23 11:34 (GMT-0700) Adam Williamson composed:
All 3.16 kernels before 3.16.0-0.rc2.git0.1 are just fundamentally broken on i686, I think, unless you pass 'vdso=0'. I wouldn't bother messing with anything unless you're using the rc2 kernel, or passing vdso=0.
That doesn't help here:
root=/dev/sda17 ipv6.disable=1 net.ifnames=0 KEYTABLE=us noplymouth selinux=0 noresume splash=verbose vga=791 video=1024x768@60 3 vdso=0
With Kernel 3.16.0-0.rc1.git4.1.fc21.i686+PAE on i865G I have to use telnet or ssh. Otherwise when init seems near completion, the screen goes black and stays that way. I commented in someone else's bug (and got scolded): https://bugzilla.redhat.com/show_bug.cgi?id=1104371
No improvement with Kernel 3.16.0-0.rc2.git0.1.fc21.i686+PAE with or without vdso=0.
Until your X.Org X11 video module is resolved you can place "xdriver=modesetting" in the kernel command line. Besides check there is no an active "Driver" directive as part of the Section "Device" somewhere in /etc/X11/xorg.conf[.d/*.conf].
"modesetting" == "modesetting_drv.so"
poma
On Mon, 2014-06-23 at 17:07 -0400, Felix Miata wrote:
On 2014-06-23 11:34 (GMT-0700) Adam Williamson composed:
All 3.16 kernels before 3.16.0-0.rc2.git0.1 are just fundamentally broken on i686, I think, unless you pass 'vdso=0'. I wouldn't bother messing with anything unless you're using the rc2 kernel, or passing vdso=0.
That doesn't help here:
root=/dev/sda17 ipv6.disable=1 net.ifnames=0 KEYTABLE=us noplymouth selinux=0 noresume splash=verbose vga=791 video=1024x768@60 3 vdso=0
With Kernel 3.16.0-0.rc1.git4.1.fc21.i686+PAE on i865G I have to use telnet or ssh. Otherwise when init seems near completion, the screen goes black and stays that way. I commented in someone else's bug (and got scolded): https://bugzilla.redhat.com/show_bug.cgi?id=1104371
Well, I wouldn't say scolded. Hans just asked you politely to file a new bug, since you have clearly different hardware. The Intel i8xx adapters are notoriously tricky hardware, and quite different from later Intel adapters. I'd say most likely yes, you're seeing a bug which is different from both the general i686 vdso bug *and* Filipe's intel video bug; so Hans is correct to ask you to file a new one. Please boot an affected kernel with 'drm.debug=15', allow the bug to happen, then either ssh in and grab the output of 'dmesg' or reboot to a working kernel and grab the output of 'journalctl -b-1' to attach to your bug. Thanks.
On 2014-06-24 15:13 (GMT-0700) Adam Williamson composed:
Hans just asked you politely to file a new bug
I've been avoiding that lately because I search for an existing bug first, and someone's wisdom has seen fit to make that unduly difficult by excluding any option in the product list to select a particular release or Rawhide rather than simply "Fedora" (from a list totaling merely 5 items). OTOH, the component list with a gazillion items to search through only shows 6.5 at a time, almost as bad as Windows' idiotic tiny window lists showing 3 out of many. Why? Is Fedora overwhelmed by people available to do triage?
On Tue, 2014-06-24 at 19:01 -0400, Felix Miata wrote:
On 2014-06-24 15:13 (GMT-0700) Adam Williamson composed:
Hans just asked you politely to file a new bug
I've been avoiding that lately because I search for an existing bug first, and someone's wisdom has seen fit to make that unduly difficult by excluding any option in the product list to select a particular release or Rawhide rather than simply "Fedora" (from a list totaling merely 5 items).
Eh? No, it hasn't. The two are separate fields. Fedora is the "Product". rawhide or 20 or 19 is the "version". You have to click the "Refresh Components/Versions/Releases/Milestones" button after selecting Fedora as the "Classification" and "Product", and then the correct options will be available. (Bugzilla isn't web 2.0-y enough to refresh it automatically).
OTOH, the component list with a gazillion items to search through only shows 6.5 at a time, almost as bad as Windows' idiotic tiny window lists showing 3 out of many.
Yeah, that's annoying.
Why?
Because Bugzilla. But, try: https://bugz.fedoraproject.org/xorg-x11-drv-intel for a handy shortcut.
Is Fedora overwhelmed by people available to do triage?
Oh, if only. Still, there's probably a fairly small number of people running i8xx hardware on Rawhide at this point.
On 2014-06-24 16:12 (GMT-0700) Adam Williamson composed:
I've been avoiding that lately because I search for an existing bug first, and someone's wisdom has seen fit to make that unduly difficult by excluding any option in the product list to select a particular release or Rawhide rather than simply "Fedora" (from a list totaling merely 5 items).
Eh? No, it hasn't. The two are separate fields. Fedora is the "Product". rawhide or 20 or 19 is the "version". You have to click the "Refresh Components/Versions/Releases/Milestones" button after selecting Fedora as the "Classification" and "Product", and then the correct options will be available. (Bugzilla isn't web 2.0-y enough to refresh it automatically).
Does one need to be running Chrom* or Konq to be offered any versions to select from? Hitting the refresh button produces no observable page change in SM rv29 or FF rv28.
On Tue, 2014-06-24 at 19:33 -0400, Felix Miata wrote:
On 2014-06-24 16:12 (GMT-0700) Adam Williamson composed:
I've been avoiding that lately because I search for an existing bug first, and someone's wisdom has seen fit to make that unduly difficult by excluding any option in the product list to select a particular release or Rawhide rather than simply "Fedora" (from a list totaling merely 5 items).
Eh? No, it hasn't. The two are separate fields. Fedora is the "Product". rawhide or 20 or 19 is the "version". You have to click the "Refresh Components/Versions/Releases/Milestones" button after selecting Fedora as the "Classification" and "Product", and then the correct options will be available. (Bugzilla isn't web 2.0-y enough to refresh it automatically).
Does one need to be running Chrom* or Konq to be offered any versions to select from? Hitting the refresh button produces no observable page change in SM rv29 or FF rv28.
I'm using Firefox. The version field is a bit further down the form than you might be looking, perhaps?
On 2014-06-24 16:35 (GMT-0700) Adam Williamson composed:
I'm using Firefox. The version field is a bit further down the form than you might be looking, perhaps?
That's it, a list made obtuse by so many things in between out of logical order, and populated by a big bunch of lines with single digits beginning with 1 (instead of e.g. most recent versions at top). Bugzilla.novell.com has a nice workaround for the illogical order: after first selecting openSUSE, one sees in the product list such names as openSUSE 13.1, openSUSE 12.3, openSUSE 12.2....
On Tue, 2014-06-24 at 19:52 -0400, Felix Miata wrote:
On 2014-06-24 16:35 (GMT-0700) Adam Williamson composed:
I'm using Firefox. The version field is a bit further down the form than you might be looking, perhaps?
That's it, a list made obtuse by so many things in between out of logical order, and populated by a big bunch of lines with single digits beginning with 1 (instead of e.g. most recent versions at top). Bugzilla.novell.com has a nice workaround for the illogical order: after first selecting openSUSE, one sees in the product list such names as openSUSE 13.1, openSUSE 12.3, openSUSE 12.2....
So...it's kind of a mess. Bugzilla was really designed to be deployed as one instance per "software project", specifically, one-instance-per-Mozilla-browser. And then some years passed, and now we're here. :P
bugzilla.redhat.com is a single bugzilla instance for two Linux distributions, a middleware stack, a couple of clouds, several virtualization systems, and Pete only knows what else. If Red Hat sprang into existence tomorrow with its current product range, we probably wouldn't create a single bugzilla instance and stuff all those products into it. We almost certainly wouldn't use quite the hierarchy we're currently saddled with. But the whole thing evolved sort of organically over the years, and it's rather difficult to change. I don't think we could easily switch over from having "Fedora" as a product with multiple versions to having multiple Fedora "products", and I'm not sure that would necessarily be a good change in all respects anyway.
It is possible to tweak things in RHBZ to improve the experience, but you have to be quite careful to consider the impacts on *everything else in RHBZ*, so it all happens quite slowly, and is unfortunately quite internal to Red Hat. Every so often we kick around the idea of splitting Fedora out from RHBZ and getting its own BZ instance or using a different tracker, but it never quite happens...just one of those things, I guess :/
On 2014-06-24 15:13 (GMT-0700) Adam Williamson composed:
Well, I wouldn't say scolded. Hans just asked you politely to file a new bug, since you have clearly different hardware. The Intel i8xx adapters are notoriously tricky hardware, and quite different from later Intel adapters. I'd say most likely yes, you're seeing a bug which is different from both the general i686 vdso bug *and* Filipe's intel video bug; so Hans is correct to ask you to file a new one. Please boot an affected kernel with 'drm.debug=15', allow the bug to happen, then either ssh in and grab the output of 'dmesg' or reboot to a working kernel and grab the output of 'journalctl -b-1' to attach to your bug.
Are you sure what I described in that bug is different? It's repeatable with http://mirrors.us.kernel.org/fedora/development/rawhide/i386/os/Packages/k/k... on i865G, i915G and i945G, but not rv200 Radeon. I've filled in a new bug page, except I've not decided what to put in its summary, if it warrants subjecting to the triagers at all.
On Tue, 2014-06-24 at 23:54 -0400, Felix Miata wrote:
On 2014-06-24 15:13 (GMT-0700) Adam Williamson composed:
Well, I wouldn't say scolded. Hans just asked you politely to file a new bug, since you have clearly different hardware. The Intel i8xx adapters are notoriously tricky hardware, and quite different from later Intel adapters. I'd say most likely yes, you're seeing a bug which is different from both the general i686 vdso bug *and* Filipe's intel video bug; so Hans is correct to ask you to file a new one. Please boot an affected kernel with 'drm.debug=15', allow the bug to happen, then either ssh in and grab the output of 'dmesg' or reboot to a working kernel and grab the output of 'journalctl -b-1' to attach to your bug.
Are you sure what I described in that bug is different?
Well, it's impossible to be *sure* unless you provide the necessary logs, as I mentioned above.
No-one can pretend to absolute knowledge of what is happening if all the info we have to go on is "X initialization fails".
On 2014-06-24 23:34 (GMT-0700) Adam Williamson composed:
...
Are you sure what I described in that bug is different?
Well, it's impossible to be *sure* unless you provide the necessary logs, as I mentioned above.
No-one can pretend to absolute knowledge of what is happening if all the info we have to go on is "X initialization fails".
Where did you see "X initialization fails"? I've been booting with 3 on cmdline. Anyway, here's 2 of 3 drm.debug=15 dmesgs captured:
http://fm.no-ip.com/Tmp/Linux/F/dmsgI865Gf21k316rc2g01.txt http://fm.no-ip.com/Tmp/Linux/F/dmsgI945Gf21k316rc2g01.txt
On Wed, 2014-06-25 at 09:06 -0400, Felix Miata wrote:
On 2014-06-24 23:34 (GMT-0700) Adam Williamson composed:
...
Are you sure what I described in that bug is different?
Well, it's impossible to be *sure* unless you provide the necessary logs, as I mentioned above.
No-one can pretend to absolute knowledge of what is happening if all the info we have to go on is "X initialization fails".
Where did you see "X initialization fails"? I've been booting with 3 on cmdline. Anyway, here's 2 of 3 drm.debug=15 dmesgs captured:
Er...this seems to be the log from the hardware you describe in your bug comment, but:
What is this from? Thanks.
On Wed, Jun 25, 2014 at 11:12 PM, Adam Williamson awilliam@redhat.com wrote:
What is this from? Thanks.
I think it's from dmesg.
Yours sincerely, Christopher Meng
Noob here.
On 2014-06-25 08:12 (GMT-0700) Adam Williamson composed:
Where did you see "X initialization fails"? I've been booting with 3 on cmdline. Anyway, here's 2 of 3 drm.debug=15 dmesgs captured:
^^^^^
Er...this seems to be the log from the hardware you describe in your bug comment, but:
^^^^^
What is this from?
On 2014-06-24 23:54 (GMT-0400) Felix Miata composed:
It's repeatable ... on i865G, i915G and i945G
And the one in the middle:
http://fm.no-ip.com/Tmp/Linux/F/dmsgI915Gf21k316rc2g01.txt ^^^^^
On Wed, 2014-06-25 at 12:02 -0400, Felix Miata wrote:
On 2014-06-25 08:12 (GMT-0700) Adam Williamson composed:
Where did you see "X initialization fails"? I've been booting with 3 on cmdline. Anyway, here's 2 of 3 drm.debug=15 dmesgs captured:
^^^^^Er...this seems to be the log from the hardware you describe in your bug comment, but:
^^^^^What is this from?
On 2014-06-24 23:54 (GMT-0400) Felix Miata composed:
It's repeatable ... on i865G, i915G and i945G
And the one in the middle:
So...these are three different machines?
I'm curious: why are you passing video= parameters on each one? Do any/all of them work if you don't pass that parameter?
On Wed, 2014-06-25 at 10:05 -0700, Adam Williamson wrote:
On Wed, 2014-06-25 at 12:02 -0400, Felix Miata wrote:
On 2014-06-25 08:12 (GMT-0700) Adam Williamson composed:
Where did you see "X initialization fails"? I've been booting with 3 on cmdline. Anyway, here's 2 of 3 drm.debug=15 dmesgs captured:
^^^^^Er...this seems to be the log from the hardware you describe in your bug comment, but:
^^^^^What is this from?
On 2014-06-24 23:54 (GMT-0400) Felix Miata composed:
It's repeatable ... on i865G, i915G and i945G
And the one in the middle:
So...these are three different machines?
I'm curious: why are you passing video= parameters on each one? Do any/all of them work if you don't pass that parameter?
...and does it work if you append an 'e':
video=1024x768e
?
On 25.06.2014 19:08, Adam Williamson wrote:
On Wed, 2014-06-25 at 10:05 -0700, Adam Williamson wrote:
On Wed, 2014-06-25 at 12:02 -0400, Felix Miata wrote:
On 2014-06-25 08:12 (GMT-0700) Adam Williamson composed:
Where did you see "X initialization fails"? I've been booting with 3 on cmdline. Anyway, here's 2 of 3 drm.debug=15 dmesgs captured:
^^^^^Er...this seems to be the log from the hardware you describe in your bug comment, but:
^^^^^What is this from?
On 2014-06-24 23:54 (GMT-0400) Felix Miata composed:
It's repeatable ... on i865G, i915G and i945G
And the one in the middle:
So...these are three different machines?
I'm curious: why are you passing video= parameters on each one? Do any/all of them work if you don't pass that parameter?
...and does it work if you append an 'e':
video=1024x768e
?
"'e' will force the display to be enabled, i.e. it will override the detection if a display is connected." https://www.kernel.org/doc/Documentation/fb/modedb.txt
Felix: "... Otherwise when init seems near completion, the screen goes black and stays that way. ..."
Obviously the screen is detected and enabled, however failing at Xorg initialisation, i.e. Xorg failing at initialisation, display just follows. And "video" res shouldn't affect the whole scene. Certainly not in my case, however I don't use it plymouth. :)
poma
On Wed, 2014-06-25 at 19:58 +0200, poma wrote:
On 25.06.2014 19:08, Adam Williamson wrote:
On Wed, 2014-06-25 at 10:05 -0700, Adam Williamson wrote:
On Wed, 2014-06-25 at 12:02 -0400, Felix Miata wrote:
On 2014-06-25 08:12 (GMT-0700) Adam Williamson composed:
Where did you see "X initialization fails"? I've been booting with 3 on cmdline. Anyway, here's 2 of 3 drm.debug=15 dmesgs captured:
^^^^^Er...this seems to be the log from the hardware you describe in your bug comment, but:
^^^^^What is this from?
On 2014-06-24 23:54 (GMT-0400) Felix Miata composed:
It's repeatable ... on i865G, i915G and i945G
And the one in the middle:
So...these are three different machines?
I'm curious: why are you passing video= parameters on each one? Do any/all of them work if you don't pass that parameter?
...and does it work if you append an 'e':
video=1024x768e
?
"'e' will force the display to be enabled, i.e. it will override the detection if a display is connected." https://www.kernel.org/doc/Documentation/fb/modedb.txt
Felix: "... Otherwise when init seems near completion, the screen goes black and stays that way. ..."
Obviously the screen is detected and enabled,
Sorry, but nope: the point where it fails may be the point where the intel kernel driver does hotplug detection.
however failing at Xorg initialisation,
That's what I thought at first, but it isn't. He's booting with '3', i.e. not to X.
On 25.06.2014 20:09, Adam Williamson wrote:
On Wed, 2014-06-25 at 19:58 +0200, poma wrote:
On 25.06.2014 19:08, Adam Williamson wrote:
On Wed, 2014-06-25 at 10:05 -0700, Adam Williamson wrote:
On Wed, 2014-06-25 at 12:02 -0400, Felix Miata wrote:
On 2014-06-25 08:12 (GMT-0700) Adam Williamson composed:
> Where did you see "X initialization fails"? I've been booting with 3 on > cmdline. Anyway, here's 2 of 3 drm.debug=15 dmesgs captured:
> http://fm.no-ip.com/Tmp/Linux/F/dmsgI865Gf21k316rc2g01.txt
^^^^^Er...this seems to be the log from the hardware you describe in your bug comment, but:
> http://fm.no-ip.com/Tmp/Linux/F/dmsgI945Gf21k316rc2g01.txt
^^^^^What is this from?
On 2014-06-24 23:54 (GMT-0400) Felix Miata composed:
It's repeatable ... on i865G, i915G and i945G
And the one in the middle:
So...these are three different machines?
I'm curious: why are you passing video= parameters on each one? Do any/all of them work if you don't pass that parameter?
...and does it work if you append an 'e':
video=1024x768e
?
"'e' will force the display to be enabled, i.e. it will override the detection if a display is connected." https://www.kernel.org/doc/Documentation/fb/modedb.txt
Felix: "... Otherwise when init seems near completion, the screen goes black and stays that way. ..."
Obviously the screen is detected and enabled,
Sorry, but nope: the point where it fails may be the point where the intel kernel driver does hotplug detection.
however failing at Xorg initialisation,
That's what I thought at first, but it isn't. He's booting with '3', i.e. not to X.
Whoops! I missed it, and I'm not surprised. At the "vdso" breakage I used # systemctl set-default multi-user.target
poma
On 2014-06-25 10:08 (GMT-0700) Adam Williamson composed:
On Wed, 2014-06-25 at 10:05 -0700, Adam Williamson wrote:
I'm curious: why are you passing video= parameters on each one? Do any/all of them work if you don't pass that parameter?
...and does it work if you append an 'e':
video=1024x768e
video=1024x768@60e doesn't help.
On 2014-06-25 14:12 (GMT-0400) Adam Williamson composed:
That answers the first question, but not the second (or the third I sent as a follow-up).
I thought I provided answers to all, so I'm not sure what might be missing. Omitting both vga= and video= doesn't change anything, which I thought I wrote early on in thread, but may be in the bug I didn't yet submit.
OTOH, might what's described at http://lists.freedesktop.org/archives/intel-gfx/2014-June/047981.html be an upstream solution forthcoming?
On Wed, 2014-06-25 at 14:59 -0400, Felix Miata wrote:
On 2014-06-25 10:08 (GMT-0700) Adam Williamson composed:
On Wed, 2014-06-25 at 10:05 -0700, Adam Williamson wrote:
I'm curious: why are you passing video= parameters on each one? Do any/all of them work if you don't pass that parameter?
...and does it work if you append an 'e':
video=1024x768e
video=1024x768@60e doesn't help.
On 2014-06-25 14:12 (GMT-0400) Adam Williamson composed:
That answers the first question, but not the second (or the third I sent as a follow-up).
I thought I provided answers to all, so I'm not sure what might be missing. Omitting both vga= and video= doesn't change anything,
That's what I was looking for, thanks.
which I thought I wrote early on in thread,
I don't know, but it's hard to remember everything that's been said!
but may be in the bug I didn't yet submit.
OTOH, might what's described at http://lists.freedesktop.org/archives/intel-gfx/2014-June/047981.html be an upstream solution forthcoming?
Good spot - that may very well be your issue, yeah, since you're using a CRT display. It would also explain why I can't reproduce the bug on my Intel graphics system, which is a laptop.
I might be able to whip up a test kernel for you later with that patch applied.
On 2014-06-25 12:53 (GMT-0700) Adam Williamson composed:
Good spot - that may very well be your issue, yeah, since you're using a CRT display. It would also explain why I can't reproduce the bug on my Intel graphics system, which is a laptop.
The i915G at least also puts to sleep my 1440x900 LCD TV and my 1600x1200 Dell LCD. Which gfxchip is in your laptop?
On 2014-06-25 16:50 (GMT-0400) Felix Miata composed:
On 2014-06-25 12:53 (GMT-0700) Adam Williamson composed:
Good spot - that may very well be your issue, yeah, since you're using a CRT display. It would also explain why I can't reproduce the bug on my Intel graphics system, which is a laptop.
The i915G at least also puts to sleep my 1440x900 LCD TV and my 1600x1200 Dell LCD. Which gfxchip is in your laptop?
And is its kernel i686?
I'm half done now doing upgrade on 64 bit 4000 series....
On 2014-06-25 12:53 (GMT-0700) Adam Williamson composed:
OTOH, might what's described at http://lists.freedesktop.org/archives/intel-gfx/2014-June/047981.html be an upstream solution forthcoming?
Good spot - that may very well be your issue, yeah, since you're using a CRT display. It would also explain why I can't reproduce the bug on my Intel graphics system, which is a laptop.
I might be able to whip up a test kernel for you later with that patch applied.
Already fixed in rc2.git2.1 on the mirrors. :-)
On 2014-06-26 12:40 (GMT-0400) Felix Miata composed:
On 2014-06-25 12:53 (GMT-0700) Adam Williamson composed:
OTOH, might what's described at http://lists.freedesktop.org/archives/intel-gfx/2014-June/047981.html be an upstream solution forthcoming?
Good spot - that may very well be your issue, yeah, since you're using a CRT display. It would also explain why I can't reproduce the bug on my Intel graphics system, which is a laptop.
I might be able to whip up a test kernel for you later with that patch applied.
Already fixed in rc2.git2.1 on the mirrors. :-)
In rc2.git4.1 on i845G, either it already regressed, or never left. :-(
24.212753] gzip (241) used greatest stack depth: 5072 bytes left [ 27.486778] intel_rng: Firmware space is locked read-only. If you can't or intel_rng: don't want to disable this in firmware setup, and if intel_rng: you are certain that your system has a functional intel_rng: RNG, try using the 'no_fwh_detect' option. [ 28.739458] [drm] Initialized drm 1.1.0 20060810 [ 29.743365] microcode: CPU0 sig=0xf29, pf=0x4, revision=0x2e [ 29.863491] microcode: Microcode Update Driver: v2.00 tigran@aivazian.fsnet.co.uk, Peter Oruba [ 30.554376] ppdev: user-space parallel port driver [ 30.654113] iTCO_vendor_support: vendor-support=0 [ 30.928260] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11 [ 30.928599] iTCO_wdt: Found a ICH4 TCO device (Version=1, TCOBASE=0x0460) [ 30.945298] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) [ 31.043903] [drm] Memory usable by graphics device = 128M [ 31.044199] [drm] Replacing VGA console driver [ 31.055722] Console: switching to colour dummy device 80x25 [ 31.075386] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 31.075474] [drm] Driver supports precise vblank timestamp query. [ 31.081165] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [ 31.086203] [drm:i9xx_set_fifo_underrun_reporting] *ERROR* pipe A underrun [ 31.125306] [drm] initialized overlay support [ 31.125401] i915 0000:00:02.0: No connectors reported connected with modes [ 31.125482] [drm] Cannot find any crtc or sizes - going 1024x768 [ 31.163431] fbcon: inteldrmfb (fb0) is primary device [ 31.179359] Console: switching to colour frame buffer device 128x48 [ 31.188771] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device [ 31.188913] i915 0000:00:02.0: registered panic notifier [ 31.192178] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 [ 32.510124] snd_intel8x0 0000:00:1f.5: intel8x0_measure_ac97_clock: measured 50454 usecs (2432 -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
On 2014-06-30 18:21 (GMT-0400) Felix Miata composed:
Already fixed in rc2.git2.1 on the mirrors. :-)
In rc2.git4.1 on i845G, either it already regressed, or never left. :-(
Every 3.16 before and after rc2.git1.1 and rc2.git2.1 makes all my Intel vtty screens black:
845 865 915 945 4100
Latest failure: kernel-3.16.0-0.rc3.git0.1.fc21.x86_64.rpm
On 02.07.2014 04:09, Felix Miata wrote:
On 2014-06-30 18:21 (GMT-0400) Felix Miata composed:
Already fixed in rc2.git2.1 on the mirrors. :-)
In rc2.git4.1 on i845G, either it already regressed, or never left. :-(
Every 3.16 before and after rc2.git1.1 and rc2.git2.1 makes all my Intel vtty screens black:
845 865 915 945 4100
Latest failure: kernel-3.16.0-0.rc3.git0.1.fc21.x86_64.rpm
drm/i915: only apply crt_present check on VLV https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/driv... author Jesse Barnes jbarnes@virtuousgeek.org 2014-06-25 15:24:29 (GMT) committer Jani Nikula jani.nikula@intel.com 2014-06-30 10:48:48 (GMT) -> Age 45 hours <-
So if you don't have patience, you can patch it yourself. I guess that's not a problem. :)
poma
On 2014-06-25 10:05 (GMT-0700) Adam Williamson composed:
So...these are three different machines?
3 out of 14 on which Rawhide is currently installed (test machines total 20+) here, among which are represented various flavors of MGA (400 & 550), SiS (Z7/Z9 XG20 core), Intel (810, 815, 845, 865, 915, 945, 965, 3100, 4100), ATI (rv200, rv250, rv370, rv380, rv516) & NVidia for video.
I'm curious: why are you passing video= parameters on each one? Do any/all of them work if you don't pass that parameter?
Most of my test machines get used most of the time with a '21"' CRT with preferred mode 1600x1200 reported as preferred mode 1280x1024 used at approximately 175% of normal viewing distance. Avoiding eyestrain requires 1152x864 or lower on the vttys unless I want to monkey with terminal font reconfiguration from default.
My second most used test machine display is a 19" LCD TV with native mode 1440x900 that reports preferred 1280x1024 but supports 4:3 modes up to 1792x1344. It is used at similar distance, so also needs 1024x768 on the vttys for the same reason as the CRT.
I also have 2 15" 1024x768, 17" & 19" 1280x1024 and 20" 1600x1200 LCD puter displays, 2 31.5" TVs, and an abundance of other CRTs to use as test conditions require, in addition to the LCDs used for my 24/7 systems that can be briefly pressed into test service when necessary.
On Wed, 2014-06-25 at 14:10 -0400, Felix Miata wrote:
On 2014-06-25 10:05 (GMT-0700) Adam Williamson composed:
So...these are three different machines?
3 out of 14 on which Rawhide is currently installed (test machines total 20+) here, among which are represented various flavors of MGA (400 & 550), SiS (Z7/Z9 XG20 core), Intel (810, 815, 845, 865, 915, 945, 965, 3100, 4100), ATI (rv200, rv250, rv370, rv380, rv516) & NVidia for video.
I'm curious: why are you passing video= parameters on each one? Do any/all of them work if you don't pass that parameter?
Most of my test machines get used most of the time with a '21"' CRT with preferred mode 1600x1200 reported as preferred mode 1280x1024 used at approximately 175% of normal viewing distance. Avoiding eyestrain requires 1152x864 or lower on the vttys unless I want to monkey with terminal font reconfiguration from default.
That answers the first question, but not the second (or the third I sent as a follow-up).
On 25.06.2014 20:10, Felix Miata wrote:
On 2014-06-25 10:05 (GMT-0700) Adam Williamson composed:
So...these are three different machines?
3 out of 14 on which Rawhide is currently installed (test machines total 20+) here, among which are represented various flavors of MGA (400 & 550), SiS (Z7/Z9 XG20 core), Intel (810, 815, 845, 865, 915, 945, 965, 3100, 4100), ATI (rv200, rv250, rv370, rv380, rv516) & NVidia for video.
I'm curious: why are you passing video= parameters on each one? Do any/all of them work if you don't pass that parameter?
Most of my test machines get used most of the time with a '21"' CRT with preferred mode 1600x1200 reported as preferred mode 1280x1024 used at approximately 175% of normal viewing distance. Avoiding eyestrain requires 1152x864 or lower on the vttys unless I want to monkey with terminal font reconfiguration from default.
My second most used test machine display is a 19" LCD TV with native mode 1440x900 that reports preferred 1280x1024 but supports 4:3 modes up to 1792x1344. It is used at similar distance, so also needs 1024x768 on the vttys for the same reason as the CRT.
I also have 2 15" 1024x768, 17" & 19" 1280x1024 and 20" 1600x1200 LCD puter displays, 2 31.5" TVs, and an abundance of other CRTs to use as test conditions require, in addition to the LCDs used for my 24/7 systems that can be briefly pressed into test service when necessary.
# yum install terminus-fonts-console
- permanent system wide /etc/vconsole.conf FONT=<Big mama font>
e.g. 'latarcyrheb-sun32' or 'ter-v32b'
- runtime local $ setfont latarcyrheb-sun32 $ setfont ter-v32b
poma
On 25.06.2014 20:49, poma wrote:
On 25.06.2014 20:10, Felix Miata wrote:
On 2014-06-25 10:05 (GMT-0700) Adam Williamson composed:
So...these are three different machines?
3 out of 14 on which Rawhide is currently installed (test machines total 20+) here, among which are represented various flavors of MGA (400 & 550), SiS (Z7/Z9 XG20 core), Intel (810, 815, 845, 865, 915, 945, 965, 3100, 4100), ATI (rv200, rv250, rv370, rv380, rv516) & NVidia for video.
I'm curious: why are you passing video= parameters on each one? Do any/all of them work if you don't pass that parameter?
Most of my test machines get used most of the time with a '21"' CRT with preferred mode 1600x1200 reported as preferred mode 1280x1024 used at approximately 175% of normal viewing distance. Avoiding eyestrain requires 1152x864 or lower on the vttys unless I want to monkey with terminal font reconfiguration from default.
My second most used test machine display is a 19" LCD TV with native mode 1440x900 that reports preferred 1280x1024 but supports 4:3 modes up to 1792x1344. It is used at similar distance, so also needs 1024x768 on the vttys for the same reason as the CRT.
I also have 2 15" 1024x768, 17" & 19" 1280x1024 and 20" 1600x1200 LCD puter displays, 2 31.5" TVs, and an abundance of other CRTs to use as test conditions require, in addition to the LCDs used for my 24/7 systems that can be briefly pressed into test service when necessary.
# yum install terminus-fonts-console
- permanent system wide
/etc/vconsole.conf FONT=<Big mama font>
e.g. 'latarcyrheb-sun32' or 'ter-v32b'
- runtime local
$ setfont latarcyrheb-sun32 $ setfont ter-v32b
systemd-214-5.fc21.x86_64 kernel-3.16.0-0.rc3.git0.1.fc21.x86_64
It seems this kernel? bug is still present[2].
"rd.vconsole.font=ter-v32b" also fails to subsist due to "fb: switching to nouveaufb from VESA VGA".
- journal systemd-vconsole-setup systemd[1]: Starting Setup Virtual Console... systemd-vconsole-setup[347]: putfont: KDFONTOP: Invalid argument systemd-vconsole-setup[347]: /usr/bin/setfont failed with error code 71. systemd[1]: Started Setup Virtual Console.
I've found so far that this can only be overcome with these two almost identical solutions; When I thought of 'actual-vconsole-setup-start' I did not know that Yegor already done it. Saṃsāra.
Yegor's solution[1]: # cp /usr/lib/systemd/system/systemd-vconsole-setup.service /etc/systemd/system/ # diff /etc/systemd/system/systemd-vconsole-setup.service \
/usr/lib/systemd/system/systemd-vconsole-setup.service
13,14c13,14 < After=sysinit.target < Before=shutdown.target ---
After=systemd-readahead-collect.service systemd-readahead-replay.service Before=sysinit.target shutdown.target
or even simpler - leave 'systemd-vconsole-setup.service' as is, and make this one /etc/systemd/system/actual-vconsole-setup-start.service: # Actual Virtual Console Setup Start
[Unit] Description=Actual Virtual Console Setup Start
[Service] Type=forking ExecStart=/usr/lib/systemd/systemd-vconsole-setup
[Install] WantedBy=rescue.target multi-user.target
# systemctl enable actual-vconsole-setup-start.service
and now you have appropriate font size for 1920x1080, no need to lower resolution via "video=<xres>x<yres>". Perhaps '32' is too large, so choose <= '28', e.g. ter-v28b or ter-v24b. /usr/share/doc/terminus-fonts-console/README[.fedora]
poma
[1] systemd-vconsole-setup: /usr/bin/setfont failed with error code 71 http://lists.freedesktop.org/archives/systemd-devel/2011-June/002562.html
[2] Can not change console font via /etc/vconsole.conf https://bugzilla.redhat.com/show_bug.cgi?id=1074113
The keyboard layout for the virtual console cannot be changed using “localectl set-keymap <map>; dracut -f; reboot;” https://bugzilla.redhat.com/show_bug.cgi?id=1033250
font settings are lost when kernel fb drivers are changed https://bugzilla.redhat.com/show_bug.cgi?id=892340
Kernel drivers lose console font settings https://bugzilla.redhat.com/show_bug.cgi?id=1074624
BTW, Adam, there are people running & testing Rawhide on i686! :)
Yes, and I am backlogged getting bugs filed for issues I am having. I have at least two different problems with 3.16 kernels that make them unusable for me.
There might be a problem with systemd creating init files for a bunch of services, since I am now seeing some services attempt to start at boot, that I can't disable.
systemd doesn't just 'create init files', I don't think. It *does* have a concept of dependencies, which could account for this effect.
I'm seeing it, at least appear, to do something like this. There's a new binary, at least since systemd-208 in F-20 (sorry, shitty hotel wifi makes it too hard to do wider triage) called:
/usr/lib/systemd/system-generators/systemd-sysv-generator
What services exactly are you talking about?
I'm seeing the following style of messages in dmesg. The following is a sample but wc tells me there's 343 entries:
[44437.200793] systemd-sysv-generator[24124]: Could not find init script for radvd.service [44437.200810] systemd-sysv-generator[24124]: Could not find init script for ebtables.service [44437.200814] systemd-sysv-generator[24124]: Could not find init script for oddjobd.service [44437.200818] systemd-sysv-generator[24124]: Could not find init script for spice-vdagentd.service [44437.200822] systemd-sysv-generator[24124]: Could not find init script for livesys-late.service [44437.200826] systemd-sysv-generator[24124]: Could not find init script for tcsd.service [44437.200831] systemd-sysv-generator[24124]: Could not find init script for livesys.service [44437.200837] systemd-sysv-generator[24124]: Could not find init script for radvd.service
I can dig further if necessary in the next few days, I'm travelling at the moment and $dayjob is a bit intense so time is limited in the short term :(
Peter
On Wed, 2014-06-25 at 00:11 +0100, Peter Robinson wrote:
BTW, Adam, there are people running & testing Rawhide on i686! :)
Yes, and I am backlogged getting bugs filed for issues I am having. I have at least two different problems with 3.16 kernels that make them unusable for me.
There might be a problem with systemd creating init files for a bunch of services, since I am now seeing some services attempt to start at boot, that I can't disable.
systemd doesn't just 'create init files', I don't think. It *does* have a concept of dependencies, which could account for this effect.
I'm seeing it, at least appear, to do something like this. There's a new binary, at least since systemd-208 in F-20 (sorry, shitty hotel wifi makes it too hard to do wider triage) called:
/usr/lib/systemd/system-generators/systemd-sysv-generator
What services exactly are you talking about?
I'm seeing the following style of messages in dmesg. The following is a sample but wc tells me there's 343 entries:
[44437.200793] systemd-sysv-generator[24124]: Could not find init script for radvd.service [44437.200810] systemd-sysv-generator[24124]: Could not find init script for ebtables.service [44437.200814] systemd-sysv-generator[24124]: Could not find init script for oddjobd.service [44437.200818] systemd-sysv-generator[24124]: Could not find init script for spice-vdagentd.service [44437.200822] systemd-sysv-generator[24124]: Could not find init script for livesys-late.service [44437.200826] systemd-sysv-generator[24124]: Could not find init script for tcsd.service [44437.200831] systemd-sysv-generator[24124]: Could not find init script for livesys.service [44437.200837] systemd-sysv-generator[24124]: Could not find init script for radvd.service
I can dig further if necessary in the next few days, I'm travelling at the moment and $dayjob is a bit intense so time is limited in the short term :(
Huh, well that's interesting. I guess I'll look into it.
On Tue, 2014-06-24 at 16:13 -0700, Adam Williamson wrote:
On Wed, 2014-06-25 at 00:11 +0100, Peter Robinson wrote:
BTW, Adam, there are people running & testing Rawhide on i686! :)
Yes, and I am backlogged getting bugs filed for issues I am having. I have at least two different problems with 3.16 kernels that make them unusable for me.
There might be a problem with systemd creating init files for a bunch of services, since I am now seeing some services attempt to start at boot, that I can't disable.
systemd doesn't just 'create init files', I don't think. It *does* have a concept of dependencies, which could account for this effect.
I'm seeing it, at least appear, to do something like this. There's a new binary, at least since systemd-208 in F-20 (sorry, shitty hotel wifi makes it too hard to do wider triage) called:
/usr/lib/systemd/system-generators/systemd-sysv-generator
What services exactly are you talking about?
I'm seeing the following style of messages in dmesg. The following is a sample but wc tells me there's 343 entries:
[44437.200793] systemd-sysv-generator[24124]: Could not find init script for radvd.service [44437.200810] systemd-sysv-generator[24124]: Could not find init script for ebtables.service [44437.200814] systemd-sysv-generator[24124]: Could not find init script for oddjobd.service [44437.200818] systemd-sysv-generator[24124]: Could not find init script for spice-vdagentd.service [44437.200822] systemd-sysv-generator[24124]: Could not find init script for livesys-late.service [44437.200826] systemd-sysv-generator[24124]: Could not find init script for tcsd.service [44437.200831] systemd-sysv-generator[24124]: Could not find init script for livesys.service [44437.200837] systemd-sysv-generator[24124]: Could not find init script for radvd.service
I can dig further if necessary in the next few days, I'm travelling at the moment and $dayjob is a bit intense so time is limited in the short term :(
Huh, well that's interesting. I guess I'll look into it.
So, I looked, and found:
http://cgit.freedesktop.org/systemd/systemd/commit/src/sysv-generator?id=95e...
if I'm reading that correctly, I think this is basically the way systemd is now handling legacy sysv initscripts - by generating systemd units for them in a transient directory (/run/systemd/generator.late) on the fly at boot time.
That particular error is from the set_dependencies_from_rcnd function. I'm finding myself too dumb to figure out exactly what the generator is trying to do at that point, but I do notice that on my Rawhide system - which is pretty old, old enough to have been sysv at one point - I have a whole ton of dangling symlinks to old initscripts in /etc/rc*.d/, and at a glance, the "Could not find init script for foo.service" messages in my logs map quite nicely to all those dangling symlinks. I suspect if I cleaned them all up, the messages would go away.
I think the "Could not find init script" errors are probably due to this 'dangling symlink' problem, and the fact that .service files are being generated is intentional - just the way systemd is handling remaining sysv services - and not a bug. That's my reading on the situation anyway. You should find the generated .service files match the remaining sysv services you have in /etc/init.d ; that's the case for me:
[adamw@adam isos]$ ls /etc/init.d/ functions livesys-late network vboxadd vboxadd-x11 livesys netconsole README vboxadd-service
[adamw@adam isos]$ ls /run/systemd/generator.late/ livesys-late.service network-online.target.wants vboxadd-service.service livesys.service network.service vboxadd-x11.service netconsole.service vboxadd.service
On Tue, Jun 24, 2014 at 16:30:59 -0700, Adam Williamson awilliam@redhat.com wrote:
I think the "Could not find init script" errors are probably due to this 'dangling symlink' problem, and the fact that .service files are being generated is intentional - just the way systemd is handling remaining sysv services - and not a bug. That's my reading on the situation anyway. You should find the generated .service files match the remaining sysv services you have in /etc/init.d ; that's the case for me:
Thanks, that helped me get rid of extraneous boot output.
I used: rm -vf `find -L /etc/rc.d -lname '*'` to remove these sym links.
However this didn't solve my concern about some services attempting to start that shouldn't. But now I'm thinking there might be some other old config around that I should look for. I'm going to start with plague-server since I never actually used that, but might have had to disable it in the past.
On Tue, 2014-06-24 at 19:45 -0500, Bruno Wolff III wrote:
On Tue, Jun 24, 2014 at 16:30:59 -0700, Adam Williamson awilliam@redhat.com wrote:
I think the "Could not find init script" errors are probably due to this 'dangling symlink' problem, and the fact that .service files are being generated is intentional - just the way systemd is handling remaining sysv services - and not a bug. That's my reading on the situation anyway. You should find the generated .service files match the remaining sysv services you have in /etc/init.d ; that's the case for me:
Thanks, that helped me get rid of extraneous boot output.
I used: rm -vf `find -L /etc/rc.d -lname '*'` to remove these sym links.
Tip:
symlinks -d ./
However this didn't solve my concern about some services attempting to start that shouldn't.
Yeah, like I said, the 'could not find init script' output and the generated services appear to be different issues.
It seems that the generator stuff causes network.service to be run, for me. It creates a directory called /run/systemd/generator.late/network-online.target.wants and symlinks network.service in there - i.e. it's saying that network.service should be run as a part of the target network-online.target . I'm not sure if this is correct, or a bug. I'll have to talk to the systemd devs about it.
I think we'd have to look into each specific case of a service being run to figure out exactly why - it'd help to see your entire /run/systemd/generator.late tree, for a start.
But now I'm thinking there might be some other old config around that I should look for. I'm going to start with plague-server since I never actually used that, but might have had to disable it in the past.
The most obvious thing is whether you have a SXXservice symlink in /etc/rc*.d; that constitutes the service being 'enabled' so far as SysV is concerned, and so in that case it seems correct for systemd to enable the runtime-generated systemd service. But there may be other reasons why this might happen, I think we'd best look at them case by case.
dropping kernel list from CC, I don't think it wants these messages.
On Tue, Jun 24, 2014 at 19:22:05 -0700, Adam Williamson awilliam@redhat.com wrote:
The most obvious thing is whether you have a SXXservice symlink in /etc/rc*.d; that constitutes the service being 'enabled' so far as SysV is concerned, and so in that case it seems correct for systemd to enable the runtime-generated systemd service. But there may be other reasons why this might happen, I think we'd best look at them case by case.
I filed a bug (https://bugzilla.redhat.com/show_bug.cgi?id=1112908) for plague. Plague has both a systemd entry and an init.d file (but not files for any run levels) for the plague-server service. That seems odd, but I don't know if that is the cause of the problem.
On Tue, 2014-06-24 at 22:50 -0500, Bruno Wolff III wrote:
On Tue, Jun 24, 2014 at 19:22:05 -0700, Adam Williamson awilliam@redhat.com wrote:
The most obvious thing is whether you have a SXXservice symlink in /etc/rc*.d; that constitutes the service being 'enabled' so far as SysV is concerned, and so in that case it seems correct for systemd to enable the runtime-generated systemd service. But there may be other reasons why this might happen, I think we'd best look at them case by case.
I filed a bug (https://bugzilla.redhat.com/show_bug.cgi?id=1112908) for plague. Plague has both a systemd entry and an init.d file (but not files for any run levels) for the plague-server service. That seems odd, but I don't know if that is the cause of the problem.
So I think I have a handle on what's causing the bug of sysv services starting when they're not supposed to - turns out to be (I think) a fairly subtle bug in the sysv-generator code, if I'm right, then I'm proud of myself for figuring it out :P See https://bugzilla.redhat.com/show_bug.cgi?id=1112908#c9 . I'm currently running a systemd scratch build which I hope is going to fix the problem:
http://koji.fedoraproject.org/koji/taskinfo?taskID=7076318
assuming it builds successfully (AdamW Patching C: Take Cover!), if you could test with that it'd be good.
sysv-generator actually landed in systemd-214 (not 209 as I'd thought), so it makes sense that we're only just now seeing this bug crop up.
On Wed, Jun 25, 2014 at 12:56:41 -0700, Adam Williamson awilliam@redhat.com wrote:
http://koji.fedoraproject.org/koji/taskinfo?taskID=7076318
assuming it builds successfully (AdamW Patching C: Take Cover!), if you could test with that it'd be good.
I'm installing it now. Should be about 30 minutes before I get back to you with results.
sysv-generator actually landed in systemd-214 (not 209 as I'd thought), so it makes sense that we're only just now seeing this bug crop up.
Do we want a bug for the dangling symlink handling? It would be nice if they got cleaned up automatically. Barring that, a different message that made it clear you should remove them as the current message wasn't all that obvious about what was going on.
On Wed, 2014-06-25 at 15:09 -0500, Bruno Wolff III wrote:
On Wed, Jun 25, 2014 at 12:56:41 -0700, Adam Williamson awilliam@redhat.com wrote:
http://koji.fedoraproject.org/koji/taskinfo?taskID=7076318
assuming it builds successfully (AdamW Patching C: Take Cover!), if you could test with that it'd be good.
I'm installing it now. Should be about 30 minutes before I get back to you with results.
Hum, you can probably skip it - the patch isn't exactly wrong, but it's also not exactly right and also not exactly sufficient. as you can probably tell, this is getting complicated... https://bugs.freedesktop.org/show_bug.cgi?id=80537
sysv-generator actually landed in systemd-214 (not 209 as I'd thought), so it makes sense that we're only just now seeing this bug crop up.
Do we want a bug for the dangling symlink handling? It would be nice if they got cleaned up automatically. Barring that, a different message that made it clear you should remove them as the current message wasn't all that obvious about what was going on.
ehhhhh, I don't know if it's really systemd's job to go around cleaning up /etc/init.d , and if it might not possibly have unintended consequences in some weird case? might want to make it a devel@ or systemd mailing list kickaround rather than a bug report. Providing more useful log info might be worth a bug report though.
On Wed, Jun 25, 2014 at 14:10:31 -0700, Adam Williamson awilliam@redhat.com wrote:
On Wed, 2014-06-25 at 15:09 -0500, Bruno Wolff III wrote:
On Wed, Jun 25, 2014 at 12:56:41 -0700, Adam Williamson awilliam@redhat.com wrote:
http://koji.fedoraproject.org/koji/taskinfo?taskID=7076318
assuming it builds successfully (AdamW Patching C: Take Cover!), if you could test with that it'd be good.
I'm installing it now. Should be about 30 minutes before I get back to you with results.
Hum, you can probably skip it - the patch isn't exactly wrong, but it's also not exactly right and also not exactly sufficient. as you can probably tell, this is getting complicated... https://bugs.freedesktop.org/show_bug.cgi?id=80537
Well it made things better. The several services that were erroneously being started are no getting started.
However on the first reboot after installation the shutdown hung. I powered off rather than wait for a timeout, since this happens relatively often with systemd updates. However the two times the system has come up, the network service (I use that in preference to NM) did not come up properly and I had to manually start it to have working network access.
systemctl status network ● network.service - LSB: Bring up/down networking Loaded: loaded (/etc/rc.d/init.d/network) Active: inactive (dead)
On Wed, 2014-06-25 at 16:16 -0500, Bruno Wolff III wrote:
On Wed, Jun 25, 2014 at 14:10:31 -0700, Adam Williamson awilliam@redhat.com wrote:
On Wed, 2014-06-25 at 15:09 -0500, Bruno Wolff III wrote:
On Wed, Jun 25, 2014 at 12:56:41 -0700, Adam Williamson awilliam@redhat.com wrote:
http://koji.fedoraproject.org/koji/taskinfo?taskID=7076318
assuming it builds successfully (AdamW Patching C: Take Cover!), if you could test with that it'd be good.
I'm installing it now. Should be about 30 minutes before I get back to you with results.
Hum, you can probably skip it - the patch isn't exactly wrong, but it's also not exactly right and also not exactly sufficient. as you can probably tell, this is getting complicated... https://bugs.freedesktop.org/show_bug.cgi?id=80537
Well it made things better. The several services that were erroneously being started are no getting started.
Yeah, but it doesn't do what the code is actually *supposed* to do, which is make those services depend on network-online.target . It would also break some other things the code currently does correctly.
However on the first reboot after installation the shutdown hung. I powered off rather than wait for a timeout, since this happens relatively often with systemd updates. However the two times the system has come up, the network service (I use that in preference to NM) did not come up properly and I had to manually start it to have working network access.
I don't think that has anything to do with my change, but it's kinda academic :)
On Tue, Jun 24, 2014 at 04:30:59PM -0700, Adam Williamson wrote:
I think the "Could not find init script" errors are probably due to this 'dangling symlink' problem, and the fact that .service files are being generated is intentional - just the way systemd is handling remaining sysv services - and not a bug.
That looks to me like an obvious bug. Not a killer one but still. systemd does so many things that it could easily check that it attempts to handle a dangling symlink and skip it instead of going into, at least, some long and noisy spurious loop. It could even leave in logs something like "Warning: old dangling symlinks in subdirectories of /etc/init.d" and possibly suggest running 'symlinks -d /etc/init.d' (or maybe even kill these leftovers itself but that would be likely going too far).
Michał
-
Adam Williamson -
Bruno Wolff III -
Christopher Meng -
Felix Miata -
Michal Jaegermann -
Peter Robinson -
poma