Created attachment 622820 [details]
The screenshot promised - I can try to extract a log in text form if needed

(In reply to Dominique Leuenberger from comment #1)
> Created attachment 622820 [details]
> The screenshot promised - I can try to extract a log in text form if needed

Complete logfile in text format, please!

> <path/to/rescue/cd/from/20150210>

?!?

Created attachment 622823 [details]
Xorg.0.log from the VM - in text form

To reproduce, download the snapshot iso from:
https://openqa.opensuse.org/assets/iso/openSUSE-Tumbleweed-Rescue-CD-i686-Snapshot20150210-Media.iso

(ave to ~/Downloads)

Then to reproduce:

qemu-kvm -cdrom ~/Downloads/openSUSE-Tumbleweed-Rescue-CD-i686-Snapshot20150210-Media.iso -m 1024

Some more info:

* the system starts up with "nomodeset" passed to the kernel
* the system FAILS to start with "nomodeset x11failsafe"

(In reply to Dominique Leuenberger from comment #6)
> Some more info:
> 
> * the system starts up with "nomodeset" passed to the kernel

Sure, In that case likely the non-KMS based cirrus driver instead of builtin modeset(ting) is being used.

> * the system FAILS to start with "nomodeset x11failsafe"

So here you're trying to use modesetting driver without KMS enabled. Not the smartest idea IMO.

Anyway, the issue here is. The builtin modeset(ting) driver now tries to use
glamor for acceleration. Apparently this doesn't work during installation due to
missing Mesa drivers depending on llvmpipe (huge deps to llvm libs). The fallback to ShadowFB fails as well. Culprit seems to be

hw/xfree86/drivers/modesetting/driver.c:789

  ret = drmGetCap(ms->fd, DRM_CAP_DUMB_PREFER_SHADOW, &value);

For some reason this fails. So neither glamor nor ShadowFB acceleration
(also known as acceleration "none").

More to come ...

BTW, it's weird to see this fail on i386, but succeed on x86_64.

(In reply to Stefan Dirsch from comment #7)
> > * the system FAILS to start with "nomodeset x11failsafe"
> 
> So here you're trying to use modesetting driver without KMS enabled. Not the
> smartest idea IMO.

In my defense: this is what the FAILSAFE option in the grub menu passes; so not invented by me.

At least we see a build warning on i386 in modesetting directory, which we do not see on x86_64.

[  307s] dri2.c: In function 'ms_dri2_create_buffer':
[  307s] dri2.c:213:5: warning: passing argument 3 of 'glamor_name_from_pixmap' from incompatible pointer type [enabled by default]
[  307s]      buffer->name = glamor_name_from_pixmap(pixmap, &pitch, &size);
[  307s]      ^
[  307s] In file included from driver.h:38:0,
[  307s]                  from dri2.c:42:
[  307s] ../../../../glamor/glamor.h:220:22: note: expected 'CARD32 *' but argument is of type 'uint32_t *'
[  307s]  extern _X_EXPORT int glamor_name_from_pixmap(PixmapPtr pixmap,

(In reply to Dominique Leuenberger from comment #5)
> To reproduce, download the snapshot iso from:
> https://openqa.opensuse.org/assets/iso/openSUSE-Tumbleweed-Rescue-CD-i686-
> Snapshot20150210-Media.iso
> 
> (ave to ~/Downloads)
> 
> Then to reproduce:
> 
> qemu-kvm -cdrom
> ~/Downloads/openSUSE-Tumbleweed-Rescue-CD-i686-Snapshot20150210-Media.iso -m
> 1024

boot hangs at networkmanager script (never times out ...)

Created attachment 622874 [details]
u_Fixed-build-warning-about-incompatible-pointer-types.patch

Fixed build warning on i386. But I don't see how this should change anything here ...

It would also be useful to see the X logfile attached for x86_64, where the builting modeset(ting) driver apparently magically works ...

(In reply to Stefan Dirsch from comment #13)
> It would also be useful to see the X logfile attached for x86_64, where the
> builting modeset(ting) driver apparently magically works ...

you can found Rescue CD X logfile at https://openqa.opensuse.org/tests/47372/file/logs.tar.bz2

if you prefer see the logfile in DVD installation on x86_64, here you are https://openqa.opensuse.org/tests/47341/file/logs.tar.bz2

Thanks. This was helpful. We're seing the same failures on x86_64 including the ones I tried to address above. Differences in logfile for x86_64 and i586 can be reduced to this.

x86_64: (II) modeset(0): Setting screen physical size to 270 x 203
x86_64: <input stuff, Xserver starts>
i586: (EE) Fatal server error:
i586: (EE) failed to create screen resources(EE)

This needs to be debugged properly on an installed system.

I need access via ssh to an installed system. Tried this one

# qemu-kvm -cdrom /mounts/dist/install/SLE-12-Desktop-GM/SLE-12-Desktop-DVD-x86_64-GM-DVD1.iso -drive file=/test/qemu.img -boot order=dc -m 1024M -net user,hostname=test,hostfwd=tcp::5555-:22

# ssh -v -p 5555 localhost
OpenSSH_6.2p2, OpenSSL 1.0.1k 8 Jan 2015
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug1: Connecting to localhost [::1] port 5555.
debug1: connect to address ::1 port 5555: Connection refused
debug1: Connecting to localhost [127.0.0.1] port 5555.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2

That's it. ssh ports in firewall are openend. sshd is running. Without ssh access to a qemu VM I cannot debug this issue. It's that simple.

ok, I did the following:

Downloaded https://openqa.opensuse.org/assets/iso/openSUSE-Tumbleweed-KDE-Live-i686-Snapshot20150211-Media.iso

then started qemu-kvm using:

qemu-kvm -m 1024 -cdrom openSUSE-Tumbleweed-KDE-Live-i686-Snapshot20150211-Media.iso -device e1000,netdev=user.0 -netdev user,id=user.0,hostfwd=tcp::5555-:22

once it seems 'hanging' (it's on VTY7, no X coming up), press alt-F1, login as root (no password)

passwd (ssh wihtout password is not accepted)
rcsshd start

then connect using ssh root@localhost from the host machine.

Ok. Thanks! ssh works now. I'll install an openSUSE 13.2-i586 now and update X packages from obs://X11:XOrg, which have been built against openSUSE 13.2.

mmap fails in hw/xfree86/drivers/modesetting/drmmode_display.c/dumb_bo_map()

    map = mmap(0, bo->size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, arg.offset);
    if (map == MAP_FAILED)
        return -errno;

(gdb) p bo->size
$16 = 16384
(gdb) p fd
$17 = 10
(gdb) p arg.offset
$19 = 4299685888

(gdb) bt
#0  dumb_bo_map (fd=10, bo=0x8290030) at dumb_bo.c:88
#1  0xb767a11e in drmmode_map_cursor_bos (pScrn=pScrn@entry=0x8290850, drmmode=drmmode@entry=0x8291158) at drmmode_display.c:1742
#2  0xb7675678 in CreateScreenResources (pScreen=0x8290070) at driver.c:889
#3  0x080f915b in xf86CrtcCreateScreenResources (screen=0x8290070) at xf86Crtc.c:709
#4  0x08084313 in dix_main (argc=argc@entry=1, argv=argv@entry=0xbffff624, envp=envp@entry=0xbffff62c) at main.c:223
#5  0x0806e12e in main (argc=1, argv=0xbffff624, envp=0xbffff62c) at stubmain.c:34

bochsdrmfb (kernel 3.19) is also affected. inteldrmfb is not affected. Neither on 3.16 nor on 3.19. By default it uses acceleration via glamor. By setting driver option "AccelMethod" "none" you can force it to use ShadowFB, which works nicely as well.

The culprit is that arg.offset takes 64bit while it's truncated at calling mmap() to 32bit off_t.

The old xf86-video-modesetting calls this via libdrm, and libdrm is built with the large-file support so that off_t becomes off64_t.  But xserver seems not built with this properly, thus off_t remains as 32bit.

An ad hoc fix is just to define _FILE_OFFSET_BITS 64 at the beginning of the code before including headers like the patch below.

Created attachment 623434 [details]
Fix patch

(In reply to Takashi Iwai from comment #21)
> The old xf86-video-modesetting calls this via libdrm, and libdrm is built
> with the large-file support so that off_t becomes off64_t.

Correction: the old code also has its own call of dumb_bo_map().  But xf86-video-modesetting itself was supposedly built with 64bit off_t support.

Ok. Takash's patch is in together with his other patch, which enables swcursor by default. Since it's still broken with cirrus KMS, also in x86_64. An issue, which apparently openQA noticed at all!

SR#286386

Closing as fixed.

This is an autogenerated message for OBS integration:
This bug (917385) was mentioned in
https://build.opensuse.org/request/show/286386 Factory / xorg-x11-server