| Summary: | nouveau driver does not return VGA connector status breaking upower | ||||||
|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | nuada | ||||
| Component: | Driver/nouveau | Assignee: | Nouveau Project <nouveau> | ||||
| Status: | RESOLVED MOVED | QA Contact: | Xorg Project Team <xorg-team> | ||||
| Severity: | normal | ||||||
| Priority: | medium | CC: | basinilya, mpagano, v_2e | ||||
| Version: | unspecified | ||||||
| Hardware: | x86-64 (AMD64) | ||||||
| OS: | Linux (All) | ||||||
| Whiteboard: | |||||||
| i915 platform: | i915 features: | ||||||
| Attachments: |
|
||||||
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 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 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 Created attachment 79854 [details] [review] Proposed fix Tested on 3.9.4, seems to hide/fix the issue. 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)? -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/15. |
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.
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