Bug 34430 - nouveau driver does not return VGA connector status breaking upower
Summary: nouveau driver does not return VGA connector status breaking upower
Status: NEEDINFO
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-18 01:25 UTC by nuada
Modified: 2015-01-17 00:12 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Proposed fix (930 bytes, patch)
2013-05-27 16:23 UTC, Robert Varga
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description nuada 2011-02-18 01:25:45 UTC
My laptop (Asus UL80VT) has hybrid graphics: intel+nvidia. After switching nvidia card off using vgaswitcheroo, upower CPU consumption goes to 100%. If nvidia card is switched back on, problem dissapeares.

This is caused by nouveau driver not returning VGA connector status properly. When upowerd tries to read status of all connectors, it hangs waiting for VGA.

Gentoo Linux
kernel: 2.6.38-rc*
xorg-server: 1.9.4
upower: 0.9.8
KDE: 4.6.0

Steps to reproduce:
1. Log in to KDE
2. switch off nvidia:
    echo OFF > /sys/kernel/debug/vgaswitcheroo/switch
3. cannot read VGA connector status:
    cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card1/card1-VGA-1/status
Comment 1 Ilya Basin 2012-09-22 06:46:53 UTC
Similar problem here. I added to /etc/rc.local:
  echo OFF > /sys/kernel/debug/vgaswitcheroo/switch

When Gnome tries to start, upowerd eats 100% CPU. So, to start Gnome I have to temporarily enable the card, then disable it again.
Similarly,
  cat "/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0/card0-VGA-1/status"

hangs when the card is OFF.


Laptop Acer Aspire 5755G
Archlinux 64
kernel 3.5.3
upower 0.9.17
gnome 3.4.2
Comment 2 Robert Varga 2012-10-15 18:19:40 UTC
For what it's worth, when upowerd enters 100%-cpu-hog mode, this is its stack trace (Thinkpad W520, gentoo sources 3.6.2):

Oct 15 20:09:17 [kernel] [  319.663638] upowerd         R  running task        0  2881      1 0x00000000
Oct 15 20:09:17 [kernel] [  319.663643]  ffffffff810440ac ffffffff81364879 ffff88023487d910 ffff88023538d320
Oct 15 20:09:17 [kernel] [  319.663649]  ffff880220075fd8 0000000000011280 ffff880220075fd8 ffff88023538d320
Oct 15 20:09:17 [kernel] [  319.663654]  0000000080000000 ffff880220075fd8 ffff880220074000 000000000061a804
Oct 15 20:09:17 [kernel] [  319.663660] Call Trace:
Oct 15 20:09:17 [kernel] [  319.663665]  [<ffffffff810440ac>] ? need_resched+0x1a/0x23
Oct 15 20:09:17 [kernel] [  319.663670]  [<ffffffff81364879>] ? __schedule+0x37c/0x393
Oct 15 20:09:17 [kernel] [  319.663676]  [<ffffffff810440ac>] ? need_resched+0x1a/0x23
Oct 15 20:09:17 [kernel] [  319.663681]  [<ffffffff81364b46>] ? preempt_schedule_irq+0x3f/0x47
Oct 15 20:09:17 [kernel] [  319.663686]  [<ffffffff81365796>] ? retint_kernel+0x26/0x30
Oct 15 20:09:17 [kernel] [  319.663720]  [<ffffffffa01aa53f>] ? nv04_timer_read+0x51/0x64 [nouveau]
Oct 15 20:09:17 [kernel] [  319.663734]  [<ffffffffa0189824>] ? nouveau_wait_eq+0x56/0x73 [nouveau]
Oct 15 20:09:17 [kernel] [  319.663761]  [<ffffffffa01ee629>] ? nv50_dac_detect+0x89/0x2c6 [nouveau]
Oct 15 20:09:17 [kernel] [  319.663784]  [<ffffffffa01a1535>] ? nouveau_connector_detect+0x243/0x267 [nouveau]
Oct 15 20:09:17 [kernel] [  319.663790]  [<ffffffff81246976>] ? status_show+0x31/0x6c
Oct 15 20:09:17 [kernel] [  319.663796]  [<ffffffff8129019c>] ? dev_attr_show+0x1e/0x46
Oct 15 20:09:17 [kernel] [  319.663803]  [<ffffffff8108928a>] ? __get_free_pages+0x10/0x3f
Oct 15 20:09:17 [kernel] [  319.663808]  [<ffffffff810fc203>] ? sysfs_read_file+0xa8/0x12e
Oct 15 20:09:17 [kernel] [  319.663812]  [<ffffffff810b54e7>] ? vfs_read+0x9b/0xc2
Oct 15 20:09:17 [kernel] [  319.663817]  [<ffffffff810b62f9>] ? fget_light+0x85/0x8d
Oct 15 20:09:17 [kernel] [  319.663821]  [<ffffffff810b5553>] ? sys_read+0x45/0x6b
Oct 15 20:09:17 [kernel] [  319.663826]  [<ffffffff81365da6>] ? system_call_fastpath+0x1a/0x1f
Comment 3 Robert Varga 2013-05-27 16:13:43 UTC
Since this is not moving ahead, here's a stack trace from 3.9.4:

Call Trace:
 <IRQ>  [<ffffffff81268e82>] ? showacpu+0x42/0x60
 [<ffffffff8108b0b5>] ? generic_smp_call_function_single_interrupt+0xb5/0x120
 [<ffffffff81023c42>] ? smp_call_function_interrupt+0x22/0x40 
 [<ffffffff814a553a>] ? call_function_interrupt+0x6a/0x70
 <EOI>  [<ffffffff814a3fd6>] ? retint_kernel+0x26/0x30
 [<ffffffff8123aa02>] ? ioread32+0x42/0x50
 [<ffffffffa03c1ce2>] ? nv04_timer_read+0x32/0x60 [nouveau]
 [<ffffffffa03c1a2a>] ? nouveau_timer_wait_eq+0x6a/0xd0 [nouveau]
 [<ffffffffa03cb40e>] ? nv50_dac_power+0x3e/0xa0 [nouveau]
 [<ffffffffa0439ed5>] ? nv50_dac_detect+0x75/0x90 [nouveau]
 [<ffffffffa0425ead>] ? nouveau_connector_detect+0x3cd/0x3e0 [nouveau]
 [<ffffffff812deebf>] ? status_show+0x3f/0x90
 [<ffffffff81350ac7>] ? dev_attr_show+0x17/0x50
 [<ffffffff810e0d02>] ? __get_free_pages+0x12/0x50
 [<ffffffff8118b15e>] ? sysfs_read_file+0xae/0x1a0
 [<ffffffff81124ce0>] ? vfs_read+0xa0/0x160
 [<ffffffff81124f31>] ? sys_read+0x51/0xa0
 [<ffffffff814a4616>] ? system_call_fastpath+0x1a/0x1f
Comment 4 Robert Varga 2013-05-27 16:23:48 UTC
Created attachment 79854 [details] [review]
Proposed fix

Tested on 3.9.4, seems to hide/fix the issue.
Comment 5 Pierre Moreau 2015-01-17 00:12:14 UTC
I did a quick check and it doesn't seem like the proposed fix was merged. Does it still occur on a recent kernel (3.18, 3.19-rc4)?


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.