After starting Xorg with the intel driver enabled, the screen gets a glowing red line at the left side and then gets totally garbled. If i plug a Monitor in the monitor shows the normal picture. I tried to fiddle a little with xrandr to switch the LVDS to auto or use different resolutions, but nothing helped. I tried this with a gentoo installation and the intel drivers from git as well as with ubuntu and the 2.4.1 and 2.4.2 drivers. My system is a sony vaio z11wn/b with an intel gm45 (x4500) and a nvidia geforce 9300m gs (i can switch between them). X.Org.log shows nothing specific and no errors, as the x-server starts up as expected. I can post it if you need it, but at the moment i cannot access my notebook. xorg.conf used was the one supplied by ubuntu as well as one edited by myself.
Created attachment 18793 [details] lspci output
Created attachment 18794 [details] Xorg.0.log
Created attachment 18795 [details] xorg.conf
Created attachment 18796 [details] Picture of the red line on the left side The Monitor gets lighted up, then a red line appears at the left side and shrinks to the bottom. Otherwise the screen stays blank. After that the image gets garbled.
Created attachment 18797 [details] Grabled output
So this happens only when you only use LVDS (laptop panel display), right? But why the log shows VGA connected?
I had no network there, so i had to start with VGA connected to pull the conf and log files. But its the same with LVDS only.
>> If i plug a Monitor in the monitor shows the normal picture. Do you mean if you connect a VGA monitor, both VGA and LVDS display ok?
No, if i plug in a VGA Monitor the Display on the VGA is okay, the LVDS is alway garbled, if the monitor is connected or not doesnt matter.
Created attachment 18798 [details] Xorg.0.log without VGA connected This is the Xorg.0.log without an VGA Display connected
Could you attach your dmesg output?
Created attachment 18799 [details] dmesg output I can only provide the dmesg output from the ubuntu live cd, because i reinstalled the notebook with xp, while this error still exists. The sonypi kernel error makes no difference, as with the gentoo setup the same error existed even when sonypi was not loaded
I have to reformulate :) I can only provide the dmesg output from the ubuntu live cd, because i reinstalled the notebook with xp, while this still happens. The sonypi kernel error makes no difference, as with the gentoo setup the display got corrupted even when sonypi was not loaded and no kernel error was present.
I installed Ubuntu again so i could test a fix if you got one. So let me know if something comes up, i would be happy to test.
Could you turn on ModeDebug option and upload new X log?
Created attachment 18909 [details] Xorg.log with ModeDebug enabled and no VGA connected
Created attachment 18910 [details] Xorg.log with ModeDebug enabled and VGA connected
Created attachment 18911 [details] [review] debug patch disable vbios panel mode, and try if current mode readback is more correct. Please try this, this patch applys to 2.4 branch driver.
Does the Patch disable the vbios panel mode or do i have to do this manually. Has this bug something to do with the issues described here: http://gentoo-wiki.com/Making_%22broken%22_Intel_video_BIOS_play_nice (could not try yet because currently @ work)
Any update?
Sorry, my harddisk crashed 2 days ago, had to get me a new one. Installing Linux again at the moment, will then test and report back.
Tried the patch, doesn't change anything Display-wise. Display looks the same, shrinking red line then garbled display.
Could you paste X log with ModeDebug?
oh, do you use 2.4.2 release? Could you try current git master or xf86-video-intel-2.4-branch tip?
I tried with git master. Will post the ModeDebug results today after work.
ok, and also try with "NoAccel" option, to see if it's really display issue.
gut feeling that this is a dup of 17292...copying Jesse.
Created attachment 19285 [details] Xorg.log with ModeDebug enabled My Notebook was defect and i had to replace it. As i am now finished with reinstalling, here is the Xorg.log output with ModeDebug enabled. Sorry for the Delay.
How about if you disable nvidia gfx in somewhere -- bios? Could you try current xf86-video-intel master? You may try to test with disable SSC, try to find "pI830->lvds_use_ssc" in src/i830_bios.c, which should look like "pI830->lvds_use_ssc = general->enable_ssc;", change it to "pI830->lvds_use_ssc = FALSE;". and retry.
Could you attach a copy of your video bios? By doing echo 1 > /sys/devices/pci0000\:00/0000\:00\:02.0/rom cat /sys/devices/pci0000\:00/0000\:00\:02.0/rom > /tmp/vbios and upload /tmp/vbios. Thanks.
I try the master after school today and send you the vbios. It is not possible to disable the nvidia card.
Created attachment 19406 [details] VBios binary VBios cat as requested
Created attachment 19407 [details] VBios binary VBios cat as requested
Created attachment 19408 [details] Xorg.log with pI830->lvds_use_ssc = FALSE I set pI830->lvds_use_ssc to FALSE but i did not help, still experiencing the same behaviour.
Could you try current master tip with no any debug patch applied?
Created attachment 19493 [details] Newest Xorg.0.log with master branch driver tried the latest tip with using the unmodified master branch. Didn't work.
Your log seems not reach the end?
Created attachment 19513 [details] Newest Xorg.0.log with master branch driver Now it should be complete, Sorry for the inconvenience.
Created attachment 19514 [details] [review] lvds bios timing flags test patch Could you try current master with this patch applied?
Created attachment 19520 [details] New Xorg.0.log with previous patch applied I tried the patch, same behaviour. Only difference i saw, is that after starting X the Monitor fades to dark instead of fading to light withe as previously.
Oliver, what's the exact distribution are you using?
At the moment i am working with arch linux. But i tried with Gentoo, Ubuntu and gOS, its the same issue with all of them. I also tried different kernels from 2.6.24 - 27.
(In reply to comment #42) > At the moment i am working with arch linux. But i tried with Gentoo, Ubuntu and > gOS, its the same issue with all of them. I also tried different kernels from > 2.6.24 - 27. > what I mean is what version of the distro, i.e. Ubuntu 8.04 or 8.10 alpha(?)/Beta(?)...
gOS 3 Ubuntu 8.04, 8.10 Alpha 3, 4, 5; Beta 1 Gentoo 2008.0 Arch Linux 2008.06 The same Behaviour with all of them.
oliver, what's the native panel resolution that your windows XP says? We just got a Sony VGN-Z540 which has very similar HW configuration as yours. and it works fine. Zhenyu and I have tested Ubuntu 8.04, 8.10 beta LiveCD...
My native Resolution is 1600x900. I already read somwhere that it seem to work with some of the japanese and american models of the Sony Z-Series. Live CDs of Ubuntu are not working either.
Hi, the Notebook is described on this site: http://vaio.sony.de/view/ShowProduct.action?product=VGN-Z11WN%2FB&site=voe_de_DE_cons&pageType=Overview&category=VN+Z+Series (Sorry, but i found no english version - i think its only sold in germany with this configuration) Is there any update? thanks
Hi, I once met the similar issue (X crash after login) on Solaris with Sony VGN-Z540. But when I disable the FBC, all work well. Could you please disable the FramebufferCompression in xorg.conf and have another try? Option "FramebufferCompression" "False" Thanks! Liang Kan
Thanks for the tip, but sadly that doesn't work either.
Are there any news? Is it possible that the high resolution causes the problem? My Notebook is comparable to the VGN-Z590 with a 1600x900 panel. If it works on a Z540 which only difference i could find is the lower video memory and the lower resolution could it be that. I am kind of helpless here, because i hate windows, and now i have to use it, because neither the intel nor the nvidia card is working under linux (nvidia not at all responding to my bug-report :( )
Oliver, after checking some docs on this switchable graphics feature, it looks like LVDS and CRT has mux control between iGPU (integrated) and dGPU (discrete), TV and all digital outputs are controlled by dGPU only. But current work to control the mux and switch is not ready yet (I'll attach a test program, could you compile that and paste the output?). You don't have setting in BIOS to use intel graphics only, right? I think vaio should have a key switch above keyboard to switch between gfx devices, have you tried with that switcher?
Created attachment 19952 [details] gpio check program for switchable gfx feature This requires libpciaccess, try to compile with "gcc -o gpio_check gpio_check.c -lpciaccess".
No, i cannot disable any of the Graphics cards in bios. The switch is no Hardware switch, i think. In Windows Device Manager i see both cards. And it doesnt make any difference how i put the switch, result stays the same. I'll try the test program immedeatly and post the ouput. Thanx
The utility says: GPIO Base address: 0x500 , Length: 64 bytes GPIO52 (dGPU_select) is used for native function instead of GPIO... And i also saw a message popping up when booting i missed before, i think its somehow related to the pcie memory: pci 0000:01:00.0: BAR 6: can't allocate mem resource [0xd0000000-0xcfffffff]
could you pls try this modeline? ModeLine "1600x900_60" 76.1 1600 1664 1728 2091 900 901 902 910 +hsync +vsync pls attach your xorg.log as well for verification. thanks!
Created attachment 20298 [details] Xorg.0.log for Modeline 1600x900_60 I tried to use it, but i think Xorg doesnt accept this Modeline. I also tried the Modeline given by gtf with the same result. Tried to force both of them using the PreferredMode switch, but it gets ignored.
Created attachment 20299 [details] Xorg.0.log for Modeline 1600x900_60 Typo in xorg.conf now using correct Mode, but no difference
Just FYI. I also tried the 915resolution utility by forcing Q965 as chipset, it shows me the resolutions and indeed there is 1600x900 missing. If i overwrite the 1600x1200 resolution with 1600x900 it makes no difference.
I installed XP and the NVidia Card is now working under Linux. Now i really can switch between cards but have to reboot to do so. But with the Stamina (Intel) Mode enabled i still get the red line and the garbled output afterwards.
Created attachment 20364 [details] [review] debug patch Could you try this patch against current git master? First try starting X without external CRT attached.
Created attachment 20484 [details] [review] set LVDS reference divisor based on current block Could you please try this patch against current git master?
Created attachment 20530 [details] Failed to start X. No garbled screen, but lockup. Upgraded to newest intel-git, mesa-git and drm. Applied the patch. X does not start, but a system lockup occurs.
Oliver, it looks patch on bug #17292 works for some people, could you test that too? That's https://bugs.freedesktop.org/attachment.cgi?id=20365
*** This bug has been marked as a duplicate of bug 17292 ***
Created attachment 22112 [details] Xorg.0.log with Version 2.6.0 and patch applied Tried the patch, does not work. Still the same effect. Tried with 2.5.1 and 2.6.0. The red line is persistent :( Sorry for the late reply, but i had to do my Bachelors work and so i had no time to try.
I also tried the other patch proposed to fix bug 17292, but that one did not help either. So i am reopening this Bug. Thank you.
Created attachment 22114 [details] Xorg.0.log with Version 2.6.0 and patch applied without KMS I saw that there is no Debug output if KMS is enabled, so i disabled it. I also applied the same hack used in bug 17292 and applied its principle to the KMS code in intel_bios.c changing it to the following: panel_fixed_mode->hdisplay = (dvo_timing->hactive_hi << 8) | dvo_timing->hactive_lo; panel_fixed_mode->hsync_start = panel_fixed_mode->hdisplay + ((dvo_timing->hsync_off_hi << 8) | dvo_timing->hsync_off_lo); panel_fixed_mode->hsync_end = panel_fixed_mode->hsync_start + dvo_timing->hsync_pulse_width; panel_fixed_mode->htotal = panel_fixed_mode->hsync_end + ((dvo_timing->hblank_hi << 8) | dvo_timing->hblank_lo); panel_fixed_mode->vdisplay = (dvo_timing->vactive_hi << 8) | dvo_timing->vactive_lo; panel_fixed_mode->vsync_start = panel_fixed_mode->vdisplay + dvo_timing->vsync_off; panel_fixed_mode->vsync_end = panel_fixed_mode->vsync_start + dvo_timing->vsync_pulse_width; panel_fixed_mode->vtotal = panel_fixed_mode->vsync_end + ((dvo_timing->vblank_hi << 8) | dvo_timing->vblank_lo); Result sadly stays the same.
(In reply to comment #66) > I also tried the other patch proposed to fix bug 17292, but that one did not > help either. So i am reopening this Bug. Thank you. > Have you tried last patch on it? https://bugs.freedesktop.org/attachment.cgi?id=21910
Yes i did, the result stays the same. Also tried it on the KMS code as stated in my previous post.
Does current master work for you? Jesse's patch is commit 57a02b50c60c10a25ff0f3cd93af9f37fa0d1b11 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Mon Jan 26 14:58:28 2009 -0800 Fixup bogus VBT modes when detected
zhenyu, it seems that the fixed mode in Oliver's vbios is correct ( Htotal is > Hsync ), so Jesse's patch won't help... In the mean time, check out the m,n,p1,p2 setting for pipe B, where the LVDS sit, between X startup and EnterVT... the mysterious spreadsheet has prove the setting used when X startup is the right combination to get the required frequency (100 Mhz dot clock). The dot clock doesn't change between X startup and EnterVT, while those parameters changed.. In order to get a given frequency, there is only one combination is right. Then the one our driver get via "calculation" is wrong, if it's not equal to the one used when X startup?
Is there any difference for LVDS PLL setting in GM45 than pre chipsets?
no change, I think, thus I doubt if this is GM45 specific. If it's true, the problem seems persist for a while - If a LVDS panel by nature can only accept one dot clock (no matter what clock the modeline says, it's changed to the one of fixed mode in lvds_mode_fixup), maybe we shouldn't bother to change (m,n,p1,p2) in crtc_mode_set from the working case ( the one set by vbios ), unless we can get the same combination via calculation...
After using the workaround described here: http://thinkfat.blogspot.com/2009/02/sony-vaio-z21-news-switching-off-nvidia.html (replacing the sony-laptop module) the Intel card initializes and I have a screen and can work normally. But as soon as the Monitor enters any standby mode and resumes the red line is back.
So if we want intel graphics to work, we have to disable NV completely, that's the theory right? Does any _DSM method should be called after you left standby? Could you send your acpidump output? Our acpi guys might be interested to look at.
Hi, Oliver Do you mean that the Intel graphics can work if the _DSM object is evauated for the nvidia card? Right? In fact the _DSM object is only to enable/disable the device's wakeup capability from the sleeping state. And it can't enable/disable the corresponding device. Will you please attach the output of acpidump, lspci -vxxx? It will be great if you can check whether the nvidia card can be disabled in BIOS option. thanks.
Created attachment 22978 [details] acpidump output The acpidump output.
Created attachment 22979 [details] lspic -vxxx output Output of lspci -vxxx
The acpidump as well as the lspci were done after loading the sony-laptop module with the previously mentioned patch applied. The BIOS like all sony BIOSes has not much settings. There is no setting to disable any of the two Cards.
(In reply to comment #74) > After using the workaround described here: > http://thinkfat.blogspot.com/2009/02/sony-vaio-z21-news-switching-off-nvidia.html > (replacing the sony-laptop module) the Intel card initializes and I have a > screen and can work normally. But as soon as the Monitor enters any standby > mode and resumes the red line is back. > would you pls help to post a reg_dump after you get it works via the workaround?
interesting. ACPI only defines the _OFF method for a power resource device. How/when to use the _OFF method for a regular device is not stated in the ACPI spec 3.0. what if you don't invoke _DSM? does this workaround still work? about the resume problem, what if you call _OFF again after resume?
Rui, maybe you can make a debug patch for Oliver? or from you analysis is it possible in gfx driver to workaround this?
Hi, sorry again for the delay :( But my setup is not working again. After posting i found out, that the fix is not working every time. it only works on one out of ten occasions. I dont get it. Does anyone know what could cause this? Thanks
Created attachment 23602 [details] [review] hi Oliver please try this patch on your machine,thanks. before entering X, pll parameter of bios pll seting are n = 2, m1 = 19, m2 = 5, p1 =2, p2 = 14, however driver change it as n = 3, m1 = 10, m2 = 8, p1 = 1 , p2 =14 although their clock are both 100M, please try it. Thanks Ma Ling
Hi, i applied the patch to the current trunk, but it does not change the behavior. If you need any logs or dumps, let me know.
(In reply to comment #85) > Hi, > i applied the patch to the current trunk, but it does not change the behavior. > If you need any logs or dumps, let me know. yes, could you please upload log file with Modedebug option on. Thanks Ma Ling
I think this one does need help from acpi side, to give us the capability to switch between intel and nv card, it looks they can't be enabled in meanwhile. Oliver, have you tried any custom dsdt hack yet?
I tried. I disassembled my dsdt, repaired it, changed the OSYS Var to "Windows 2006". Otherwise i dont know how to hack specifics in the it. I'll upload the ModeDebug log in the afternoon.
hi, all it seems that some works are already done for this issue. http://archive.netbsd.se/?ml=xorg&a=2009-02&t=9908058 Oliver, Could you please try the latest sony-laptop driver and see if it helps in your case please? I don't know if this (invoking _DSM) is the right direction, and I'll kick off a discussion about this in the mail list.
Hi, i tried the module already, yielded the same result. I am not sure, that this is the definitive answer. While it enables to use the NVidia Card in my case, by switching, the card itself is not deactivated properly. Only the second intel PCI Entry disappears (0:02.1).
Hello, something strange happend. If I switch to stamina mode with the module i get the red line. But if i switch to speed, and then to stamina again, it works. I really do not get it...
Oliver, How do you switch between them? and the problem only happens when you enable the Intel graphics card and disable the nvidia one, right?
Hi, found out yesterday by trial and error, that it only works with the patch from MaLing applied to the master branch. Without it i get the red Line anyways. The procedure is as follows. With the modified sony-laptop module i can switch between the cards (no real switch though, but ACPI hack, as explained in the link you gave a few posts back). To make it work i have to activate the nvidia card first, then I have to switch to the intel card, then and only then X starts up okay.
lower priority. Rui suggested we could add that fix for linux sony_acpi module. And Ling's patch would be commited after some cleanups.
summary: - Ling's patch has been checked in as fix for bug# 17805 - the other issue is about ACPI. it's been fixed in sony-acpi module. so, I'm closing this bug.
Sorry to report a followup to this bug, but i dont know if i should open a new one. With the current Master X starts fine, but as soon as i open any app i get artifacts all over the screen. If I move a window, the artifacts are moved to.
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.