| Summary: | Driver 0.4.0 crashes with recent linux kernel version | ||
|---|---|---|---|
| Product: | xorg | Reporter: | Tolsti <abc12345678900> |
| Component: | Driver/openchrome | Assignee: | Openchrome development list <openchrome-devel> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | andyrtr, kevinbrace, xavier |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | |||
Created attachment 123768 [details]
logfile for kern 4.5.1
Hi Torsten, I looked at the log files, and I do see something weird. Here is the Xorg.0.log with Linux kernel 4.4.5. ____________________________________________________________ . . . [ 11.364] (II) CHROME(0): VIAMapMMIO [ 11.364] (--) CHROME(0): mapping MMIO @ 0xfb000000 with size 0xd000 [ 11.364] (--) CHROME(0): mapping BitBlt MMIO @ 0xfb200000 with size 0x200000 [ 11.364] (II) CHROME(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0 [ 11.364] (II) CHROME(0): VIAMapFB [ 11.364] (--) CHROME(0): mapping framebuffer @ 0xf0000000 with size 0x4000000 [ 11.364] (--) CHROME(0): Frame buffer start: 0x7f2bc12cb000, free start: 0x0 end: 0x4000000 [ 11.364] (II) CHROME(0): Creating default Display subsection in Screen section . . . ____________________________________________________________ Here is the Xorg.0.log with Linux kernel 4.5.1. ____________________________________________________________ . . . [ 354.283] (II) CHROME(0): VIAMapMMIO [ 354.283] (--) CHROME(0): mapping MMIO @ 0xfb000000 with size 0xd000 [ 354.283] (--) CHROME(0): mapping BitBlt MMIO @ 0xfb200000 with size 0x200000 [ 354.283] (II) CHROME(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0 [ 354.283] (II) CHROME(0): VIAMapFB [ 354.283] (--) CHROME(0): mapping framebuffer @ 0xf0000000 with size 0x4000000 [ 354.284] (EE) CHROME(0): Unable to map mmio BAR. Invalid argument (22) [ 354.284] (II) CHROME(0): VIAFreeRec [ 354.284] (II) CHROME(0): Entered VIAUnmapMMIO. [ 354.284] (II) CHROME(0): Exiting VIAUnmapMMIO. [ 354.284] (II) CHROME(0): VIAFreeScreen [ 354.284] (II) CHROME(0): VIAFreeRec [ 354.284] (EE) [ 354.284] (EE) Backtrace: [ 354.284] (EE) 0: /usr/lib/xorg-server/Xorg (OsLookupColor+0x139) [0x594d49] [ 354.285] (EE) 1: /usr/lib/libc.so.6 (__restore_rt+0x0) [0x7fa7fb6eb32f] [ 354.286] (EE) 2: /usr/lib/xorg/modules/drivers/openchrome_drv.so (_init+0xd0fe) [0x7fa7f65c4fde] [ 354.286] (EE) 3: /usr/lib/xorg-server/Xorg (xf86DeleteScreen+0x5a) [0x480c2a] [ 354.286] (EE) 4: /usr/lib/xorg-server/Xorg (InitOutput+0xcdb) [0x47b29b] [ 354.287] (EE) 5: /usr/lib/xorg-server/Xorg (remove_fs_handlers+0x264) [0x43a074] [ 354.288] (EE) 6: /usr/lib/libc.so.6 (__libc_start_main+0xf0) [0x7fa7fb6d8710] [ 354.288] (EE) 7: /usr/lib/xorg-server/Xorg (_start+0x29) [0x424589] [ 354.289] (EE) 8: ? (?+0x29) [0x29] [ 354.289] (EE) [ 354.289] (EE) Segmentation fault at address 0xa4 [ 354.289] (EE) . . . ____________________________________________________________ I do not recall the exact commit that fixed the above segmentation fault, but it could have been this one. https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/?id=c6fd0017eeafc796124437e7bfc9906433b3f28a However, before the segmentation fault, there is an error. ____________________________________________________________ . . . [ 354.284] (EE) CHROME(0): Unable to map mmio BAR. Invalid argument (22) . . . ____________________________________________________________ This is the code that likely tripped up OpenChrome. ____________________________________________________________________________ . . . err = pci_device_map_range(pVia->PciInfo, pVia->FrameBufferBase, pVia->videoRambytes, (PCI_DEV_MAP_FLAG_WRITABLE | PCI_DEV_MAP_FLAG_WRITE_COMBINE), (void **)&pVia->FBBase); if (err) { xf86DrvMsg(pScrn->scrnIndex, X_ERROR, "Unable to map mmio BAR. %s (%d)\n", strerror(err), err); return FALSE; } . . . ____________________________________________________________________________ It appears that pci_device_map_range API's arguments or behavior has changed. I probably should not say that OpenChrome is not responsible for it, but I feel like this is a Linux kernel or libpciaccess problem (bug). I still got both the FB mapping error and a segfault with latest git (0.4.176) and kernel 4.5.6. while everything works with kernel 4.4.9. Fully updated Fedora 23 with VIA Epia-M (CLE266). [ 118.791] (II) CHROME(0): Entered viaMapFB. [ 118.791] (--) CHROME(0): Mapping a frame buffer at address 0xd8000000 with size 0x4000000. [ 118.793] (EE) CHROME(0): Unable to map a frame buffer. Error: Invalid argument (22) [ 118.793] (II) CHROME(0): Exiting viaMapFB. [ 118.793] (II) CHROME(0): VIAFreeRec [ 118.793] (II) CHROME(0): Entered viaUnmapMMIO. [ 118.793] (II) CHROME(0): Entered viaMMIODisable. [ 118.793] (II) CHROME(0): Exiting viaMMIODisable. [ 118.793] (II) CHROME(0): Exiting viaUnmapMMIO. [ 118.793] (II) CHROME(0): VIAFreeScreen [ 118.793] (II) CHROME(0): VIAFreeRec [ 118.793] (EE) [ 118.793] (EE) Backtrace: [ 118.797] (EE) 0: /usr/libexec/Xorg (OsLookupColor+0x146) [0x81fb606] [ 118.803] (EE) 1: ? (?+0x146) [0xb76e0ec1] [ 118.806] (EE) 2: /usr/lib/xorg/modules/drivers/openchrome_drv.so (VIAFreeScreen+0x33) [0xb690ae23] [ 118.810] (EE) 3: /usr/libexec/Xorg (xf86DeleteScreen+0x67) [0x80cb197] [ 118.812] (EE) 4: /usr/libexec/Xorg (InitOutput+0xdfa) [0x80c522a] [ 118.816] (EE) 5: /usr/libexec/Xorg (remove_fs_handlers+0x31a) [0x807e74a] [ 118.819] (EE) 6: /usr/libexec/Xorg (miPolyFillRect+0x2da) [0x8066f8a] [ 118.829] (EE) 7: /lib/libc.so.6 (__libc_start_main+0xf5) [0xb705d545] [ 118.831] (EE) 8: /usr/libexec/Xorg (_start+0x21) [0x8066d26] [ 118.833] (EE) [ 118.833] (EE) Segmentation fault at address 0x10c (In reply to Xavier Bachelot from comment #3) Hi Xavier, > I still got both the FB mapping error and a segfault with latest git > (0.4.176) and kernel 4.5.6. while everything works with kernel 4.4.9. Fully > updated Fedora 23 with VIA Epia-M (CLE266). > > [ 118.791] (II) CHROME(0): Entered viaMapFB. > [ 118.791] (--) CHROME(0): Mapping a frame buffer at address 0xd8000000 > with size 0x4000000. > [ 118.793] (EE) CHROME(0): Unable to map a frame buffer. > Error: Invalid argument (22) > [ 118.793] (II) CHROME(0): Exiting viaMapFB. > [ 118.793] (II) CHROME(0): VIAFreeRec > [ 118.793] (II) CHROME(0): Entered viaUnmapMMIO. > [ 118.793] (II) CHROME(0): Entered viaMMIODisable. > [ 118.793] (II) CHROME(0): Exiting viaMMIODisable. > [ 118.793] (II) CHROME(0): Exiting viaUnmapMMIO. > [ 118.793] (II) CHROME(0): VIAFreeScreen > [ 118.793] (II) CHROME(0): VIAFreeRec > [ 118.793] (EE) > [ 118.793] (EE) Backtrace: > [ 118.797] (EE) 0: /usr/libexec/Xorg (OsLookupColor+0x146) [0x81fb606] > [ 118.803] (EE) 1: ? (?+0x146) [0xb76e0ec1] > [ 118.806] (EE) 2: /usr/lib/xorg/modules/drivers/openchrome_drv.so > (VIAFreeScreen+0x33) [0xb690ae23] > [ 118.810] (EE) 3: /usr/libexec/Xorg (xf86DeleteScreen+0x67) [0x80cb197] > [ 118.812] (EE) 4: /usr/libexec/Xorg (InitOutput+0xdfa) [0x80c522a] > [ 118.816] (EE) 5: /usr/libexec/Xorg (remove_fs_handlers+0x31a) [0x807e74a] > [ 118.819] (EE) 6: /usr/libexec/Xorg (miPolyFillRect+0x2da) [0x8066f8a] > [ 118.829] (EE) 7: /lib/libc.so.6 (__libc_start_main+0xf5) [0xb705d545] > [ 118.831] (EE) 8: /usr/libexec/Xorg (_start+0x21) [0x8066d26] > [ 118.833] (EE) > [ 118.833] (EE) Segmentation fault at address 0x10c I have not fundamentally changed the code from the older version to the newer one. As I may have said in another reply for this subject, is this Linux kernel or libpciaccess problem? Perhaps, you can remove PCI_DEV_MAP_FLAG_WRITE_COMBINE to see if it helps. > I have not fundamentally changed the code from the older version to the > newer one. > As I may have said in another reply for this subject, is this Linux kernel > or libpciaccess problem? fwiw, just switching from linux 4.4 to linux 4.5 triggers the failure. libpciaccess has not been changed, nor openchrome. This might as well be a behaviour of the driver that was tolerated before but is not anymore and thus might warrant a fix on our side ? While looking around the net for issues with pci_device_map_range, I've read about something similar in mga driver which was mapping 2 crtc to the same fb for clone mode. This worked for a time but then the driver needed to be fixed. This was circa 2010 iirc, so might be something different... https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-mga/+bug/292214/comments/8 > Perhaps, you can remove PCI_DEV_MAP_FLAG_WRITE_COMBINE to see if it helps. I've tried that, it didn't help. (In reply to Xavier Bachelot from comment #5) Hi Xavier, > > > fwiw, just switching from linux 4.4 to linux 4.5 triggers the failure. > libpciaccess has not been changed, nor openchrome. > > This might as well be a behaviour of the driver that was tolerated before > but is not anymore and thus might warrant a fix on our side ? While looking > around the net for issues with pci_device_map_range, I've read about > something similar in mga driver which was mapping 2 crtc to the same fb for > clone mode. This worked for a time but then the driver needed to be fixed. > This was circa 2010 iirc, so might be something different... > https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-mga/+bug/292214/ > comments/8 > > > I've tried that, it didn't help. I am not sure what can be done at this point. At least, it does not appears to be an issue of address double mapping unlike the other situations you have pointed (with Matrox). I really hate to see this bug to be a blocker for Version 0.5. Hi Xavier, Please try the latest OpenChrome Version 0.4.178. I will like to see if the crash pattern (i.e., segmentation fault) change. The code prior to 0.4.178 was calling VIAFreeRec function twice, and that was discontinued. I will like to see if the X server will at least gracefully stop the DDX loading process rather than having a segmentation fault. After that, I will upload a patch you can apply against Version 0.4.178. The updated code, at least with my computer, doesn't cause problems. Hi Xavier, Calling VIAFreeRec function was leading to a segmentation fault. This is not good. The bug itself it a separate issue. Error handling code is very hard to reproduce, so I will like to fix that one before trying to fix the FB memory allocation bug with Linux 4.5 kernel. Hi Kevin, I agree, testing error path is hard. I guess the FB mapping error path was never exercised, so the segfault was not seen before the other bug with kernel/libpciaccess/openchrome was triggered. Anyway, I've tested 0.4.178, it still segfaults although the second call to viaFreeRec is not logged anymore. [ 137.149] (--) CHROME(0): Probed amount of VideoRAM = 65536 kB [ 137.149] (II) CHROME(0): Entered viaMapMMIO. [ 137.151] (--) CHROME(0): Mapping MMIO at address 0xdc000000 with size 0xd000. [ 137.151] (--) CHROME(0): Mapping 2D Host BitBLT space at address 0xdc200000 with size 0x200000. [ 137.151] (II) CHROME(0): Entered viaMMIOEnable. [ 137.151] (II) CHROME(0): Exiting viaMMIOEnable. [ 137.151] (II) CHROME(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0 [ 137.151] (II) CHROME(0): Exiting viaMapMMIO. [ 137.151] (II) CHROME(0): Entered viaMapFB. [ 137.153] (--) CHROME(0): Mapping a frame buffer at address 0xd8000000 with size 0x4000000. [ 137.153] (EE) CHROME(0): Unable to map a frame buffer. Error: Invalid argument (22) [ 137.153] (II) CHROME(0): Exiting viaMapFB. [ 137.153] (II) CHROME(0): VIAFreeRec [ 137.153] (II) CHROME(0): Entered viaUnmapMMIO. [ 137.153] (II) CHROME(0): Entered viaMMIODisable. [ 137.153] (II) CHROME(0): Exiting viaMMIODisable. [ 137.153] (II) CHROME(0): Exiting viaUnmapMMIO. [ 137.155] (II) CHROME(0): VIAFreeScreen [ 137.155] (EE) [ 137.155] (EE) Backtrace: [ 137.160] (EE) 0: /usr/libexec/Xorg (OsLookupColor+0x146) [0x81fb606] [ 137.165] (EE) 1: ? (?+0x146) [0xb76ffec1] [ 137.169] (EE) 2: /usr/lib/xorg/modules/drivers/openchrome_drv.so (VIAFreeScreen+0x2c) [0xb6929e1c] [ 137.171] (EE) 3: /usr/libexec/Xorg (xf86DeleteScreen+0x67) [0x80cb197] [ 137.175] (EE) 4: /usr/libexec/Xorg (InitOutput+0xdfa) [0x80c522a] [ 137.187] (EE) 5: /usr/libexec/Xorg (remove_fs_handlers+0x31a) [0x807e74a] [ 137.199] (EE) 6: /usr/libexec/Xorg (miPolyFillRect+0x2da) [0x8066f8a] [ 137.222] (EE) 7: /lib/libc.so.6 (__libc_start_main+0xf5) [0xb707c545] [ 137.227] (EE) 8: /usr/libexec/Xorg (_start+0x21) [0x8066d26] [ 137.231] (EE) [ 137.231] (EE) Segmentation fault at address 0x10c Created attachment 124478 [details] [review] Proposed fix mapping FB first Hi Xavier, I will try to come up with a fix to fix that segmentation fault you are seeing, but in the meantime, I uploaded a proposed fix (it does not cause problems either way in my environment). Now FB is being mapped first before MMIOs are mapped. As far as I can tell, unlike the Matrox or SiS DDX situations, there is no memory map memory region overlap among the 3 memory maps used by OpenChrome. I have tried this, but the driver still crashes. I have also attached a new logfile. (In reply to Kevin Brace from comment #10) > Created attachment 124478 [details] [review] [review] > Proposed fix mapping FB first Created attachment 124484 [details]
logfile for patch 124478
Latest git + patch, same log here : [ 1484.833] (--) CHROME(0): Probed amount of VideoRAM = 65536 kB [ 1484.833] (II) CHROME(0): Entered viaMapFB. [ 1484.833] (--) CHROME(0): Mapping a frame buffer at address 0xd8000000 with size 0x4000000. [ 1484.833] (EE) CHROME(0): Unable to map a frame buffer. Error: Invalid argument (22) [ 1484.833] (II) CHROME(0): Exiting viaMapFB. [ 1484.833] (II) CHROME(0): VIAFreeRec [ 1484.833] (II) CHROME(0): Entered viaUnmapMMIO. [ 1484.833] (II) CHROME(0): Entered viaMMIODisable. [ 1484.833] (EE) [ 1484.835] (EE) Backtrace: [ 1484.837] (EE) 0: /usr/libexec/Xorg (OsLookupColor+0x146) [0x81fb606] [ 1484.843] (EE) 1: ? (?+0x146) [0xb76f7ec1] [ 1484.843] (EE) [ 1484.843] (EE) Segmentation fault at address 0x0 latest git + patch, but on kernel 4.4 : [ 75.795] (--) CHROME(0): Probed amount of VideoRAM = 65536 kB [ 75.795] (II) CHROME(0): Entered viaMapFB. [ 75.795] (--) CHROME(0): Mapping a frame buffer at address 0xd8000000 with size 0x4000000. [ 75.808] (--) CHROME(0): Frame buffer start address: 0xb29d6000, free start: 0x0 end: 0x4000000 [ 75.808] (II) CHROME(0): Exiting viaMapFB. [ 75.808] (II) CHROME(0): Entered viaMapMMIO. [ 75.808] (--) CHROME(0): Mapping MMIO at address 0xdc000000 with size 0xd000. [ 75.808] (--) CHROME(0): Mapping 2D Host BitBLT space at address 0xdc200000 with size 0x200000. [ 75.808] (II) CHROME(0): Entered viaMMIOEnable. [ 75.810] (II) CHROME(0): Exiting viaMMIOEnable. [ 75.810] (II) CHROME(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0 [ 75.810] (II) CHROME(0): Exiting viaMapMMIO. I think this bug will likely be a blocker for OpenChrome Version 0.5. If this bug is fixed, OpenChrome Version 0.4.x will be turned into Version 0.4.901 shortly. Version 0.4.901 will be RC2 (Release Candidate 2). I am looking at the size parameter of pci_device_map_range now, and maybe as an experiment, it can be provided with a hard coded numerical value. I will make a patch for it in the next few hours. Actually, is it possible to try out a smaller frame buffer option? Usually, this can be adjusted in the BIOS setup. I will like to try that first. Created attachment 124510 [details]
log-file for 16MB VideoRam
Hi,
I lowered the VideoRAM as much as possible, but nothing changed.
Hello, I also post my output from lspci -vvv for the vga controller: 01:00.0 VGA compatible controller: VIA Technologies, Inc. CN700/P4M800 Pro/P4M800 CE/VN800 Graphics [S3 UniChrome Pro] (rev 01) (prog-if 00 [VGA controller]) Subsystem: FIRST INTERNATIONAL Computer Inc Device 601a Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 64 (500ns min) Interrupt: pin A routed to IRQ 16 Region 0: Memory at f4000000 (32-bit, prefetchable) [size=64M] Region 1: Memory at fb000000 (32-bit, non-prefetchable) [size=16M] [virtual] Expansion ROM at fc000000 [disabled] [size=64K] Capabilities: [60] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [70] AGP version 3.0 Status: RQ=256 Iso- ArqSz=0 Cal=7 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3+ Rate=x4,x8 Command: RQ=8 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW- Rate=x8 Kernel driver in use: viafb Kernel modules: viafb Hi Torsten, Please try Version 0.4.186. I did make number of improvements to the error handling of the code. All the commits since Version 0.4.181 were made to fix the bug you have encountered. Error code paths rarely get exercised, so as a developer, I do find this to be a good opportunity to get that portion tested (and I am sorry for your inconvenience.). I am hoping that segmentation fault will no longer happen with the improvements I have made to the code (the previous code quality was pretty terrible), but I still think that it will not necessarily fix the bug. I will likely need to contact Linux kernel developers to get them to look into what is going on if Version 0.4.186 does not fix the bug. Also, I may need to look at dmesg since it is a memory mapping problem. Basically pci_device_map_range is telling the caller that the memory map was already mapped by someone. Created attachment 124529 [details]
dmesg output as you asked for
Created attachment 124530 [details]
new error logfile with latest git and kernel 4.6
Created attachment 124531 [details]
latest working log-file (just in case someone wants to look at it)
Hello Kevin, do not worry, I am a linux admin, so I do not mind helping with this problem (and helping to get my own linux at home running again). Your hint with the memory begin already mapped was pretty good: viafb was using it. So I disabled the video driver with the kernel parameter "video=vesa:off vga=normal" The driver is working fine again. (In reply to Tolsti from comment #25) Hi Torsten, > Hello Kevin, > > do not worry, I am a linux admin, so I do not mind helping with this problem > (and helping to get my own linux at home running again). > Your hint with the memory begin already mapped was pretty good: viafb was > using it. So I disabled the video driver with the kernel parameter > "video=vesa:off vga=normal" > The driver is working fine again. Okay, this basically exonerates OpenChrome, but it is still not nice having this problem. I will file a bug report with bugzilla.kernel.org regarding this bug in the next 24 hours. I saw this part of the dmesg that caught my attention. _______________________________________________________________________ . . . [ 1.656374] io scheduler deadline registered [ 1.656455] io scheduler cfq registered (default) [ 1.656657] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [ 1.656703] pciehp: PCI Express Hot Plug Controller Driver version: 0.4 [ 1.656730] vesafb: mode is 1280x800x32, linelength=5120, pages=0 [ 1.656733] vesafb: scrolling: redraw [ 1.656736] vesafb: Truecolor: size=0:8:8:8, shift=0:16:8:0 [ 1.656767] vesafb: framebuffer at 0xf4000000, mapped to 0xffffc90000400000, using 4032k, total 4032k [ 1.711655] Console: switching to colour frame buffer device 160x50 [ 1.766240] fb0: VESA VGA frame buffer device [ 1.766341] GHES: HEST is not enabled! [ 1.766508] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled [ 1.787091] 00:04: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A [ 1.787657] Linux agpgart interface v0.103 . . . _______________________________________________________________________ You are right. VESA FB device driver is claiming address 0xf4000000. This is the same address OpenChrome will try to claim later on. _______________________________________________________________________ . . . [ 15.506] (II) Module vgahw: vendor="X.Org Foundation" [ 15.507] compiled for 1.18.3, module version = 0.1.0 [ 15.507] ABI class: X.Org Video Driver, version 20.0 [ 15.507] (--) CHROME(0): Probed amount of VideoRAM = 16384 kB [ 15.507] (II) CHROME(0): Entered viaMapMMIO. [ 15.507] (--) CHROME(0): Mapping MMIO at address 0xFB000000 with size 52 KB. [ 15.507] (--) CHROME(0): Mapping 2D Host BitBLT space at address 0xFB200000 with size 2048 KB. [ 15.507] (--) CHROME(0): Mapping the frame buffer at address 0xF4000000 with size 16384 KB. [ 15.507] (EE) CHROME(0): Unable to map the frame buffer. Error: Invalid argument (22) [ 15.507] (II) CHROME(0): Exiting viaMapMMIO. [ 15.507] (II) CHROME(0): VIAFreeRec [ 15.507] (II) CHROME(0): VIAFreeScreen [ 15.507] (II) UnloadModule: "openchrome" [ 15.507] (II) UnloadSubModule: "vgahw" [ 15.507] (II) Unloading vgahw [ 15.507] (EE) Screen(s) found, but none have a usable configuration. [ 15.507] (EE) Fatal server error: [ 15.507] (EE) no screens found(EE) [ 15.507] (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. [ 15.507] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information. [ 15.507] (EE) [ 15.528] (EE) Server terminated with error (1). Closing log file. _______________________________________________________________________ For now, if you wanted to use OpenChrome with Linux 4.5 or later, please disable VESA frame buffer device driver. One "good" thing about this bug you reported is that it allowed issues with the DDX error handling code to be exercised. I do go into this issue all the time, but I took over the development of this project only this February, and I think it is fair to say that previous developers did not really think through when they wrote many portions of the code, particularly DDX and display controller initialization. I have been spending a lot of time cleaning up the code so that it is more readable and maintainable. I knew I had to eventually clean up the portions of the code that caused all the segmentation faults, however, most of the time the old code did not cause issues, so it was assigned to be a low priority item. It appears that segmentation fault is no longer happening, and that is what I want. This bug is interesting since there was a report of OpenChrome not booting if viafb was not loaded (Bug 94797). This person was using Linux 4.4 kernel. The bug is still open, and I plan to contact this person for more testing. Anyway, I will move the bug report to bugzilla.kernel.org very soon, and deal with it over there. Now that OpenChrome is exonerated, I will turn the latest OpenChrome into Version 0.5 RC2 (Release Candidate 2) in the next few days. Hi Torsten, I just filed a bug report with Linux kernel developers. https://bugzilla.kernel.org/show_bug.cgi?id=120281 You may have to help them fix the bug as well. Just to let you know, it often takes weeks to months to fix just one bug, and when you first filed the bug report, I was not really able to concentrate on your bug since I was trying to fix other bugs of OpenChrome that were a lot serious. https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/?id=21ae2b4c3c02812a69e9162791c6db2e6ec36842 That version (Version 0.4.158) fixed the longstanding bug with runtime screen resolution change, and also, that was the hardest bug so far for me to find the solutions to it. Furthermore, I wanted to implement the initial support for those that have VT1632A DVI chip, and this was achieved with Version 0.4.179. https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/?id=b57d2f95275f6ef0db098773a48b1cfbb442acac Often times, it takes tremendous amount of intellectual concentration to fix just one bug, and in many cases, the bugs were mainly created the previous developers who did not test their code adequately. Both of those 2 bugs fit this category. Anyway, I will stay on this bug until it is fixed, but in the meantime, I will start making the final preparation for OpenChrome Version 0.5 RC2. I will keep the bug open until Linux kernel developers do something about it. Hello Kevin, thanks for your effort. I have updated my driver to the 0.5RC, and it is working fine. Torsten. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 123767 [details] logfile for kern 4.4.5 Hello everybody, I am using arch-linux and came across the following problem: After updating to kernel 4.5.1 the X-server does not start. When I downgrade to kernel 4.4.5 all is fine again. I have attached two logfiles for the two kernel versions. Please let me know if I can help with anything. Torsten.