http://bugzilla.opensuse.org/show_bug.cgi?id=971907 Egbert Eich changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |xorg-maintainer-bugs@forge. | |provo.novell.com -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=971907 http://bugzilla.opensuse.org/show_bug.cgi?id=971907#c3 Egbert Eich changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |eich@suse.com Flags| |needinfo?(eich@suse.com) --- Comment #3 from Egbert Eich --- Larry, let me have a look at this. I may be able to give you some useful hints. I was going to look at it yesterday - oddly it took me some time to find the driver sources. Setting a NEEDINFO to me. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=971907 http://bugzilla.opensuse.org/show_bug.cgi?id=971907#c5 Helga Fischer changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hfischer@eschkitai.de --- Comment #5 from Helga Fischer --- Me too ;) Running tumbleweed on a openSUSE 13.2 a guest in virtualbox (5.0.16 r105871). Getting no X; startx fails. linux-ttwd:~ # startx hostname: Name or service not known xauth: file /root/.serverauth.2045 does not exist X.Org X Server 1.18.1 Release Date: 2016-02-08 X Protocol Version 11, Revision 0 Build Operating System: openSUSE SUSE LINUX Current Operating System: Linux linux-ttwd 4.5.0-1-default #1 SMP PREEMPT Wed Mar 16 17:30:21 UTC 2016 (b2c9ae5) x86_64 Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.5.0-1-default root=UUID=a4cfa924-19dc-4738-abca-8ff47f8f8da5 resume=/dev/sda1 splash=silent quiet showopts Build Date: 07 March 2016 02:09:18PM Current version of pixman: 0.34.0 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Tue Mar 22 18:24:34 2016 (==) Using config directory: "/etc/X11/xorg.conf.d" (==) Using system config directory "/usr/share/X11/xorg.conf.d" (EE) Fatal server error: (EE) AddScreen/ScreenInit failed for driver 0 (EE) (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information. (EE) (EE) Server terminated with error (1). Closing log file. xinit: giving up xinit: unable to connect to X server: Connection refused xinit: server error ------------------------------------------------------------------------------------------- xinit failed. /usr/bin/Xorg is not setuid, maybe that's the reason? If so either use a display manager (strongly recommended) or adjust /etc/permissions.local and run "chkstat --system --set" afterwards -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=971907 http://bugzilla.opensuse.org/show_bug.cgi?id=971907#c7 --- Comment #7 from Egbert Eich --- @Larry: I did some investigations: 1. This appears to be a kernel issue as it works with the previous kernel I had installed. 2. I was able to track it down to a piece of code trying to mmap PCI resources. The relevant code that fails on the current TW kernel is: ======= #include #include #include #include #include #include #include #include #include int main(void) { void *val; int fd = open("/sys/bus/pci/devices/0000:00:02.0/resource0", O_RDWR | O_CLOEXEC); if (fd < 0) exit (1); val = mmap(NULL, 0xc00000, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); if (val == MAP_FAILED) { printf("failed: %s\n",strerror(errno)); } close (fd); } ======== This little program fails when run on the current TW kernel but succeeds on older kernels as well as on Leap 42.1. The parameters passed to mmap() seem to be ok, the map size is < pci aperture size, so this can't be the problem. I will dig into the kernel tomorrow if you don't beat me to it or have a better idea, for today I will call it a day. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=971907 http://bugzilla.opensuse.org/show_bug.cgi?id=971907#c9 --- Comment #9 from Egbert Eich --- Larry, I've resumed working on this ;) Meanwhile I found which test causes the -EINVAL in pci_mmap_resource() - i just don't know why, yet. Currently building the working 4.4 kernel to have a comparison. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=971907 http://bugzilla.opensuse.org/show_bug.cgi?id=971907#c11 --- Comment #11 from Egbert Eich --- Stupid me. It is the VESA driver which is running on these resources and is keeping them busy of course! I could have thought of this as well, now I took the hard route. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=971907 http://bugzilla.opensuse.org/show_bug.cgi?id=971907#c13 --- Comment #13 from Larry Finger --- I just verified that adding "iomem=relaxed" to the kernel command line allows the standard kernel to boot normally. I will give that workaround to the Forum entry listed by the OP. If I follow your patch, the essential change is that you are clearing the IORESOURCE_BUSY bit. To me, that seems a lot less ugly than forcing the entire system to relax its protection of /dev/mem. Please Cc me on any discussions with kernel devs. In the meantime, I will add your patch to the VirtualBox build and get the build started. If a better solution becomes available, I can always replace this one. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=971907 http://bugzilla.opensuse.org/show_bug.cgi?id=971907#c15 --- Comment #15 from Rick Hunnicutt --- (In reply to Larry Finger from comment #13)

