|
Bugzilla – Full Text Bug Listing |
| Summary: | xf86-video-vesa: (EE) VESA(0): Cannot read int vect | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Jens Westemeier <Jens_Westemeier> |
| Component: | X.Org | Assignee: | Stefan Dirsch <sndirsch> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <xorg-maintainer-bugs> |
| Severity: | Normal | ||
| Priority: | P3 - Medium | CC: | luizluca, mpluskal, mvidner, tchvatal, wbauer |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | SUSE Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
X server log
Xorg 0 log from 13.2 NET installer in VirtualBox Xorg 0 log using vesa from 13.2 installed system |
||
|
Description
Jens Westemeier
2015-05-26 12:52:50 UTC
Created attachment 635649 [details]
X server log
Confirmed with the 20150525 snapshot, and a default VBox VM (12 MB VRAM)
i | virtualbox | package | 4.3.20-13.1 | x86_64 | oS 13.2 update
I can confirm this as well, but it's not at all specific to VirtualBox. I can reproduce the same (with a similar Xorg.0.log) on real hardware if I add "nomodeset" to the boot options (or blacklisting the KMS driver via brokenmodules=i915 or similar). Adding "vga=0x317" or similar makes it work again. If needed/helpful, I can provide an Xorg.0.log for both cases. Btw, I think the same issue has been reported as bug#929134 too. *** Bug 929134 has been marked as a duplicate of this bug. *** X people, please check whether we are setting up X right or whether the bug is in X. (In reply to Martin Vidner from comment #1) > Created attachment 635649 [details] > X server log > > Confirmed with the 20150525 snapshot, and a default VBox VM (12 MB VRAM) > i | virtualbox | package | 4.3.20-13.1 | x86_64 | oS 13.2 update [ 55.011] (II) LoadModule: "vboxvideo" [ 55.012] (WW) Warning, couldn't open module vboxvideo [ 55.012] (II) UnloadModule: "vboxvideo" [ 55.012] (II) Unloading vboxvideo [ 55.012] (EE) Failed to load module "vboxvideo" (module does not exist, 0) vboxvideo X driver is missing. Sure you have virtualbox-guest-x11 package installed? Also fallback to fbdev fails, since you don't have a kernel framebuffer configured. Kernel command line: initrd=initrd splash=silent (vga=0x317 or alike is missing here) Last fallback to vesa driver fails as well [ 55.055] (II) VESA(0): initializing int10 [ 55.055] (EE) VESA(0): Cannot read int vect I guess that's related to virtualbox (likely providing a broken VESA BIOS). (In reply to Stefan Dirsch from comment #5) > vboxvideo X driver is missing. Sure you have virtualbox-guest-x11 package > installed? Yes, it is missing, just like radeon, intel, and nouveau (in this case it falls back to "modesetting" though, which seems to work) But, FTR, it is missing on the 13.2 NET-install medium as well, there the installer does come up in graphical mode. > I guess that's related to virtualbox (likely providing a broken VESA BIOS). As I wrote, I can reproduce the problem on real hardware too (tried on an intel system), by specifying "nomodeset" at the kernel command line. I have exactly the same VESA error in the Xorg.0.log on the real hardware. (In reply to Wolfgang Bauer from comment #6) > (In reply to Stefan Dirsch from comment #5) > > vboxvideo X driver is missing. Sure you have virtualbox-guest-x11 package > > installed? > Yes, it is missing, just like radeon, intel, and nouveau (in this case it > falls back to "modesetting" though, which seems to work) Ah. So xf86-video-modesetting is available? Why not also virtualbox-guest-x11? > But, FTR, it is missing on the 13.2 NET-install medium as well, there the > installer does come up in graphical mode. So you're claiming that on the NET install we rely on vesa driver only? Feel free to provide a Xorg.0.log for a 13.2 NET-install. > > I guess that's related to virtualbox (likely providing a broken VESA BIOS). > As I wrote, I can reproduce the problem on real hardware too (tried on an > intel system), by specifying "nomodeset" at the kernel command line. > > I have exactly the same VESA error in the Xorg.0.log on the real hardware. You also need to disable kernel framebuffer for that. Possibly we really see a regression for vesa driver for tumbleweed. On the other hand this means that we did rely exclusively on vesa driver for the NET install. Which sounds weird to me. What's happening on machines running in UEFI mode? I guess fbdev X driver is working there, right? Created attachment 636000 [details] Xorg 0 log from 13.2 NET installer in VirtualBox (In reply to Stefan Dirsch from comment #7) > Ah. So xf86-video-modesetting is available? Why not also > virtualbox-guest-x11? I cannot answer that. But shouldn't some fallback work in any case? > So you're claiming that on the NET install we rely on vesa driver only? Feel > free to provide a Xorg.0.log for a 13.2 NET-install. I didn't. I only claimed that vboxvideo driver was missing and still the installer started in graphical mode... ;-) Attached the Xorg.0.log, it indeed (successfully) fell back to VESA. Instead of the VESA error, there's this now: (In reply to Stefan Dirsch from comment #7) > Ah. So xf86-video-modesetting is available? Why not also > virtualbox-guest-x11? I cannot answer that. But shouldn't some fallback work in any case? > So you're claiming that on the NET install we rely on vesa driver only? Feel > free to provide a Xorg.0.log for a 13.2 NET-install. I didn't. I only claimed that vboxvideo driver was missing and still the installer started in graphical mode... ;-) Attached the Xorg.0.log, it indeed (successfully) fell back to VESA. Instead of the VESA error, it contains this now: [ 226.503] (II) VESA(0): initializing int10 [ 226.509] (II) VESA(0): Primary V_BIOS segment is: 0xc000 [ 226.514] (II) VESA(0): VESA BIOS detected [ 226.514] (II) VESA(0): VESA VBE Version 2.0 [ 226.514] (II) VESA(0): VESA VBE Total Mem: 12288 kB [ 226.514] (II) VESA(0): VESA VBE OEM: VirtualBox VESA BIOS [ 226.514] (II) VESA(0): VESA VBE OEM Software Rev: 0.3 [ 226.514] (II) VESA(0): VESA VBE OEM Vendor: Oracle Corporation [ 226.514] (II) VESA(0): VESA VBE OEM Product: Oracle VM VirtualBox VBE Adapter [ 226.514] (II) VESA(0): VESA VBE OEM Product Rev: Oracle VM VirtualBox Version 4.3.28 > > I have exactly the same VESA error in the Xorg.0.log on the real hardware. > > You also need to disable kernel framebuffer for that. But this (just adding "nomodeset" to the boot options, or choosing "No KMS" from gfxboot's "F3 Video Mode" menu on non-UEFI systems) also worked in 13.2 and earlier I think. At least that's what we often suggested to people that couldn't run the installer because of graphical problems. And IMHO, this should still be possible as a relatively simple method to work-around graphics driver problems. > What's happening on machines running in UEFI mode? I guess fbdev X driver is > working there, right? I don't have any UEFI hardware here to test, sorry. Sorry for the mess in my previous comment, I hope it's still readable. (something went wrong with copy/paste... :-( ) Another thing I'd like to mention (not sure if it's relevant): Fallback to fbdev does work on an installed Tumbleweed system inside VirtualBox when I uninstall virtualbox-guest-x11, without specifying "vga=xxx" on the kernel command line. Haven't tried vesa yet, but can do if wanted. (In reply to Wolfgang Bauer from comment #8) > Instead of the VESA error, there's this now: > (In reply to Stefan Dirsch from comment #7) > > Ah. So xf86-video-modesetting is available? Why not also > > virtualbox-guest-x11? > > I cannot answer that. > But shouldn't some fallback work in any case? It would be preferrable, yes. > > So you're claiming that on the NET install we rely on vesa driver only? Feel > > free to provide a Xorg.0.log for a 13.2 NET-install. > > I didn't. I only claimed that vboxvideo driver was missing and still the > installer started in graphical mode... ;-) > > Attached the Xorg.0.log, it indeed (successfully) fell back to VESA. > > Instead of the VESA error, it contains this now: > [ 226.503] (II) VESA(0): initializing int10 > [ 226.509] (II) VESA(0): Primary V_BIOS segment is: 0xc000 > [ 226.514] (II) VESA(0): VESA BIOS detected > [ 226.514] (II) VESA(0): VESA VBE Version 2.0 > [ 226.514] (II) VESA(0): VESA VBE Total Mem: 12288 kB > [ 226.514] (II) VESA(0): VESA VBE OEM: VirtualBox VESA BIOS > [ 226.514] (II) VESA(0): VESA VBE OEM Software Rev: 0.3 > [ 226.514] (II) VESA(0): VESA VBE OEM Vendor: Oracle Corporation > [ 226.514] (II) VESA(0): VESA VBE OEM Product: Oracle VM VirtualBox VBE > Adapter > [ 226.514] (II) VESA(0): VESA VBE OEM Product Rev: Oracle VM VirtualBox > Version 4.3.28 Ok. Then this smells like a regression in vesa X driver. Unfortunately I don't see a single change in vesa driver between openSUSE 13.2 and factory/tumbleweed. :-( Could you provide the complete X logfile for openSUSE 13.2 installation, please? Could be that a submodule, which gets loaded by vesa driver itself got changed and could explain the change in behaviour. > > > I have exactly the same VESA error in the Xorg.0.log on the real hardware. > > > > You also need to disable kernel framebuffer for that. > > But this (just adding "nomodeset" to the boot options, or choosing "No KMS" > from gfxboot's "F3 Video Mode" menu on non-UEFI systems) also worked in 13.2 > and earlier I think. At least that's what we often suggested to people that > couldn't run the installer because of graphical problems. I'm talking about generic kernel framebuffer (available via the vga=0xXXX option), not drmfb of KMS drivers. > And IMHO, this should still be possible as a relatively simple method to > work-around graphics driver problems. It's independant of KMS fb. See above. KMS's drmfb just replaces the generic kernel fb. > > What's happening on machines running in UEFI mode? I guess fbdev X driver is > > working there, right? > > I don't have any UEFI hardware here to test, sorry. I see. (In reply to Stefan Dirsch from comment #10) > Could you provide the complete X logfile for > openSUSE 13.2 installation, please? I did attach it already: https://bugzilla.suse.com/attachment.cgi?id=636000 That was after booting the installer inside VirtualBox and aborting the installation on the (graphical) license screen. Or do you mean a log file from an installed 13.2 system? In that case, does one from real hardware suffice, or should I do an installation inside VirtualBox? And should it be using vesa (I suppose so), or does that not matter? I mean the logfile from openSUSE 13.2 - using vesa driver. Real hardware is fine. Created attachment 636025 [details]
Xorg 0 log using vesa from 13.2 installed system
Ok, this one is from an up-to-date 13.2 system (radeon graphics), booting with nomodeset after uninstalling xf86-video-fbdev, i.e. using vesa.
Just for the record, booting the Tumbleweed VirtualBox VM with vesa results in Xorg not starting with the same error ("Cannot read int vec") in the Xorg log.
Thanks. Submodules being loaded by vesa are ibvbe.so and libint10.so. I need to reproduce and debug the issue. Upstream commit 0a78b599b34cc8b5fe6fe82f90e90234e8ab7a56 to the xserver fixes this. SubmitReq to Factory: ID: 309268 This is an autogenerated message for OBS integration: This bug (932319) was mentioned in https://build.opensuse.org/request/show/309268 Factory / xorg-x11-server (In reply to Egbert Eich from comment #16) > SubmitReq to Factory: ID: 309268 I installed the new xorg-x11-server package from X11:XOrg to my VirtualBox Tumbleweed VM, and can confirm that Xorg starts now using the vesa driver. So I'd expect the graphical installer to work fine again too after this has been accepted to Factory... Thank you! I tried openSUSE-Tumbleweed-NET-x86_64-Snapshot20150610-Media.iso and can confirm that the bug is fixed. Thanks |