Summary: | sys-kernel/gentoo-sources-3.6.0 to 3.9.6 - vga_switcheroo switch to Radeon blanks screen as Intel CRTC mode is disabled on card suspend, a MUX-ed system does not like this. | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jimis Hol <jimishol> |
Component: | [OLD] Core system | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
Status: | RESOLVED FIXED | ||
Severity: | normal | Keywords: | UPSTREAM |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
URL: | https://bugzilla.kernel.org/show_bug.cgi?id=55311 | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=463838 | ||
Whiteboard: | linux-3.6-regression watch-linux-bugzilla http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=a261b246ebd552fd5d5a8ed84cc931bb821c427f | ||
Package list: | Runtime testing required: | --- | |
Attachments: |
difference of config of 3.5.7 and 3.8.0
dmesg with black screen when switch from untel to radeon 3.9.6 current kernel config git log v3.5..v3.7 --grep='switcheroo' bisect.log history of my first try of bisecting Xorg.0.log Got through ssh cause of black screen after switch to radeon. Kernel 3.9.6 Xorg.0.log From working laptop, no black screen after succesfull switch to radeon. Kernel 3.5.7 this must be the right one my dmidecode output |
Description
Jimis Hol
2013-02-22 14:15:37 UTC
Created attachment 339698 [details]
difference of config of 3.5.7 and 3.8.0
When i booted with kernel 3.5.6 all were ok. Since 3.5.6 isnt in portage i emerged 3.5.7
I attach the diff of these 2 kernels where i compare the configuration files. I tried to differ only in wireless access.
Because of new CONFIG_X86_SMAP=y i even gave in grub nosmap and nosmep but without success, x11-drivers/xf86-video-ati-7.1.0 was built with the following: USE="udev (-glamor)" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,-z,lazy" sys-apps/hprofile-2.0_beta2 was built with the following: USE="(multilib)" ABI_X86="64" Do newer versions like gentoo-sources-3.9.6 and git-sources-3.10-rc6 still demonstrate this problem? If still present on those versions, could you try to capture dmesg after a failed switch? You could schedule a short sleep and then redirect dmesg to a file and let it automatically reboot after that. txs for replying. Today evening i tried with kernel 3.9.6 Problem remains Started with intel and tried to go to radeon and got black screen. i have a /usr/share/X11/xorg.conf.d/13-video.radeon as link to 13-video that says Section "Device" Identifier "video" Driver "radeon" BusID "PCI:01:00:0" #this one was added today 6-19-13 # Option "RegistryDwords" "EnableBrightnessControl=1" not working either EndSection In dmesg i attach, note the changes at the like BusID Perhaps the new udev is the reason. i dont know. As i said 3.5.7 works ok if i chose it for boot. Created attachment 351432 [details]
dmesg with black screen when switch from untel to radeon
(In reply to Jimis Hol from comment #5) > Created attachment 351432 [details] > dmesg with black screen when switch from untel to radeon It says "[ 11.995612] [Firmware Bug]: Duplicate ACPI video bus devices for the same VGA controller, please try module parameter "video.allow_duplicates=1"if the current driver doesn't work.". 1) Did 3.5.7 output this as well? 2) Can you try if adding that kernel parameter works? this is my start in grub.conf title Gentoo Linux 3.9.6 root (hd0,5) kernel /boot/3.9.6-gentoo root=/dev/sda7 radeon.agpmode=8 radeon.modeset=1 video.allow_duplicates=1 title Gentoo Linux 3.5.7 root (hd0,5) kernel /boot/3.5.7-gentoo root=/dev/sda7 radeon.agpmode=8 radeon.modeset=1 video.allow_duplicates=1 Cannot remeber if there is some kernel option. 3.9.6 differs a lot from 3.5.7 I will attach my .config in case you are intersted. txs Created attachment 351438 [details]
3.9.6 current kernel config
kernel 3.5.7 had DRM_RADEON_KMS 3.9.6 has DRM_RADEON_UMS but when i try to switch i'm forced to sudo hprofile. Then i am gone to terminal where i log in again and sudo once more. It works to 3.5.7 but not later. userspace modesetting with DRM_RADEON_UMS isnt working either on or off. I connected to laptop through ssh ptest of vgaswitcheroo seems to give radeon. And switch file at /sys/kernel is ok. I didn't see any error in Xorg.0.log or dmesg I think it isn't switcheroo after all. It must be open source radeon that maybe must be configured differently. There is a bug about this upstream at https://bugzilla.kernel.org/show_bug.cgi?id=55311 but I forgot to tell you and set the URL wrong the first time, could you take a look there? Backlight for radeon never worked for me and a fixing of it was my main hope with new kernels but since i try upgrade them manually its time consuming. I 'll stick with kernel 3.5.7 hoping to read about some fix of this bug of black screen. As I read in your last url and their links some guys have the 'opposite' problem of switching from working radeon to a black screen of intel.(My laptop starts with working intel). So something changed in >=3.6 kernels where fixing a bug gave rise to this problem and somehow intel or radeon drivers have to make adaptions. May be the title 'vgaswitcheroo fails to switch' is wrong failing to describe the problem. Thank you for replies. Created attachment 352412 [details] git log v3.5..v3.7 --grep='switcheroo' There apparently have not been a lot of vga_switcheroo commits between 3.5 (working) and 3.7 (broken), could you try versions in between the working 3.5 and broken 3.6 to indicate more specifically which commit might be failing? You can do this by performing a git bisect; pass the last known to work version as well as the first broken version to it. http://wiki.gentoo.org/wiki/Kernel_git-bisect (A way to do less commits is to restrict by file; I would discourage you from doing that, because the fault might not lie with vga_switcheroo, but if you want to give it a try anyway you could run it once for ./drivers/gpu/vga/vga_switcheroo.c and once for ./include/linux/vga_switcheroo.h using the "git bisect start [--no-checkout] [<bad> [<good>...]] [--] [<paths>...]" syntax; if the reverse patch for the resulting bad commit does not fix it, you will still have to run a full bisect) Let us assume i could try bisect that seems little hard for me. I don't know how to start it according to http://wiki.gentoo.org/wiki/Kernel_git-bisect. My menuconfig is working, do to previous emerge --sync ONLY with kernels linux-3.5.7-gentoo and linux-3.9.6-gentoo They differ a lot!! The first that i tried and didnt worked was linux-3.6.11-gentoo but i cant menuconfig it because of "make: *** No rule to make target `menuconfig'. Stop." Today gentoo-sources (i use testing ~amd64) goes up from 3.4.51 to 3.7.10-r1 (fortunately i installed specifically 3.5.7 so i didn't lost menuconfig) So how can i start bisect? In http://git.kernel.org/pub/scm/linux/kernel/git/ i didn't recognised a thing!! Is it proper the root # cd /usr/src root # git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-stable and afterwards the root # git bisect bad v3.6.11 | tee -a /root/bisect.log #OR v3.7.10-r1 root # git bisect good v3.5.7 | tee -a /root/bisect.log Txs Tom (In reply to Jimis Hol from comment #14) > My menuconfig is working, do to previous emerge --sync ONLY with kernels > linux-3.5.7-gentoo and linux-3.9.6-gentoo They differ a lot!! The first that > i tried and didnt worked was linux-3.6.11-gentoo but i cant menuconfig it > because of "make: *** No rule to make target `menuconfig'. Stop." Can I get the full output of that? Is there a Makefile in /usr/src/linux? This sounds like an incomplete kernel sources install to me. > Today gentoo-sources (i use testing ~amd64) goes up from 3.4.51 to 3.7.10-r1 > (fortunately i installed specifically 3.5.7 so i didn't lost menuconfig) So > how can i start bisect? You don't need gentoo-sources for the bisect. > In http://git.kernel.org/pub/scm/linux/kernel/git/ i didn't recognised a > thing!! > > Is it proper the > root # cd /usr/src > root # git clone > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git > linux-stable Don't forget to `cd linux-stable` after cloning it. Perhaps do `eselect kernel set linux-stable` too if you use genkernel. > and afterwards the > root # git bisect bad v3.6.11 | tee -a /root/bisect.log #OR v3.7.10-r1 > root # git bisect good v3.5.7 | tee -a /root/bisect.log Yes; after that you can build the kernel, boot into the newly built kernel and if it works you run `git bisect good` and if it is broken you run `git bisect bad`, then it will pick a new commit and you repeat this paragraph. (Build --> Test --> Good / Bad --> Build --> Test --> Good / Bad --> ... --> You'll eventually find the bad commit) Something must gone wrong with my bisecting because 1) the first bad commit doesn't seemed to be related with graphics or expceted anyway as i read it 2)building with git didn't reproduced the excact behaviour. All of my "bisect bad" were given because i couldn't start X nor had a /sys/kernel/debug/vgaswitcheroo folder BUT i had text with console. So not really black screens (I slept with no wireless even with kernel 3.5.7 but by the first poweron in the morning all are as usual). Are gentoo-sources included in linux-stable.git? I attach the bisect.log and some history of my procedure with the hope you can pinpoint what i did wrong. Maybe i could retry. txs again Created attachment 352608 [details]
bisect.log
Created attachment 352610 [details]
history of my first try of bisecting
Since i was propably wrong and xgi has to do with graphics, this is my cards lspci -v |grep VGA 00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller]) 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Park [Mobility Radeon HD 5430/5450/5470] (prog-if 00 [VGA controller]) XGI framebuffer, related to XGI video driver. Seems irrelevant. (In reply to Jimis Hol from comment #16) > 2)building with git didn't reproduced the excact behaviour. All of my > "bisect bad" were given because i couldn't start X nor had a > /sys/kernel/debug/vgaswitcheroo folder BUT i had text with console. So not > really black screens Sorry to disappoint you. The gist of it is that it should either 1) work (good) or 2) go black (black) otherwise the bisect will be meaningless; anything in between, is indeed the result of a wrong kernel upgrade. I think you need to rebuild external modules if you have any; you can do this with `emerge @module-rebuild` for the kernel modules as well as `emerge @x11-module-rebuild` for X11 modules. Can you attach the /var/log/Xorg.0.log if it still goes wrong? You might want to script parts of this so you don't have to retype all the commands. For instance, add the following two commands to .bashrc so you can do `doprep` followed by `git bisect good_or_bad_here | tee -a /root/bisect.log` followed by `dotest` followed by `reboot`. doprep() { cd /usr/src/linux mount /dev/sda6 /boot } dotest() { cp ../linux-3.5.7-gentoo/.config .config make oldconfig make -j2 && make modules_install cp arch/x86_64/boot/bzImage /boot/gentoo-bisect } You could combine them even more so all you have to type is `bisect bad` or `bisect good`, but if you go for that make sure you get it to check the return codes right. You can get back to start by running `git bisect reset` after which you can do the `git bisect start` again. Created attachment 352618 [details]
Xorg.0.log Got through ssh cause of black screen after switch to radeon. Kernel 3.9.6
Created attachment 352620 [details]
Xorg.0.log From working laptop, no black screen after succesfull switch to radeon. Kernel 3.5.7
I'm too tiered today. Till i try again bisect i post 2 Xorg.0.log The error about Failed to load module "modesetting" doesn't seem to affect functionality because it appears even before succesfully switch to radeon with kernel 3.5.7
Worth noting that when was in black screen with kernel 3.9.6 i switched to intel using ssh connection but ended with a blinking cursor at top left of black screen failing to see gdm screen.
I dont know the significance of this but first oldconfig again ends without asking any new option but with warning: (DRM) selects DMA_SHARED_BUFFER which has unmet direct dependencies (EXPERIMENTAL) As in previous attempt i ignored it this time i will pass through menuconfig too Created attachment 352696 [details]
this must be the right one
Finally being more carefull this time with kernel update i think i managed to finish bisecting procedure. Txs Tom
I cant help but ask if might be this bug to be related with the fact that changing the brightness never worked with radeon in this hybrid setup (In reply to Jimis Hol from comment #25) > I cant help but ask if might be this bug to be related with the fact that > changing the brightness never worked with radeon in this hybrid setup I don't think the brightness is related but it definitely can cause the screen to blank because this is the Cathode Ray Tube Controller (CRTC) which controls video timings. http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=a261b246ebd552fd5d5a8ed84cc931bb821c427f As can be seen on above URL, the commit is relatively small; can you please try to go back to your current kernel and remove the intel_modeset_disable(dev); instruction from the file /drivers/gpu/drm/i915/i915_drv.c? I think that when it is trying to put the card to sleep there (when you switch to Radeon) that this command wrongly turns off the display; this shouldn't happen in your case, since you want the Intel card to route the output from your Radeon card. I think you have a MUX-ed system, where both GPUs are connected to the display via switching multiplexer located on or near the Intel card. I think this call should be guarded to check whether vga_switcheroo is present. When removing the line helps, could you report a new kernel bug upstream about that at https://bugzilla.kernel.org such that they can fix this for you in the future? You might also instead choose to send a mail to the kernel mailing list (http://www.tux.org/lkml/) with a patch to fix this; since it is a patch and not a bug, it will get faster looked into. Though, to write a patch the appropriate vga_switcheroo check should be written and I'm not entirely sure how to do that. Or who knows, maybe the line should just not be there; you'd have to be a video card developer to know that... I hope that lines help you fix your issue. Tom Wijsman !!! I thank you from the deeps of my heart. For the first time i saw Gallium 0.4 on AMD CEDAR in my Linux gentoo-laptop-g62 3.9.6-gentoo #8 SMP Sat Jul 6 15:53:14 EEST 2013 x86_64 Intel(R) Core(TM) i5 CPU M 460 @ 2.53GHz GenuineIntel GNU/Linux I putted intel_modeset_disable(dev); of 524 row in /* */ and became /* intel_modeset_disable(dev); */ from the /usr/src/linux/drivers/gpu/drm/i915/i915_drv.c gave make clean make -j2 && make modules_install and emerge -av @x11-module-rebuild just in case that it would be neccesary and..... I have both my cards # lspci -v |grep VGA 00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller]) 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Park [Mobility Radeon HD 5430/5450/5470] (prog-if 00 [VGA controller]) at my HP G62 laptop AGAIN!! (of course still without the ability to change brigthness as usual :D ) Will this bug change to a resolved one? Thank you!! I am not member of bugzilla.kernel.org, nor belong there as my knowlenges of the subject are zero. I use only this bugs.gentoo.org and i am just a dedicated gentoo user. I never used mailing list and by visiting http://www.tux.org/lkml/ I was out of my abilties So I cant report this bug farther (I tried but i couldnt even find a proper title in my mind). If you can't do it for me because you obviously missing my hardware that is needing for testing, i will try to subscribe myself in bugzilla.kernel. Mailing list is totally strange for me. I have better news, upon checking the latest kernels this appears fixed in 3.10. http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=24576d23976746cb52e7700c4cadbf4bc1bc3472 My dear Tom I was happy to give emerge -av =sys-kernel/gentoo-sources-3.10.0 and make oldconfig from the 3.9.6 configuration but black screen persist and there is no intel_modeset_disable(dev); line in /usr/src/linux/drivers/gpu/drm/i915/i915_drv.c so as to do the same trick as i did with 3.9.6 It seems that bisecting from 3.5.7 all the way to 3.10.0 would be tedious. as i dont think that a bisecting from our modified 3.9.6 can be done. Sorry to disappoint you, i was so willing to confirm that 3.10.0 was ok :( Eh, it represents itself in a different form there. list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) dev_priv->display.crtc_disable(crtc); Removing these two lines in 3.10.0 should work for you. I now see that these two lines also disable CRTC; heh, I'll report this soon. The bug I gave earlier appears to be the same so we don't need to file a duplicate; I am closing this bug to track the upstream bug. Upstream asks for dmidecode information to add a quirk to fix this in the kernel; please `emerge sys-apps/dmidecode` and attach the `dmidecode` output upstream. Created attachment 354040 [details]
my dmidecode output
dmidecode was already installed if it matters. Txs for conserning about it :)
|