I just verified that adding "iomem=relaxed" to the kernel command line allows the standard kernel to boot normally. I will give that workaround to the Forum entry listed by the OP.

If I follow your patch, the essential change is that you are clearing the IORESOURCE_BUSY bit. To me, that seems a lot less ugly than forcing the entire system to relax its protection of /dev/mem.

Please Cc me on any discussions with kernel devs. In the meantime, I will add your patch to the VirtualBox build and get the build started. If a better solution becomes available, I can always replace this one.

KDE still seems to have a problem with the "iomem=relaxed" parameter added. My boot log shows: Mar 23 08:17:04 linux-54cy audit[1985]: ANOM_ABEND auid=1023 uid=1023 gid=100 ses=1 pid=1985 comm="klauncher" exe="/usr/bin/kdeinit5" sig=11 Mar 23 08:17:04 linux-54cy kernel: show_signal_msg: 330 callbacks suppressed Mar 23 08:17:04 linux-54cy kernel: klauncher[1985]: segfault at 9610 ip 0000000000009610 sp 00007fffcdfda308 error 14 in kdeinit5[400000+d000] Mar 23 08:17:04 linux-54cy audit[1987]: ANOM_ABEND auid=1023 uid=1023 gid=100 ses=1 pid=1987 comm="kded5" exe="/usr/bin/kdeinit5" sig=11 Mar 23 08:17:04 linux-54cy kernel: kded5[1987]: segfault at 9610 ip 0000000000009610 sp 00007fffcdfd9d18 error 14 in kdeinit5[400000+d000] Mar 23 08:17:04 linux-54cy audit[1990]: ANOM_ABEND auid=1023 uid=1023 gid=100 ses=1 pid=1990 comm="kcminit_startup" exe="/usr/bin/kdeinit5" sig=11 Mar 23 08:17:04 linux-54cy kernel: kcminit_startup[1990]: segfault at 9610 ip 0000000000009610 sp 00007fffcdfd9d88 error 14 in kdeinit5[400000+d000] Mar 23 08:17:06 linux-54cy systemd-coredump[1986]: Process 1985 (klauncher) of user 1023 dumped core. Mar 23 08:17:08 linux-54cy systemd-coredump[1993]: Process 1987 (kded5) of user 1023 dumped core. Mar 23 08:17:08 linux-54cy systemd-coredump[1994]: Process 1990 (kcminit_startup) of user 1023 dumped core. Mar 23 08:17:20 linux-54cy audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-localed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Mar 23 08:18:39 linux-54cy audit[1656]: USER_AUTH pid=1656 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication grantors=pam_gnome_keyring,pam_unix acct="root" exe="/bin/login" hostname=? addr=? terminal=tty1 res=success' and the desktop never comes up -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=971907 http://bugzilla.opensuse.org/show_bug.cgi?id=971907#c17 --- Comment #17 from Egbert Eich --- (In reply to Takashi Iwai from comment #14)

Yes, there might be other things, and the new config does this so intentionally; it's the purpose of the hardening, after all.

The same issue (VRAM reserved by vesafb) is a long-standing issue, even for KMS. In the case of KMS, the fb switchover happens, so that vesafb leaves the resources before the new drmfb takes it again.

