|
Description
Jan Girlich
2005-04-22 10:12:34 UTC
Created attachment 2513 [details]
[1] dual-monitor-conf
Created attachment 2514 [details]
[2] Xorg.0.log
Created attachment 2515 [details]
[3] single-monitor-conf
Can you try replacing the libint10.a in /usr/X11R6/lib/modules/linux/ with the one from 6.8.2 ? And retry ? It seems not to change anything. I copied /usr/X11R6/lib/modules/linux/libint10.a from xorg-x11-6.8.2-r1 (gentoo ebuild which works for me with dual-monitor-setup) to /usr/lib/modules/linux/libint10.a, changed the config to dual-monitor-setup [1] and rebooted the laptop to be sure no strange effects interfere. This [4] is the Xorg.0.log, which I think is exactly the same output. Created attachment 2519 [details]
Xorg.0.log with libint10.a from xorg-6.8.2
O.k. Can you try the driver from http://www.fairlite.demon.co.uk/intel.html ? Okay, I used the original libint10.a from 6.8.99.3 and my dual-monitor-config. But the error still exists and there are no big changes, so I made a diff to the old logfile to see the differences: thinkpad ~ # diff Xorg.0.log.20050421 /var/log/Xorg.0.log 0a1 > 20c21 < (==) Log file: "/var/log/Xorg.0.log", Time: Sat Apr 23 13:13:00 2005 --- > (==) Log file: "/var/log/Xorg.0.log", Time: Sun Apr 24 23:12:43 2005 328c329 < compiled for 6.8.99.3, module version = 1.3.0 --- > compiled for 6.8.99.3, module version = 1.5.70 346c347,348 < i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G, 915GM --- > i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G, E7221 (i915), > 915GM 434a437 > (II) I810(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000 470a474 > (II) I810(1): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000 516d519 < Can you post the log from 6.8.2 ? Also, Can you try reversing the patch in bug 2880 in your CVS checkout and try again ? You'll need to rebuild the Xserver. Created attachment 2537 [details] xorg-6.8.2 with dual-monitor-config This works fine for me. I'll try to compile the CVS-version with reversed patch from bug #2880, but this will take some time because I never did CVS-checkout etc with xorg before. Try loading the 6.8.2 i810 driver (i810_drv.o) with the 6.8.99.3 installation. Does that help, as I don't think this has anything to do with the i810 driver at all. Using the 6.8.2's i810_drv.o with xorg-6.8.99.3 works for me! I'm sorry but it seems to me like it has to do something with the driver, right? ;) I attached the Xorg.0.log Created attachment 2544 [details]
xorg-6.8.99.3 with i810_drv.o from 6.8.2 and dual-monitor-conf
I'm still not convinced it's the driver. Can you try 6.8.2 with the i810_drv from 6.8.99.3 ?? Created attachment 2566 [details]
xorg-6.8.2 with i810_drv.0 from 6.8.99.3 and dual
Well, I'm sorry :)
Do you still want me to test an up-to-date CVS-checkout? If so, I will do so
probably tomorrow.
I think it's definately worth it. Because the point at which it's crashing is so very close to the start of the driver that it hasn't changed between 6.8.2 and 6.8.99.3. It might also be kernel related. As I can see that you are using 2.6.12-rc2 with the problem, but 2.6.12-rc3 which works. Try 6.8.99.3 on the 2.6.12-rc3 kernel. Did you get chance to try my suggestions ? FYI Jan, I just stuck the 6.8.99.5 snapshot into portage. Soryy, I'm busy right now. But I will have some time the next days, so I will try different kernels (2.6.12-rc2, 2.6.12-rc3 and maybe 2.6.10) and xorg-6.8.99.5. I tested xorg 6.8.99.5 with exactly the same results. Today I will test the different kernels. Jan And the results with the kernel ? Sorry for the long delay... I tried the following kernels: vanilla 2.6.12-rc2 vanilla 2.6.12-rc3 vanilla 2.6.12-rc4 where there is no difference in using i810_drv.o from your website, xorg-6.8.2-r2, xorg-6.8.99.3 or xorg-6.8.99.5 The error is always the same, like described above. And I also tested gentoo 2.6.10-r6 gentoo 2.6.9-r13 with xorg-6.8.99.5 with no success. I am going to try to revert to the last state when it worked which was: vanilla 2.6.12-rc2 xorg-6.8.2-r1 Jan Maybe I'm misunderstanding something, but are you saying that you can simply switch between Gentoo xorg 6.8.2-r1 and 6.8.2-r2 and that fixes/breaks it, while retaining the same kernel, i810_drv.o, and everything else? If so, that narrows things down to a very small number of patches I pulled from Xorg CVS HEAD. No, I'm sorry, I just tested 6.8.2-r2 to be sure, but it works there, too. So it works in every version <=6.8.2-r2 and in no version above that. So this bug is Gentoo specific ?? No, I think we just eliminated that option. I'm confused. He said it works in <=6.8.2-r2 but no version above that. I'm under the impression that the -r2 (or any postfix like this) is from gentoo ?? So why isn't it Gentoo specific ? Does it work with X.Org's 6.8.2 release without any of the -r1, -r2 or -r<anything> ?? You are entirely right that -rX is a Gentoo suffix. The context you're missing is that -r1 and -r2 are the only available revisions of 6.8.2. We also have snapshots of 6.8.99.5 and 6.8.99.8, and I'll probably add next week's snapshot as well. O.k. It might be worth adding 6.8.99.1 and 6.8.99.2 etc up to 6.8.99.5 so that we can zoom in on what caused it. OK, I'll look into that early next week. I'm just heading out for a trip this evening. Created attachment 2945 [details] [review] patch Here's an ebuild for 6.8.99.1. To "port" to other versions, simply copy the ebuild to the new version number, and do the same in /usr/portage/distfiles for the patchset and fileset. Happens on my ThinkPad X40 as well, but it's now thoughtfully dead. Sigh. Having talked to Jan offline and sent a debug Xserver that I built. It doesn't happen. So it's not the driver. Probably something getting mis-compiled, or something with the build environment, or maybe even something that's changed within the Xserver that doesn't expose itself with a debug version. But it's definately not the driver. Jan has gone away for 5 weeks now anyway, so it'll rot for a while as I can't reproduce this at all. Created attachment 3088 [details] [review] generic-agp-detect-1.patch Oh, one other thing, is that Jan built a 6.8.2 server again and it's failed there too. Attached is the log file that I received from Jan for others info. So it's not something that changed from 6.8.2 onwards. Wonder if this is the libvgahw.a gcc4 miscompilation manifesting itself. I'll try to debug on my laptop. Not that I can see. The two logs that Jan has provided show that libvgahw is loading (probably as it's specified in the config file in the modules section). But the driver hasn't done anything with it at the stage it crashes. Let me know how I can help though Daniel. Can we get any useful info out of the new backtrace in >=6.8.99.14? No because it's a crash inside the BIOS and not the server. OK. So, it seems this bug can only be triggered on a fresh boot -- i.e. it's only on the very first run when VBE gets initialised that this can trigger. If it's failed once, it seems to continue to fail until rebooted; conversely with success. This happened with my BIOS revision 1.02 reproducibly, and sporadically with the BIOS revision 1.21 after I had to send it in (X40 2317NM) for servicing. I haven't been able to trigger it lately, try as I might. I'm seeing this exact same problem, using Ubuntu Breezy Badger on a Dell Inspiron 700m. With the latest Breezy package (xserver-xorg 6.8.2-50 and xserver-xorg-driver-i810 6.8.2-50), X will crash if I enable the external CRT, and refuse to work until I reboot. If I grab the i810 driver from the older Hoary Hedgehog release (package xserver-xorg 6.8.2-10), it works fine. As you can see, the only part of the version number that's different is the Ubuntu version (from 10 to 50), so maybe it has to do with the way it's compiled. In any case, the only file I need to downgrade to fix the problem is /usr/X11R6/lib/modules/drivers/i810_drv.o. Okay, so I'm back. I read the last two comments and I would have never found out that the problem is "triggered" at the first initialisation of the VBE. So I made the tests with Alans Xorg-server again and switched the computer off and on between all the tests. xorg-version s/d works? logfile 1) xorg-6.8.99.14 single y Xorg.0.log.20050828-test1 2) xorg-6.8.2-r1 dual y Xorg.0.log.20050828-test2 3) xorg-6.8.99.14 dual y Xorg.0.log.20050828-test3 And I made this little test-series _without_ any reboot in between: a) xorg-6.8.99.14 dual y Xorg.0.log.20050828-test4-1 with Alans Xorg-server b) xorg-6.8.99.14 dual n Xorg.0.log.20050828-test4-2 with orig. Xorg-server c) xorg-6.8.99.14 dual n Xorg.0.log.20050828-test4-3 with Alans Xorg-server After the the original Xorg-server started the error occurs all the time. But the error is not triggered by Alans Xorg-server. I hope this helps to understand better. Jan Created attachment 3109 [details]
xorg-6.8.99.14 single works
Created attachment 3110 [details]
xorg-6.8.2-r1 dual works
Created attachment 3112 [details]
xorg-6.8.99.14 dual works
Created attachment 3113 [details]
xorg-6.8.99.14 dual alans-server works
Created attachment 3114 [details]
xorg-6.8.99.14 dual orig.-server works _not_
Created attachment 3115 [details]
xorg-6.8.99.14 dual alans-server works _not_
After testing some scenarios I did this test: - Xorg-6.8.2 with dual-config - Alans debugging-Xorg-server - Alans i810_drv.o from www.fairlite.demon.co.uk/intel.html as from 2. september 2005 This combination crashes reproducible even after a hard reboot. Created attachment 3158 [details] testcase with debugging-server which crashes reproducible. See comment #50 That's not my debugging server. Look at the output, it was built on a machine called thinkpad. As I'm not able to provide some usefull logs or similar, I kind of give up on this topic. Actually the i810-driver makes me going crazy. Ringbuffer-probs, no dual-screen or no 3D-acc./opengl after suspend-to-ram (depending on which version I use). If anyone is able to push this further, please, go on. I will watch this bug-report and help as good as I can. Bye Jan PS: I think it's okay to mark this bug as NEEDINFO because we need some good logfiles, right? I found someone who I think has the same problem with debian on the thinkpad linux mailinglist: http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-September/029267.html I pointed him here, so hopefully he will contribute. Jan Some error message as Jan on Debian Unstable, X Window System Version 6.8.2 (Debian 6.8.2.dfsg.1-6 20050831134411 @squee), Kernel 2.6.13 from kernel.org and "Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)". Kernel config: http://www.mopage.de/linux/kernel-config Xorg log: http://www.mopage.de/linux/Xorg.0.log Xorg config: http://www.mopage.de/linux/xorg.conf How can I help? I'm having this same problem on an IBM Thinkpad R51 running Ubuntu Breezy beta. This is 6.8.2 with backported patches (I'm not sure which). As before, if I enable dual head mode, X won't start and won't restart in single head mode until I power off the box. 0000:00:02.0 VGA compatible controller: Intel Corp. 82852/855GM Integrated Graphics Device (rev 02) I have tried using the latest driver from Alan's site with no change. I also tried using the earlier i810 driver from Ubuntu Hoary, which used to work. The old driver with the new xorg got far enough to start both screens but locked up shortly after. The following are the log files from each attempt: http://dparrish.com/xorg/Xorg.0.log-single_after_boot_ok http://dparrish.com/xorg/Xorg.0.log-dual_after_single_broken http://dparrish.com/xorg/Xorg.0.log-single_after_dual_broken http://dparrish.com/xorg/Xorg.0.log-dual_old_driver_broken_different And my config files: http://dparrish.com/xorg/xorg.conf.dual http://dparrish.com/xorg/xorg.conf.single And lspci output: http://dparrish.com/xorg/lspci.txt Also, the diff of the source programs/Xserver/hw/xfree86/drivers/i810 between the version that does work and the version that doesn't. http://dparrish.com/xorg/i810_driver.diff I also tried using earlier versions of libint10 and libvgahw without success. In addition to my comment (#55): With dual-head configuration the external monitor switches on, then xorg crashes, then I got garbled output of the laptop screen on the external monitor. I am not able to start with a single-head configuration until I reboot, or until I switch the output to the external monitor using "/bin/echo lcd_disable,crt_enable >/proc/acpi/ibm/video", but this requires acpi-ibm modules and only works on thinkpads. It works on my system. Laptop: Fujitsu siemens e4010 OS: Linux Gentoo Kernel: 2.6.13-rc1 Monitors: Internal LCD (1400x1050) and external TFT (1280x1024) Use /dev/agpgart as a module in the kernel (and also i810 as a module). Install kde with xinerama support: USE=xinerama emerge -v kdebase /etc/modules.autoload.d/kernel-2.6: 8139too ipw2100 intelfb evdev psmouse i830 agpgart Replace existing i810_drv.o file with mine [1] (see attachment) in folder /usr/lib/modules/drivers/ Use my xorg.conf file [2] (see attachment). Reboot system with the external attached (and "auto" selected in the bios for the monitor's choice). And it should work! Created attachment 3377 [details]
My i810_drv.o file [1]
Created attachment 3378 [details]
My xorg.conf file [2]
Thank you to Alan for his driver and to Sainio Pasi for his help. Pierre Lafaye de Micheaux plafaye@club.fr Thanks Pierre for the updated driver. It still doesn't fix my setup though. The new driver from Pasi doesn't solve my problem, too.
I tried kernel-2.6.13 and xorg-6.8.2
So I wrote an email to Pasi to ask him about what his driver does.
And I took a look at Pierre's xorg.conf:
-------------------------------
Section "Module"
Load "fbdevhw"
[...]
Load "glx"
# Load "dri"
EndSection
-------------------------------
This looks to me like you are using fbdev for xorg an thus aren't using
3D-accelleration, which I do need to be activated.
Actually I don't know much about fbdev and how it works but man fbdevhw tells me
this:
fbdev(4x) is a non-accelerated driver which runs on top of the fbdevhw
module. fbdevhw can be used by other drivers too, this is usually
activated with `Option "UseFBDev"' in the device section.
So, could you try modifying your xorg.conf like this (and maybe remove intelfb
from your /etc/modules.autoload.d/kernel-2.6)?
Section "Module"
# Load "fbdevhw"
[...]
Load "glx"
Load "dri"
EndSection
Jan
Pasi Sainio answered my email and it turned out the driver he gave to Pierre was just the newest one from http://www.fairlite.demon.co.uk/intel.html . new driver doesn't seem to make a difference to me, same error message Created attachment 3500 [details]
Xorg log
Created attachment 3501 [details]
xorg.conf
My apologies, not sure how I ended up attaching these 2 files to this bug. They were meant for bug 643. - Mathieu Can anyone confirm this only happen with xorg >= 6.8.2 compiled with gcc 4 ? A week ago I was using gentoo with a system built with gcc 3.4 , xorg was working fine with dual head and i810 driver. Then I switched to gcc 4, recompiled the whole system and I was getting the vm86() syscall when trying to launch xorg. I tried to upgrade xorg, but 6.8.99 and modular 7.0rc (still built with gcc 4) failed in the same way. I think if I had rebuilt the whole system after downgrading gcc(and maybe glibc too), it would work again. But instead, I installed debian etch, without checking which versions it was using (I didn't know yet it was a real bug, so I thought it would just work with an other distrib). And I was quite surprised to found the same bug again. That's when I saw etch was using gcc 4, and thus xorg was built with it. I really don't know if this could help too, let me know if there is anything more useful I could do, because I really want to see this bug solved. The problem first started occurring for me with gcc4. No, I refute that because I'm using gcc 3.3.6 and have the same problem. Never tried gcc4 though. I even tried different compiler-flags from none to everything possible with my architecture. No change. I have this bug as well, on an IBM ThinkPad X40 running OpenBSD 3.8 / OpenBSD -current Created attachment 3716 [details]
Config file for OpenBSD
Created attachment 3717 [details]
Xorg.0.log for OpenBSD 3.8-current
(In reply to comment #71) > No, I refute that because I'm using gcc 3.3.6 and have the same problem. Never > tried gcc4 though. I even tried different compiler-flags from none to everything > possible with my architecture. No change. It's funny that this problem started occuring for 2 people with gcc 4. Alan Hourihane already suggested it could be some problem in the build environment, and I'm totally convinced it is. Btw, I couldn't be more confused about all the results you posted, I still have no idea which setups work, and which setups don't. But it isn't maybe the problem. Though, I suggest that the skilled people here who can't reproduce the problem try debian testing or unstable, maybe ubuntu breezy too (I cant confirm this). I'm not sure if being able to reproduce it helps though, if it isn't possible to debug it from a broken setup. Well the problem with all the different posts is: I was confused, too. Some setups worked the first time but never again, some worked arbitrary, some never, ... Later (comment #41) Daniel Stone found out that this problem is only triggered at the first initialisation of the VBE after a fresh reboot. This explained the mess with my logs and makes most of them useless. :( (In reply to comment #76) > Well the problem with all the different posts is: I was confused, too. Some > setups worked the first time but never again, some worked arbitrary, some never, ... > > Later (comment #41) Daniel Stone found out that this problem is only triggered > at the first initialisation of the VBE after a fresh reboot. This explained the > mess with my logs and makes most of them useless. :( Yes I finally got that by reading the whole thread carefully, but even by only looking at the results after comment #43, I still don't know if I can get a working xorg again, with my current system/build environment. I don't understand what's your exact setup corresponding to each Xorg.0.log file you posted. I think that in each Xorg.0.log, we can read that it was built by the same kernel than the one you are using. So you are only using xorg servers you built yourself ? Are you always using the same build environment ? What are the differences between the working and non working xorg ? I have the same problem with my external-monitor-only configuration (no dual head). I have a Dell Inspiron 700m and Ubuntu Breezy. I had the same problem using SuSE SLICK (based on SUPER which is based on OpenSuSE 10.0). The same config worked fine in Ubuntu Hoary. I am pretty sure that SLICK and breezy use gcc 4.0 and Hoary uses 3.X, which supports the gcc theory. I installed this: http://dri.freedesktop.org/snapshots/i810-20051203-linux.i386.tar.bz2 and this: http://www.fairlite.demon.co.uk/intel.html and it didn't fix the problem. I'm attaching my config and my Xorg.0.log. Let me know what I can do to help. I'd also be interested to know if there is any other way to get Xorg to use my external monitor that doesn't trigger this error. Created attachment 3984 [details]
[2] Xorg.0.log of failed external-monitor-only config
Created attachment 3985 [details]
[1] xorg.conf - CRT_Only layout used to create error log above
Created attachment 4178 [details] [review] patch to fix dual head problems in xorg-6.9.0 I experienced the same problems when trying to upgrade from 6.8.2 to 6.9.0 (X40, BIOS Build: 3181). It seems not to be related to build system issues but to changes in i830_driver.c. The attached patch is against i830_driver.c from 6.9.0 and fixes it for me (there may be side effects, so please use at your own risk!) I hope this narrows the problem down so it can be fixed upstream. The 2005-12-29 patch above fixes the problem for me on OpenBSD 3.8-current and IBM ThinkPad X40. Ryan, from looking at your log file, your problem is completely different to the original problem in this bug. And Thomas, I'm not sure what problem you were seeing, but it would be useful if you attach your log file too, before you applied this patch, as I can't see any reason why this would help Jan. Created attachment 4185 [details]
Log from working Dual head configuration with the 2005-12-29 patch
My suspicion is that it is at the very least a related bug; the logs seem to die in the same place (during int10 initialisation), the behaviour is identical (including the failure to work with the LCD-only config after having attempted a Dual config). It would be interesting to see a log file from linux on identical hardware, but the difference in the logs may simply be related to differences between OpenBSD and Linux (primarily OpenBSD's stricter and randomized memory allocation schemes) I don't mind submitting this as a NEW bug if you think it's absolutely necessary, but I've confirmed with other OpenBSD developpers (the IBM X40 is the de-facto standard laptop for OpenBSD) that this patch does fix the problem on OpenBSD. Created attachment 4187 [details]
Xorg.0.log - crash with original i830_driver.c
Here is the log file for the original 6.9.0 sources. Note, after this crash X
won't start again as mentioned in other postings above, but I do not have to
reboot the box, just closing and opening the lid helps.
Created attachment 4188 [details]
Xorg.0.log - working with patched i830_driver.c
...and here is the log file with my patch applied. Fine to see that the patch
works for Ryan under OpenBSD too. We seem to have the same hardware, but I am
running it under Linux.
(In reply to comment #85) > My suspicion is that it is at the very least a related bug; the logs seem to die > in the same place (during int10 initialisation), the behaviour is identical > (including the failure to work with the LCD-only config after having attempted a > Dual config). My suspicion is that it isn't related, because the crash is happening before the driver really does anything, whereas in yours and Thomas' case it's crashing because the BIOS can't deal with switching from a dual head config to another dual head config, even though they could be the same configs. The first part of Thomas' patch shouldn't be needed either. I'll get this patch into my test driver so it can get wider testing again, and then I can get this back into the release driver. Thanks for working on it though Thomas - much appreciated. (In reply to comment #88) > The first part of Thomas' patch shouldn't be needed either. Leaving out any of the two parts of the patch makes X crash again. So at least in my case both parts are needed. > I'll get this patch into my test driver so it can get wider testing again, and > then I can get this back into the release driver. Thanks for working on it > though Thomas - much appreciated. Glad to see that it is useful and that you are considering it for the release driver. specifiedMonitor is TRUE when you specify the MonitorLayout so, it definately should not be needed in the dual head case as you always need to specify it. (In reply to comment #90) > specifiedMonitor is TRUE when you specify the MonitorLayout so, it > definately should not be needed in the dual head case as you always need to > specify it. It is FALSE when it comes to the second head. Instead of the return statement I have now added code to print out the value which produces the following sequence in the log file: (II) I810(0): specifiedMonitor is TRUE (II) I810(0): specifiedMonitor is TRUE (II) I810(1): specifiedMonitor is FALSE (II) I810(0): specifiedMonitor is TRUE (II) I810(0): specifiedMonitor is TRUE (II) I810(0): specifiedMonitor is TRUE I think you'll find it's because your patch should really be wrapped with
if (IsPrimary(pScrn)) {
...
}
around the SetDisplayDevices() call.
(In reply to comment #92) > I think you'll find it's because your patch should really be wrapped with > > if (IsPrimary(pScrn)) { > ... > } > > around the SetDisplayDevices() call. Doing so results in a server crash again. Obviously it would be possible to conditionally execute the first part in such a way (instead of removing the whole statement) but I don't know if this is meaningful... O.k. thanks for testing that case. Thomas - can you print out what pI830->savedDevices is when you call SetDisplayDevices() on the primary and secondary heads?? (In reply to comment #95) > Thomas - can you print out what pI830->savedDevices is when you call > SetDisplayDevices() on the primary and secondary heads?? Printing it out at the top of SetDisplayDevices() produces: (II) I810(0): savedDevices is 0x800 (II) I810(0): savedDevices is 0x800 (II) I810(1): savedDevices is 0x800 (II) I810(0): savedDevices is 0x800 (II) I810(0): savedDevices is 0x800 (II) I810(0): savedDevices is 0x800 So far we see that the server crashes if SetDisplayDevices() is not called for the second head (resp. prematurely terminated if !pI830->specifiedMonitor). I've got a similar problem. I have a Dell Latitude D505 with built in Intel 855GM. I am using a dual-screen config with the inbuild Notebook-TFT and an external Dell 2001FP. In single-head configuration everything works good, but when i try to configure the second one and startup kdm... i will only get a turquoise background and Xorg dies as a zombie with 100% cpu. I don't find any errors or other problems in the Xorg.0.log. I will attach the xorg.conf and Xorg.0.log after this post. Created attachment 4254 [details]
xorg.conf
Created attachment 4255 [details]
Xorg.0.log
Created attachment 4256 [details] [review] Do not re-initialize VBE on the second head, but use the primarys view of VBE. (In reply to comment #96) Thomas, Can you reverse your patch and try this instead and let me know. Created attachment 4257 [details] [review] patch for VBE Sorry, That had some wrong function names. Use this instead. (In reply to comment #101) > Use this instead. Alan, I tried your patch(*) _instead_ of mine and the server crashes again. But if I apply _both_ patches it works fine - so the missing SetDisplayDevices() call for the second head seems to be still an issue. (*) Note, I had to remove the line: pI830->used3D = pI8301->used3D; Can you provide a log ? Created attachment 4296 [details] crash with Alan's patch (In reply to comment #103) This is the log file for the case that I apply your patch instead of mine. Created attachment 4297 [details] ok with Alan's patch and my patch (In reply to comment #103) ...and this is the log file for the case that I apply both patches. I only want the case of my patch, please don't apply yours and submit another logfile. (In reply to comment #106) > I only want the case of my patch, please don't apply yours... That case is shown in the attachement (id=4296) of comment #104 - sorry if it was not clear enough. O.k. Sorry, Now can you apply both mine & your patch, but remove the pI830->specifiedMonitor part (i.e. the first block of your patch). Created attachment 4308 [details] crash with alan's patch and the second part of my patch (In reply to comment #108) I removed the first part of my patch, so the two lines if (!pI830->specifiedMonitor) return TRUE; remain in SetDisplayDevices(). Your patch and the second part of my patch are applied. Additionally, I have added a line to print out pI830->specifiedMonitor before the conditional return statement above. You can see that pI830->specifiedMonitor is still false in case of the second head. Therefore SetDisplayDevices() does nothing and the server crashes again (as expected). Can you VT switch o.k. with your patch ?? Does anyone mind setting up SSH access for me to try a few things with this ?? alanh: i would, but unfortunately my laptop's in ibm's hands at the moment, who want a lazy $au1700 to fix the screen. sorry. (In reply to comment #110) > Can you VT switch o.k. with your patch ?? Yes, switching between VTs and X works fine. Additionally, I am using a kernel with vesa framebuffer support without problems (the unpatched Xserver crashes also when using kernels without framebuffer support). Suspend-to-ram (together with dri) works fine, too. Just a note to your comment #92: Actually, it is possible to wrap the call to SetDisplayDevices() in my patch with: if (!IsPrimary(pScrn)) { ... } Created attachment 4321 [details] [review] Set Pipe to default for the head. Right, there's still something deeper going on here that I need to work out. Can you remove all patches, and just try this on it's own. Created attachment 4323 [details] [review] updated pipe patch Sorry, that last one will probably crash - try this. (In reply to comment #115) > Sorry, that last one will probably crash - try this. Alan, this one looks good - no crash and everything seems to work fine! Created attachment 4325 [details] ok with Alan's SetPipeAccess patch (In reply to comment #116) ...and here is the corresponding log file. O.k. Great. Thanks for testing. Well, that sounds pretty promising. What about the patch now? Is it usable, Alain? Will it be incorporated in your driver and Xorg soon? Thanks a lot so far. Yes, I should hopefully commit the new source code later today. Everyone should upgrade to 6.9/7.0 though as they'll get rotation (via XRandR) too :-) I've just committed it. For those who can build from source - give it a go. I applied this patch to the latest x.org 7.0 driver in Ubuntu Dapper (xserver-xorg-driver-i810_1.4.1.3) and rebuilt. Hooray, it works! I can use my external LCD again. Thanks! I've uploaded 1.5.194 which has the Xvideo fixes from the Xorg 7.0 driver backported to the Xorg 6.8.2 driver. Those who can't upgrade to 7.0 may want to try 1.5.193 now. mean to say 'dual head' and not 'xvideo' in that last comment - c&p problem. Sorry. (In reply to comment #122) > I applied this patch to the latest x.org 7.0 driver in Ubuntu Dapper > (xserver-xorg-driver-i810_1.4.1.3) and rebuilt. Hooray, it works! I can use my > external LCD again. Thanks! I can also confirm that this resolves my issues with the dapper driver, fellow Fettig. I compiled Xorg CVS modular according http://xorg.freedesktop.org/wiki/ModularDevelopersGuide on Ubuntu Breezy, and I still get a "vm86() syscall generated signal 11" error when trying to dual head. The log lists version 7.0, so it was not using my old X version. What repository has the fixed driver? *** Bug 6231 has been marked as a duplicate of this bug. *** Closing this bug as the fix has been merged to mainline. Bryce, please open a new bug if you still have an issue. |
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.