Hello, Upgarding to latest Xorg (6.7.0) from FreeBSD ports breaks the i810 display on HP d530 series workstations. The previous installed version of X11R6 4.3.0 worked perfectly on the same hardware. The problem persists on X4.4 also. [buffy] ~> pciconf -lv | less agp0@pci0:2:0: class=0x030000 card=0x00b90e11 chip=0x25628086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82845G/GL/GV/GE/PE Integrated Graphics Device' class = display subclass = VGA uhci0@pci0:29:0: class=0x0c0300 card=0x00b90e11 chip=0x24c28086 rev=0x01 % startx ... (WW) ****INVALID IO ALLOCATION**** b: 0x14e0 e: 0x14e7 correcting (EE) I810(0): No Video BIOS modes for chosen depth. (EE) Screen(s) found, but none have a usable configuration. More people having the same problem on HP hardware: http://lists.freebsd.org/pipermail/freebsd-x11/2004-September/000868.html http://www.netsys.com/openbsd-misc/2004/09/msg00189.html
Have you tried upgrading to 6.8.x ? Especially 6.8.2 which has just been released ?
(In reply to comment #1) > Have you tried upgrading to 6.8.x ? > Especially 6.8.2 which has just been released ? The bug is present in both 6.8.1 and 6.8.2. So as I'm using the same computer model as Shanker, I now run a rather peculiar setup with xorg for everything except server. That job goes to XFree86.
Can you post a log with 6.8.2 then ?
You also might want to try adding this to your Device section Option "MonitorLayout" "CRT,NONE"
(In reply to comment #3) > Can you post a log with 6.8.2 then ? Exact same output as in the original bug post. Adding Option "MonitorLayout" "CRT,NONE" to the Device section didn't seem to make any difference either.
I'd of expected some different output with that option, but if not..... It looks like a serious enough bug in HP's Video BIOS that we can't use it and it's unlikely to get fixed in the driver. I'd contact HP and tell them about the problem.
(In reply to comment #6) > I'd of expected some different output with that option, but if not..... > It looks like a serious enough bug in HP's Video BIOS that we can't use it and > it's unlikely to get fixed in the driver. I'd contact HP and tell them about the > problem. Still, why does it work perfectly in XFree86 4.3? I just can't grok the logic of it not working in xorg and xfree86 4.4 if it actually worked just fine at one point... it shouldn't be an impossible thing to fix then should it?
Ah, I missed that it worked in 4.3.0. Can you try this driver ... http://www.fairlite.demon.co.uk/intel.html and let me know if it fixes it.
You also might want to try Option "DisplayInfo" "False"
(In reply to comment #8) > Ah, I missed that it worked in 4.3.0. > Can you try this driver ... > http://www.fairlite.demon.co.uk/intel.html > and let me know if it fixes it. Didn't seem to do the trick, neither that option. I tried both that driver and the one that came with xf86 4.3 (And verified that it actually tried using it), neither worked. I noticed something else interesting, I had the default depth to 24 bit, but my i810 doesn't support 24 bit (only 8,16,32). However, changing my depth to 16 bit did not make any difference wrt the error message outputted. The i810 driver actually lists the available modes and the mode I have selected is listed, so this is weird.
So you are saying that 4.3 driver didn't work now ? I could really use a log from the time you tried with the new driver.
(In reply to comment #11) > So you are saying that 4.3 driver didn't work now ? > I could really use a log from the time you tried with the new driver. The log using the driver you pointed to is at http://www.debolaz.com/temp/Xorg.0.log.txt using the configuration file http://www.debolaz.com/temp/xorg.conf.txt
Note: XFree86 4.3 still works just fine, just not the i810 driver when copied to xorg 6.8.2.
I'm afraid that's not with the driver from the website, as the version is wrong. Make sure you are installing the driver in /usr/X11R6/lib/modules/drivers and post a new log.
(In reply to comment #14) > I'm afraid that's not with the driver from the website, as the version is wrong. > Make sure you are installing the driver in > /usr/X11R6/lib/modules/drivers > and post a new log. Sorrz, indeed an old driver. New log out at same url.
This sounds like a bug introduced in the VBE module... If you've got the modules from 4.3 hanging around, try copying libvbe.a from 4.3 to /usr/X11R6/lib/modules to replace the one in X.Org 6.8.x and see if that helps.
(In reply to comment #16) > This sounds like a bug introduced in the VBE module... > If you've got the modules from 4.3 hanging around, try copying libvbe.a from 4.3 > to /usr/X11R6/lib/modules to replace the one in X.Org 6.8.x and see if that helps. Same results as far as I can tell, log at http://www.debolaz.com/temp/Xorg.0.log.libvbe430.txt
O.k. Try shutting down the machine first, and then trying again but leave the new driver in.
(In reply to comment #18) > O.k. Try shutting down the machine first, and then trying again but leave the > new driver in. Same results after rebooting the machine (Using i810_drv.o from the website and libvbe.a from xf86 4.3)
Can you get me a log of it working with 4.3 ?
(In reply to comment #20) > Can you get me a log of it working with 4.3 ? http://www.debolaz.com/temp/XFree86.0.log.txt
Config file for XFree86 4.3.0 at http://www.debolaz.com/temp/XF86Config.txt
I've uploaded a fresh driver to the website v1.5.7 - can you try that ?
(In reply to comment #23) > I've uploaded a fresh driver to the website v1.5.7 - can you try that ? Results at http://www.debolaz.com/temp/Xorg.0.log.newdriver.txt
Driver version 1.5.8 is up - try that. Does XFree86 4.3 work even after X.Org fails without a reboot ?
(In reply to comment #25) > Driver version 1.5.8 is up - try that. > Does XFree86 4.3 work even after X.Org fails without a reboot ? Results at http://www.debolaz.com/temp/Xorg.0.log.newdriver.txt and yes, XFree86 4.3 worked fine without a reboot.
Can you now move the file /usr/X11R6/lib/modules/linux/libint10.a out of the way, say into /root and then start X again. Does that change anything ?
(In reply to comment #27) > Can you now move the file > /usr/X11R6/lib/modules/linux/libint10.a > out of the way, say into /root and then start X again. Does that change anything ? Seems to bail out when it can't find it, results at http://www.debolaz.com/temp/Xorg.0.log.noint10.txt
O.k. Put that back. I didn't realize that you are running FreeBSD. Driver 1.5.9 is up. try that.
(In reply to comment #29) > O.k. Put that back. I didn't realize that you are running FreeBSD. > Driver 1.5.9 is up. try that. Didn't work. Updated http://www.debolaz.com/temp/Xorg.0.log.newdriver.txt though not much new content. :/
Hang on a minute. Can you remove the line that says.... VideoRam 8192 in your Xorg config file.
(In reply to comment #31) > Hang on a minute. > Can you remove the line that says.... > VideoRam 8192 > in your Xorg config file. Didn't work, results in newdriver.txt and updated xorg.conf in xorg.conf.txt.
If you don't mind the lag, I can make an ssh tunnel for my machine and give you root on it so you can experiment yourself.
Maybe a little later tonight, I've got to go out for a couple of hours soon. Email me the details though. In the meantime.... Try using libint10.a from XFree86 4.3 If the XFree86 4.3 driver doesn't work in the X.Org 6.8.x enviroment, I'm not sure it's a driver fault.
(In reply to comment #34) > Maybe a little later tonight, I've got to go out for a couple of hours soon. > Email me the details though. > In the meantime.... > Try using libint10.a from XFree86 4.3 > If the XFree86 4.3 driver doesn't work in the X.Org 6.8.x enviroment, I'm not > sure it's a driver fault. I actually tried replacing every video driver mentioned in Xorg.0.log with the corresponding driver from XFree86 4.3.0, it did not make any difference. As for the i810 driver not being responsible, the fact that the XFree86 4.3.0 driver didn't work in the first place would suggest that. I didn't try xorg 6.8.2 driver on XFree86 4.3.0 would be interesting but I haven't got the time to try it right now. I suspect that'd work just fine though, so how to resolve this if the driver is not at fault?
Turns out to be a bug in the PCI validation code. Sent an email with details to Egbert to take a closer look.
I would like to take a closer look. Could you please provide two things? 1. Output of 'scanpci -v' 2. add the line #define DEBUG at the top of xc/programs/Xserver/hw/xfree86/common/xf86pciBus.c rebuild the file, relink the Xserver run it and attach the log file.
Created attachment 1993 [details] scanpci output sent by user
Created attachment 1994 [details] Xserver log file sent by user
Created attachment 1995 [details] [review] Patch to add some more debug output
Created attachment 1998 [details] [review] Possible fix Please try the following patch.
(In reply to comment #41) > Created an attachment (id=1998) [edit] > Possible fix > Please try the following patch. Good day! xorg start successful. Thenks you!
As it's been confirmed that the patch solves the problem I will commit it ASAP.
Created attachment 2006 [details] [review] Nicer solution.
I think this can be applied now Egbert. I've had two people confirm it's good.
*** This bug has been marked as a duplicate of 2963 ***
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.