But in the case of vbox... Well, is vesafb used at all? If yes, how can it keep running while another user-mode driver is running up?

Of course, vesafb is used on VirtualBox in non-EFI mode. All user space drivers have been running on top of vesafb (or EFI fb). Some ioctl(fd, KDSETMODE, KD_GRAPHICS) usually convinces the fbdev layer to not paint any more. IHMO, once this mode is left, the fbdev layer repaints the screen. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=971907 http://bugzilla.opensuse.org/show_bug.cgi?id=971907#c19 --- Comment #19 from Takashi Iwai --- (In reply to Egbert Eich from comment #17)

(In reply to Takashi Iwai from comment #14)

...

Yes, there might be other things, and the new config does this so intentionally; it's the purpose of the hardening, after all.

The same issue (VRAM reserved by vesafb) is a long-standing issue, even for KMS. In the case of KMS, the fb switchover happens, so that vesafb leaves the resources before the new drmfb takes it again.

But in the case of vbox... Well, is vesafb used at all? If yes, how can it keep running while another user-mode driver is running up?

Of course, vesafb is used on VirtualBox in non-EFI mode. All user space drivers have been running on top of vesafb (or EFI fb). Some ioctl(fd, KDSETMODE, KD_GRAPHICS) usually convinces the fbdev layer to not paint any more. IHMO, once this mode is left, the fbdev layer repaints the screen.

So, we may teach the driver to adjust the busy flag on the fly there? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=971907 http://bugzilla.opensuse.org/show_bug.cgi?id=971907#c21 --- Comment #21 from Larry Finger --- I will be away most of tomorrow and Friday, and I will need to catch up after I get home. In the meantime, I will be looking for a solution. After thinking about it, I do not think changing vesafb is viable. Changing the default configuration would likely be better. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=971907 http://bugzilla.opensuse.org/show_bug.cgi?id=971907#c23 --- Comment #23 from Larry Finger --- I have an additional followup. The VB Guest additions installed from the 5.0.17 version that I build still do not work; however, installing them from the iso that Oracle publishes is working with a Gnome desktop as long as 3D acceleration is turned off. I am still investigating these issues. Note that with 5.0.17, it is possible to use gdm, thus it is no linger necessary to change the DISPLAYMANAGER line in /etc/sysconfig/displaymanager to lightdm. There is no need to use the "iomem=relaxed" kernel option. A virtual machine containing the latest update to Tumbleweed KDE works fine with VirtualBox 5.0.16. I cannot duplicate the problems of Comment #15. To reiterate, neither Gnome nor KDE desktops require changing the kernel command line with kernel 4.5.0. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=971907 http://bugzilla.opensuse.org/show_bug.cgi?id=971907#c26 Egbert Eich changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED --- Comment #26 from Egbert Eich --- (In reply to Jon Grossart from comment #25)

Still broken on 20160406+ snapshot.

It fails for the same reason -- sddm crashes and won't start preventing any graphical desktop. Removing the virtualbox-guest* packages still allows the desktop to boot. Using the iomem=relaxed kernel option also no longer works.

Then this is a different reason. Create new ticket and provide logs. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=971907 http://bugzilla.opensuse.org/show_bug.cgi?id=971907#c28 --- Comment #28 from Takashi Iwai --- (In reply to kolA flash from comment #27)

(In reply to Larry Finger from comment #24)

...

I have just committed VB 5.0.17 to the build system. This version implements using gdm as the window manager for the new versions of X.org that do not run as root. X should start in both Gnome and KDE desktops.

Just updated to the current tumbleweed version, but still got that problem.

You mentioned gdm. But I'm using KDE and kdm. So does the fix only apply to gdm? What about lightdm?

lightdm should be OK. If it doesn't work, it's a different issue. Please open another bug report. AFAIK, KDE doesn't use lightdm but sddm as default. And there seems another bug, see comment 26. -- You are receiving this mail because: You are on the CC list for the bug.