|Summary:||Switcheroo regression: Intel card usage causing 100% CPU in kslowd000|
|Product:||Drivers||Reporter:||Michał Witkowski (neuro)|
|Attachments:||Dmesg showing the problem. Clean boot into single user mode. Modprobe i915, modprobe radeon. Switch to DDIS, switch to DINT.|
Description Michał Witkowski 2010-05-31 19:54:13 UTC
Created attachment 26595 [details] Dmesg showing the problem. Clean boot into single user mode. Modprobe i915, modprobe radeon. Switch to DDIS, switch to DINT. Hi, I've got a Lenovo U330 with Intel 4500MHD and Radeon 3450 running Arch Linux. I recently compiled a new version of kernel from the "drm-radeon-testing" branch. My last kernel was from 20100511, which was working fine. In order to switch to my intel card upon boot I have to do: echo "DDIS" > $SWITCHEROO echo "DINT" > $SWITCHEROO in order to completely turn off the Ati card. It's not ideal (see bug 15851), but it worked ok. The order of module loading was intel > radeon. After moving to 20100521 or 20100531 after I do the above changes I can turn off my Ati card, but a kernel-level process kslowd000 takes one whole core. Moreover, I am _unable_ to switch between cards once again. Doing: echo "DDIS" > $SWITCHEROO I get a hard freeze, which didn't occur with 20100521. In that version I could switch between cards without problems many times. What's more, I get the following messages in dmesg after i do DDIS the first which wasn't there before: i915: switched off [drm:intel_dp_aux_ch] *ERROR* dp_aux_ch not done status 0x01450085 i915 0000:00:02.0: BAR 0: set to [mem 0xe0000000-0xe03fffff 64bit] (PCI address [0xe0000000-0xe03fffff] i915 0000:00:02.0: BAR 2: set to [mem 0xd0000000-0xdfffffff 64bit pref] (PCI address [0xd0000000-0xdfffffff] i915 0000:00:02.0: BAR 4: set to [io 0x6110-0x6117] (PCI address [0x6110-0x6117] i915: switched off i915 0000:00:02.0: setting latency timer to 64 It seems that something broke vga_switcheroo between 20100511 and 20100521 in drm-radeon-testing.
Comment 1 Michał Witkowski 2010-06-03 18:52:01 UTC
It seems the problem had been fixed by: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=fbf81762e385d3d45acad057b654d56972acf58c http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=afa3b60c905f606e8245115474d77787035e02eb I no longer get the problem with intel switching locking up and I can use switcheroo as before. This seems to be fixed. Many thanks Dave!
Comment 2 Michał Witkowski 2010-06-21 11:21:29 UTC
Unfortunately the problem is back. My previous kernel from the drm-radeon-testing branch was built on 20100603 and incorporated the above fixes. I could switch between graphics cards without any problems. Today (20100621) I've built two kernels from drm-radeon-testing and drm-linus. Unfortunately both have the above problems, i.e. after switching to discrete card (radeon) and then back to integrated (intel) kslowd000 takes up 100% CPU and any further switching results in kernel locking up. I get the following in dmesg: vga_switcheroo: client 1 refused switch vga_switcheroo: setting delayed switch to client 0 i915: switched on i915 0000:00:02.0: BAR 0: set to [mem 0xe0000000-0xe03fffff 64bit] (PCI address [0xe0000000-0xe03fffff] i915 0000:00:02.0: BAR 2: set to [mem 0xd0000000-0xdfffffff 64bit pref] (PCI address [0xd0000000-0xdfffffff] i915 0000:00:02.0: BAR 4: set to [io 0x6110-0x6117] (PCI address [0x6110-0x6117] i915 0000:00:02.0: setting latency timer to 64 vga_switcheroo: processing delayed switch to 0 fbcon: Remapping primary device, fb0, to tty 1-63 radeon: switched off [drm] Disabling audio support It would be really cool if the mainline kernel didn't have this problem.
Comment 3 Michał Witkowski 2010-08-10 17:42:05 UTC
Hi. I just tried a kernel from drm-radeon-testing (20100805) and the same problem persists. However, I noticed that it only appears whenever I've got anything plugged into the HDMI port. In other words: when I have something in HDMI (of the radeon card) doing DDIS > DINT causes kslowd to go 100% CPU, and with DDIS > DINT > DDIS the system hangs. When there's nothing in the HDMI port, everything's working fine. Just thought I'll share that observation hoping it'll be helpful to someone.
Comment 4 Dave Airlie 2010-12-12 07:47:42 UTC
oh wierd, I wonder will the same thing happen here if I plug something into DP port on the machine I have here. does setting drm_kms_helper.poll=0 on the command line help? though it sounds like we get an irq stuck or something, does drm.debug=4 show anything interesting happen?