https://bugs.freedesktop.org/show_bug.cgi?id=33999 --- Comment #8 from Alex Buell <alex.buell at munted.org.uk> 2011-03-01 03:01:51 PST --- http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=ace98a492353e6de712f4f717e6d3f562e3591f0 fixes the crash in the X server. (thanks to pq) There are still problems, but trying 2.6.38-rc6 at the moment. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at freedesktop.org Tue Mar 1 08:05:45 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Tue, 1 Mar 2011 08:05:45 -0800 (PST) Subject: [Bug 33445] NVS 3100M : Blank screen on kernel module loading In-Reply-To: <bug-33445-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> References: <bug-33445-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> Message-ID: <20110301160545.63E26130009@xxxxxxxxxxxxxxxxxxxxxxxx> https://bugs.freedesktop.org/show_bug.cgi?id=33445 --- Comment #8 from celelibi at gmail.com 2011-03-01 08:05:44 PST --- As I've been told on IRC, here is a mmio trace when loading nouveau. http://ompldr.org/vN200OQ It contains two marks : before running modprobe nouveau, and after it complete. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From madman2003 at gmail.com Tue Mar 1 13:08:31 2011 From: madman2003 at gmail.com (Maarten Maathuis) Date: Tue, 1 Mar 2011 21:08:31 +0000 Subject: CCACHE and VFETCH FAULTs causing lockups Message-ID: <AANLkTik0CkbQz=PoXNG7bQEn_5ssAfp7cr=Z=3qJz6h2@xxxxxxxxxxxxxx> Mar 1 18:21:23 madman kernel: [ 1697.116256] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_VFETCH FAULT Mar 1 18:21:23 madman kernel: [ 1697.116275] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_VFETCH 00f00000 0000fe0c 00000000 00000000 Mar 1 18:21:23 madman kernel: [ 1697.116283] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_CCACHE FAULT Mar 1 18:21:23 madman kernel: [ 1697.116299] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_CCACHE 00000080 00000000 00000000 00000000 00000000 00000004 00000000 Mar 1 18:21:23 madman kernel: [ 1697.116306] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP Mar 1 18:21:23 madman kernel: [ 1697.116318] [drm] nouveau 0000:01:00.0: PGRAPH - ch 3 (0x00018f3000) subc 7 class 0x8297 mthd 0x15e0 data 0x00000000 Mar 1 18:21:23 madman kernel: [ 1697.116330] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_VFETCH FAULT Mar 1 18:21:23 madman kernel: [ 1697.116342] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_VFETCH 00f00000 0000fe0c 00000000 00000000 Mar 1 18:21:23 madman kernel: [ 1697.116349] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_CCACHE FAULT Mar 1 18:21:23 madman kernel: [ 1697.116363] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_CCACHE 00000080 00000000 00000000 00000000 00000000 00000004 00080000 Mar 1 18:21:23 madman kernel: [ 1697.116371] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP Mar 1 18:21:23 madman kernel: [ 1697.116380] [drm] nouveau 0000:01:00.0: PGRAPH - ch 3 (0x00018f3000) subc 7 class 0x8297 mthd 0x1084 data 0x219d6fff Mar 1 18:21:23 madman kernel: [ 1697.116392] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_VFETCH FAULT Mar 1 18:21:23 madman kernel: [ 1697.116404] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_VFETCH 00f00000 0000fe0c 00000000 00000000 Mar 1 18:21:23 madman kernel: [ 1697.116410] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP Mar 1 18:21:23 madman kernel: [ 1697.116420] [drm] nouveau 0000:01:00.0: PGRAPH - ch 3 (0x00018f3000) subc 7 class 0x8297 mthd 0x15e0 data 0x00000000 Mar 1 18:21:29 madman kernel: [ 1703.981014] [drm] nouveau 0000:01:00.0: Failed to idle channel 3. Mar 1 18:21:31 madman kernel: [ 1705.601034] [drm] nouveau 0000:01:00.0: Ctxprog is still running Those come after 15-30 minutes of running warzone2100, i haven't played any games for a while, so no idea how long this has been going on. I also got a TRAP_CCACHE on channel 2 a little while ago, it takes much longer to trigger (a few hours). I'm using todays "nouveau kernel" git. I'm guessing something is being unmapped too early or without reason, or some cache is stale. But it isn't obvious what exactly it is. Because i don't remember having these lockups before I'm inclined to guess that this commit is involved http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=6330d8f5ecc4a19fd2ad3c7fa128b2f4c2ce3360 Any ideas? Maarten. -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. From madman2003 at gmail.com Tue Mar 1 13:25:25 2011 From: madman2003 at gmail.com (Maarten Maathuis) Date: Tue, 1 Mar 2011 21:25:25 +0000 Subject: CCACHE and VFETCH FAULTs causing lockups In-Reply-To: <AANLkTik0CkbQz=PoXNG7bQEn_5ssAfp7cr=Z=3qJz6h2@xxxxxxxxxxxxxx> References: <AANLkTik0CkbQz=PoXNG7bQEn_5ssAfp7cr=Z=3qJz6h2@xxxxxxxxxxxxxx> Message-ID: <AANLkTikRgt0Ri6m_cw_4KjLE8rOCgBA9mzeaNrV6ATse@xxxxxxxxxxxxxx> On Tue, Mar 1, 2011 at 9:08 PM, Maarten Maathuis <madman2003 at gmail.com> wrote: > Mar ?1 18:21:23 madman kernel: [ 1697.116256] [drm] nouveau > 0000:01:00.0: PGRAPH - TRAP_VFETCH FAULT > Mar ?1 18:21:23 madman kernel: [ 1697.116275] [drm] nouveau > 0000:01:00.0: PGRAPH - TRAP_VFETCH 00f00000 0000fe0c 00000000 00000000 > Mar ?1 18:21:23 madman kernel: [ 1697.116283] [drm] nouveau > 0000:01:00.0: PGRAPH - TRAP_CCACHE FAULT > Mar ?1 18:21:23 madman kernel: [ 1697.116299] [drm] nouveau > 0000:01:00.0: PGRAPH - TRAP_CCACHE 00000080 00000000 00000000 00000000 > 00000000 00000004 00000000 > Mar ?1 18:21:23 madman kernel: [ 1697.116306] [drm] nouveau > 0000:01:00.0: PGRAPH - TRAP > Mar ?1 18:21:23 madman kernel: [ 1697.116318] [drm] nouveau > 0000:01:00.0: PGRAPH - ch 3 (0x00018f3000) subc 7 class 0x8297 mthd > 0x15e0 data 0x00000000 > Mar ?1 18:21:23 madman kernel: [ 1697.116330] [drm] nouveau > 0000:01:00.0: PGRAPH - TRAP_VFETCH FAULT > Mar ?1 18:21:23 madman kernel: [ 1697.116342] [drm] nouveau > 0000:01:00.0: PGRAPH - TRAP_VFETCH 00f00000 0000fe0c 00000000 00000000 > Mar ?1 18:21:23 madman kernel: [ 1697.116349] [drm] nouveau > 0000:01:00.0: PGRAPH - TRAP_CCACHE FAULT > Mar ?1 18:21:23 madman kernel: [ 1697.116363] [drm] nouveau > 0000:01:00.0: PGRAPH - TRAP_CCACHE 00000080 00000000 00000000 00000000 > 00000000 00000004 00080000 > Mar ?1 18:21:23 madman kernel: [ 1697.116371] [drm] nouveau > 0000:01:00.0: PGRAPH - TRAP > Mar ?1 18:21:23 madman kernel: [ 1697.116380] [drm] nouveau > 0000:01:00.0: PGRAPH - ch 3 (0x00018f3000) subc 7 class 0x8297 mthd > 0x1084 data 0x219d6fff > Mar ?1 18:21:23 madman kernel: [ 1697.116392] [drm] nouveau > 0000:01:00.0: PGRAPH - TRAP_VFETCH FAULT > Mar ?1 18:21:23 madman kernel: [ 1697.116404] [drm] nouveau > 0000:01:00.0: PGRAPH - TRAP_VFETCH 00f00000 0000fe0c 00000000 00000000 > Mar ?1 18:21:23 madman kernel: [ 1697.116410] [drm] nouveau > 0000:01:00.0: PGRAPH - TRAP > Mar ?1 18:21:23 madman kernel: [ 1697.116420] [drm] nouveau > 0000:01:00.0: PGRAPH - ch 3 (0x00018f3000) subc 7 class 0x8297 mthd > 0x15e0 data 0x00000000 > Mar ?1 18:21:29 madman kernel: [ 1703.981014] [drm] nouveau > 0000:01:00.0: Failed to idle channel 3. > Mar ?1 18:21:31 madman kernel: [ 1705.601034] [drm] nouveau > 0000:01:00.0: Ctxprog is still running > > Those come after 15-30 minutes of running warzone2100, i haven't > played any games for a while, so no idea how long this has been going > on. > I also got a TRAP_CCACHE on channel 2 a little while ago, it takes > much longer to trigger (a few hours). I'm using todays "nouveau > kernel" git. > > I'm guessing something is being unmapped too early or without reason, > or some cache is stale. But it isn't obvious what exactly it is. > > Because i don't remember having these lockups before I'm inclined to > guess that this commit is involved > http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=6330d8f5ecc4a19fd2ad3c7fa128b2f4c2ce3360 > > Any ideas? > > Maarten. > > -- > Far away from the primal instinct, the song seems to fade away, the > river get wider between your thoughts and the things we do and say. > This is the "DDX" trap: Mar 1 22:19:48 madman kernel: [ 1499.376769] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_CCACHE FAULT Mar 1 22:19:48 madman kernel: [ 1499.376782] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_CCACHE 00000080 00000000 00000000 00000000 00000000 00000004 00000000 Mar 1 22:19:48 madman kernel: [ 1499.376785] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP Mar 1 22:19:48 madman kernel: [ 1499.376790] [drm] nouveau 0000:01:00.0: PGRAPH - ch 2 (0x0000840000) subc 5 class 0x8297 mthd 0x0f04 data 0x00000000 -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. From bskeggs at redhat.com Tue Mar 1 13:51:07 2011 From: bskeggs at redhat.com (Ben Skeggs) Date: Wed, 02 Mar 2011 07:51:07 +1000 Subject: CCACHE and VFETCH FAULTs causing lockups In-Reply-To: <AANLkTik0CkbQz=PoXNG7bQEn_5ssAfp7cr=Z=3qJz6h2@xxxxxxxxxxxxxx> References: <AANLkTik0CkbQz=PoXNG7bQEn_5ssAfp7cr=Z=3qJz6h2@xxxxxxxxxxxxxx> Message-ID: <1299016269.1822.3.camel@nisroch> On Tue, 2011-03-01 at 21:08 +0000, Maarten Maathuis wrote: > Those come after 15-30 minutes of running warzone2100, i haven't > played any games for a while, so no idea how long this has been going > on. > I also got a TRAP_CCACHE on channel 2 a little while ago, it takes > much longer to trigger (a few hours). I'm using todays "nouveau > kernel" git. You're not the first person to have reported this fwiw, personally, I haven't seen it yet.. > > I'm guessing something is being unmapped too early or without reason, > or some cache is stale. But it isn't obvious what exactly it is. > > Because i don't remember having these lockups before I'm inclined to > guess that this commit is involved > http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=6330d8f5ecc4a19fd2ad3c7fa128b2f4c2ce3360 > > Any ideas? Not really. If this commit *is* the cause, the problem is still somewhere else. That commit just makes sure PTEs are marked invalid, so if it's causing your faults, then previously the GPU would still have been reading/writing invalid data. Plus, I expect you should probably have seen a VM fault.. Ben. > > Maarten. > From madman2003 at gmail.com Tue Mar 1 14:20:23 2011 From: madman2003 at gmail.com (Maarten Maathuis) Date: Tue, 1 Mar 2011 22:20:23 +0000 Subject: CCACHE and VFETCH FAULTs causing lockups In-Reply-To: <1299016269.1822.3.camel@nisroch> References: <AANLkTik0CkbQz=PoXNG7bQEn_5ssAfp7cr=Z=3qJz6h2@xxxxxxxxxxxxxx> <1299016269.1822.3.camel@nisroch> Message-ID: <AANLkTimiy=U04vfiXRAqDj_eT+zxSN2_3NvmF4jRQWxc@xxxxxxxxxxxxxx> On Tue, Mar 1, 2011 at 9:51 PM, Ben Skeggs <bskeggs at redhat.com> wrote: > On Tue, 2011-03-01 at 21:08 +0000, Maarten Maathuis wrote: > >> Those come after 15-30 minutes of running warzone2100, i haven't >> played any games for a while, so no idea how long this has been going >> on. >> I also got a TRAP_CCACHE on channel 2 a little while ago, it takes >> much longer to trigger (a few hours). I'm using todays "nouveau >> kernel" git. > You're not the first person to have reported this fwiw, personally, I > haven't seen it yet.. > >> >> I'm guessing something is being unmapped too early or without reason, >> or some cache is stale. But it isn't obvious what exactly it is. >> >> Because i don't remember having these lockups before I'm inclined to >> guess that this commit is involved >> http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=6330d8f5ecc4a19fd2ad3c7fa128b2f4c2ce3360 >> >> Any ideas? > Not really. ?If this commit *is* the cause, the problem is still > somewhere else. ?That commit just makes sure PTEs are marked invalid, so > if it's causing your faults, then previously the GPU would still have > been reading/writing invalid data. > > Plus, I expect you should probably have seen a VM fault.. So these faults are just generic errors? Unrelated to page faults? > > Ben. >> >> Maarten. >> > > > -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. From bugzilla-daemon at freedesktop.org Wed Mar 2 05:33:46 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Wed, 2 Mar 2011 05:33:46 -0800 (PST) Subject: [Bug 34919] New: DVI Dock Connectors: Signal but not usable. Message-ID: <bug-34919-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> https://bugs.freedesktop.org/show_bug.cgi?id=34919 Summary: DVI Dock Connectors: Signal but not usable. Product: xorg Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org ReportedBy: kirchmeyer at gmail.com QAContact: xorg-team at lists.x.org When monitor(s) plugged into DVI port(s) (any combination), the monitor stays black as if it has a signal (no check cable message) however they are not available to use. xrandr does not report any DVI ports. Please let me know what further information would be useful. VGA seems to work... xrandr Screen 0: minimum 320 x 200, current 1680 x 1050, maximum 8192 x 8192 LVDS-1 unknown connection (normal left inverted right x axis y axis) 1920x1200 60.0 + 59.9 1920x1080 60.0 1600x1200 59.9 1680x1050 60.0 1400x1050 60.0 1280x1024 59.9 1280x960 59.9 1152x864 60.0 1024x768 59.9 800x600 59.9 640x480 59.4 720x400 59.6 640x400 60.0 640x350 59.8 VGA-1 connected 1680x1050+0+0 (normal left inverted right x axis y axis) 434mm x 270mm 1680x1050 59.9*+ 60.0 1280x1024 75.0 60.0 1440x900 75.0 59.9 1280x960 60.0 1152x864 75.0 1024x768 75.1 60.0 832x624 74.6 800x600 75.0 60.3 56.2 640x480 75.0 60.0 720x400 70.1 dmesg | grep drm [drm] Initialized drm 1.1.0 20060810 [drm] nouveau 0000:01:00.0: Detected an NV50 generation card (0x092f00a2) [drm] nouveau 0000:01:00.0: Attempting to load BIOS image from PRAMIN [drm] nouveau 0000:01:00.0: ... appears to be valid [drm] nouveau 0000:01:00.0: BIT BIOS found [drm] nouveau 0000:01:00.0: Bios version 62.92.5a.00 [drm] nouveau 0000:01:00.0: TMDS table version 2.0 [drm] nouveau 0000:01:00.0: Found Display Configuration Block version 4.0 [drm] nouveau 0000:01:00.0: Raw DCB entry 0: 01000323 00010034 [drm] nouveau 0000:01:00.0: Raw DCB entry 1: 02011300 00000028 [drm] nouveau 0000:01:00.0: Raw DCB entry 2: 01122306 0f220d00 [drm] nouveau 0000:01:00.0: Raw DCB entry 3: 01122302 00020d00 [drm] nouveau 0000:01:00.0: Raw DCB entry 4: 02133316 0f320e00 [drm] nouveau 0000:01:00.0: Raw DCB entry 5: 02133312 00120e00 [drm] nouveau 0000:01:00.0: Raw DCB entry 6: 0000000e 00000000 [drm] nouveau 0000:01:00.0: DCB connector table: VHER 0x40 5 16 4 [drm] nouveau 0000:01:00.0: 0: 0x00000040: type 0x40 idx 0 tag 0xff [drm] nouveau 0000:01:00.0: 1: 0x00000100: type 0x00 idx 1 tag 0xff [drm] nouveau 0000:01:00.0: 2: 0x00005246: type 0x46 idx 2 tag 0x07 [drm] nouveau 0000:01:00.0: 3: 0x0000a346: type 0x46 idx 3 tag 0x08 [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 0 at offset 0xCF9A [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 1 at offset 0xD4E5 [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 2 at offset 0xE24D [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 3 at offset 0xE34B [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 4 at offset 0xE5B3 [drm] nouveau 0000:01:00.0: Parsing VBIOS init table at offset 0xE618 [drm] nouveau 0000:01:00.0: 0xE618: Condition still not met after 20ms, skipping following opcodes [drm] nouveau 0000:01:00.0: 4 available performance level(s) [drm] nouveau 0000:01:00.0: 0: memory 100MHz core 200MHz shader 400MHz voltage 850mV fanspeed 100% [drm] nouveau 0000:01:00.0: 1: memory 301MHz core 275MHz shader 550MHz voltage 850mV fanspeed 100% [drm] nouveau 0000:01:00.0: 2: memory 301MHz core 383MHz shader 767MHz voltage 850mV fanspeed 100% [drm] nouveau 0000:01:00.0: 3: memory 799MHz core 550MHz shader 1375MHz voltage 1000mV fanspeed 100% [drm] nouveau 0000:01:00.0: c: memory 300MHz core 275MHz shader 1100MHz [drm] nouveau 0000:01:00.0: Detected 1024MiB VRAM [drm] nouveau 0000:01:00.0: 512 MiB GART (aperture) [drm] nouveau 0000:01:00.0: Off-chip encoder 6/0 unsupported [drm] nouveau 0000:01:00.0: Off-chip encoder 2/0 unsupported [drm] nouveau 0000:01:00.0: Off-chip encoder 6/1 unsupported [drm] nouveau 0000:01:00.0: Off-chip encoder 2/1 unsupported [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [drm] No driver support for vblank timestamp query. [drm] nouveau 0000:01:00.0: ACPI backlight interface available, not registering our own [drm] nouveau 0000:01:00.0: allocated 1680x1050 fb: 0x60000000, bo ffff88040d20a400 drm: registered panic notifier [drm] Initialized nouveau 0.0.16 20090420 for 0000:01:00.0 on minor 0 [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 92 [drm:drm_edid_block_valid] *ERROR* Raw EDID: [drm] nouveau 0000:01:00.0: DDC responded, but no EDID for VGA-1 [drm] nouveau 0000:01:00.0: DDC responded, but no EDID for VGA-1 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at freedesktop.org Wed Mar 2 05:42:29 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Wed, 2 Mar 2011 05:42:29 -0800 (PST) Subject: [Bug 34919] DVI Dock Connectors: Signal but not usable. In-Reply-To: <bug-34919-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> References: <bug-34919-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> Message-ID: <20110302134229.265D4130009@xxxxxxxxxxxxxxxxxxxxxxxx> https://bugs.freedesktop.org/show_bug.cgi?id=34919 --- Comment #1 from Maarten Maathuis <madman2003 at gmail.com> 2011-03-02 05:42:28 PST --- The reason is: [drm] nouveau 0000:01:00.0: Off-chip encoder 6/0 unsupported [drm] nouveau 0000:01:00.0: Off-chip encoder 2/0 unsupported [drm] nouveau 0000:01:00.0: Off-chip encoder 6/1 unsupported [drm] nouveau 0000:01:00.0: Off-chip encoder 2/1 unsupported No idea how much work it is to implement support. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at freedesktop.org Wed Mar 2 05:48:07 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Wed, 2 Mar 2011 05:48:07 -0800 (PST) Subject: [Bug 34919] DVI Dock Connectors: Signal but not usable. In-Reply-To: <bug-34919-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> References: <bug-34919-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> Message-ID: <20110302134807.8931A130005@xxxxxxxxxxxxxxxxxxxxxxxx> https://bugs.freedesktop.org/show_bug.cgi?id=34919 --- Comment #2 from kirchmeyer at gmail.com 2011-03-02 05:48:07 PST --- Ok well at least I know it's not something I'm doing wrong. Honestly this is the only reason that keeps me from sticking with nouveau. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From madman2003 at gmail.com Wed Mar 2 14:43:38 2011 From: madman2003 at gmail.com (Maarten Maathuis) Date: Wed, 2 Mar 2011 22:43:38 +0000 Subject: CCACHE and VFETCH FAULTs causing lockups In-Reply-To: <1299016269.1822.3.camel@nisroch> References: <AANLkTik0CkbQz=PoXNG7bQEn_5ssAfp7cr=Z=3qJz6h2@xxxxxxxxxxxxxx> <1299016269.1822.3.camel@nisroch> Message-ID: <AANLkTimwGyz1d=W_ZdcaBARO0sw=wZ470Cwy+8407s-m@xxxxxxxxxxxxxx> On Tue, Mar 1, 2011 at 9:51 PM, Ben Skeggs <bskeggs at redhat.com> wrote: > On Tue, 2011-03-01 at 21:08 +0000, Maarten Maathuis wrote: > >> Those come after 15-30 minutes of running warzone2100, i haven't >> played any games for a while, so no idea how long this has been going >> on. >> I also got a TRAP_CCACHE on channel 2 a little while ago, it takes >> much longer to trigger (a few hours). I'm using todays "nouveau >> kernel" git. > You're not the first person to have reported this fwiw, personally, I > haven't seen it yet.. > >> >> I'm guessing something is being unmapped too early or without reason, >> or some cache is stale. But it isn't obvious what exactly it is. >> >> Because i don't remember having these lockups before I'm inclined to >> guess that this commit is involved >> http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=6330d8f5ecc4a19fd2ad3c7fa128b2f4c2ce3360 >> >> Any ideas? > Not really. ?If this commit *is* the cause, the problem is still > somewhere else. ?That commit just makes sure PTEs are marked invalid, so > if it's causing your faults, then previously the GPU would still have > been reading/writing invalid data. I reverted the commit today and things seem to be going be better, I'll give it a few more days before coming to a conclusion. I understand that the real issue is somewhere else. > > Plus, I expect you should probably have seen a VM fault.. > > Ben. >> >> Maarten. >> > > > -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. From airlied at gmail.com Thu Mar 3 01:36:09 2011 From: airlied at gmail.com (Dave Airlie) Date: Thu, 3 Mar 2011 19:36:09 +1000 Subject: [lm-sensors] hwmon API update In-Reply-To: <20110213230833.0ee2ff16@xxxxxxxxxxxxxxxx> References: <4D57CC24.1040306@xxxxxxx> <20110213171640.GB13323@xxxxxxxxxxxx> <20110213230833.0ee2ff16@xxxxxxxxxxxxxxxx> Message-ID: <AANLkTindG=m4FhNS202MH8YVBUCoDEADTQLxo-Bf_8qx@xxxxxxxxxxxxxx> On Mon, Feb 14, 2011 at 8:08 AM, Jean Delvare <khali at linux-fr.org> wrote: > On Sun, 13 Feb 2011 09:16:40 -0800, Guenter Roeck wrote: >> On Sun, Feb 13, 2011 at 07:18:44AM -0500, Martin Peres wrote: >> > Hi, >> > >> > I am working on power management on the nouveau driver and I need a way >> > to get data out of and send commands to the i2c drivers from the kernel >> > space. Martin, you probably should have cc'ed Matthew since it was his patch you based this on, and I think he can provide a good explaination. to clarify some points, radeon does probably want something exactly like this, we just haven't gotten to it completely yet, I'd rather not have two drivers in the kernel for exact same hardware, and I believe sharing the hwmon code to do what we want is a good plan since you don't go around reinventing wheels, but if hwmon/i2c maintainers have no interest it leaves with little choice but to implement about 5-10 i2c drivers again in drm codebase. Maybe hwmon/i2c maintainers could suggest a cleaner way to implement what we want, which I think I can summarize as a) access to monitored values in-kernel b) no userspace access to the same values except via sanitised via the driver. though I'm not following this as closely as I should so I may have missed something. Dave. From martin.peres at free.fr Thu Mar 3 05:09:54 2011 From: martin.peres at free.fr (Martin Peres) Date: Thu, 03 Mar 2011 14:09:54 +0100 Subject: [lm-sensors] hwmon API update In-Reply-To: <AANLkTindG=m4FhNS202MH8YVBUCoDEADTQLxo-Bf_8qx@xxxxxxxxxxxxxx> References: <4D57CC24.1040306@xxxxxxx> <20110213171640.GB13323@xxxxxxxxxxxx> <20110213230833.0ee2ff16@xxxxxxxxxxxxxxxx> <AANLkTindG=m4FhNS202MH8YVBUCoDEADTQLxo-Bf_8qx@xxxxxxxxxxxxxx> Message-ID: <4D6F9322.3080209@xxxxxxx> Dave, The answers are inlined. Le 03/03/2011 10:36, Dave Airlie a ?crit : > Martin, > > you probably should have cc'ed Matthew since it was his patch you based this on, > and I think he can provide a good explaination. I knew he was monitoring the nouveau ML. He provided a good explanation but forgot to CC the nouveau ML. Could someone in the lm-sensors mailing list forward the most important thread? > to clarify some points, > > radeon does probably want something exactly like this, we just haven't gotten to > it completely yet, I'd rather not have two drivers in the kernel for > exact same hardware, > and I believe sharing the hwmon code to do what we want is a good plan since you > don't go around reinventing wheels, but if hwmon/i2c maintainers have > no interest > it leaves with little choice but to implement about 5-10 i2c drivers > again in drm codebase. > > Maybe hwmon/i2c maintainers could suggest a cleaner way to implement > what we want, > which I think I can summarize as > > a) access to monitored values in-kernel > b) no userspace access to the same values except via sanitised via the driver. a) is mandatory, b) would be great! > though I'm not following this as closely as I should so I may have > missed something. I don't think you missed anything but long argue on the lm-sensors ML. > Dave. The reason why I didn't answer on this matter earlier was that I was in the process of moving from one city to another. I only got the internet access on both my computers yesterday evening and I was planing to restart the process this week end. It's good to see you we are not the only one needing this. Martin From martin.peres at free.fr Thu Mar 3 09:29:22 2011 From: martin.peres at free.fr (Martin Peres) Date: Thu, 03 Mar 2011 18:29:22 +0100 Subject: [lm-sensors] hwmon API update In-Reply-To: <20110303152216.GA21667@xxxxxxxxxxxx> References: <4D57CC24.1040306@xxxxxxx> <20110213171640.GB13323@xxxxxxxxxxxx> <20110213230833.0ee2ff16@xxxxxxxxxxxxxxxx> <AANLkTindG=m4FhNS202MH8YVBUCoDEADTQLxo-Bf_8qx@xxxxxxxxxxxxxx> <20110303152216.GA21667@xxxxxxxxxxxx> Message-ID: <4D6FCFF2.7040604@xxxxxxx> Le 03/03/2011 16:22, Guenter Roeck a ?crit : > On Thu, Mar 03, 2011 at 04:36:09AM -0500, Dave Airlie wrote: >> On Mon, Feb 14, 2011 at 8:08 AM, Jean Delvare<khali at linux-fr.org> wrote: >>> On Sun, 13 Feb 2011 09:16:40 -0800, Guenter Roeck wrote: >>>> On Sun, Feb 13, 2011 at 07:18:44AM -0500, Martin Peres wrote: >>>>> Hi, >>>>> >>>>> I am working on power management on the nouveau driver and I need a way >>>>> to get data out of and send commands to the i2c drivers from the kernel >>>>> space. >> Martin, >> >> you probably should have cc'ed Matthew since it was his patch you based this on, >> and I think he can provide a good explaination. >> >> to clarify some points, >> >> radeon does probably want something exactly like this, we just haven't gotten to >> it completely yet, I'd rather not have two drivers in the kernel for >> exact same hardware, >> and I believe sharing the hwmon code to do what we want is a good plan since you >> don't go around reinventing wheels, but if hwmon/i2c maintainers have >> no interest >> it leaves with little choice but to implement about 5-10 i2c drivers >> again in drm codebase. >> >> Maybe hwmon/i2c maintainers could suggest a cleaner way to implement >> what we want, >> which I think I can summarize as >> >> a) access to monitored values in-kernel >> b) no userspace access to the same values except via sanitised via the driver. >> > This is not a matter of "no interest". Interest is there, but if one demands > too much one may get nothing. > > Request for b) so far was "no userspace access", period. This is unacceptable > since providing userspace access to monitored values is the whole point of hwmon. > > I could imagine an API that covers both a) and b), as long as b) focuses > on the "sanitize" aspect and doesn't try to limit userspace access to attributes. > > Guenter b) was introduced by Dave, I never asked for it because I don't mind duplicating sensor data (one hwmon device named nouveau and one for the raw access to the i2c chip). My only wish was to provide a simple way for users to read/change their fan speed and get the GPU temperature no matter if their card have an i2c controller or not. I do agree that sanitizing could be of interest, I especially think about tweaking the temperature value with parameters stored inside the vbios. I am fully open to suggestions as long as it involves sharing the code in one way or another. Martin From koriakim at 0x04.net Tue Mar 1 14:06:15 2011 From: koriakim at 0x04.net (koriakim at 0x04.net) Date: Tue, 01 Mar 2011 23:06:15 +0100 Subject: CCACHE and VFETCH FAULTs causing lockups In-Reply-To: <AANLkTimiy=U04vfiXRAqDj_eT+zxSN2_3NvmF4jRQWxc@xxxxxxxxxxxxxx> References: <AANLkTik0CkbQz=PoXNG7bQEn_5ssAfp7cr=Z=3qJz6h2@xxxxxxxxxxxxxx> <1299016269.1822.3.camel@nisroch> <AANLkTimiy=U04vfiXRAqDj_eT+zxSN2_3NvmF4jRQWxc@xxxxxxxxxxxxxx> Message-ID: <1299017175.4061.6.camel@bandersnatch> > So these faults are just generic errors? Unrelated to page faults? These faults *are* page faults, in a way. On nv50, page faults are quite weird. When a fault happens, the MMU's fault reporting registers at 0x100c90 are filled with fault information, and the 'fault pending' flag is set. This is what nouveau reports as VM FAULT. However, this does NOT trigger any specific interrupt - the fault is instead reported to requesting engine, which in turn reports an engine-specific interrupt, like VFETCH FAULT or CCACHE FAULT. These interrupts sometimes [eg for TPROP traps] also report some more useful information in engine-specific registers. Usually getting an engine fault implies getting a VM fault, but not always, so nouveau reports them separately - it only uses the engine fault as a trigger to check for new VM faults, but does not associate them in any way. The reasons for mismatches could be: - Interrupts that trigger VM fault in some cases, but not in others: DMA_PUSHER/MEM_FAULT can happen due to DMA_LIMIT overrun, or due to VM fault - Multiple VM faults in quick succession will result in only one of them being reported as VM fault, but all of them as engine faults Hope this clears things up. Marcin Ko?cielnicki -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/nouveau/attachments/20110301/dd44239f/attachment.htm> From guenter.roeck at ericsson.com Thu Mar 3 07:22:16 2011 From: guenter.roeck at ericsson.com (Guenter Roeck) Date: Thu, 3 Mar 2011 07:22:16 -0800 Subject: [lm-sensors] hwmon API update In-Reply-To: <AANLkTindG=m4FhNS202MH8YVBUCoDEADTQLxo-Bf_8qx@xxxxxxxxxxxxxx> References: <4D57CC24.1040306@xxxxxxx> <20110213171640.GB13323@xxxxxxxxxxxx> <20110213230833.0ee2ff16@xxxxxxxxxxxxxxxx> <AANLkTindG=m4FhNS202MH8YVBUCoDEADTQLxo-Bf_8qx@xxxxxxxxxxxxxx> Message-ID: <20110303152216.GA21667@xxxxxxxxxxxx> On Thu, Mar 03, 2011 at 04:36:09AM -0500, Dave Airlie wrote: > On Mon, Feb 14, 2011 at 8:08 AM, Jean Delvare <khali at linux-fr.org> wrote: > > On Sun, 13 Feb 2011 09:16:40 -0800, Guenter Roeck wrote: > >> On Sun, Feb 13, 2011 at 07:18:44AM -0500, Martin Peres wrote: > >> > Hi, > >> > > >> > I am working on power management on the nouveau driver and I need a way > >> > to get data out of and send commands to the i2c drivers from the kernel > >> > space. > > Martin, > > you probably should have cc'ed Matthew since it was his patch you based this on, > and I think he can provide a good explaination. > > to clarify some points, > > radeon does probably want something exactly like this, we just haven't gotten to > it completely yet, I'd rather not have two drivers in the kernel for > exact same hardware, > and I believe sharing the hwmon code to do what we want is a good plan since you > don't go around reinventing wheels, but if hwmon/i2c maintainers have > no interest > it leaves with little choice but to implement about 5-10 i2c drivers > again in drm codebase. > > Maybe hwmon/i2c maintainers could suggest a cleaner way to implement > what we want, > which I think I can summarize as > > a) access to monitored values in-kernel > b) no userspace access to the same values except via sanitised via the driver. > This is not a matter of "no interest". Interest is there, but if one demands too much one may get nothing. Request for b) so far was "no userspace access", period. This is unacceptable since providing userspace access to monitored values is the whole point of hwmon. I could imagine an API that covers both a) and b), as long as b) focuses on the "sanitize" aspect and doesn't try to limit userspace access to attributes. Guenter From dev at lynxeye.de Thu Mar 3 12:48:15 2011 From: dev at lynxeye.de (Lucas Stach) Date: Thu, 03 Mar 2011 21:48:15 +0100 Subject: [lm-sensors] hwmon API update In-Reply-To: <4D6FCFF2.7040604@xxxxxxx> References: <4D57CC24.1040306@xxxxxxx> <20110213171640.GB13323@xxxxxxxxxxxx> <20110213230833.0ee2ff16@xxxxxxxxxxxxxxxx> <AANLkTindG=m4FhNS202MH8YVBUCoDEADTQLxo-Bf_8qx@xxxxxxxxxxxxxx> <20110303152216.GA21667@xxxxxxxxxxxx> <4D6FCFF2.7040604@xxxxxxx> Message-ID: <1299185295.2255.13.camel@workstation> Am Donnerstag, den 03.03.2011, 18:29 +0100 schrieb Martin Peres: > Le 03/03/2011 16:22, Guenter Roeck a ?crit : > > On Thu, Mar 03, 2011 at 04:36:09AM -0500, Dave Airlie wrote: > >> On Mon, Feb 14, 2011 at 8:08 AM, Jean Delvare<khali at linux-fr.org> wrote: > >>> On Sun, 13 Feb 2011 09:16:40 -0800, Guenter Roeck wrote: > >>>> On Sun, Feb 13, 2011 at 07:18:44AM -0500, Martin Peres wrote: > >>>>> Hi, > >>>>> > >>>>> I am working on power management on the nouveau driver and I need a way > >>>>> to get data out of and send commands to the i2c drivers from the kernel > >>>>> space. > >> Martin, > >> > >> you probably should have cc'ed Matthew since it was his patch you based this on, > >> and I think he can provide a good explaination. > >> > >> to clarify some points, > >> > >> radeon does probably want something exactly like this, we just haven't gotten to > >> it completely yet, I'd rather not have two drivers in the kernel for > >> exact same hardware, > >> and I believe sharing the hwmon code to do what we want is a good plan since you > >> don't go around reinventing wheels, but if hwmon/i2c maintainers have > >> no interest > >> it leaves with little choice but to implement about 5-10 i2c drivers > >> again in drm codebase. > >> > >> Maybe hwmon/i2c maintainers could suggest a cleaner way to implement > >> what we want, > >> which I think I can summarize as > >> > >> a) access to monitored values in-kernel > >> b) no userspace access to the same values except via sanitised via the driver. > >> > > This is not a matter of "no interest". Interest is there, but if one demands > > too much one may get nothing. > > > > Request for b) so far was "no userspace access", period. This is unacceptable > > since providing userspace access to monitored values is the whole point of hwmon. And that is what we want to do. But it would be nice if the graphics drivers could provide a _single_ interface to userspace. Not all boards have i2c hardware monitoring chips and with a single interface we could fall back to the internal gpu sensor, transparently for the user. > > > > I could imagine an API that covers both a) and b), as long as b) focuses > > on the "sanitize" aspect and doesn't try to limit userspace access to attributes. > > > > Guenter > b) was introduced by Dave, I never asked for it because I don't mind > duplicating sensor data (one hwmon device named nouveau and one for the > raw access to the i2c chip). Sorry for the confusion Martin, I brought up the point of limiting userspace access and did not cc the nouveau mailing list. I think it is bad behaviour to expose values to userspace which are totally off the real values. This confuses users and should be avoided, especially since we can provide sanitized values. Why should we push the logic and api for sanitizing the values to many hwmon drivers if we could easily do this at a single point in the graphics driver, if we provide the userspace interface ourself and use the hwmon driver only to instrument the monitoring chip? > My only wish was to provide a simple way for users to read/change their > fan speed and get the GPU temperature no matter if their card have an > i2c controller or not. > I do agree that sanitizing could be of interest, I especially think > about tweaking the temperature value with parameters stored inside the > vbios. > > I am fully open to suggestions as long as it involves sharing the code > in one way or another. > > Martin > _______________________________________________ > Nouveau mailing list > Nouveau at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/nouveau > From bugzilla-daemon at freedesktop.org Thu Mar 3 13:14:12 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Thu, 3 Mar 2011 13:14:12 -0800 (PST) Subject: [Bug 31676] garbled text after loading nouveau module on EFI boot; X driver thinks there are no connected outputs In-Reply-To: <bug-31676-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> References: <bug-31676-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> Message-ID: <20110303211412.C1E9E130005@xxxxxxxxxxxxxxxxxxxxxxxx> https://bugs.freedesktop.org/show_bug.cgi?id=31676 --- Comment #13 from Armando Di Cianno <armando at goodship.net> 2011-03-03 13:14:12 PST --- I can confirm this bug, and especially comment #10 - I have exactly the same distortion in BIOS mode (not worrying about EFI here at the moment. As expected, the binary blob NVIDIA drivers work just fine. None of 2.6.35-gentoo-r5, or more importantly vanilla 2.6.37 or 2.6.36-rc7 work with nouveau. `dmesg |grep -e "drm" -e "nouveau" -e "nvidia"` on 2.6.38-rc7 looks like this: ##### [drm] Initialized drm 1.1.0 20060810 nouveau 0000:02:00.0: PCI INT A -> Link[LGPU] -> GSI 22 (level, low) -> IRQ 22 nouveau 0000:02:00.0: setting latency timer to 64 [drm] nouveau 0000:02:00.0: Detected an NV50 generation card (0x0af100a2) [drm] nouveau 0000:02:00.0: Attempting to load BIOS image from PRAMIN [drm] nouveau 0000:02:00.0: ... appears to be valid [drm] nouveau 0000:02:00.0: BIT BIOS found [drm] nouveau 0000:02:00.0: Bios version 70.89.13.00 [drm] nouveau 0000:02:00.0: Pointer to BIT loadval table invalid [drm] nouveau 0000:02:00.0: TMDS table version 2.0 [drm] nouveau 0000:02:00.0: Found Display Configuration Block version 4.0 [drm] nouveau 0000:02:00.0: Raw DCB entry 0: 040001b6 0f220010 [drm] nouveau 0000:02:00.0: Raw DCB entry 1: 020112a6 0f220010 [drm] nouveau 0000:02:00.0: Raw DCB entry 2: 02011262 00020010 [drm] nouveau 0000:02:00.0: Raw DCB entry 3: 0000000e 00000000 [drm] nouveau 0000:02:00.0: DCB connector table: VHER 0x40 5 16 4 [drm] nouveau 0000:02:00.0: 0: 0x00002047: type 0x47 idx 0 tag 0x08 [drm] nouveau 0000:02:00.0: 1: 0x00101146: type 0x46 idx 1 tag 0x07 [drm] nouveau 0000:02:00.0: Parsing VBIOS init table 0 at offset 0x6A0C [drm] nouveau 0000:02:00.0: 0x6CC8: Condition still not met after 20ms, skipping following opcodes [drm] nouveau 0000:02:00.0: Parsing VBIOS init table 1 at offset 0x6E7D [drm] nouveau 0000:02:00.0: Parsing VBIOS init table 2 at offset 0x6E7F [drm] nouveau 0000:02:00.0: Parsing VBIOS init table 3 at offset 0x6EB4 [drm] nouveau 0000:02:00.0: Parsing VBIOS init table 4 at offset 0x6F78 [drm] nouveau 0000:02:00.0: Parsing VBIOS init table at offset 0x6FDD [drm] nouveau 0000:02:00.0: 0x6FDD: Condition still not met after 20ms, skipping following opcodes [drm] nouveau 0000:02:00.0: 4 available performance level(s) [drm] nouveau 0000:02:00.0: 0: memory 405MHz core 405MHz shader 405MHz voltage 900mV [drm] nouveau 0000:02:00.0: 1: memory 450MHz core 450MHz shader 810MHz voltage 900mV [drm] nouveau 0000:02:00.0: 2: memory 450MHz core 450MHz shader 810MHz voltage 900mV [drm] nouveau 0000:02:00.0: 3: memory 450MHz core 450MHz shader 950MHz voltage 900mV [drm] nouveau 0000:02:00.0: c: memory 0MHz core 550MHz shader 1400MHz [drm] nouveau 0000:02:00.0: Detected 256MiB VRAM [drm] nouveau 0000:02:00.0: Stolen system memory at: 0x00af000000 [drm] nouveau 0000:02:00.0: 512 MiB GART (aperture) [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [drm] No driver support for vblank timestamp query. [drm] nouveau 0000:02:00.0: allocated 1366x768 fb: 0x60000000, bo ffff88013a93fc00 fb0: nouveaufb frame buffer device drm: registered panic notifier [drm] Initialized nouveau 0.0.16 20090420 for 0000:02:00.0 on minor 0 ehci_hcd 0000:00:04.1: disable lpm/ppcd for nvidia mcp89 ehci_hcd 0000:00:06.1: disable lpm/ppcd for nvidia mcp89 mbp_nvidia_bl: MacBookAir 3,1 detected Modules linked in: sco bnep rfcomm l2cap snd_hda_codec_hdmi snd_hda_codec_cirrus snd_hda_intel snd_hda_codec snd_hwdep snd_pcm uvcvideo snd_timer applesmc input_polldev mbp_nvidia_bl btusb snd snd_page_alloc mac_hid rtc_cmos xfs exportfs jfs reiserfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq raid1 raid0 dm_snapshot dm_mirror dm_region_hash dm_log scsi_wait_scan usbhid usb_storage hid_apple hid bcm5974 ##### Happy to test any patches or suggestions. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From dev at lynxeye.de Thu Mar 3 13:56:56 2011 From: dev at lynxeye.de (Lucas Stach) Date: Thu, 03 Mar 2011 22:56:56 +0100 Subject: [lm-sensors] hwmon API update In-Reply-To: <1299187158.18605.28.camel@groeck-laptop> References: <4D57CC24.1040306@xxxxxxx> <20110213171640.GB13323@xxxxxxxxxxxx> <20110213230833.0ee2ff16@xxxxxxxxxxxxxxxx> <AANLkTindG=m4FhNS202MH8YVBUCoDEADTQLxo-Bf_8qx@xxxxxxxxxxxxxx> <20110303152216.GA21667@xxxxxxxxxxxx> <4D6FCFF2.7040604@xxxxxxx> <1299185295.2255.13.camel@workstation> <1299187158.18605.28.camel@groeck-laptop> Message-ID: <1299189416.2255.22.camel@workstation> Am Donnerstag, den 03.03.2011, 13:19 -0800 schrieb Guenter Roeck: > On Thu, 2011-03-03 at 15:48 -0500, Lucas Stach wrote: > > Am Donnerstag, den 03.03.2011, 18:29 +0100 schrieb Martin Peres: > > > Le 03/03/2011 16:22, Guenter Roeck a ?crit : > > > > On Thu, Mar 03, 2011 at 04:36:09AM -0500, Dave Airlie wrote: > > > >> On Mon, Feb 14, 2011 at 8:08 AM, Jean Delvare<khali at linux-fr.org> wrote: > > > >>> On Sun, 13 Feb 2011 09:16:40 -0800, Guenter Roeck wrote: > > > >>>> On Sun, Feb 13, 2011 at 07:18:44AM -0500, Martin Peres wrote: > > > >>>>> Hi, > > > >>>>> > > > >>>>> I am working on power management on the nouveau driver and I need a way > > > >>>>> to get data out of and send commands to the i2c drivers from the kernel > > > >>>>> space. > > > >> Martin, > > > >> > > > >> you probably should have cc'ed Matthew since it was his patch you based this on, > > > >> and I think he can provide a good explaination. > > > >> > > > >> to clarify some points, > > > >> > > > >> radeon does probably want something exactly like this, we just haven't gotten to > > > >> it completely yet, I'd rather not have two drivers in the kernel for > > > >> exact same hardware, > > > >> and I believe sharing the hwmon code to do what we want is a good plan since you > > > >> don't go around reinventing wheels, but if hwmon/i2c maintainers have > > > >> no interest > > > >> it leaves with little choice but to implement about 5-10 i2c drivers > > > >> again in drm codebase. > > > >> > > > >> Maybe hwmon/i2c maintainers could suggest a cleaner way to implement > > > >> what we want, > > > >> which I think I can summarize as > > > >> > > > >> a) access to monitored values in-kernel > > > >> b) no userspace access to the same values except via sanitised via the driver. > > > >> > > > > This is not a matter of "no interest". Interest is there, but if one demands > > > > too much one may get nothing. > > > > > > > > Request for b) so far was "no userspace access", period. This is unacceptable > > > > since providing userspace access to monitored values is the whole point of hwmon. > > > > And that is what we want to do. But it would be nice if the graphics > > drivers could provide a _single_ interface to userspace. Not all boards > > have i2c hardware monitoring chips and with a single interface we could > > fall back to the internal gpu sensor, transparently for the user. > > > > > > > > > > I could imagine an API that covers both a) and b), as long as b) focuses > > > > on the "sanitize" aspect and doesn't try to limit userspace access to attributes. > > > > > > > > Guenter > > > b) was introduced by Dave, I never asked for it because I don't mind > > > duplicating sensor data (one hwmon device named nouveau and one for the > > > raw access to the i2c chip). > > > > Sorry for the confusion Martin, I brought up the point of limiting > > userspace access and did not cc the nouveau mailing list. I think it is > > bad behaviour to expose values to userspace which are totally off the > > real values. This confuses users and should be avoided, especially since > > we can provide sanitized values. > > > > Why should we push the logic and api for sanitizing the values to many > > hwmon drivers if we could easily do this at a single point in the > > graphics driver, if we provide the userspace interface ourself and use > > the hwmon driver only to instrument the monitoring chip? > > I don't think the functionality (nor the internal API) should have to be > implemented in individual drivers. Instead, there should be a new API > between hwmon drivers and the hwmon core. Using this API, the hwmon core > would read/write raw values from/to hwmon drivers and make those values > available to userland and to other drivers (such as the nouveau driver). > The hwmon core would then also perform sanitizing if necessary, ie call > registered sanitizing functions. > > With this approach, hwmon would report sanitized values, graphics > drivers would not have to support/generate hwmon sysfs ABI attributes, > and hwmon driver structure would be much simpler, since drivers could > concentrate on getting data from and to chips instead of having to deal > with sysfs attributes. That would be a win for everyone. > > Guenter This is a bigger change than we initially aimed for and I didn't dare to ask for such a heavy modification, but I'm very happy with this solution if you prefer and support it this way. If you have no objections I will try to hack something together by this weekend so we could further discuss the issue with some real code at hand. -- Lucas From guenter.roeck at ericsson.com Thu Mar 3 13:19:18 2011 From: guenter.roeck at ericsson.com (Guenter Roeck) Date: Thu, 3 Mar 2011 13:19:18 -0800 Subject: [lm-sensors] hwmon API update In-Reply-To: <1299185295.2255.13.camel@workstation> References: <4D57CC24.1040306@xxxxxxx> <20110213171640.GB13323@xxxxxxxxxxxx> <20110213230833.0ee2ff16@xxxxxxxxxxxxxxxx> <AANLkTindG=m4FhNS202MH8YVBUCoDEADTQLxo-Bf_8qx@xxxxxxxxxxxxxx> <20110303152216.GA21667@xxxxxxxxxxxx> <4D6FCFF2.7040604@xxxxxxx> <1299185295.2255.13.camel@workstation> Message-ID: <1299187158.18605.28.camel@groeck-laptop> On Thu, 2011-03-03 at 15:48 -0500, Lucas Stach wrote: > Am Donnerstag, den 03.03.2011, 18:29 +0100 schrieb Martin Peres: > > Le 03/03/2011 16:22, Guenter Roeck a ?crit : > > > On Thu, Mar 03, 2011 at 04:36:09AM -0500, Dave Airlie wrote: > > >> On Mon, Feb 14, 2011 at 8:08 AM, Jean Delvare<khali at linux-fr.org> wrote: > > >>> On Sun, 13 Feb 2011 09:16:40 -0800, Guenter Roeck wrote: > > >>>> On Sun, Feb 13, 2011 at 07:18:44AM -0500, Martin Peres wrote: > > >>>>> Hi, > > >>>>> > > >>>>> I am working on power management on the nouveau driver and I need a way > > >>>>> to get data out of and send commands to the i2c drivers from the kernel > > >>>>> space. > > >> Martin, > > >> > > >> you probably should have cc'ed Matthew since it was his patch you based this on, > > >> and I think he can provide a good explaination. > > >> > > >> to clarify some points, > > >> > > >> radeon does probably want something exactly like this, we just haven't gotten to > > >> it completely yet, I'd rather not have two drivers in the kernel for > > >> exact same hardware, > > >> and I believe sharing the hwmon code to do what we want is a good plan since you > > >> don't go around reinventing wheels, but if hwmon/i2c maintainers have > > >> no interest > > >> it leaves with little choice but to implement about 5-10 i2c drivers > > >> again in drm codebase. > > >> > > >> Maybe hwmon/i2c maintainers could suggest a cleaner way to implement > > >> what we want, > > >> which I think I can summarize as > > >> > > >> a) access to monitored values in-kernel > > >> b) no userspace access to the same values except via sanitised via the driver. > > >> > > > This is not a matter of "no interest". Interest is there, but if one demands > > > too much one may get nothing. > > > > > > Request for b) so far was "no userspace access", period. This is unacceptable > > > since providing userspace access to monitored values is the whole point of hwmon. > > And that is what we want to do. But it would be nice if the graphics > drivers could provide a _single_ interface to userspace. Not all boards > have i2c hardware monitoring chips and with a single interface we could > fall back to the internal gpu sensor, transparently for the user. > > > > > > > I could imagine an API that covers both a) and b), as long as b) focuses > > > on the "sanitize" aspect and doesn't try to limit userspace access to attributes. > > > > > > Guenter > > b) was introduced by Dave, I never asked for it because I don't mind > > duplicating sensor data (one hwmon device named nouveau and one for the > > raw access to the i2c chip). > > Sorry for the confusion Martin, I brought up the point of limiting > userspace access and did not cc the nouveau mailing list. I think it is > bad behaviour to expose values to userspace which are totally off the > real values. This confuses users and should be avoided, especially since > we can provide sanitized values. > > Why should we push the logic and api for sanitizing the values to many > hwmon drivers if we could easily do this at a single point in the > graphics driver, if we provide the userspace interface ourself and use > the hwmon driver only to instrument the monitoring chip? I don't think the functionality (nor the internal API) should have to be implemented in individual drivers. Instead, there should be a new API between hwmon drivers and the hwmon core. Using this API, the hwmon core would read/write raw values from/to hwmon drivers and make those values available to userland and to other drivers (such as the nouveau driver). The hwmon core would then also perform sanitizing if necessary, ie call registered sanitizing functions. With this approach, hwmon would report sanitized values, graphics drivers would not have to support/generate hwmon sysfs ABI attributes, and hwmon driver structure would be much simpler, since drivers could concentrate on getting data from and to chips instead of having to deal with sysfs attributes. That would be a win for everyone. Guenter From guenter.roeck at ericsson.com Thu Mar 3 14:03:42 2011 From: guenter.roeck at ericsson.com (Guenter Roeck) Date: Thu, 3 Mar 2011 14:03:42 -0800 Subject: [lm-sensors] hwmon API update In-Reply-To: <1299189416.2255.22.camel@workstation> References: <4D57CC24.1040306@xxxxxxx> <20110213171640.GB13323@xxxxxxxxxxxx> <20110213230833.0ee2ff16@xxxxxxxxxxxxxxxx> <AANLkTindG=m4FhNS202MH8YVBUCoDEADTQLxo-Bf_8qx@xxxxxxxxxxxxxx> <20110303152216.GA21667@xxxxxxxxxxxx> <4D6FCFF2.7040604@xxxxxxx> <1299185295.2255.13.camel@workstation> <1299187158.18605.28.camel@groeck-laptop> <1299189416.2255.22.camel@workstation> Message-ID: <1299189822.18605.35.camel@groeck-laptop> On Thu, 2011-03-03 at 16:56 -0500, Lucas Stach wrote: > Am Donnerstag, den 03.03.2011, 13:19 -0800 schrieb Guenter Roeck: > > On Thu, 2011-03-03 at 15:48 -0500, Lucas Stach wrote: > > > Am Donnerstag, den 03.03.2011, 18:29 +0100 schrieb Martin Peres: > > > > Le 03/03/2011 16:22, Guenter Roeck a ?crit : > > > > > On Thu, Mar 03, 2011 at 04:36:09AM -0500, Dave Airlie wrote: > > > > >> On Mon, Feb 14, 2011 at 8:08 AM, Jean Delvare<khali at linux-fr.org> wrote: > > > > >>> On Sun, 13 Feb 2011 09:16:40 -0800, Guenter Roeck wrote: > > > > >>>> On Sun, Feb 13, 2011 at 07:18:44AM -0500, Martin Peres wrote: > > > > >>>>> Hi, > > > > >>>>> > > > > >>>>> I am working on power management on the nouveau driver and I need a way > > > > >>>>> to get data out of and send commands to the i2c drivers from the kernel > > > > >>>>> space. > > > > >> Martin, > > > > >> > > > > >> you probably should have cc'ed Matthew since it was his patch you based this on, > > > > >> and I think he can provide a good explaination. > > > > >> > > > > >> to clarify some points, > > > > >> > > > > >> radeon does probably want something exactly like this, we just haven't gotten to > > > > >> it completely yet, I'd rather not have two drivers in the kernel for > > > > >> exact same hardware, > > > > >> and I believe sharing the hwmon code to do what we want is a good plan since you > > > > >> don't go around reinventing wheels, but if hwmon/i2c maintainers have > > > > >> no interest > > > > >> it leaves with little choice but to implement about 5-10 i2c drivers > > > > >> again in drm codebase. > > > > >> > > > > >> Maybe hwmon/i2c maintainers could suggest a cleaner way to implement > > > > >> what we want, > > > > >> which I think I can summarize as > > > > >> > > > > >> a) access to monitored values in-kernel > > > > >> b) no userspace access to the same values except via sanitised via the driver. > > > > >> > > > > > This is not a matter of "no interest". Interest is there, but if one demands > > > > > too much one may get nothing. > > > > > > > > > > Request for b) so far was "no userspace access", period. This is unacceptable > > > > > since providing userspace access to monitored values is the whole point of hwmon. > > > > > > And that is what we want to do. But it would be nice if the graphics > > > drivers could provide a _single_ interface to userspace. Not all boards > > > have i2c hardware monitoring chips and with a single interface we could > > > fall back to the internal gpu sensor, transparently for the user. > > > > > > > > > > > > > I could imagine an API that covers both a) and b), as long as b) focuses > > > > > on the "sanitize" aspect and doesn't try to limit userspace access to attributes. > > > > > > > > > > Guenter > > > > b) was introduced by Dave, I never asked for it because I don't mind > > > > duplicating sensor data (one hwmon device named nouveau and one for the > > > > raw access to the i2c chip). > > > > > > Sorry for the confusion Martin, I brought up the point of limiting > > > userspace access and did not cc the nouveau mailing list. I think it is > > > bad behaviour to expose values to userspace which are totally off the > > > real values. This confuses users and should be avoided, especially since > > > we can provide sanitized values. > > > > > > Why should we push the logic and api for sanitizing the values to many > > > hwmon drivers if we could easily do this at a single point in the > > > graphics driver, if we provide the userspace interface ourself and use > > > the hwmon driver only to instrument the monitoring chip? > > > > I don't think the functionality (nor the internal API) should have to be > > implemented in individual drivers. Instead, there should be a new API > > between hwmon drivers and the hwmon core. Using this API, the hwmon core > > would read/write raw values from/to hwmon drivers and make those values > > available to userland and to other drivers (such as the nouveau driver). > > The hwmon core would then also perform sanitizing if necessary, ie call > > registered sanitizing functions. > > > > With this approach, hwmon would report sanitized values, graphics > > drivers would not have to support/generate hwmon sysfs ABI attributes, > > and hwmon driver structure would be much simpler, since drivers could > > concentrate on getting data from and to chips instead of having to deal > > with sysfs attributes. That would be a win for everyone. > > > > Guenter > > This is a bigger change than we initially aimed for and I didn't dare to > ask for such a heavy modification, but I'm very happy with this solution > if you prefer and support it this way. If done right, it should be much less invasive than the previous approach - meaning existing drivers would not have to be modified and can be converted as time permits. > u have no objections I will try to hack something together by this > weekend so we could further discuss the issue with some real code at > hand. > Sure, go ahead. I started something too, but I don't really have much time right now. Guenter From martin.peres at free.fr Thu Mar 3 15:53:12 2011 From: martin.peres at free.fr (Martin Peres) Date: Fri, 04 Mar 2011 00:53:12 +0100 Subject: [lm-sensors] hwmon API update In-Reply-To: <1299189822.18605.35.camel@groeck-laptop> References: <4D57CC24.1040306@xxxxxxx> <20110213171640.GB13323@xxxxxxxxxxxx> <20110213230833.0ee2ff16@xxxxxxxxxxxxxxxx> <AANLkTindG=m4FhNS202MH8YVBUCoDEADTQLxo-Bf_8qx@xxxxxxxxxxxxxx> <20110303152216.GA21667@xxxxxxxxxxxx> <4D6FCFF2.7040604@xxxxxxx> <1299185295.2255.13.camel@workstation> <1299187158.18605.28.camel@groeck-laptop> <1299189416.2255.22.camel@workstation> <1299189822.18605.35.camel@groeck-laptop> Message-ID: <4D7029E8.4040706@xxxxxxx> Le 03/03/2011 23:03, Guenter Roeck a ?crit : > On Thu, 2011-03-03 at 16:56 -0500, Lucas Stach wrote: >> Am Donnerstag, den 03.03.2011, 13:19 -0800 schrieb Guenter Roeck: >>> On Thu, 2011-03-03 at 15:48 -0500, Lucas Stach wrote: >>>> Am Donnerstag, den 03.03.2011, 18:29 +0100 schrieb Martin Peres: >>>>> Le 03/03/2011 16:22, Guenter Roeck a ?crit : >>>>>> On Thu, Mar 03, 2011 at 04:36:09AM -0500, Dave Airlie wrote: >>>>>>> On Mon, Feb 14, 2011 at 8:08 AM, Jean Delvare<khali at linux-fr.org> wrote: >>>>>>>> On Sun, 13 Feb 2011 09:16:40 -0800, Guenter Roeck wrote: >>>>>>>>> On Sun, Feb 13, 2011 at 07:18:44AM -0500, Martin Peres wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I am working on power management on the nouveau driver and I need a way >>>>>>>>>> to get data out of and send commands to the i2c drivers from the kernel >>>>>>>>>> space. >>>>>>> Martin, >>>>>>> >>>>>>> you probably should have cc'ed Matthew since it was his patch you based this on, >>>>>>> and I think he can provide a good explaination. >>>>>>> >>>>>>> to clarify some points, >>>>>>> >>>>>>> radeon does probably want something exactly like this, we just haven't gotten to >>>>>>> it completely yet, I'd rather not have two drivers in the kernel for >>>>>>> exact same hardware, >>>>>>> and I believe sharing the hwmon code to do what we want is a good plan since you >>>>>>> don't go around reinventing wheels, but if hwmon/i2c maintainers have >>>>>>> no interest >>>>>>> it leaves with little choice but to implement about 5-10 i2c drivers >>>>>>> again in drm codebase. >>>>>>> >>>>>>> Maybe hwmon/i2c maintainers could suggest a cleaner way to implement >>>>>>> what we want, >>>>>>> which I think I can summarize as >>>>>>> >>>>>>> a) access to monitored values in-kernel >>>>>>> b) no userspace access to the same values except via sanitised via the driver. >>>>>>> >>>>>> This is not a matter of "no interest". Interest is there, but if one demands >>>>>> too much one may get nothing. >>>>>> >>>>>> Request for b) so far was "no userspace access", period. This is unacceptable >>>>>> since providing userspace access to monitored values is the whole point of hwmon. >>>> And that is what we want to do. But it would be nice if the graphics >>>> drivers could provide a _single_ interface to userspace. Not all boards >>>> have i2c hardware monitoring chips and with a single interface we could >>>> fall back to the internal gpu sensor, transparently for the user. >>>> >>>>>> I could imagine an API that covers both a) and b), as long as b) focuses >>>>>> on the "sanitize" aspect and doesn't try to limit userspace access to attributes. >>>>>> >>>>>> Guenter >>>>> b) was introduced by Dave, I never asked for it because I don't mind >>>>> duplicating sensor data (one hwmon device named nouveau and one for the >>>>> raw access to the i2c chip). >>>> Sorry for the confusion Martin, I brought up the point of limiting >>>> userspace access and did not cc the nouveau mailing list. I think it is >>>> bad behaviour to expose values to userspace which are totally off the >>>> real values. This confuses users and should be avoided, especially since >>>> we can provide sanitized values. >>>> >>>> Why should we push the logic and api for sanitizing the values to many >>>> hwmon drivers if we could easily do this at a single point in the >>>> graphics driver, if we provide the userspace interface ourself and use >>>> the hwmon driver only to instrument the monitoring chip? >>> I don't think the functionality (nor the internal API) should have to be >>> implemented in individual drivers. Instead, there should be a new API >>> between hwmon drivers and the hwmon core. Using this API, the hwmon core >>> would read/write raw values from/to hwmon drivers and make those values >>> available to userland and to other drivers (such as the nouveau driver). >>> The hwmon core would then also perform sanitizing if necessary, ie call >>> registered sanitizing functions. >>> >>> With this approach, hwmon would report sanitized values, graphics >>> drivers would not have to support/generate hwmon sysfs ABI attributes, >>> and hwmon driver structure would be much simpler, since drivers could >>> concentrate on getting data from and to chips instead of having to deal >>> with sysfs attributes. That would be a win for everyone. >>> >>> Guenter >> This is a bigger change than we initially aimed for and I didn't dare to >> ask for such a heavy modification, but I'm very happy with this solution >> if you prefer and support it this way. > If done right, it should be much less invasive than the previous > approach - meaning existing drivers would not have to be modified and > can be converted as time permits. The previous solution already permitted that, but anyway, it's good to see you welcome change. >> u have no objections I will try to hack something together by this >> weekend so we could further discuss the issue with some real code at >> hand. >> > Sure, go ahead. I started something too, but I don't really have much > time right now. I'm eager to see the solutions both of you have come up with! > Guenter From guenter.roeck at ericsson.com Thu Mar 3 16:59:00 2011 From: guenter.roeck at ericsson.com (Guenter Roeck) Date: Thu, 3 Mar 2011 16:59:00 -0800 Subject: [lm-sensors] hwmon API update In-Reply-To: <4D7029E8.4040706@xxxxxxx> References: <20110213171640.GB13323@xxxxxxxxxxxx> <20110213230833.0ee2ff16@xxxxxxxxxxxxxxxx> <AANLkTindG=m4FhNS202MH8YVBUCoDEADTQLxo-Bf_8qx@xxxxxxxxxxxxxx> <20110303152216.GA21667@xxxxxxxxxxxx> <4D6FCFF2.7040604@xxxxxxx> <1299185295.2255.13.camel@workstation> <1299187158.18605.28.camel@groeck-laptop> <1299189416.2255.22.camel@workstation> <1299189822.18605.35.camel@groeck-laptop> <4D7029E8.4040706@xxxxxxx> Message-ID: <20110304005900.GB31318@xxxxxxxxxxxx> On Thu, Mar 03, 2011 at 06:53:12PM -0500, Martin Peres wrote: [ ... ] > >>> Guenter > >> This is a bigger change than we initially aimed for and I didn't dare to > >> ask for such a heavy modification, but I'm very happy with this solution > >> if you prefer and support it this way. > > If done right, it should be much less invasive than the previous > > approach - meaning existing drivers would not have to be modified and > > can be converted as time permits. > The previous solution already permitted that, but anyway, it's good to > see you welcome change. It touched all drivers. It did not move anything out of drivers, forcing drivers supporting the new functions to support both sysfs _and_ the new functions. Significant difference. The idea here - at least mine - is to move sysfs attribute management into core hwmon code. Guenter From martin.peres at free.fr Fri Mar 4 00:36:13 2011 From: martin.peres at free.fr (Martin Peres) Date: Fri, 04 Mar 2011 09:36:13 +0100 Subject: [lm-sensors] hwmon API update In-Reply-To: <20110304005900.GB31318@xxxxxxxxxxxx> References: <20110213171640.GB13323@xxxxxxxxxxxx> <20110213230833.0ee2ff16@xxxxxxxxxxxxxxxx> <AANLkTindG=m4FhNS202MH8YVBUCoDEADTQLxo-Bf_8qx@xxxxxxxxxxxxxx> <20110303152216.GA21667@xxxxxxxxxxxx> <4D6FCFF2.7040604@xxxxxxx> <1299185295.2255.13.camel@workstation> <1299187158.18605.28.camel@groeck-laptop> <1299189416.2255.22.camel@workstation> <1299189822.18605.35.camel@groeck-laptop> <4D7029E8.4040706@xxxxxxx> <20110304005900.GB31318@xxxxxxxxxxxx> Message-ID: <4D70A47D.7090209@xxxxxxx> Le 04/03/2011 01:59, Guenter Roeck a ?crit : > On Thu, Mar 03, 2011 at 06:53:12PM -0500, Martin Peres wrote: > [ ... ] >>>>> Guenter >>>> This is a bigger change than we initially aimed for and I didn't dare to >>>> ask for such a heavy modification, but I'm very happy with this solution >>>> if you prefer and support it this way. >>> If done right, it should be much less invasive than the previous >>> approach - meaning existing drivers would not have to be modified and >>> can be converted as time permits. >> The previous solution already permitted that, but anyway, it's good to >> see you welcome change. > It touched all drivers. It did not move anything out of drivers, forcing drivers > supporting the new functions to support both sysfs _and_ the new functions. > Significant difference. > > The idea here - at least mine - is to move sysfs attribute management > into core hwmon code. > > Guenter oh, yes, It touched a bit every driver but I already proposed the sysfs management to be in the hwmon core, the advantage of the solution Matthew Garrett proposed was good because it allowed the transition from the old to the new API to happen smoothly. Anyway, I'm really interested in the solution you'll come up with, I don't mean to say Matthew's solution is the best possible ;) Martin From wilderkde at gmail.com Fri Mar 4 01:34:09 2011 From: wilderkde at gmail.com (Jacopo De Simoi) Date: Fri, 4 Mar 2011 10:34:09 +0100 Subject: New window pixmap initialization Message-ID: <201103041034.09766.wilderkde@xxxxxxxxx> Hello nouveau devs I'd like some informations on the pixmap initialization for a new window in a (xrender) composited setting; I'm currently trying to improve the xrender backend of kwin (i.e. kde composited window manager) and I'm facing some issues which might or might not be driver related. From what it seems, when a new window is created with geometry (x y w h) the pixmap is first initialized with the content of the screen in the rect (x y w h), is this correct? This actually is causing glitches with effects that animate the appearance of the given window by some kind of motion, since one can see for a split second a portion of screen moving for no reason and afterwards the new window appearing (as soon as it has been first painted). Imvho, if an argb window is created, it would be much much cleaner to init its pixmap with a fully transparent color; trying to implement this in the wm is kind of weird; on the other hand I got pretty quickly lost examining ddx code, so I have a few questions: 1? Is first pixmap creation in a composited setting driver dependent? 2? I assume that upon creation the contents of the pixmap should actually be undefined and are init'd like I said for purely convenience reasons; is this correct? is there anything in the specs about that which I did not see? 3? Would it be possible for the nouveau driver to implement the alternate initialization strategy for argb windows? Does the new strategy make sense to you? 4? I'd be happy to provide a patch for point 3, provided that somebody helps me out with finding the right place for it; Thanks a lot; __J P.S. I'm always on IRC, nick wilder From marcin.slusarz at gmail.com Fri Mar 4 08:49:05 2011 From: marcin.slusarz at gmail.com (Marcin Slusarz) Date: Fri, 4 Mar 2011 17:49:05 +0100 Subject: [PATCH] drm/nouveau: fix __nouveau_fence_wait performance regression In-Reply-To: <20110213203804.GA5395@xxxxxxx> References: <20110213203804.GA5395@xxxxxxx> Message-ID: <20110304164905.GA2743@xxxxxxx> On Sun, Feb 13, 2011 at 09:38:04PM +0100, Marcin Slusarz wrote: > Combination of locking and interchannel synchronization changes > uncovered poor behaviour of nouveau_fence_wait, which on HZ=100 > configuration could waste up to 10 ms per call. > Depending on application, it lead to 10-30% FPS regression. > To fix it, shorten thread sleep time to 0.1 ms and ensure > spinning happens for at least one *full* tick. > > Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> > --- > drivers/gpu/drm/nouveau/nouveau_fence.c | 10 ++++++++-- > 1 files changed, 8 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c > index 221b846..75ba5e2 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_fence.c > +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c > @@ -27,6 +27,9 @@ > #include "drmP.h" > #include "drm.h" > > +#include <linux/ktime.h> > +#include <linux/hrtimer.h> > + > #include "nouveau_drv.h" > #include "nouveau_ramht.h" > #include "nouveau_dma.h" > @@ -230,9 +233,12 @@ int > __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) > { > unsigned long timeout = jiffies + (3 * DRM_HZ); > - unsigned long sleep_time = jiffies + 1; > + unsigned long sleep_time = jiffies + 2; > + ktime_t t; > int ret = 0; > > + t = ktime_set(0, NSEC_PER_MSEC / 10); > + > while (1) { > if (__nouveau_fence_signalled(sync_obj, sync_arg)) > break; > @@ -245,7 +251,7 @@ __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) > __set_current_state(intr ? TASK_INTERRUPTIBLE > : TASK_UNINTERRUPTIBLE); > if (lazy && time_after_eq(jiffies, sleep_time)) > - schedule_timeout(1); > + schedule_hrtimeout(&t, HRTIMER_MODE_REL); > > if (intr && signal_pending(current)) { > ret = -ERESTARTSYS; > -- > 1.7.4.rc3 > ping again From marcin.slusarz at gmail.com Fri Mar 4 08:50:17 2011 From: marcin.slusarz at gmail.com (Marcin Slusarz) Date: Fri, 4 Mar 2011 17:50:17 +0100 Subject: [PATCH] gallium/nv50: use 0x8697 class on NVAF In-Reply-To: <20110222173240.GA9687@xxxxxxx> References: <20110222173240.GA9687@xxxxxxx> Message-ID: <20110304165017.GB2743@xxxxxxx> On Tue, Feb 22, 2011 at 06:32:40PM +0100, Marcin Slusarz wrote: > Addresses: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/723012 > > Reported-and-tested-by: Alan Pope > --- > src/gallium/drivers/nv50/nv50_reg.h | 4 ++++ > src/gallium/drivers/nv50/nv50_screen.c | 3 +++ > 2 files changed, 7 insertions(+), 0 deletions(-) > > diff --git a/src/gallium/drivers/nv50/nv50_reg.h b/src/gallium/drivers/nv50/nv50_reg.h > index 949838b..90d77e5 100644 > --- a/src/gallium/drivers/nv50/nv50_reg.h > +++ b/src/gallium/drivers/nv50/nv50_reg.h > @@ -1685,6 +1685,10 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. > > > > +#define NVAFTCL 0x00008697 > + > + > + > #define NV50_COMPUTE 0x000050c0 > > #define NV50_COMPUTE_NOP 0x00000100 > diff --git a/src/gallium/drivers/nv50/nv50_screen.c b/src/gallium/drivers/nv50/nv50_screen.c > index edc3d54..8069509 100644 > --- a/src/gallium/drivers/nv50/nv50_screen.c > +++ b/src/gallium/drivers/nv50/nv50_screen.c > @@ -389,6 +389,9 @@ nv50_screen_create(struct pipe_winsys *ws, struct nouveau_device *dev) > case 0xac: > tesla_class = NVA0TCL; > break; > + case 0xaf: > + tesla_class = NVAFTCL; > + break; > default: > tesla_class = NVA8TCL; > break; > -- > 1.7.4.rc3 > ping if it's wrong for some reason, just say so... From bugzilla-daemon at freedesktop.org Fri Mar 4 15:45:50 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Fri, 4 Mar 2011 15:45:50 -0800 (PST) Subject: [Bug 35025] New: Serious compiler warnings Message-ID: <bug-35025-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> https://bugs.freedesktop.org/show_bug.cgi?id=35025 Summary: Serious compiler warnings Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: blocker Priority: medium Component: Drivers/DRI/nouveau AssignedTo: nouveau at lists.freedesktop.org ReportedBy: johannesobermayr at gmx.de git20110304.1454 E: Mesa 64bit-portability-issue nouveau_texture.c:400, 489 E: Mesa 64bit-portability-issue nouveau_screen.c:254, 257 nouveau_texture.c: In function 'nouveau_teximage': nouveau_texture.c:400:2: warning: implicit declaration of function '_mesa_validate_pbo_teximage' nouveau_texture.c:400:9: warning: assignment makes pointer from integer without a cast nouveau_texture.c:417:3: warning: implicit declaration of function '_mesa_unmap_teximage_pbo' nouveau_texture.c: In function 'nouveau_texsubimage': nouveau_texture.c:489:9: warning: assignment makes pointer from integer without a cast nouveau_mm.c: In function 'mm_slab_new': nouveau_mm.c:147:17: warning: format '%lu' expects type 'long unsigned int', but argument 2 has type 'uint64_t' nouveau_screen.c: In function 'nouveau_screen_init': nouveau_screen.c:254:2: warning: implicit declaration of function 'nouveau_mm_create' nouveau_screen.c:254:18: warning: assignment makes pointer from integer without a cast nouveau_screen.c:257:18: warning: assignment makes pointer from integer without a cast nouveau_screen.c: In function 'nouveau_screen_fini': nouveau_screen.c:266:2: warning: implicit declaration of function 'nouveau_mm_destroy' -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at freedesktop.org Sat Mar 5 15:08:09 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Sat, 5 Mar 2011 15:08:09 -0800 (PST) Subject: [Bug 27501] nVidia 9600M GT (Macbook Pro current model) is unable to boot In-Reply-To: <bug-27501-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> References: <bug-27501-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> Message-ID: <20110305230809.55F9E130009@xxxxxxxxxxxxxxxxxxxxxxxx> https://bugs.freedesktop.org/show_bug.cgi?id=27501 --- Comment #5 from Alex Murray <murray.alex at gmail.com> 2011-03-05 15:08:08 PST --- The latest development version of Ubuntu (and hence I assume nouveau) still has this bug - under Ubuntu Natty Alpha 3 I still need nouveau.noaccel=1 to boot without hanging with a PRAMIN flush timeout on my MacBook Pro 5,1. Any other info which is required to try and sort out this bug - would be great to be able to get acceleration on my machine.... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at freedesktop.org Sat Mar 5 18:53:21 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Sat, 5 Mar 2011 18:53:21 -0800 (PST) Subject: [Bug 35049] New: Cannot use higher resolutions of monitor Message-ID: <bug-35049-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> https://bugs.freedesktop.org/show_bug.cgi?id=35049 Summary: Cannot use higher resolutions of monitor Product: xorg Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org ReportedBy: sancaktar.1 at osu.edu QAContact: xorg-team at lists.x.org I did a fresh Debian install to sid, upgraded to experimental to get xorg 1.9.99.903 (1.10.0 RC 3) then followed the instructions on the nouveau wiki (http://nouveau.freedesktop.org/wiki/DebianInstall) to build a new kernel and drivers. This was successful. The problem is that I have a monitor which supports up to 2560x1600 (which the monitor reports by EDID) but the drivers will only run at 1280x800. If I use xrandr to resize, I get a desktop that is compressed to be equivalent to the larger size, but is actually 1280x800. I have tried adding a virtual line to my monitor section and setting the preferredmode. These did not help. The Xorg log shows that it detects the higher resolutions. I tried booting the kernel with video=DVI-I-1:2560x1600. The kernel FB driver does exactly the same thing, making the text very small but still actually outputting the lower resolution. I originally thought that this was a dual-link problem, but I don't think that 1280x800 is even the maximum for a single DVI cable. The propriety driver works at the higher resolutions. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at freedesktop.org Sat Mar 5 18:58:10 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Sat, 5 Mar 2011 18:58:10 -0800 (PST) Subject: [Bug 35049] Cannot use higher resolutions of monitor In-Reply-To: <bug-35049-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> References: <bug-35049-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> Message-ID: <20110306025810.CEA44130005@xxxxxxxxxxxxxxxxxxxxxxxx> https://bugs.freedesktop.org/show_bug.cgi?id=35049 --- Comment #1 from sancaktar.1 at osu.edu 2011-03-05 18:58:10 PST --- Created an attachment (id=44160) --> (https://bugs.freedesktop.org/attachment.cgi?id=44160) xorg config file Same results with the second card commented out. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at freedesktop.org Sat Mar 5 18:58:43 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Sat, 5 Mar 2011 18:58:43 -0800 (PST) Subject: [Bug 35049] Cannot use higher resolutions of monitor In-Reply-To: <bug-35049-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> References: <bug-35049-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> Message-ID: <20110306025844.396EC130005@xxxxxxxxxxxxxxxxxxxxxxxx> https://bugs.freedesktop.org/show_bug.cgi?id=35049 --- Comment #2 from sancaktar.1 at osu.edu 2011-03-05 18:58:43 PST --- Created an attachment (id=44161) --> (https://bugs.freedesktop.org/attachment.cgi?id=44161) dmesg -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at freedesktop.org Sun Mar 6 03:29:55 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Sun, 6 Mar 2011 03:29:55 -0800 (PST) Subject: [Bug 35056] New: nouveau freezes with TRAP_TEXTURE error in logs - Mouse keeps moving Message-ID: <bug-35056-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> https://bugs.freedesktop.org/show_bug.cgi?id=35056 Summary: nouveau freezes with TRAP_TEXTURE error in logs - Mouse keeps moving Product: xorg Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org ReportedBy: HMWiesinger at gmx.at QAContact: xorg-team at lists.x.org Created an attachment (id=44166) --> (https://bugs.freedesktop.org/attachment.cgi?id=44166) Log output I upgraded to kernel 2.6.38-rc7 yesterday and experience what seem to be freezes after a couple of hours of use. The mouse cursor keeps moving, but everything else is just stuck and I can't switch back from X to tty either. However, the system is accessible and fully usable over ssh. Attached is the content of /var/log/messages from system startup until the crash. I have a Quadro FX770M, running in a HP notebook. My graphics stack is as follows: - kernel: 2.6.38-rc7 - xorg-server: 1.9.4 - mesa: 7.10_92a619b - libdrm: 2.4.23 - xf86-video-nouveau: 8bb82312 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From dev at lynxeye.de Sun Mar 6 12:10:10 2011 From: dev at lynxeye.de (Lucas Stach) Date: Sun, 06 Mar 2011 21:10:10 +0100 Subject: CCACHE and VFETCH FAULTs causing lockups In-Reply-To: <AANLkTimwGyz1d=W_ZdcaBARO0sw=wZ470Cwy+8407s-m@xxxxxxxxxxxxxx> References: <AANLkTik0CkbQz=PoXNG7bQEn_5ssAfp7cr=Z=3qJz6h2@xxxxxxxxxxxxxx> <1299016269.1822.3.camel@nisroch> <AANLkTimwGyz1d=W_ZdcaBARO0sw=wZ470Cwy+8407s-m@xxxxxxxxxxxxxx> Message-ID: <1299442210.2253.9.camel@workstation> Just adding a me too. I updated from 3fdb729eb7de5597961eb3fbaf0bdfe6f4262307 and now I get lockups from time to time (max. 60 mins) with normal 2D desktop usage. No 3D involved here. Logs only contain: Mar 6 17:27:51 workstation kernel: [ 341.970412] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_CCACHE FAULT Mar 6 17:27:51 workstation kernel: [ 341.970435] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_CCACHE 000e0080 00000000 00000000 00000000 00000000 00000004 00000000 Mar 6 17:27:51 workstation kernel: [ 341.970444] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP Mar 6 17:27:51 workstation kernel: [ 341.970456] [drm] nouveau 0000:01:00.0: PGRAPH - ch 2 (0x0000a38000) subc 5 class 0x8397 mthd 0x0f04 data 0x00000000 Tested chipset is my nvA8. -- Lucas Am Mittwoch, den 02.03.2011, 22:43 +0000 schrieb Maarten Maathuis: > On Tue, Mar 1, 2011 at 9:51 PM, Ben Skeggs <bskeggs at redhat.com> wrote: > > On Tue, 2011-03-01 at 21:08 +0000, Maarten Maathuis wrote: > > > >> Those come after 15-30 minutes of running warzone2100, i haven't > >> played any games for a while, so no idea how long this has been going > >> on. > >> I also got a TRAP_CCACHE on channel 2 a little while ago, it takes > >> much longer to trigger (a few hours). I'm using todays "nouveau > >> kernel" git. > > You're not the first person to have reported this fwiw, personally, I > > haven't seen it yet.. > > > >> > >> I'm guessing something is being unmapped too early or without reason, > >> or some cache is stale. But it isn't obvious what exactly it is. > >> > >> Because i don't remember having these lockups before I'm inclined to > >> guess that this commit is involved > >> http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=6330d8f5ecc4a19fd2ad3c7fa128b2f4c2ce3360 > >> > >> Any ideas? > > Not really. If this commit *is* the cause, the problem is still > > somewhere else. That commit just makes sure PTEs are marked invalid, so > > if it's causing your faults, then previously the GPU would still have > > been reading/writing invalid data. > > I reverted the commit today and things seem to be going be better, > I'll give it a few more days before coming to a conclusion. I > understand that the real issue is somewhere else. > > > > > Plus, I expect you should probably have seen a VM fault.. > > > > Ben. > >> > >> Maarten. > >> > > > > > > > > > From nholtz at cee.carleton.ca Sun Mar 6 18:04:59 2011 From: nholtz at cee.carleton.ca (Neal Holtz) Date: Sun, 06 Mar 2011 21:04:59 -0500 Subject: Linux Mint 10 KDE Live DVD would not start on Fujitsu laptop, NVIDIA video, HDMI Message-ID: <201103062105.00061.nholtz@xxxxxxxxxxxxxxx> I had a problem with LInux Mint 10 KDE, with the Live DVD resulting in a blank screen and no keyboard response during the KDE splash. I traced it to the fact that the laptop screen was turned off and it had switched to HDMI. After installing LM 10 KDE and installing the NVIDI proprietary drivers (and disabling nouveau), it worked fine. I have reported it as launchpad bug 724722, and more info is available there, including lots of logs: https://bugs.launchpad.net/linuxmint/+bug/724722 There are at least 2 other similar cases reported on launchpad/linuxmint Machine particulars: wall:~> inxi -F System: Host wall Kernel 2.6.35-27-generic x86_64 (64 bit) Distro Linux Mint 10 KDE CPU: Dual core Intel Core i5 M 430 (-HT-MCP-) cache 3072 KB flags (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips 9044.14 Clock Speeds: (1) 1199.00 MHz (2) 1199.00 MHz (3) 1199.00 MHz (4) 1199.00 MHz Graphics: Card nVidia GT216 [GeForce GT 330M] tty res: 148x52 Audio: Card-1 nVidia High Definition Audio Controller driver HDA Intel BusID: 01:00.1 Card-2 Intel 5 Series/3400 Series Chipset High Definition Audiodriver HDA Intel BusID: 00:1b.0 Sound: Advanced Linux Sound Architecture Version 1.0.23 Network: Card-1 Atheros AR9287 Wireless Network Adapter (PCI-Express) driver ath9k BusID: 10:00.0 Card-2 Broadcom NetLink BCM57780 Gigabit Ethernet PCIe driver tg3 v: 3.110 BusID: 18:00.0 Disks: HDD Total Size: 500.1GB (15.1% used) 1: /dev/sda FUJITSU_MJA2500B 500.1GB Partition: ID:/ size: 19G used: 6.5G (38%) fs: ext4 ID:/home size: 437G used: 64G (16%) fs: ext4 ID:swap-1 size: 4.10GB used: 0.00GB (0%) fs: swap Info: Processes 191 Uptime 1:29 Memory 743.8/3824.2MB Runlevel 2 Client Shell inxi 1.4.12 -- Neal Holtz http://cee.carleton.ca/~nholtz Dept. of Civil and Environmental Engineering, Carleton University, Ottawa, Ontario, Canada K1S 5B6. nholtz at cee.carleton.ca Public Key: http://holtz3.cee.carleton.ca/~nholtz/pubkey.asc Office-Hours: http://holtz3.cee.carleton.ca/~nholtz/office-hours.html Free-Busy: http://holtz3.cee.carleton.ca/~nholtz/free-busy.cgi From marcin.slusarz at gmail.com Mon Mar 7 03:31:35 2011 From: marcin.slusarz at gmail.com (Marcin Slusarz) Date: Mon, 7 Mar 2011 12:31:35 +0100 Subject: [PATCH] drm/nouveau: properly handle pushbuffer check failures Message-ID: <20110307113135.GA2788@xxxxxxx> When "buffer in list" check does not pass, don't free validation lists - they were not initialized yet. Fixes this oops: [drm] nouveau 0000:02:00.0: push 105 buffer not in list BUG: unable to handle kernel NULL pointer dereference at 000000000000057c IP: [<ffffffff81236aa4>] do_raw_spin_lock+0x14/0x13c PGD 1ac6cb067 PUD 1aaa52067 PMD 0 CPU 0 Modules linked in: nouveau ttm drm_kms_helper snd_hda_codec_realtek snd_hda_intel snd_hda_codec Pid: 6265, comm: OilRush_x86 Not tainted 2.6.38-rc6-nv+ #632 System manufacturer System Product Name/P6T SE RIP: 0010:[<ffffffff81236aa4>] [<ffffffff81236aa4>] do_raw_spin_lock+0x14/0x13c (...) Process OilRush_x86 (pid: 6265, threadinfo ffff8801a6aee000, task ffff8801a26c0000) 0000000000000000 ffff8801ac74c618 0000000000000000 0000000000000578 0000000000000000 ffff8801ac74c618 0000000000000000 ffff8801bd9d0000 [<ffffffff81417f78>] _raw_spin_lock+0x1e/0x22 [<ffffffffa00a2746>] nouveau_bo_fence+0x2e/0x60 [nouveau] [<ffffffffa00a540b>] validate_fini_list+0x35/0xeb [nouveau] [<ffffffffa00a54d3>] validate_fini+0x12/0x31 [nouveau] [<ffffffffa00a6386>] nouveau_gem_ioctl_pushbuf+0xe94/0xf6b [nouveau] [<ffffffff8141ac56>] ? sub_preempt_count+0x9e/0xb2 [<ffffffff81417e94>] ? _raw_spin_unlock_irqrestore+0x30/0x4d [<ffffffff8105dea2>] ? __wake_up+0x3f/0x48 [<ffffffff812aebb4>] drm_ioctl+0x289/0x361 [<ffffffff8141ac56>] ? sub_preempt_count+0x9e/0xb2 [<ffffffffa00a54f2>] ? nouveau_gem_ioctl_pushbuf+0x0/0xf6b [nouveau] [<ffffffff8141ac56>] ? sub_preempt_count+0x9e/0xb2 [<ffffffffa010caa2>] nouveau_compat_ioctl+0x16/0x1c [nouveau] [<ffffffff81142c0d>] compat_sys_ioctl+0x1c8/0x12d7 [<ffffffff814179ca>] ? trace_hardirqs_off_thunk+0x3a/0x6c [<ffffffff81058099>] sysenter_dispatch+0x7/0x30 [<ffffffff8141798e>] ? trace_hardirqs_on_thunk+0x3a/0x3c RIP [<ffffffff81236aa4>] do_raw_spin_lock+0x14/0x13c RSP <ffff8801a6aefb88> ---[ end trace 0014d5d93e6147e1 ]--- Additionally, don't call validate_fini twice in case of validation failure. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_gem.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c b/drivers/gpu/drm/nouveau/nouveau_gem.c index 3ce58d2..e8b04f4 100644 --- a/drivers/gpu/drm/nouveau/nouveau_gem.c +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c @@ -600,7 +600,7 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data, if (push[i].bo_index >= req->nr_buffers) { NV_ERROR(dev, "push %d buffer not in list\n", i); ret = -EINVAL; - goto out; + goto out_prevalid; } bo[push[i].bo_index].read_domains |= (1 << 31); @@ -612,7 +612,7 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data, if (ret) { if (ret != -ERESTARTSYS) NV_ERROR(dev, "validate: %d\n", ret); - goto out; + goto out_prevalid; } /* Apply any relocations that are required */ @@ -705,6 +705,8 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data, out: validate_fini(&op, fence); nouveau_fence_unref(&fence); + +out_prevalid: kfree(bo); kfree(push); -- 1.7.4.rc3 From bugzilla-daemon at freedesktop.org Mon Mar 7 09:21:58 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Mon, 7 Mar 2011 09:21:58 -0800 (PST) Subject: [Bug 24555] X server crash In-Reply-To: <bug-24555-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> References: <bug-24555-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> Message-ID: <20110307172158.DCD5713000C@xxxxxxxxxxxxxxxxxxxxxxxx> https://bugs.freedesktop.org/show_bug.cgi?id=24555 Marcin Slusarz <marcin.slusarz at gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #1 from Marcin Slusarz <marcin.slusarz at gmail.com> 2011-03-07 09:21:58 PST --- https://bugzilla.redhat.com/show_bug.cgi?id=528005#c7 Marking as fixed. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at freedesktop.org Mon Mar 7 09:41:19 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Mon, 7 Mar 2011 09:41:19 -0800 (PST) Subject: [Bug 24866] AddScreen/ScreenInit failed for driver 0 / NV50 In-Reply-To: <bug-24866-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> References: <bug-24866-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> Message-ID: <20110307174119.75A9B13004F@xxxxxxxxxxxxxxxxxxxxxxxx> https://bugs.freedesktop.org/show_bug.cgi?id=24866 Marcin Slusarz <marcin.slusarz at gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #2 from Marcin Slusarz <marcin.slusarz at gmail.com> 2011-03-07 09:41:18 PST --- This bug is related to UMS codepath which was removed more than a year ago and KMS should work fine. If it does not, please file new bug report. I'm closing this bug. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at freedesktop.org Mon Mar 7 09:52:34 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Mon, 7 Mar 2011 09:52:34 -0800 (PST) Subject: [Bug 25036] KMS + multihead leaves ghost mouse pointer In-Reply-To: <bug-25036-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> References: <bug-25036-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> Message-ID: <20110307175234.43001130051@xxxxxxxxxxxxxxxxxxxxxxxx> https://bugs.freedesktop.org/show_bug.cgi?id=25036 Marcin Slusarz <marcin.slusarz at gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #7 from Marcin Slusarz <marcin.slusarz at gmail.com> 2011-03-07 09:52:33 PST --- It seems to be fixed, so I'm closing this bug report. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at freedesktop.org Mon Mar 7 09:56:04 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Mon, 7 Mar 2011 09:56:04 -0800 (PST) Subject: [Bug 25071] GPU lockup G80 8800 In-Reply-To: <bug-25071-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> References: <bug-25071-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> Message-ID: <20110307175604.A423D13004E@xxxxxxxxxxxxxxxxxxxxxxxx> https://bugs.freedesktop.org/show_bug.cgi?id=25071 --- Comment #5 from Marcin Slusarz <marcin.slusarz at gmail.com> 2011-03-07 09:56:04 PST --- Is it still an issue on recent kernels? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at freedesktop.org Mon Mar 7 10:07:46 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Mon, 7 Mar 2011 10:07:46 -0800 (PST) Subject: [Bug 25261] Fails at start on NV44 In-Reply-To: <bug-25261-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> References: <bug-25261-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> Message-ID: <20110307180746.6190F13000C@xxxxxxxxxxxxxxxxxxxxxxxx> https://bugs.freedesktop.org/show_bug.cgi?id=25261 --- Comment #2 from Marcin Slusarz <marcin.slusarz at gmail.com> 2011-03-07 10:07:46 PST --- Xorg.log indicates you were using UMS, which was removed more than a year ago. Can you check current nouveau? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From madman2003 at gmail.com Mon Mar 7 10:10:13 2011 From: madman2003 at gmail.com (Maarten Maathuis) Date: Mon, 7 Mar 2011 18:10:13 +0000 Subject: [PATCH] drm/nouveau: properly handle pushbuffer check failures In-Reply-To: <20110307113135.GA2788@xxxxxxx> References: <20110307113135.GA2788@xxxxxxx> Message-ID: <AANLkTin4oJda-wB4b6X9B+En3EXX6wHXQdVg=o_qX0zA@xxxxxxxxxxxxxx> On Mon, Mar 7, 2011 at 11:31 AM, Marcin Slusarz <marcin.slusarz at gmail.com> wrote: > When "buffer in list" check does not pass, don't free validation lists - they were > not initialized yet. > > Fixes this oops: > > [drm] nouveau 0000:02:00.0: push 105 buffer not in list > BUG: unable to handle kernel NULL pointer dereference at 000000000000057c > IP: [<ffffffff81236aa4>] do_raw_spin_lock+0x14/0x13c > PGD 1ac6cb067 PUD 1aaa52067 PMD 0 > CPU 0 > Modules linked in: nouveau ttm drm_kms_helper snd_hda_codec_realtek snd_hda_intel snd_hda_codec > > Pid: 6265, comm: OilRush_x86 Not tainted 2.6.38-rc6-nv+ #632 System manufacturer System Product Name/P6T SE > RIP: 0010:[<ffffffff81236aa4>] ?[<ffffffff81236aa4>] do_raw_spin_lock+0x14/0x13c > (...) > Process OilRush_x86 (pid: 6265, threadinfo ffff8801a6aee000, task ffff8801a26c0000) > ?0000000000000000 ffff8801ac74c618 0000000000000000 0000000000000578 > ?0000000000000000 ffff8801ac74c618 0000000000000000 ffff8801bd9d0000 > ?[<ffffffff81417f78>] _raw_spin_lock+0x1e/0x22 > ?[<ffffffffa00a2746>] nouveau_bo_fence+0x2e/0x60 [nouveau] > ?[<ffffffffa00a540b>] validate_fini_list+0x35/0xeb [nouveau] > ?[<ffffffffa00a54d3>] validate_fini+0x12/0x31 [nouveau] > ?[<ffffffffa00a6386>] nouveau_gem_ioctl_pushbuf+0xe94/0xf6b [nouveau] > ?[<ffffffff8141ac56>] ? sub_preempt_count+0x9e/0xb2 > ?[<ffffffff81417e94>] ? _raw_spin_unlock_irqrestore+0x30/0x4d > ?[<ffffffff8105dea2>] ? __wake_up+0x3f/0x48 > ?[<ffffffff812aebb4>] drm_ioctl+0x289/0x361 > ?[<ffffffff8141ac56>] ? sub_preempt_count+0x9e/0xb2 > ?[<ffffffffa00a54f2>] ? nouveau_gem_ioctl_pushbuf+0x0/0xf6b [nouveau] > ?[<ffffffff8141ac56>] ? sub_preempt_count+0x9e/0xb2 > ?[<ffffffffa010caa2>] nouveau_compat_ioctl+0x16/0x1c [nouveau] > ?[<ffffffff81142c0d>] compat_sys_ioctl+0x1c8/0x12d7 > ?[<ffffffff814179ca>] ? trace_hardirqs_off_thunk+0x3a/0x6c > ?[<ffffffff81058099>] sysenter_dispatch+0x7/0x30 > ?[<ffffffff8141798e>] ? trace_hardirqs_on_thunk+0x3a/0x3c > RIP ?[<ffffffff81236aa4>] do_raw_spin_lock+0x14/0x13c > ?RSP <ffff8801a6aefb88> > ---[ end trace 0014d5d93e6147e1 ]--- > > Additionally, don't call validate_fini twice in case of validation failure. > > Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> > --- > ?drivers/gpu/drm/nouveau/nouveau_gem.c | ? ?6 ++++-- > ?1 files changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c b/drivers/gpu/drm/nouveau/nouveau_gem.c > index 3ce58d2..e8b04f4 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_gem.c > +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c > @@ -600,7 +600,7 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data, > ? ? ? ? ? ? ? ?if (push[i].bo_index >= req->nr_buffers) { > ? ? ? ? ? ? ? ? ? ? ? ?NV_ERROR(dev, "push %d buffer not in list\n", i); > ? ? ? ? ? ? ? ? ? ? ? ?ret = -EINVAL; > - ? ? ? ? ? ? ? ? ? ? ? goto out; > + ? ? ? ? ? ? ? ? ? ? ? goto out_prevalid; > ? ? ? ? ? ? ? ?} > > ? ? ? ? ? ? ? ?bo[push[i].bo_index].read_domains |= (1 << 31); > @@ -612,7 +612,7 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data, > ? ? ? ?if (ret) { > ? ? ? ? ? ? ? ?if (ret != -ERESTARTSYS) > ? ? ? ? ? ? ? ? ? ? ? ?NV_ERROR(dev, "validate: %d\n", ret); > - ? ? ? ? ? ? ? goto out; > + ? ? ? ? ? ? ? goto out_prevalid; > ? ? ? ?} > > ? ? ? ?/* Apply any relocations that are required */ > @@ -705,6 +705,8 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data, > ?out: > ? ? ? ?validate_fini(&op, fence); > ? ? ? ?nouveau_fence_unref(&fence); > + > +out_prevalid: > ? ? ? ?kfree(bo); > ? ? ? ?kfree(push); > > -- > 1.7.4.rc3 > > _______________________________________________ > Nouveau mailing list > Nouveau at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/nouveau > This seems a simple fix, so i pushed it. -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. From madman2003 at gmail.com Mon Mar 7 10:15:46 2011 From: madman2003 at gmail.com (Maarten Maathuis) Date: Mon, 7 Mar 2011 18:15:46 +0000 Subject: [PATCH] gallium/nv50: use 0x8697 class on NVAF In-Reply-To: <20110304165017.GB2743@xxxxxxx> References: <20110222173240.GA9687@xxxxxxx> <20110304165017.GB2743@xxxxxxx> Message-ID: <AANLkTinJdfL13yT3hze+5vj8Kv9cAxCsF-4YCJt9Hebv@xxxxxxxxxxxxxx> On Fri, Mar 4, 2011 at 4:50 PM, Marcin Slusarz <marcin.slusarz at gmail.com> wrote: > On Tue, Feb 22, 2011 at 06:32:40PM +0100, Marcin Slusarz wrote: >> Addresses: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/723012 >> >> Reported-and-tested-by: Alan Pope >> --- >> ?src/gallium/drivers/nv50/nv50_reg.h ? ?| ? ?4 ++++ >> ?src/gallium/drivers/nv50/nv50_screen.c | ? ?3 +++ >> ?2 files changed, 7 insertions(+), 0 deletions(-) >> >> diff --git a/src/gallium/drivers/nv50/nv50_reg.h b/src/gallium/drivers/nv50/nv50_reg.h >> index 949838b..90d77e5 100644 >> --- a/src/gallium/drivers/nv50/nv50_reg.h >> +++ b/src/gallium/drivers/nv50/nv50_reg.h >> @@ -1685,6 +1685,10 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. >> >> >> >> +#define NVAFTCL ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0x00008697 >> + >> + >> + >> ?#define NV50_COMPUTE ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x000050c0 >> >> ?#define ?NV50_COMPUTE_NOP ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0x00000100 >> diff --git a/src/gallium/drivers/nv50/nv50_screen.c b/src/gallium/drivers/nv50/nv50_screen.c >> index edc3d54..8069509 100644 >> --- a/src/gallium/drivers/nv50/nv50_screen.c >> +++ b/src/gallium/drivers/nv50/nv50_screen.c >> @@ -389,6 +389,9 @@ nv50_screen_create(struct pipe_winsys *ws, struct nouveau_device *dev) >> ? ? ? ? ? ? ? case 0xac: >> ? ? ? ? ? ? ? ? ? ? ? tesla_class = NVA0TCL; >> ? ? ? ? ? ? ? ? ? ? ? break; >> + ? ? ? ? ? ? case 0xaf: >> + ? ? ? ? ? ? ? ? ? ? tesla_class = NVAFTCL; >> + ? ? ? ? ? ? ? ? ? ? break; >> ? ? ? ? ? ? ? default: >> ? ? ? ? ? ? ? ? ? ? ? tesla_class = NVA8TCL; >> ? ? ? ? ? ? ? ? ? ? ? break; >> -- >> 1.7.4.rc3 >> > > ping > > if it's wrong for some reason, just say so... > > _______________________________________________ > Nouveau mailing list > Nouveau at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/nouveau > The patch seems ok to me, the nitpicker in me would tell you to separate the reported by and tested by tags and include Alan Pope's email address :) -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. From madman2003 at gmail.com Mon Mar 7 10:18:41 2011 From: madman2003 at gmail.com (Maarten Maathuis) Date: Mon, 7 Mar 2011 18:18:41 +0000 Subject: [PATCH] drm/nouveau: fix __nouveau_fence_wait performance regression In-Reply-To: <20110304164905.GA2743@xxxxxxx> References: <20110213203804.GA5395@xxxxxxx> <20110304164905.GA2743@xxxxxxx> Message-ID: <AANLkTin_jouzPDGfNnYq_BRqPzbvOW+F6jFNuc7p=p5E@xxxxxxxxxxxxxx> On Fri, Mar 4, 2011 at 4:49 PM, Marcin Slusarz <marcin.slusarz at gmail.com> wrote: > On Sun, Feb 13, 2011 at 09:38:04PM +0100, Marcin Slusarz wrote: >> Combination of locking and interchannel synchronization changes >> uncovered poor behaviour of nouveau_fence_wait, which on HZ=100 >> configuration could waste up to 10 ms per call. >> Depending on application, it lead to 10-30% FPS regression. >> To fix it, shorten thread sleep time to 0.1 ms and ensure >> spinning happens for at least one *full* tick. >> >> Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> >> --- >> ?drivers/gpu/drm/nouveau/nouveau_fence.c | ? 10 ++++++++-- >> ?1 files changed, 8 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c >> index 221b846..75ba5e2 100644 >> --- a/drivers/gpu/drm/nouveau/nouveau_fence.c >> +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c >> @@ -27,6 +27,9 @@ >> ?#include "drmP.h" >> ?#include "drm.h" >> >> +#include <linux/ktime.h> >> +#include <linux/hrtimer.h> >> + >> ?#include "nouveau_drv.h" >> ?#include "nouveau_ramht.h" >> ?#include "nouveau_dma.h" >> @@ -230,9 +233,12 @@ int >> ?__nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) >> ?{ >> ? ? ? unsigned long timeout = jiffies + (3 * DRM_HZ); >> - ? ? unsigned long sleep_time = jiffies + 1; >> + ? ? unsigned long sleep_time = jiffies + 2; >> + ? ? ktime_t t; >> ? ? ? int ret = 0; >> >> + ? ? t = ktime_set(0, NSEC_PER_MSEC / 10); >> + >> ? ? ? while (1) { >> ? ? ? ? ? ? ? if (__nouveau_fence_signalled(sync_obj, sync_arg)) >> ? ? ? ? ? ? ? ? ? ? ? break; >> @@ -245,7 +251,7 @@ __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) >> ? ? ? ? ? ? ? __set_current_state(intr ? TASK_INTERRUPTIBLE >> ? ? ? ? ? ? ? ? ? ? ? : TASK_UNINTERRUPTIBLE); >> ? ? ? ? ? ? ? if (lazy && time_after_eq(jiffies, sleep_time)) >> - ? ? ? ? ? ? ? ? ? ? schedule_timeout(1); >> + ? ? ? ? ? ? ? ? ? ? schedule_hrtimeout(&t, HRTIMER_MODE_REL); >> >> ? ? ? ? ? ? ? if (intr && signal_pending(current)) { >> ? ? ? ? ? ? ? ? ? ? ? ret = -ERESTARTSYS; >> -- >> 1.7.4.rc3 >> > > ping again > _______________________________________________ > Nouveau mailing list > Nouveau at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/nouveau > This looks ok to me, but I would like to get Ben Skeggs ok on this one as well. So i've CC'ed him, hopefully he'll notice :-) -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. From marcin.slusarz at gmail.com Mon Mar 7 10:28:58 2011 From: marcin.slusarz at gmail.com (Marcin Slusarz) Date: Mon, 7 Mar 2011 19:28:58 +0100 Subject: [PATCH] gallium/nv50: use 0x8697 class on NVAF In-Reply-To: <AANLkTinJdfL13yT3hze+5vj8Kv9cAxCsF-4YCJt9Hebv@xxxxxxxxxxxxxx> References: <20110222173240.GA9687@xxxxxxx> <20110304165017.GB2743@xxxxxxx> <AANLkTinJdfL13yT3hze+5vj8Kv9cAxCsF-4YCJt9Hebv@xxxxxxxxxxxxxx> Message-ID: <20110307182858.GA9371@xxxxxxx> On Mon, Mar 07, 2011 at 06:15:46PM +0000, Maarten Maathuis wrote: > On Fri, Mar 4, 2011 at 4:50 PM, Marcin Slusarz <marcin.slusarz at gmail.com> wrote: > > On Tue, Feb 22, 2011 at 06:32:40PM +0100, Marcin Slusarz wrote: > >> Addresses: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/723012 > >> > >> Reported-and-tested-by: Alan Pope > >> --- > >> ?src/gallium/drivers/nv50/nv50_reg.h ? ?| ? ?4 ++++ > >> ?src/gallium/drivers/nv50/nv50_screen.c | ? ?3 +++ > >> ?2 files changed, 7 insertions(+), 0 deletions(-) > >> > >> diff --git a/src/gallium/drivers/nv50/nv50_reg.h b/src/gallium/drivers/nv50/nv50_reg.h > >> index 949838b..90d77e5 100644 > >> --- a/src/gallium/drivers/nv50/nv50_reg.h > >> +++ b/src/gallium/drivers/nv50/nv50_reg.h > >> @@ -1685,6 +1685,10 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. > >> > >> > >> > >> +#define NVAFTCL ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0x00008697 > >> + > >> + > >> + > >> ?#define NV50_COMPUTE ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x000050c0 > >> > >> ?#define ?NV50_COMPUTE_NOP ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0x00000100 > >> diff --git a/src/gallium/drivers/nv50/nv50_screen.c b/src/gallium/drivers/nv50/nv50_screen.c > >> index edc3d54..8069509 100644 > >> --- a/src/gallium/drivers/nv50/nv50_screen.c > >> +++ b/src/gallium/drivers/nv50/nv50_screen.c > >> @@ -389,6 +389,9 @@ nv50_screen_create(struct pipe_winsys *ws, struct nouveau_device *dev) > >> ? ? ? ? ? ? ? case 0xac: > >> ? ? ? ? ? ? ? ? ? ? ? tesla_class = NVA0TCL; > >> ? ? ? ? ? ? ? ? ? ? ? break; > >> + ? ? ? ? ? ? case 0xaf: > >> + ? ? ? ? ? ? ? ? ? ? tesla_class = NVAFTCL; > >> + ? ? ? ? ? ? ? ? ? ? break; > >> ? ? ? ? ? ? ? default: > >> ? ? ? ? ? ? ? ? ? ? ? tesla_class = NVA8TCL; > >> ? ? ? ? ? ? ? ? ? ? ? break; > >> -- > >> 1.7.4.rc3 > >> > > > > ping > > > > if it's wrong for some reason, just say so... > > > > The patch seems ok to me, the nitpicker in me would tell you to > separate the reported by and tested by tags and include Alan Pope's > email address :) > Christoph already fixed it in his big "nv50: replace most of it with nvc0 driver ported to nv50" commit. Thanks for a review anyway :), Marcin From bugzilla-daemon at freedesktop.org Mon Mar 7 10:36:27 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Mon, 7 Mar 2011 10:36:27 -0800 (PST) Subject: [Bug 25777] Blank Screen on Gt230M In-Reply-To: <bug-25777-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> References: <bug-25777-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> Message-ID: <20110307183627.6997D13000C@xxxxxxxxxxxxxxxxxxxxxxxx> https://bugs.freedesktop.org/show_bug.cgi?id=25777 --- Comment #6 from Marcin Slusarz <marcin.slusarz at gmail.com> 2011-03-07 10:36:26 PST --- This should be fixed now. Patrick, can you confirm this? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at freedesktop.org Mon Mar 7 10:48:17 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Mon, 7 Mar 2011 10:48:17 -0800 (PST) Subject: [Bug 25938] black screen on the iMac powerpc using nouveau In-Reply-To: <bug-25938-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> References: <bug-25938-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> Message-ID: <20110307184817.AAB0213004F@xxxxxxxxxxxxxxxxxxxxxxxx> https://bugs.freedesktop.org/show_bug.cgi?id=25938 Marcin Slusarz <marcin.slusarz at gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #10 from Marcin Slusarz <marcin.slusarz at gmail.com> 2011-03-07 10:48:17 PST --- Patch was commited, so I'm closing this bug report as FIXED. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at freedesktop.org Mon Mar 7 11:16:15 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Mon, 7 Mar 2011 11:16:15 -0800 (PST) Subject: [Bug 25071] GPU lockup G80 8800 In-Reply-To: <bug-25071-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> References: <bug-25071-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> Message-ID: <20110307191615.C28C913004F@xxxxxxxxxxxxxxxxxxxxxxxx> https://bugs.freedesktop.org/show_bug.cgi?id=25071 --- Comment #6 from Chris Bannister <c.bannister at gmail.com> 2011-03-07 11:16:11 PST --- (In reply to comment #5) > Is it still an issue on recent kernels? My 8800 actually died last month, so sorry cant answer that. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at freedesktop.org Mon Mar 7 11:21:45 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Mon, 7 Mar 2011 11:21:45 -0800 (PST) Subject: [Bug 26028] Display corruption at startup In-Reply-To: <bug-26028-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> References: <bug-26028-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> Message-ID: <20110307192145.7730713004F@xxxxxxxxxxxxxxxxxxxxxxxx> https://bugs.freedesktop.org/show_bug.cgi?id=26028 Marcin Slusarz <marcin.slusarz at gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |NOTABUG --- Comment #2 from Marcin Slusarz <marcin.slusarz at gmail.com> 2011-03-07 11:21:45 PST --- No response from the reporter for more than a year. Marking as NOT A BUG. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at freedesktop.org Mon Mar 7 13:43:28 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Mon, 7 Mar 2011 13:43:28 -0800 (PST) Subject: [Bug 25071] GPU lockup G80 8800 In-Reply-To: <bug-25071-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> References: <bug-25071-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> Message-ID: <20110307214328.8773913004F@xxxxxxxxxxxxxxxxxxxxxxxx> https://bugs.freedesktop.org/show_bug.cgi?id=25071 --- Comment #7 from Alexey Dobriyan <adobriyan at gmail.com> 2011-03-07 13:43:27 PST --- > Is it still an issue on recent kernels? No. Have been using nouaveufb for quite a time. For the record 2.6.38-rc7 is OK, and earlier. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From madman2003 at gmail.com Mon Mar 7 13:51:05 2011 From: madman2003 at gmail.com (Maarten Maathuis) Date: Mon, 7 Mar 2011 21:51:05 +0000 Subject: CCACHE and VFETCH FAULTs causing lockups In-Reply-To: <62F49887-5C29-4DFD-9166-3BB6AD0E23F1@xxxxxxxxx> References: <AANLkTik0CkbQz=PoXNG7bQEn_5ssAfp7cr=Z=3qJz6h2@xxxxxxxxxxxxxx> <1299016269.1822.3.camel@nisroch> <AANLkTimiy=U04vfiXRAqDj_eT+zxSN2_3NvmF4jRQWxc@xxxxxxxxxxxxxx> <65DF9FD4-DDE0-4BA3-950A-422A3F1EF9DA@xxxxxxxxx> <AANLkTi=7YDLL8N=15ktHE3oYB2LMkm2WQ6y20+-gfmT_@xxxxxxxxxxxxxx> <62F49887-5C29-4DFD-9166-3BB6AD0E23F1@xxxxxxxxx> Message-ID: <AANLkTi=jNcm+868ppNTGA+6ufqi7muctHxMnpzj9J-k8@xxxxxxxxxxxxxx> On Sun, Mar 6, 2011 at 2:24 PM, Ben Skeggs <skeggsb at gmail.com> wrote: > > > Sent from my iPhone > > On 07/03/2011, at 0:03, Maarten Maathuis <madman2003 at gmail.com> wrote: > >> On Sun, Mar 6, 2011 at 1:44 PM, Ben Skeggs <skeggsb at gmail.com> wrote: >>> Sorry for the top posting, it's late and typing from my phone in bed lol. >>> >>> Just wanted to see if you had an update? And, this is NV86 I guess? >>> >>> Ben. >>> >>> Sent from my iPhone >>> >>> On 02/03/2011, at 8:20, Maarten Maathuis <madman2003 at gmail.com> wrote: >>> >>>> On Tue, Mar 1, 2011 at 9:51 PM, Ben Skeggs <bskeggs at redhat.com> wrote: >>>>> On Tue, 2011-03-01 at 21:08 +0000, Maarten Maathuis wrote: >>>>> >>>>>> Those come after 15-30 minutes of running warzone2100, i haven't >>>>>> played any games for a while, so no idea how long this has been going >>>>>> on. >>>>>> I also got a TRAP_CCACHE on channel 2 a little while ago, it takes >>>>>> much longer to trigger (a few hours). I'm using todays "nouveau >>>>>> kernel" git. >>>>> You're not the first person to have reported this fwiw, personally, I >>>>> haven't seen it yet.. >>>>> >>>>>> >>>>>> I'm guessing something is being unmapped too early or without reason, >>>>>> or some cache is stale. But it isn't obvious what exactly it is. >>>>>> >>>>>> Because i don't remember having these lockups before I'm inclined to >>>>>> guess that this commit is involved >>>>>> http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=6330d8f5ecc4a19fd2ad3c7fa128b2f4c2ce3360 >>>>>> >>>>>> Any ideas? >>>>> Not really. ?If this commit *is* the cause, the problem is still >>>>> somewhere else. ?That commit just makes sure PTEs are marked invalid, so >>>>> if it's causing your faults, then previously the GPU would still have >>>>> been reading/writing invalid data. >>>>> >>>>> Plus, I expect you should probably have seen a VM fault.. >>>> >>>> So these faults are just generic errors? Unrelated to page faults? >>>> >>>>> >>>>> Ben. >>>>>> >>>>>> Maarten. >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Far away from the primal instinct, the song seems to fade away, the >>>> river get wider between your thoughts and the things we do and say. >>>> _______________________________________________ >>>> Nouveau mailing list >>>> Nouveau at lists.freedesktop.org >>>> http://lists.freedesktop.org/mailman/listinfo/nouveau >>> >> >> No this is NV96. The revert definitely helps, but no luck so far in >> finding a plausible cause for the problem. > Hey, > > Ok. Hmm. I thought you had NV86 for some reason! It's a long shot and I'm not entirely convinced it'll help at all, but can you switch graph.tlb_flush pointer to the nv86 version and see if anything changes? I used to have a NV86, but it died more than a year ago in the typical way for that generation of card, due to thermal issues I guess (it was a passively cooled card). I haven't tried using the nv86 tlb flush, out of curiosity, is this something nvidia does (a lot) on nv86? > > The *other* possible thing is that the ttm delayed delete queue is causing multiple tlb flushes to happen at the same time. ?I'll add locking for that in the morning, that was a complete oversight. I've had no lockups since you added the spinlocks, so maybe that was it. Time will tell. > > Ben. > >> >> -- >> Far away from the primal instinct, the song seems to fade away, the >> river get wider between your thoughts and the things we do and say. > -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. From bugzilla-daemon at freedesktop.org Mon Mar 7 14:20:55 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Mon, 7 Mar 2011 14:20:55 -0800 (PST) Subject: [Bug 25071] GPU lockup G80 8800 In-Reply-To: <bug-25071-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> References: <bug-25071-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> Message-ID: <20110307222055.D74D513004F@xxxxxxxxxxxxxxxxxxxxxxxx> https://bugs.freedesktop.org/show_bug.cgi?id=25071 Marcin Slusarz <marcin.slusarz at gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #8 from Marcin Slusarz <marcin.slusarz at gmail.com> 2011-03-07 14:20:55 PST --- Thanks. I'm marking this as FIXED. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From skeggsb at gmail.com Mon Mar 7 14:22:45 2011 From: skeggsb at gmail.com (Ben Skeggs) Date: Tue, 08 Mar 2011 08:22:45 +1000 Subject: CCACHE and VFETCH FAULTs causing lockups In-Reply-To: <AANLkTi=jNcm+868ppNTGA+6ufqi7muctHxMnpzj9J-k8@xxxxxxxxxxxxxx> References: <AANLkTik0CkbQz=PoXNG7bQEn_5ssAfp7cr=Z=3qJz6h2@xxxxxxxxxxxxxx> <1299016269.1822.3.camel@nisroch> <AANLkTimiy=U04vfiXRAqDj_eT+zxSN2_3NvmF4jRQWxc@xxxxxxxxxxxxxx> <65DF9FD4-DDE0-4BA3-950A-422A3F1EF9DA@xxxxxxxxx> <AANLkTi=7YDLL8N=15ktHE3oYB2LMkm2WQ6y20+-gfmT_@xxxxxxxxxxxxxx> <62F49887-5C29-4DFD-9166-3BB6AD0E23F1@xxxxxxxxx> <AANLkTi=jNcm+868ppNTGA+6ufqi7muctHxMnpzj9J-k8@xxxxxxxxxxxxxx> Message-ID: <1299536569.29441.1.camel@nisroch> On Mon, 2011-03-07 at 21:51 +0000, Maarten Maathuis wrote: > On Sun, Mar 6, 2011 at 2:24 PM, Ben Skeggs <skeggsb at gmail.com> wrote: > > > > > > Sent from my iPhone > > > > On 07/03/2011, at 0:03, Maarten Maathuis <madman2003 at gmail.com> wrote: > > > >> On Sun, Mar 6, 2011 at 1:44 PM, Ben Skeggs <skeggsb at gmail.com> wrote: > >>> Sorry for the top posting, it's late and typing from my phone in bed lol. > >>> > >>> Just wanted to see if you had an update? And, this is NV86 I guess? > >>> > >>> Ben. > >>> > >>> Sent from my iPhone > >>> > >>> On 02/03/2011, at 8:20, Maarten Maathuis <madman2003 at gmail.com> wrote: > >>> > >>>> On Tue, Mar 1, 2011 at 9:51 PM, Ben Skeggs <bskeggs at redhat.com> wrote: > >>>>> On Tue, 2011-03-01 at 21:08 +0000, Maarten Maathuis wrote: > >>>>> > >>>>>> Those come after 15-30 minutes of running warzone2100, i haven't > >>>>>> played any games for a while, so no idea how long this has been going > >>>>>> on. > >>>>>> I also got a TRAP_CCACHE on channel 2 a little while ago, it takes > >>>>>> much longer to trigger (a few hours). I'm using todays "nouveau > >>>>>> kernel" git. > >>>>> You're not the first person to have reported this fwiw, personally, I > >>>>> haven't seen it yet.. > >>>>> > >>>>>> > >>>>>> I'm guessing something is being unmapped too early or without reason, > >>>>>> or some cache is stale. But it isn't obvious what exactly it is. > >>>>>> > >>>>>> Because i don't remember having these lockups before I'm inclined to > >>>>>> guess that this commit is involved > >>>>>> http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=6330d8f5ecc4a19fd2ad3c7fa128b2f4c2ce3360 > >>>>>> > >>>>>> Any ideas? > >>>>> Not really. If this commit *is* the cause, the problem is still > >>>>> somewhere else. That commit just makes sure PTEs are marked invalid, so > >>>>> if it's causing your faults, then previously the GPU would still have > >>>>> been reading/writing invalid data. > >>>>> > >>>>> Plus, I expect you should probably have seen a VM fault.. > >>>> > >>>> So these faults are just generic errors? Unrelated to page faults? > >>>> > >>>>> > >>>>> Ben. > >>>>>> > >>>>>> Maarten. > >>>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Far away from the primal instinct, the song seems to fade away, the > >>>> river get wider between your thoughts and the things we do and say. > >>>> _______________________________________________ > >>>> Nouveau mailing list > >>>> Nouveau at lists.freedesktop.org > >>>> http://lists.freedesktop.org/mailman/listinfo/nouveau > >>> > >> > >> No this is NV96. The revert definitely helps, but no luck so far in > >> finding a plausible cause for the problem. > > Hey, > > > > Ok. Hmm. I thought you had NV86 for some reason! It's a long shot and I'm not entirely convinced it'll help at all, but can you switch graph.tlb_flush pointer to the nv86 version and see if anything changes? > > I used to have a NV86, but it died more than a year ago in the typical > way for that generation of card, due to thermal issues I guess (it was > a passively cooled card). I haven't tried using the nv86 tlb flush, > out of curiosity, is this something nvidia does (a lot) on nv86? Yes, NVIDIA do it on pretty much every card I've looked at traces for, we've never seen any need for other chipsets as of yet however. Originally, it looked like NVIDIA did this on all pre-NVA3 cards, but, a trace of my T510 with recent drivers show that they do it on NVA3+ now too. > > > > > The *other* possible thing is that the ttm delayed delete queue is causing multiple tlb flushes to happen at the same time. I'll add locking for that in the morning, that was a complete oversight. > > I've had no lockups since you added the spinlocks, so maybe that was > it. Time will tell. *crosses fingers* Ben. > > > > > Ben. > > > >> > >> -- > >> Far away from the primal instinct, the song seems to fade away, the > >> river get wider between your thoughts and the things we do and say. > > > > > From bskeggs at redhat.com Mon Mar 7 14:24:26 2011 From: bskeggs at redhat.com (Ben Skeggs) Date: Tue, 08 Mar 2011 08:24:26 +1000 Subject: [PATCH] drm/nouveau: fix __nouveau_fence_wait performance regression In-Reply-To: <AANLkTin_jouzPDGfNnYq_BRqPzbvOW+F6jFNuc7p=p5E@xxxxxxxxxxxxxx> References: <20110213203804.GA5395@xxxxxxx> <20110304164905.GA2743@xxxxxxx> <AANLkTin_jouzPDGfNnYq_BRqPzbvOW+F6jFNuc7p=p5E@xxxxxxxxxxxxxx> Message-ID: <1299536668.29441.3.camel@nisroch> On Mon, 2011-03-07 at 18:18 +0000, Maarten Maathuis wrote: > On Fri, Mar 4, 2011 at 4:49 PM, Marcin Slusarz <marcin.slusarz at gmail.com> wrote: > > On Sun, Feb 13, 2011 at 09:38:04PM +0100, Marcin Slusarz wrote: > >> Combination of locking and interchannel synchronization changes > >> uncovered poor behaviour of nouveau_fence_wait, which on HZ=100 > >> configuration could waste up to 10 ms per call. > >> Depending on application, it lead to 10-30% FPS regression. > >> To fix it, shorten thread sleep time to 0.1 ms and ensure > >> spinning happens for at least one *full* tick. > >> > >> Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> > >> --- > >> drivers/gpu/drm/nouveau/nouveau_fence.c | 10 ++++++++-- > >> 1 files changed, 8 insertions(+), 2 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c > >> index 221b846..75ba5e2 100644 > >> --- a/drivers/gpu/drm/nouveau/nouveau_fence.c > >> +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c > >> @@ -27,6 +27,9 @@ > >> #include "drmP.h" > >> #include "drm.h" > >> > >> +#include <linux/ktime.h> > >> +#include <linux/hrtimer.h> > >> + > >> #include "nouveau_drv.h" > >> #include "nouveau_ramht.h" > >> #include "nouveau_dma.h" > >> @@ -230,9 +233,12 @@ int > >> __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) > >> { > >> unsigned long timeout = jiffies + (3 * DRM_HZ); > >> - unsigned long sleep_time = jiffies + 1; > >> + unsigned long sleep_time = jiffies + 2; > >> + ktime_t t; > >> int ret = 0; > >> > >> + t = ktime_set(0, NSEC_PER_MSEC / 10); > >> + > >> while (1) { > >> if (__nouveau_fence_signalled(sync_obj, sync_arg)) > >> break; > >> @@ -245,7 +251,7 @@ __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) > >> __set_current_state(intr ? TASK_INTERRUPTIBLE > >> : TASK_UNINTERRUPTIBLE); > >> if (lazy && time_after_eq(jiffies, sleep_time)) > >> - schedule_timeout(1); > >> + schedule_hrtimeout(&t, HRTIMER_MODE_REL); > >> > >> if (intr && signal_pending(current)) { > >> ret = -ERESTARTSYS; > >> -- > >> 1.7.4.rc3 > >> > > > > ping again > > _______________________________________________ > > Nouveau mailing list > > Nouveau at lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/nouveau > > > > This looks ok to me, but I would like to get Ben Skeggs ok on this one > as well. So i've CC'ed him, hopefully he'll notice :-) Ah sorry, I have actually looked at this quite a while back but came to no solid conclusion. While yes, I did see some minor performance improvement from it, I also notice that now we once again get 100% CPU usage while an app is waiting for the GPU a lot.. Ben. > From marcin.slusarz at gmail.com Mon Mar 7 15:22:56 2011 From: marcin.slusarz at gmail.com (Marcin Slusarz) Date: Tue, 8 Mar 2011 00:22:56 +0100 Subject: [PATCH] drm/nouveau: fix __nouveau_fence_wait performance regression In-Reply-To: <1299536668.29441.3.camel@nisroch> References: <20110213203804.GA5395@xxxxxxx> <20110304164905.GA2743@xxxxxxx> <AANLkTin_jouzPDGfNnYq_BRqPzbvOW+F6jFNuc7p=p5E@xxxxxxxxxxxxxx> <1299536668.29441.3.camel@nisroch> Message-ID: <20110307232256.GA2680@xxxxxxx> On Tue, Mar 08, 2011 at 08:24:26AM +1000, Ben Skeggs wrote: > On Mon, 2011-03-07 at 18:18 +0000, Maarten Maathuis wrote: > > On Fri, Mar 4, 2011 at 4:49 PM, Marcin Slusarz <marcin.slusarz at gmail.com> wrote: > > > On Sun, Feb 13, 2011 at 09:38:04PM +0100, Marcin Slusarz wrote: > > >> Combination of locking and interchannel synchronization changes > > >> uncovered poor behaviour of nouveau_fence_wait, which on HZ=100 > > >> configuration could waste up to 10 ms per call. > > >> Depending on application, it lead to 10-30% FPS regression. > > >> To fix it, shorten thread sleep time to 0.1 ms and ensure > > >> spinning happens for at least one *full* tick. > > >> > > >> Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> > > >> --- > > >> drivers/gpu/drm/nouveau/nouveau_fence.c | 10 ++++++++-- > > >> 1 files changed, 8 insertions(+), 2 deletions(-) > > >> > > >> diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c > > >> index 221b846..75ba5e2 100644 > > >> --- a/drivers/gpu/drm/nouveau/nouveau_fence.c > > >> +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c > > >> @@ -27,6 +27,9 @@ > > >> #include "drmP.h" > > >> #include "drm.h" > > >> > > >> +#include <linux/ktime.h> > > >> +#include <linux/hrtimer.h> > > >> + > > >> #include "nouveau_drv.h" > > >> #include "nouveau_ramht.h" > > >> #include "nouveau_dma.h" > > >> @@ -230,9 +233,12 @@ int > > >> __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) > > >> { > > >> unsigned long timeout = jiffies + (3 * DRM_HZ); > > >> - unsigned long sleep_time = jiffies + 1; > > >> + unsigned long sleep_time = jiffies + 2; > > >> + ktime_t t; > > >> int ret = 0; > > >> > > >> + t = ktime_set(0, NSEC_PER_MSEC / 10); > > >> + > > >> while (1) { > > >> if (__nouveau_fence_signalled(sync_obj, sync_arg)) > > >> break; > > >> @@ -245,7 +251,7 @@ __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) > > >> __set_current_state(intr ? TASK_INTERRUPTIBLE > > >> : TASK_UNINTERRUPTIBLE); > > >> if (lazy && time_after_eq(jiffies, sleep_time)) > > >> - schedule_timeout(1); > > >> + schedule_hrtimeout(&t, HRTIMER_MODE_REL); > > >> > > >> if (intr && signal_pending(current)) { > > >> ret = -ERESTARTSYS; > > >> -- > > >> 1.7.4.rc3 > > >> > > > > > > ping again > > > _______________________________________________ > > > Nouveau mailing list > > > Nouveau at lists.freedesktop.org > > > http://lists.freedesktop.org/mailman/listinfo/nouveau > > > > > > > This looks ok to me, but I would like to get Ben Skeggs ok on this one > > as well. So i've CC'ed him, hopefully he'll notice :-) > Ah sorry, I have actually looked at this quite a while back but came to > no solid conclusion. > > While yes, I did see some minor performance improvement from it, I also > notice that now we once again get 100% CPU usage while an app is waiting > for the GPU a lot.. It's not "minor" performance improvement: without this patch (FPS): nexuiz: 53 wop: 181 tremulous: 157 wsw0.5: 89 glxgears: 730 with: nexuiz: 63 (+18%) wop: 248 (+37%) tremulous: 156 (-0.6%) wsw0.5: 91 (+2%) glxgears: 1054 (+44%) Ok, so you are worried about CPU usage... Let's see what will happen if I remove spinning added by "drm/nouveau: Spin for a bit in nouveau_fence_wait() before yielding the CPU". reduced version (attached): nexuiz: 62 wop: 248 trem: 157 wsw0.5: 90 glxgears: 1055 Good enough? --- From: Marcin Slusarz <marcin.slusarz at gmail.com> Subject: [PATCH] drm/nouveau: fix __nouveau_fence_wait performance regression Combination of locking and interchannel synchronization changes uncovered poor behaviour of nouveau_fence_wait, which on HZ=100 configuration could waste up to 10 ms per call. Depending on application, it lead to 10-30% FPS regression. To fix it, shorten thread sleep time to 0.1 ms. Additionally, remove spinning (added by "drm/nouveau: Spin for a bit in nouveau_fence_wait() before yielding the CPU"), because it's not needed anymore. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_fence.c | 11 ++++++++--- 1 files changed, 8 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c index a244702..010243b 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fence.c +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c @@ -27,6 +27,9 @@ #include "drmP.h" #include "drm.h" +#include <linux/ktime.h> +#include <linux/hrtimer.h> + #include "nouveau_drv.h" #include "nouveau_ramht.h" #include "nouveau_dma.h" @@ -229,9 +232,11 @@ int __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) { unsigned long timeout = jiffies + (3 * DRM_HZ); - unsigned long sleep_time = jiffies + 1; + ktime_t t; int ret = 0; + t = ktime_set(0, NSEC_PER_MSEC / 10); + while (1) { if (__nouveau_fence_signalled(sync_obj, sync_arg)) break; @@ -243,8 +248,8 @@ __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) __set_current_state(intr ? TASK_INTERRUPTIBLE : TASK_UNINTERRUPTIBLE); - if (lazy && time_after_eq(jiffies, sleep_time)) - schedule_timeout(1); + if (lazy) + schedule_hrtimeout(&t, HRTIMER_MODE_REL); if (intr && signal_pending(current)) { ret = -ERESTARTSYS; -- 1.7.4.rc3 From marcin.slusarz at gmail.com Mon Mar 7 15:27:19 2011 From: marcin.slusarz at gmail.com (Marcin Slusarz) Date: Tue, 8 Mar 2011 00:27:19 +0100 Subject: [PATCH] drm/nouveau: fix __nouveau_fence_wait performance regression In-Reply-To: <20110307232256.GA2680@xxxxxxx> References: <20110213203804.GA5395@xxxxxxx> <20110304164905.GA2743@xxxxxxx> <AANLkTin_jouzPDGfNnYq_BRqPzbvOW+F6jFNuc7p=p5E@xxxxxxxxxxxxxx> <1299536668.29441.3.camel@nisroch> <20110307232256.GA2680@xxxxxxx> Message-ID: <20110307232719.GB2680@xxxxxxx> On Tue, Mar 08, 2011 at 12:22:56AM +0100, Marcin Slusarz wrote: > On Tue, Mar 08, 2011 at 08:24:26AM +1000, Ben Skeggs wrote: > > On Mon, 2011-03-07 at 18:18 +0000, Maarten Maathuis wrote: > > > On Fri, Mar 4, 2011 at 4:49 PM, Marcin Slusarz <marcin.slusarz at gmail.com> wrote: > > > > On Sun, Feb 13, 2011 at 09:38:04PM +0100, Marcin Slusarz wrote: > > > >> Combination of locking and interchannel synchronization changes > > > >> uncovered poor behaviour of nouveau_fence_wait, which on HZ=100 > > > >> configuration could waste up to 10 ms per call. > > > >> Depending on application, it lead to 10-30% FPS regression. > > > >> To fix it, shorten thread sleep time to 0.1 ms and ensure > > > >> spinning happens for at least one *full* tick. > > > >> > > > >> Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> > > > >> --- > > > >> drivers/gpu/drm/nouveau/nouveau_fence.c | 10 ++++++++-- > > > >> 1 files changed, 8 insertions(+), 2 deletions(-) > > > >> > > > >> diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c > > > >> index 221b846..75ba5e2 100644 > > > >> --- a/drivers/gpu/drm/nouveau/nouveau_fence.c > > > >> +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c > > > >> @@ -27,6 +27,9 @@ > > > >> #include "drmP.h" > > > >> #include "drm.h" > > > >> > > > >> +#include <linux/ktime.h> > > > >> +#include <linux/hrtimer.h> > > > >> + > > > >> #include "nouveau_drv.h" > > > >> #include "nouveau_ramht.h" > > > >> #include "nouveau_dma.h" > > > >> @@ -230,9 +233,12 @@ int > > > >> __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) > > > >> { > > > >> unsigned long timeout = jiffies + (3 * DRM_HZ); > > > >> - unsigned long sleep_time = jiffies + 1; > > > >> + unsigned long sleep_time = jiffies + 2; > > > >> + ktime_t t; > > > >> int ret = 0; > > > >> > > > >> + t = ktime_set(0, NSEC_PER_MSEC / 10); > > > >> + > > > >> while (1) { > > > >> if (__nouveau_fence_signalled(sync_obj, sync_arg)) > > > >> break; > > > >> @@ -245,7 +251,7 @@ __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) > > > >> __set_current_state(intr ? TASK_INTERRUPTIBLE > > > >> : TASK_UNINTERRUPTIBLE); > > > >> if (lazy && time_after_eq(jiffies, sleep_time)) > > > >> - schedule_timeout(1); > > > >> + schedule_hrtimeout(&t, HRTIMER_MODE_REL); > > > >> > > > >> if (intr && signal_pending(current)) { > > > >> ret = -ERESTARTSYS; > > > >> -- > > > >> 1.7.4.rc3 > > > >> > > > > > > > > ping again > > > > _______________________________________________ > > > > Nouveau mailing list > > > > Nouveau at lists.freedesktop.org > > > > http://lists.freedesktop.org/mailman/listinfo/nouveau > > > > > > > > > > This looks ok to me, but I would like to get Ben Skeggs ok on this one > > > as well. So i've CC'ed him, hopefully he'll notice :-) > > Ah sorry, I have actually looked at this quite a while back but came to > > no solid conclusion. > > > > While yes, I did see some minor performance improvement from it, I also > > notice that now we once again get 100% CPU usage while an app is waiting > > for the GPU a lot.. > > It's not "minor" performance improvement: > > without this patch (FPS): > nexuiz: 53 > wop: 181 > tremulous: 157 > wsw0.5: 89 > glxgears: 730 > > with: > nexuiz: 63 (+18%) > wop: 248 (+37%) > tremulous: 156 (-0.6%) > wsw0.5: 91 (+2%) > glxgears: 1054 (+44%) > > > Ok, so you are worried about CPU usage... Let's see what will happen if > I remove spinning added by "drm/nouveau: Spin for a bit in > nouveau_fence_wait() before yielding the CPU". > > reduced version (attached): > nexuiz: 62 > wop: 248 > trem: 157 > wsw0.5: 90 > glxgears: 1055 > > Good enough? Just for comparison: kernel 2.6.37 + pre nvc0fied mesa had: nexuiz: 34 wop: 139 tremulous: 82 wsw0.5: 53 glxgears: 1056 > --- > From: Marcin Slusarz <marcin.slusarz at gmail.com> > Subject: [PATCH] drm/nouveau: fix __nouveau_fence_wait performance regression > > Combination of locking and interchannel synchronization changes > uncovered poor behaviour of nouveau_fence_wait, which on HZ=100 > configuration could waste up to 10 ms per call. > Depending on application, it lead to 10-30% FPS regression. > > To fix it, shorten thread sleep time to 0.1 ms. > > Additionally, remove spinning (added by "drm/nouveau: Spin for > a bit in nouveau_fence_wait() before yielding the CPU"), because > it's not needed anymore. > > Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> > --- > drivers/gpu/drm/nouveau/nouveau_fence.c | 11 ++++++++--- > 1 files changed, 8 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c > index a244702..010243b 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_fence.c > +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c > @@ -27,6 +27,9 @@ > #include "drmP.h" > #include "drm.h" > > +#include <linux/ktime.h> > +#include <linux/hrtimer.h> > + > #include "nouveau_drv.h" > #include "nouveau_ramht.h" > #include "nouveau_dma.h" > @@ -229,9 +232,11 @@ int > __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) > { > unsigned long timeout = jiffies + (3 * DRM_HZ); > - unsigned long sleep_time = jiffies + 1; > + ktime_t t; > int ret = 0; > > + t = ktime_set(0, NSEC_PER_MSEC / 10); > + > while (1) { > if (__nouveau_fence_signalled(sync_obj, sync_arg)) > break; > @@ -243,8 +248,8 @@ __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) > > __set_current_state(intr ? TASK_INTERRUPTIBLE > : TASK_UNINTERRUPTIBLE); > - if (lazy && time_after_eq(jiffies, sleep_time)) > - schedule_timeout(1); > + if (lazy) > + schedule_hrtimeout(&t, HRTIMER_MODE_REL); > > if (intr && signal_pending(current)) { > ret = -ERESTARTSYS; > -- > 1.7.4.rc3 > From bskeggs at redhat.com Mon Mar 7 16:34:37 2011 From: bskeggs at redhat.com (Ben Skeggs) Date: Tue, 08 Mar 2011 10:34:37 +1000 Subject: [PATCH] drm/nouveau: fix __nouveau_fence_wait performance regression In-Reply-To: <20110307232719.GB2680@xxxxxxx> References: <20110213203804.GA5395@xxxxxxx> <20110304164905.GA2743@xxxxxxx> <AANLkTin_jouzPDGfNnYq_BRqPzbvOW+F6jFNuc7p=p5E@xxxxxxxxxxxxxx> <1299536668.29441.3.camel@nisroch> <20110307232256.GA2680@xxxxxxx> <20110307232719.GB2680@xxxxxxx> Message-ID: <1299544479.14726.2.camel@nisroch> On Tue, 2011-03-08 at 00:27 +0100, Marcin Slusarz wrote: > On Tue, Mar 08, 2011 at 12:22:56AM +0100, Marcin Slusarz wrote: > > On Tue, Mar 08, 2011 at 08:24:26AM +1000, Ben Skeggs wrote: > > > On Mon, 2011-03-07 at 18:18 +0000, Maarten Maathuis wrote: > > > > On Fri, Mar 4, 2011 at 4:49 PM, Marcin Slusarz <marcin.slusarz at gmail.com> wrote: > > > > > On Sun, Feb 13, 2011 at 09:38:04PM +0100, Marcin Slusarz wrote: > > > > >> Combination of locking and interchannel synchronization changes > > > > >> uncovered poor behaviour of nouveau_fence_wait, which on HZ=100 > > > > >> configuration could waste up to 10 ms per call. > > > > >> Depending on application, it lead to 10-30% FPS regression. > > > > >> To fix it, shorten thread sleep time to 0.1 ms and ensure > > > > >> spinning happens for at least one *full* tick. > > > > >> > > > > >> Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> > > > > >> --- > > > > >> drivers/gpu/drm/nouveau/nouveau_fence.c | 10 ++++++++-- > > > > >> 1 files changed, 8 insertions(+), 2 deletions(-) > > > > >> > > > > >> diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c > > > > >> index 221b846..75ba5e2 100644 > > > > >> --- a/drivers/gpu/drm/nouveau/nouveau_fence.c > > > > >> +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c > > > > >> @@ -27,6 +27,9 @@ > > > > >> #include "drmP.h" > > > > >> #include "drm.h" > > > > >> > > > > >> +#include <linux/ktime.h> > > > > >> +#include <linux/hrtimer.h> > > > > >> + > > > > >> #include "nouveau_drv.h" > > > > >> #include "nouveau_ramht.h" > > > > >> #include "nouveau_dma.h" > > > > >> @@ -230,9 +233,12 @@ int > > > > >> __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) > > > > >> { > > > > >> unsigned long timeout = jiffies + (3 * DRM_HZ); > > > > >> - unsigned long sleep_time = jiffies + 1; > > > > >> + unsigned long sleep_time = jiffies + 2; > > > > >> + ktime_t t; > > > > >> int ret = 0; > > > > >> > > > > >> + t = ktime_set(0, NSEC_PER_MSEC / 10); > > > > >> + > > > > >> while (1) { > > > > >> if (__nouveau_fence_signalled(sync_obj, sync_arg)) > > > > >> break; > > > > >> @@ -245,7 +251,7 @@ __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) > > > > >> __set_current_state(intr ? TASK_INTERRUPTIBLE > > > > >> : TASK_UNINTERRUPTIBLE); > > > > >> if (lazy && time_after_eq(jiffies, sleep_time)) > > > > >> - schedule_timeout(1); > > > > >> + schedule_hrtimeout(&t, HRTIMER_MODE_REL); > > > > >> > > > > >> if (intr && signal_pending(current)) { > > > > >> ret = -ERESTARTSYS; > > > > >> -- > > > > >> 1.7.4.rc3 > > > > >> > > > > > > > > > > ping again > > > > > _______________________________________________ > > > > > Nouveau mailing list > > > > > Nouveau at lists.freedesktop.org > > > > > http://lists.freedesktop.org/mailman/listinfo/nouveau > > > > > > > > > > > > > This looks ok to me, but I would like to get Ben Skeggs ok on this one > > > > as well. So i've CC'ed him, hopefully he'll notice :-) > > > Ah sorry, I have actually looked at this quite a while back but came to > > > no solid conclusion. > > > > > > While yes, I did see some minor performance improvement from it, I also > > > notice that now we once again get 100% CPU usage while an app is waiting > > > for the GPU a lot.. > > > > It's not "minor" performance improvement: > > > > without this patch (FPS): > > nexuiz: 53 > > wop: 181 > > tremulous: 157 > > wsw0.5: 89 > > glxgears: 730 > > > > with: > > nexuiz: 63 (+18%) > > wop: 248 (+37%) > > tremulous: 156 (-0.6%) > > wsw0.5: 91 (+2%) > > glxgears: 1054 (+44%) > > > > > > Ok, so you are worried about CPU usage... Let's see what will happen if > > I remove spinning added by "drm/nouveau: Spin for a bit in > > nouveau_fence_wait() before yielding the CPU". > > > > reduced version (attached): > > nexuiz: 62 > > wop: 248 > > trem: 157 > > wsw0.5: 90 > > glxgears: 1055 > > > > Good enough? > > Just for comparison: > kernel 2.6.37 + pre nvc0fied mesa had: > nexuiz: 34 > wop: 139 > tremulous: 82 > wsw0.5: 53 > glxgears: 1056 Here's what I see on NVA8 with nv50fiednvc0 (mesa master and nouveau master), with all cpu cores set to "performance": Before: gears: 998 (25.0% cpu) OA: 197.2 nexuiz: 34.81 After: gears: 980 (21.0% cpu) OA: 195.7 nexuiz: 35.30 I also tried with all cores set to "powersave" for comparison. It's pretty much the same deal there with little to no difference between before/after, *except* glxgears gains 100fps here. Ben. > > > --- > > From: Marcin Slusarz <marcin.slusarz at gmail.com> > > Subject: [PATCH] drm/nouveau: fix __nouveau_fence_wait performance regression > > > > Combination of locking and interchannel synchronization changes > > uncovered poor behaviour of nouveau_fence_wait, which on HZ=100 > > configuration could waste up to 10 ms per call. > > Depending on application, it lead to 10-30% FPS regression. > > > > To fix it, shorten thread sleep time to 0.1 ms. > > > > Additionally, remove spinning (added by "drm/nouveau: Spin for > > a bit in nouveau_fence_wait() before yielding the CPU"), because > > it's not needed anymore. > > > > Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> > > --- > > drivers/gpu/drm/nouveau/nouveau_fence.c | 11 ++++++++--- > > 1 files changed, 8 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c > > index a244702..010243b 100644 > > --- a/drivers/gpu/drm/nouveau/nouveau_fence.c > > +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c > > @@ -27,6 +27,9 @@ > > #include "drmP.h" > > #include "drm.h" > > > > +#include <linux/ktime.h> > > +#include <linux/hrtimer.h> > > + > > #include "nouveau_drv.h" > > #include "nouveau_ramht.h" > > #include "nouveau_dma.h" > > @@ -229,9 +232,11 @@ int > > __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) > > { > > unsigned long timeout = jiffies + (3 * DRM_HZ); > > - unsigned long sleep_time = jiffies + 1; > > + ktime_t t; > > int ret = 0; > > > > + t = ktime_set(0, NSEC_PER_MSEC / 10); > > + > > while (1) { > > if (__nouveau_fence_signalled(sync_obj, sync_arg)) > > break; > > @@ -243,8 +248,8 @@ __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) > > > > __set_current_state(intr ? TASK_INTERRUPTIBLE > > : TASK_UNINTERRUPTIBLE); > > - if (lazy && time_after_eq(jiffies, sleep_time)) > > - schedule_timeout(1); > > + if (lazy) > > + schedule_hrtimeout(&t, HRTIMER_MODE_REL); > > > > if (intr && signal_pending(current)) { > > ret = -ERESTARTSYS; > > -- > > 1.7.4.rc3 > > > _______________________________________________ > Nouveau mailing list > Nouveau at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/nouveau From currojerez at riseup.net Mon Mar 7 16:58:50 2011 From: currojerez at riseup.net (Francisco Jerez) Date: Tue, 08 Mar 2011 01:58:50 +0100 Subject: [PATCH] drm/nouveau: fix __nouveau_fence_wait performance regression In-Reply-To: <20110307232256.GA2680@xxxxxxx> (Marcin Slusarz's message of "Tue, 8 Mar 2011 00:22:56 +0100") References: <20110213203804.GA5395@xxxxxxx> <20110304164905.GA2743@xxxxxxx> <AANLkTin_jouzPDGfNnYq_BRqPzbvOW+F6jFNuc7p=p5E@xxxxxxxxxxxxxx> <1299536668.29441.3.camel@nisroch> <20110307232256.GA2680@xxxxxxx> Message-ID: <87lj0qzaut.fsf@xxxxxxxxxx> Marcin Slusarz <marcin.slusarz at gmail.com> writes: > On Tue, Mar 08, 2011 at 08:24:26AM +1000, Ben Skeggs wrote: >> On Mon, 2011-03-07 at 18:18 +0000, Maarten Maathuis wrote: >> > On Fri, Mar 4, 2011 at 4:49 PM, Marcin Slusarz <marcin.slusarz at gmail.com> wrote: >> > > On Sun, Feb 13, 2011 at 09:38:04PM +0100, Marcin Slusarz wrote: >> > >> Combination of locking and interchannel synchronization changes >> > >> uncovered poor behaviour of nouveau_fence_wait, which on HZ=100 >> > >> configuration could waste up to 10 ms per call. >> > >> Depending on application, it lead to 10-30% FPS regression. >> > >> To fix it, shorten thread sleep time to 0.1 ms and ensure >> > >> spinning happens for at least one *full* tick. >> > >> >> > >> Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> >> > >> --- >> > >> drivers/gpu/drm/nouveau/nouveau_fence.c | 10 ++++++++-- >> > >> 1 files changed, 8 insertions(+), 2 deletions(-) >> > >> >> > >> diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c >> > >> index 221b846..75ba5e2 100644 >> > >> --- a/drivers/gpu/drm/nouveau/nouveau_fence.c >> > >> +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c >> > >> @@ -27,6 +27,9 @@ >> > >> #include "drmP.h" >> > >> #include "drm.h" >> > >> >> > >> +#include <linux/ktime.h> >> > >> +#include <linux/hrtimer.h> >> > >> + >> > >> #include "nouveau_drv.h" >> > >> #include "nouveau_ramht.h" >> > >> #include "nouveau_dma.h" >> > >> @@ -230,9 +233,12 @@ int >> > >> __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) >> > >> { >> > >> unsigned long timeout = jiffies + (3 * DRM_HZ); >> > >> - unsigned long sleep_time = jiffies + 1; >> > >> + unsigned long sleep_time = jiffies + 2; >> > >> + ktime_t t; >> > >> int ret = 0; >> > >> >> > >> + t = ktime_set(0, NSEC_PER_MSEC / 10); >> > >> + >> > >> while (1) { >> > >> if (__nouveau_fence_signalled(sync_obj, sync_arg)) >> > >> break; >> > >> @@ -245,7 +251,7 @@ __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) >> > >> __set_current_state(intr ? TASK_INTERRUPTIBLE >> > >> : TASK_UNINTERRUPTIBLE); >> > >> if (lazy && time_after_eq(jiffies, sleep_time)) >> > >> - schedule_timeout(1); >> > >> + schedule_hrtimeout(&t, HRTIMER_MODE_REL); >> > >> >> > >> if (intr && signal_pending(current)) { >> > >> ret = -ERESTARTSYS; >> > >> -- >> > >> 1.7.4.rc3 >> > >> >> > > >> > > ping again >> > > _______________________________________________ >> > > Nouveau mailing list >> > > Nouveau at lists.freedesktop.org >> > > http://lists.freedesktop.org/mailman/listinfo/nouveau >> > > >> > >> > This looks ok to me, but I would like to get Ben Skeggs ok on this one >> > as well. So i've CC'ed him, hopefully he'll notice :-) >> Ah sorry, I have actually looked at this quite a while back but came to >> no solid conclusion. >> >> While yes, I did see some minor performance improvement from it, I also >> notice that now we once again get 100% CPU usage while an app is waiting >> for the GPU a lot.. > > It's not "minor" performance improvement: > > without this patch (FPS): > nexuiz: 53 > wop: 181 > tremulous: 157 > wsw0.5: 89 > glxgears: 730 > > with: > nexuiz: 63 (+18%) > wop: 248 (+37%) > tremulous: 156 (-0.6%) > wsw0.5: 91 (+2%) > glxgears: 1054 (+44%) > > > Ok, so you are worried about CPU usage... Let's see what will happen if > I remove spinning added by "drm/nouveau: Spin for a bit in > nouveau_fence_wait() before yielding the CPU". > > reduced version (attached): > nexuiz: 62 > wop: 248 > trem: 157 > wsw0.5: 90 > glxgears: 1055 > > Good enough? Remember to exercise some software fallbacks as well (e.g. something using core fonts), software fallbacks were the main users of the spinning you've removed. Anyway, software fallbacks and occlusion queries are the only two places (that I can think of now) where we need the low latency your patch gives, and, as Ben already pointed out, we probably want to keep CPU usage at minimum in every other case. As a middle ground, the "lazy" flag (or rather, a "hog" flag?) could be exposed all the way up to userspace, and those two cases fixed to set the flag differently. What do you think? > > --- > From: Marcin Slusarz <marcin.slusarz at gmail.com> > Subject: [PATCH] drm/nouveau: fix __nouveau_fence_wait performance regression > > Combination of locking and interchannel synchronization changes > uncovered poor behaviour of nouveau_fence_wait, which on HZ=100 > configuration could waste up to 10 ms per call. > Depending on application, it lead to 10-30% FPS regression. > > To fix it, shorten thread sleep time to 0.1 ms. > > Additionally, remove spinning (added by "drm/nouveau: Spin for > a bit in nouveau_fence_wait() before yielding the CPU"), because > it's not needed anymore. > > Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> > --- > drivers/gpu/drm/nouveau/nouveau_fence.c | 11 ++++++++--- > 1 files changed, 8 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c > index a244702..010243b 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_fence.c > +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c > @@ -27,6 +27,9 @@ > #include "drmP.h" > #include "drm.h" > > +#include <linux/ktime.h> > +#include <linux/hrtimer.h> > + > #include "nouveau_drv.h" > #include "nouveau_ramht.h" > #include "nouveau_dma.h" > @@ -229,9 +232,11 @@ int > __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) > { > unsigned long timeout = jiffies + (3 * DRM_HZ); > - unsigned long sleep_time = jiffies + 1; > + ktime_t t; > int ret = 0; > > + t = ktime_set(0, NSEC_PER_MSEC / 10); > + > while (1) { > if (__nouveau_fence_signalled(sync_obj, sync_arg)) > break; > @@ -243,8 +248,8 @@ __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) > > __set_current_state(intr ? TASK_INTERRUPTIBLE > : TASK_UNINTERRUPTIBLE); > - if (lazy && time_after_eq(jiffies, sleep_time)) > - schedule_timeout(1); > + if (lazy) > + schedule_hrtimeout(&t, HRTIMER_MODE_REL); > > if (intr && signal_pending(current)) { > ret = -ERESTARTSYS; -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 229 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/nouveau/attachments/20110308/8e2f7b20/attachment.pgp> From dev at lynxeye.de Tue Mar 8 03:22:36 2011 From: dev at lynxeye.de (Lucas Stach) Date: Tue, 08 Mar 2011 12:22:36 +0100 Subject: CCACHE and VFETCH FAULTs causing lockups In-Reply-To: <1299536569.29441.1.camel@nisroch> References: <AANLkTik0CkbQz=PoXNG7bQEn_5ssAfp7cr=Z=3qJz6h2@xxxxxxxxxxxxxx> <1299016269.1822.3.camel@nisroch> <AANLkTimiy=U04vfiXRAqDj_eT+zxSN2_3NvmF4jRQWxc@xxxxxxxxxxxxxx> <65DF9FD4-DDE0-4BA3-950A-422A3F1EF9DA@xxxxxxxxx> <AANLkTi=7YDLL8N=15ktHE3oYB2LMkm2WQ6y20+-gfmT_@xxxxxxxxxxxxxx> <62F49887-5C29-4DFD-9166-3BB6AD0E23F1@xxxxxxxxx> <AANLkTi=jNcm+868ppNTGA+6ufqi7muctHxMnpzj9J-k8@xxxxxxxxxxxxxx> <1299536569.29441.1.camel@nisroch> Message-ID: <1299583356.2199.1.camel@workstation> Am Dienstag, den 08.03.2011, 08:22 +1000 schrieb Ben Skeggs: > > > > > > The *other* possible thing is that the ttm delayed delete queue is causing multiple tlb flushes to happen at the same time. I'll add locking for that in the morning, that was a complete oversight. > > > > I've had no lockups since you added the spinlocks, so maybe that was > > it. Time will tell. > *crosses fingers* > Confirming that nouveau seems pretty stable again on my NVA8 after the locking commit. No lockups so far. -- Lucas > Ben. From marcin.slusarz at gmail.com Tue Mar 8 04:16:28 2011 From: marcin.slusarz at gmail.com (Marcin Slusarz) Date: Tue, 8 Mar 2011 13:16:28 +0100 Subject: [PATCH] drm/nouveau: fix __nouveau_fence_wait performance regression In-Reply-To: <87lj0qzaut.fsf@xxxxxxxxxx> References: <20110213203804.GA5395@xxxxxxx> <20110304164905.GA2743@xxxxxxx> <AANLkTin_jouzPDGfNnYq_BRqPzbvOW+F6jFNuc7p=p5E@xxxxxxxxxxxxxx> <1299536668.29441.3.camel@nisroch> <20110307232256.GA2680@xxxxxxx> <87lj0qzaut.fsf@xxxxxxxxxx> Message-ID: <20110308121628.GA20238@xxxxxxx> On Tue, Mar 08, 2011 at 01:58:50AM +0100, Francisco Jerez wrote: > Marcin Slusarz <marcin.slusarz at gmail.com> writes: > > > On Tue, Mar 08, 2011 at 08:24:26AM +1000, Ben Skeggs wrote: > >> On Mon, 2011-03-07 at 18:18 +0000, Maarten Maathuis wrote: > >> > On Fri, Mar 4, 2011 at 4:49 PM, Marcin Slusarz <marcin.slusarz at gmail.com> wrote: > >> > > On Sun, Feb 13, 2011 at 09:38:04PM +0100, Marcin Slusarz wrote: > >> > >> Combination of locking and interchannel synchronization changes > >> > >> uncovered poor behaviour of nouveau_fence_wait, which on HZ=100 > >> > >> configuration could waste up to 10 ms per call. > >> > >> Depending on application, it lead to 10-30% FPS regression. > >> > >> To fix it, shorten thread sleep time to 0.1 ms and ensure > >> > >> spinning happens for at least one *full* tick. > >> > >> > >> > >> Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> > >> > >> --- > >> > >> drivers/gpu/drm/nouveau/nouveau_fence.c | 10 ++++++++-- > >> > >> 1 files changed, 8 insertions(+), 2 deletions(-) > >> > >> > >> > >> diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c > >> > >> index 221b846..75ba5e2 100644 > >> > >> --- a/drivers/gpu/drm/nouveau/nouveau_fence.c > >> > >> +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c > >> > >> @@ -27,6 +27,9 @@ > >> > >> #include "drmP.h" > >> > >> #include "drm.h" > >> > >> > >> > >> +#include <linux/ktime.h> > >> > >> +#include <linux/hrtimer.h> > >> > >> + > >> > >> #include "nouveau_drv.h" > >> > >> #include "nouveau_ramht.h" > >> > >> #include "nouveau_dma.h" > >> > >> @@ -230,9 +233,12 @@ int > >> > >> __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) > >> > >> { > >> > >> unsigned long timeout = jiffies + (3 * DRM_HZ); > >> > >> - unsigned long sleep_time = jiffies + 1; > >> > >> + unsigned long sleep_time = jiffies + 2; > >> > >> + ktime_t t; > >> > >> int ret = 0; > >> > >> > >> > >> + t = ktime_set(0, NSEC_PER_MSEC / 10); > >> > >> + > >> > >> while (1) { > >> > >> if (__nouveau_fence_signalled(sync_obj, sync_arg)) > >> > >> break; > >> > >> @@ -245,7 +251,7 @@ __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) > >> > >> __set_current_state(intr ? TASK_INTERRUPTIBLE > >> > >> : TASK_UNINTERRUPTIBLE); > >> > >> if (lazy && time_after_eq(jiffies, sleep_time)) > >> > >> - schedule_timeout(1); > >> > >> + schedule_hrtimeout(&t, HRTIMER_MODE_REL); > >> > >> > >> > >> if (intr && signal_pending(current)) { > >> > >> ret = -ERESTARTSYS; > >> > >> -- > >> > >> 1.7.4.rc3 > >> > >> > >> > > > >> > > ping again > >> > > _______________________________________________ > >> > > Nouveau mailing list > >> > > Nouveau at lists.freedesktop.org > >> > > http://lists.freedesktop.org/mailman/listinfo/nouveau > >> > > > >> > > >> > This looks ok to me, but I would like to get Ben Skeggs ok on this one > >> > as well. So i've CC'ed him, hopefully he'll notice :-) > >> Ah sorry, I have actually looked at this quite a while back but came to > >> no solid conclusion. > >> > >> While yes, I did see some minor performance improvement from it, I also > >> notice that now we once again get 100% CPU usage while an app is waiting > >> for the GPU a lot.. > > > > It's not "minor" performance improvement: > > > > without this patch (FPS): > > nexuiz: 53 > > wop: 181 > > tremulous: 157 > > wsw0.5: 89 > > glxgears: 730 > > > > with: > > nexuiz: 63 (+18%) > > wop: 248 (+37%) > > tremulous: 156 (-0.6%) > > wsw0.5: 91 (+2%) > > glxgears: 1054 (+44%) > > > > > > Ok, so you are worried about CPU usage... Let's see what will happen if > > I remove spinning added by "drm/nouveau: Spin for a bit in > > nouveau_fence_wait() before yielding the CPU". > > > > reduced version (attached): > > nexuiz: 62 > > wop: 248 > > trem: 157 > > wsw0.5: 90 > > glxgears: 1055 > > > > Good enough? > > Remember to exercise some software fallbacks as well (e.g. something > using core fonts), software fallbacks were the main users of the > spinning you've removed. corefonts are pretty fast (measured "time dmesg"): without (spinning + timeout 10ms): 0.08s with (spinning + hrtimeout 0.1ms): 0.08s reduced (no spinning + hrtimeout 0.1ms): 0.25s old (no spinning + timeout 10ms): 13s So I think "no spinning + hrtimeout 0.1ms" is a reasonable compromise... BTW, old behaviour (no spinning + timeout 10ms) affects other workloads too nexuiz: 50 wop: 153 tremulous: 155 wsw0.5: 89 glxgears: 100 (!) > Anyway, software fallbacks and occlusion queries are the only two places > (that I can think of now) where we need the low latency your patch > gives, and, as Ben already pointed out, we probably want to keep CPU > usage at minimum in every other case. As a middle ground, the "lazy" > flag (or rather, a "hog" flag?) could be exposed all the way up to > userspace, and those two cases fixed to set the flag differently. > > What do you think? I'm not sure. I think optimizing for low CPU usage is not the best what we can do right now. 3D performance is still too low behind blob. Let's fix 3D perf first and think about CPU usage later. > > > > --- > > From: Marcin Slusarz <marcin.slusarz at gmail.com> > > Subject: [PATCH] drm/nouveau: fix __nouveau_fence_wait performance regression > > > > Combination of locking and interchannel synchronization changes > > uncovered poor behaviour of nouveau_fence_wait, which on HZ=100 > > configuration could waste up to 10 ms per call. > > Depending on application, it lead to 10-30% FPS regression. > > > > To fix it, shorten thread sleep time to 0.1 ms. > > > > Additionally, remove spinning (added by "drm/nouveau: Spin for > > a bit in nouveau_fence_wait() before yielding the CPU"), because > > it's not needed anymore. > > > > Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> > > --- > > drivers/gpu/drm/nouveau/nouveau_fence.c | 11 ++++++++--- > > 1 files changed, 8 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c > > index a244702..010243b 100644 > > --- a/drivers/gpu/drm/nouveau/nouveau_fence.c > > +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c > > @@ -27,6 +27,9 @@ > > #include "drmP.h" > > #include "drm.h" > > > > +#include <linux/ktime.h> > > +#include <linux/hrtimer.h> > > + > > #include "nouveau_drv.h" > > #include "nouveau_ramht.h" > > #include "nouveau_dma.h" > > @@ -229,9 +232,11 @@ int > > __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) > > { > > unsigned long timeout = jiffies + (3 * DRM_HZ); > > - unsigned long sleep_time = jiffies + 1; > > + ktime_t t; > > int ret = 0; > > > > + t = ktime_set(0, NSEC_PER_MSEC / 10); > > + > > while (1) { > > if (__nouveau_fence_signalled(sync_obj, sync_arg)) > > break; > > @@ -243,8 +248,8 @@ __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) > > > > __set_current_state(intr ? TASK_INTERRUPTIBLE > > : TASK_UNINTERRUPTIBLE); > > - if (lazy && time_after_eq(jiffies, sleep_time)) > > - schedule_timeout(1); > > + if (lazy) > > + schedule_hrtimeout(&t, HRTIMER_MODE_REL); > > > > if (intr && signal_pending(current)) { > > ret = -ERESTARTSYS; From currojerez at riseup.net Tue Mar 8 08:22:52 2011 From: currojerez at riseup.net (Francisco Jerez) Date: Tue, 08 Mar 2011 17:22:52 +0100 Subject: [PATCH] drm/nouveau: fix __nouveau_fence_wait performance regression In-Reply-To: <20110308121628.GA20238@xxxxxxx> (Marcin Slusarz's message of "Tue, 8 Mar 2011 13:16:28 +0100") References: <20110213203804.GA5395@xxxxxxx> <20110304164905.GA2743@xxxxxxx> <AANLkTin_jouzPDGfNnYq_BRqPzbvOW+F6jFNuc7p=p5E@xxxxxxxxxxxxxx> <1299536668.29441.3.camel@nisroch> <20110307232256.GA2680@xxxxxxx> <87lj0qzaut.fsf@xxxxxxxxxx> <20110308121628.GA20238@xxxxxxx> Message-ID: <871v2hzin7.fsf@xxxxxxxxxx> Marcin Slusarz <marcin.slusarz at gmail.com> writes: > On Tue, Mar 08, 2011 at 01:58:50AM +0100, Francisco Jerez wrote: >> Marcin Slusarz <marcin.slusarz at gmail.com> writes: >> >> > On Tue, Mar 08, 2011 at 08:24:26AM +1000, Ben Skeggs wrote: >> >> On Mon, 2011-03-07 at 18:18 +0000, Maarten Maathuis wrote: >> >> > On Fri, Mar 4, 2011 at 4:49 PM, Marcin Slusarz <marcin.slusarz at gmail.com> wrote: >> >> > > On Sun, Feb 13, 2011 at 09:38:04PM +0100, Marcin Slusarz wrote: >> >> > >> Combination of locking and interchannel synchronization changes >> >> > >> uncovered poor behaviour of nouveau_fence_wait, which on HZ=100 >> >> > >> configuration could waste up to 10 ms per call. >> >> > >> Depending on application, it lead to 10-30% FPS regression. >> >> > >> To fix it, shorten thread sleep time to 0.1 ms and ensure >> >> > >> spinning happens for at least one *full* tick. >> >> > >> >> >> > >> Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> >> >> > >> --- >> >> > >> drivers/gpu/drm/nouveau/nouveau_fence.c | 10 ++++++++-- >> >> > >> 1 files changed, 8 insertions(+), 2 deletions(-) >> >> > >> >> >> > >> diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c >> >> > >> index 221b846..75ba5e2 100644 >> >> > >> --- a/drivers/gpu/drm/nouveau/nouveau_fence.c >> >> > >> +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c >> >> > >> @@ -27,6 +27,9 @@ >> >> > >> #include "drmP.h" >> >> > >> #include "drm.h" >> >> > >> >> >> > >> +#include <linux/ktime.h> >> >> > >> +#include <linux/hrtimer.h> >> >> > >> + >> >> > >> #include "nouveau_drv.h" >> >> > >> #include "nouveau_ramht.h" >> >> > >> #include "nouveau_dma.h" >> >> > >> @@ -230,9 +233,12 @@ int >> >> > >> __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) >> >> > >> { >> >> > >> unsigned long timeout = jiffies + (3 * DRM_HZ); >> >> > >> - unsigned long sleep_time = jiffies + 1; >> >> > >> + unsigned long sleep_time = jiffies + 2; >> >> > >> + ktime_t t; >> >> > >> int ret = 0; >> >> > >> >> >> > >> + t = ktime_set(0, NSEC_PER_MSEC / 10); >> >> > >> + >> >> > >> while (1) { >> >> > >> if (__nouveau_fence_signalled(sync_obj, sync_arg)) >> >> > >> break; >> >> > >> @@ -245,7 +251,7 @@ __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) >> >> > >> __set_current_state(intr ? TASK_INTERRUPTIBLE >> >> > >> : TASK_UNINTERRUPTIBLE); >> >> > >> if (lazy && time_after_eq(jiffies, sleep_time)) >> >> > >> - schedule_timeout(1); >> >> > >> + schedule_hrtimeout(&t, HRTIMER_MODE_REL); >> >> > >> >> >> > >> if (intr && signal_pending(current)) { >> >> > >> ret = -ERESTARTSYS; >> >> > >> -- >> >> > >> 1.7.4.rc3 >> >> > >> >> >> > > >> >> > > ping again >> >> > > _______________________________________________ >> >> > > Nouveau mailing list >> >> > > Nouveau at lists.freedesktop.org >> >> > > http://lists.freedesktop.org/mailman/listinfo/nouveau >> >> > > >> >> > >> >> > This looks ok to me, but I would like to get Ben Skeggs ok on this one >> >> > as well. So i've CC'ed him, hopefully he'll notice :-) >> >> Ah sorry, I have actually looked at this quite a while back but came to >> >> no solid conclusion. >> >> >> >> While yes, I did see some minor performance improvement from it, I also >> >> notice that now we once again get 100% CPU usage while an app is waiting >> >> for the GPU a lot.. >> > >> > It's not "minor" performance improvement: >> > >> > without this patch (FPS): >> > nexuiz: 53 >> > wop: 181 >> > tremulous: 157 >> > wsw0.5: 89 >> > glxgears: 730 >> > >> > with: >> > nexuiz: 63 (+18%) >> > wop: 248 (+37%) >> > tremulous: 156 (-0.6%) >> > wsw0.5: 91 (+2%) >> > glxgears: 1054 (+44%) >> > >> > >> > Ok, so you are worried about CPU usage... Let's see what will happen if >> > I remove spinning added by "drm/nouveau: Spin for a bit in >> > nouveau_fence_wait() before yielding the CPU". >> > >> > reduced version (attached): >> > nexuiz: 62 >> > wop: 248 >> > trem: 157 >> > wsw0.5: 90 >> > glxgears: 1055 >> > >> > Good enough? >> >> Remember to exercise some software fallbacks as well (e.g. something >> using core fonts), software fallbacks were the main users of the >> spinning you've removed. > > corefonts are pretty fast (measured "time dmesg"): > > without (spinning + timeout 10ms): 0.08s > with (spinning + hrtimeout 0.1ms): 0.08s > reduced (no spinning + hrtimeout 0.1ms): 0.25s > old (no spinning + timeout 10ms): 13s > Ah, so it's still trading one performance regression for another, and you could make everyone happy at the same time. > So I think "no spinning + hrtimeout 0.1ms" is a reasonable compromise... > What's the CPU usage difference between the spinning and the no-spinning cases? It's likely to be negligible for most applications aside from the ones using queries and fallbacks intensively, and in those two cases I agree with you that optimizing for low CPU usage doesn't make a huge lot of sense, getting low latency is already hard enough. If I'm wrong and the initial spinning affects the overall CPU usage negatively, then we have two different use cases with different latency requirements and the DRM API needs to be fixed (though, there're maybe other solutions to explore first, like, start with a really small hrtimeout and increase it exponentially up to some cut-off value). > BTW, old behaviour (no spinning + timeout 10ms) affects other workloads too > nexuiz: 50 > wop: 153 > tremulous: 155 > wsw0.5: 89 > glxgears: 100 (!) > >> Anyway, software fallbacks and occlusion queries are the only two places >> (that I can think of now) where we need the low latency your patch >> gives, and, as Ben already pointed out, we probably want to keep CPU >> usage at minimum in every other case. As a middle ground, the "lazy" >> flag (or rather, a "hog" flag?) could be exposed all the way up to >> userspace, and those two cases fixed to set the flag differently. >> >> What do you think? > > I'm not sure. I think optimizing for low CPU usage is not the best what > we can do right now. 3D performance is still too low behind blob. > Let's fix 3D perf first and think about CPU usage later. > IMHO, switching to lazy waits was the right choice at this stage, it doesn't make optimizing for "3D performance" any harder, quite the opposite, it helps to pinpoint some poorly-pipelining programming practices by making the already existing performance problem more obvious. >> > >> > --- >> > From: Marcin Slusarz <marcin.slusarz at gmail.com> >> > Subject: [PATCH] drm/nouveau: fix __nouveau_fence_wait performance regression >> > >> > Combination of locking and interchannel synchronization changes >> > uncovered poor behaviour of nouveau_fence_wait, which on HZ=100 >> > configuration could waste up to 10 ms per call. >> > Depending on application, it lead to 10-30% FPS regression. >> > >> > To fix it, shorten thread sleep time to 0.1 ms. >> > >> > Additionally, remove spinning (added by "drm/nouveau: Spin for >> > a bit in nouveau_fence_wait() before yielding the CPU"), because >> > it's not needed anymore. >> > >> > Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> >> > --- >> > drivers/gpu/drm/nouveau/nouveau_fence.c | 11 ++++++++--- >> > 1 files changed, 8 insertions(+), 3 deletions(-) >> > >> > diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c >> > index a244702..010243b 100644 >> > --- a/drivers/gpu/drm/nouveau/nouveau_fence.c >> > +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c >> > @@ -27,6 +27,9 @@ >> > #include "drmP.h" >> > #include "drm.h" >> > >> > +#include <linux/ktime.h> >> > +#include <linux/hrtimer.h> >> > + >> > #include "nouveau_drv.h" >> > #include "nouveau_ramht.h" >> > #include "nouveau_dma.h" >> > @@ -229,9 +232,11 @@ int >> > __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) >> > { >> > unsigned long timeout = jiffies + (3 * DRM_HZ); >> > - unsigned long sleep_time = jiffies + 1; >> > + ktime_t t; >> > int ret = 0; >> > >> > + t = ktime_set(0, NSEC_PER_MSEC / 10); >> > + >> > while (1) { >> > if (__nouveau_fence_signalled(sync_obj, sync_arg)) >> > break; >> > @@ -243,8 +248,8 @@ __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) >> > >> > __set_current_state(intr ? TASK_INTERRUPTIBLE >> > : TASK_UNINTERRUPTIBLE); >> > - if (lazy && time_after_eq(jiffies, sleep_time)) >> > - schedule_timeout(1); >> > + if (lazy) >> > + schedule_hrtimeout(&t, HRTIMER_MODE_REL); >> > >> > if (intr && signal_pending(current)) { >> > ret = -ERESTARTSYS; -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 229 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/nouveau/attachments/20110308/8900d569/attachment.pgp> From wilderkde at gmail.com Tue Mar 8 13:30:20 2011 From: wilderkde at gmail.com (Jacopo De Simoi) Date: Tue, 8 Mar 2011 22:30:20 +0100 Subject: New window pixmap initialization In-Reply-To: <201103041034.09766.wilderkde@xxxxxxxxx> References: <201103041034.09766.wilderkde@xxxxxxxxx> Message-ID: <201103082230.20866.wilderkde@xxxxxxxxx> Nevermind, I found out that it was a bizarre strategy of Qt for some specific window types apologies for the noise _J > Hello nouveau devs > > I'd like some informations on the pixmap initialization for a new window in > a (xrender) composited setting; I'm currently trying to improve the xrender backend of > kwin (i.e. kde composited window manager) and I'm facing some issues which might > or might not be driver related. > > From what it seems, when a new window is created with geometry (x y w h) > the pixmap is first initialized with the content of the screen in the rect (x y w h), > is this correct? > > This actually is causing glitches with effects that animate the appearance of the given window > by some kind of motion, since one can see for a split second a portion of screen moving for no reason > and afterwards the new window appearing (as soon as it has been first painted). > > Imvho, if an argb window is created, it would be much much cleaner to init its pixmap with a fully > transparent color; trying to implement this in the wm is kind of weird; on the other hand > I got pretty quickly lost examining ddx code, so I have a few questions: > > 1? Is first pixmap creation in a composited setting driver dependent? > 2? I assume that upon creation the contents of the pixmap should actually be undefined > and are init'd like I said for purely convenience reasons; is this correct? is there anything in the specs about that > which I did not see? > 3? Would it be possible for the nouveau driver to implement the alternate initialization strategy for argb windows? > Does the new strategy make sense to you? > 4? I'd be happy to provide a patch for point 3, provided that somebody helps me out with finding the right place > for it; > > Thanks a lot; > __J > > P.S. I'm always on IRC, nick wilder > _______________________________________________ > Nouveau mailing list > Nouveau at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/nouveau > From madman2003 at gmail.com Tue Mar 8 14:44:33 2011 From: madman2003 at gmail.com (Maarten Maathuis) Date: Tue, 8 Mar 2011 22:44:33 +0000 Subject: CCACHE and VFETCH FAULTs causing lockups In-Reply-To: <1299536569.29441.1.camel@nisroch> References: <AANLkTik0CkbQz=PoXNG7bQEn_5ssAfp7cr=Z=3qJz6h2@xxxxxxxxxxxxxx> <1299016269.1822.3.camel@nisroch> <AANLkTimiy=U04vfiXRAqDj_eT+zxSN2_3NvmF4jRQWxc@xxxxxxxxxxxxxx> <65DF9FD4-DDE0-4BA3-950A-422A3F1EF9DA@xxxxxxxxx> <AANLkTi=7YDLL8N=15ktHE3oYB2LMkm2WQ6y20+-gfmT_@xxxxxxxxxxxxxx> <62F49887-5C29-4DFD-9166-3BB6AD0E23F1@xxxxxxxxx> <AANLkTi=jNcm+868ppNTGA+6ufqi7muctHxMnpzj9J-k8@xxxxxxxxxxxxxx> <1299536569.29441.1.camel@nisroch> Message-ID: <AANLkTim2iO=GeWSYhvMuzswk7tjwOBMzBkcya3DW=Cb6@xxxxxxxxxxxxxx> On Mon, Mar 7, 2011 at 10:22 PM, Ben Skeggs <skeggsb at gmail.com> wrote: > On Mon, 2011-03-07 at 21:51 +0000, Maarten Maathuis wrote: >> On Sun, Mar 6, 2011 at 2:24 PM, Ben Skeggs <skeggsb at gmail.com> wrote: >> > >> > >> > Sent from my iPhone >> > >> > On 07/03/2011, at 0:03, Maarten Maathuis <madman2003 at gmail.com> wrote: >> > >> >> On Sun, Mar 6, 2011 at 1:44 PM, Ben Skeggs <skeggsb at gmail.com> wrote: >> >>> Sorry for the top posting, it's late and typing from my phone in bed lol. >> >>> >> >>> Just wanted to see if you had an update? And, this is NV86 I guess? >> >>> >> >>> Ben. >> >>> >> >>> Sent from my iPhone >> >>> >> >>> On 02/03/2011, at 8:20, Maarten Maathuis <madman2003 at gmail.com> wrote: >> >>> >> >>>> On Tue, Mar 1, 2011 at 9:51 PM, Ben Skeggs <bskeggs at redhat.com> wrote: >> >>>>> On Tue, 2011-03-01 at 21:08 +0000, Maarten Maathuis wrote: >> >>>>> >> >>>>>> Those come after 15-30 minutes of running warzone2100, i haven't >> >>>>>> played any games for a while, so no idea how long this has been going >> >>>>>> on. >> >>>>>> I also got a TRAP_CCACHE on channel 2 a little while ago, it takes >> >>>>>> much longer to trigger (a few hours). I'm using todays "nouveau >> >>>>>> kernel" git. >> >>>>> You're not the first person to have reported this fwiw, personally, I >> >>>>> haven't seen it yet.. >> >>>>> >> >>>>>> >> >>>>>> I'm guessing something is being unmapped too early or without reason, >> >>>>>> or some cache is stale. But it isn't obvious what exactly it is. >> >>>>>> >> >>>>>> Because i don't remember having these lockups before I'm inclined to >> >>>>>> guess that this commit is involved >> >>>>>> http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=6330d8f5ecc4a19fd2ad3c7fa128b2f4c2ce3360 >> >>>>>> >> >>>>>> Any ideas? >> >>>>> Not really. ?If this commit *is* the cause, the problem is still >> >>>>> somewhere else. ?That commit just makes sure PTEs are marked invalid, so >> >>>>> if it's causing your faults, then previously the GPU would still have >> >>>>> been reading/writing invalid data. >> >>>>> >> >>>>> Plus, I expect you should probably have seen a VM fault.. >> >>>> >> >>>> So these faults are just generic errors? Unrelated to page faults? >> >>>> >> >>>>> >> >>>>> Ben. >> >>>>>> >> >>>>>> Maarten. >> >>>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> Far away from the primal instinct, the song seems to fade away, the >> >>>> river get wider between your thoughts and the things we do and say. >> >>>> _______________________________________________ >> >>>> Nouveau mailing list >> >>>> Nouveau at lists.freedesktop.org >> >>>> http://lists.freedesktop.org/mailman/listinfo/nouveau >> >>> >> >> >> >> No this is NV96. The revert definitely helps, but no luck so far in >> >> finding a plausible cause for the problem. >> > Hey, >> > >> > Ok. Hmm. I thought you had NV86 for some reason! It's a long shot and I'm not entirely convinced it'll help at all, but can you switch graph.tlb_flush pointer to the nv86 version and see if anything changes? >> >> I used to have a NV86, but it died more than a year ago in the typical >> way for that generation of card, due to thermal issues I guess (it was >> a passively cooled card). I haven't tried using the nv86 tlb flush, >> out of curiosity, is this something nvidia does (a lot) on nv86? > Yes, NVIDIA do it on pretty much every card I've looked at traces for, > we've never seen any need for other chipsets as of yet however. > Originally, it looked like NVIDIA did this on all pre-NVA3 cards, but, a > trace of my T510 with recent drivers show that they do it on NVA3+ now > too. > >> >> > >> > The *other* possible thing is that the ttm delayed delete queue is causing multiple tlb flushes to happen at the same time. ?I'll add locking for that in the morning, that was a complete oversight. >> >> I've had no lockups since you added the spinlocks, so maybe that was >> it. Time will tell. > *crosses fingers* > > Ben. >> >> > >> > Ben. >> > >> >> >> >> -- >> >> Far away from the primal instinct, the song seems to fade away, the >> >> river get wider between your thoughts and the things we do and say. >> > >> >> >> > > > It went alright for quite some time (much longer than before), but i got another one. I should note this happened at the exact moment X rendered something over my fullscreen opengl app. So it does smell a bit fishy. I'll have a look myself at possible causes again. Mar 8 23:30:58 madman kernel: [25325.644794] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_CCACHE FAULT Mar 8 23:30:58 madman kernel: [25325.644815] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_CCACHE 00000080 00000000 00000000 00000000 00000000 00000004 00000000 Mar 8 23:30:58 madman kernel: [25325.644829] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_MP - TP1: Unhandled ustatus 0x00020000 Mar 8 23:30:58 madman kernel: [25325.644836] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP Mar 8 23:30:58 madman kernel: [25325.644848] [drm] nouveau 0000:01:00.0: PGRAPH - ch 2 (0x0000840000) subc 5 class 0x8297 mthd 0x0f04 data 0x00000000 Mar 8 23:30:58 madman kernel: [25325.644865] [drm] nouveau 0000:01:00.0: VM: trapped read at 0x002000f000 on ch 2 [0x00000840] PFIFO/PFIFO_READ/SEMAPHORE reason: DMAOBJ_LIMIT -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. From madman2003 at gmail.com Tue Mar 8 15:06:22 2011 From: madman2003 at gmail.com (Maarten Maathuis) Date: Tue, 8 Mar 2011 23:06:22 +0000 Subject: CCACHE and VFETCH FAULTs causing lockups In-Reply-To: <AANLkTim2iO=GeWSYhvMuzswk7tjwOBMzBkcya3DW=Cb6@xxxxxxxxxxxxxx> References: <AANLkTik0CkbQz=PoXNG7bQEn_5ssAfp7cr=Z=3qJz6h2@xxxxxxxxxxxxxx> <1299016269.1822.3.camel@nisroch> <AANLkTimiy=U04vfiXRAqDj_eT+zxSN2_3NvmF4jRQWxc@xxxxxxxxxxxxxx> <65DF9FD4-DDE0-4BA3-950A-422A3F1EF9DA@xxxxxxxxx> <AANLkTi=7YDLL8N=15ktHE3oYB2LMkm2WQ6y20+-gfmT_@xxxxxxxxxxxxxx> <62F49887-5C29-4DFD-9166-3BB6AD0E23F1@xxxxxxxxx> <AANLkTi=jNcm+868ppNTGA+6ufqi7muctHxMnpzj9J-k8@xxxxxxxxxxxxxx> <1299536569.29441.1.camel@nisroch> <AANLkTim2iO=GeWSYhvMuzswk7tjwOBMzBkcya3DW=Cb6@xxxxxxxxxxxxxx> Message-ID: <AANLkTimkop4OXFw_TN2KFVm9GDn337WE3JqiZK3Ut7Jg@xxxxxxxxxxxxxx> On Tue, Mar 8, 2011 at 10:44 PM, Maarten Maathuis <madman2003 at gmail.com> wrote: > On Mon, Mar 7, 2011 at 10:22 PM, Ben Skeggs <skeggsb at gmail.com> wrote: >> On Mon, 2011-03-07 at 21:51 +0000, Maarten Maathuis wrote: >>> On Sun, Mar 6, 2011 at 2:24 PM, Ben Skeggs <skeggsb at gmail.com> wrote: >>> > >>> > >>> > Sent from my iPhone >>> > >>> > On 07/03/2011, at 0:03, Maarten Maathuis <madman2003 at gmail.com> wrote: >>> > >>> >> On Sun, Mar 6, 2011 at 1:44 PM, Ben Skeggs <skeggsb at gmail.com> wrote: >>> >>> Sorry for the top posting, it's late and typing from my phone in bed lol. >>> >>> >>> >>> Just wanted to see if you had an update? And, this is NV86 I guess? >>> >>> >>> >>> Ben. >>> >>> >>> >>> Sent from my iPhone >>> >>> >>> >>> On 02/03/2011, at 8:20, Maarten Maathuis <madman2003 at gmail.com> wrote: >>> >>> >>> >>>> On Tue, Mar 1, 2011 at 9:51 PM, Ben Skeggs <bskeggs at redhat.com> wrote: >>> >>>>> On Tue, 2011-03-01 at 21:08 +0000, Maarten Maathuis wrote: >>> >>>>> >>> >>>>>> Those come after 15-30 minutes of running warzone2100, i haven't >>> >>>>>> played any games for a while, so no idea how long this has been going >>> >>>>>> on. >>> >>>>>> I also got a TRAP_CCACHE on channel 2 a little while ago, it takes >>> >>>>>> much longer to trigger (a few hours). I'm using todays "nouveau >>> >>>>>> kernel" git. >>> >>>>> You're not the first person to have reported this fwiw, personally, I >>> >>>>> haven't seen it yet.. >>> >>>>> >>> >>>>>> >>> >>>>>> I'm guessing something is being unmapped too early or without reason, >>> >>>>>> or some cache is stale. But it isn't obvious what exactly it is. >>> >>>>>> >>> >>>>>> Because i don't remember having these lockups before I'm inclined to >>> >>>>>> guess that this commit is involved >>> >>>>>> http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=6330d8f5ecc4a19fd2ad3c7fa128b2f4c2ce3360 >>> >>>>>> >>> >>>>>> Any ideas? >>> >>>>> Not really. ?If this commit *is* the cause, the problem is still >>> >>>>> somewhere else. ?That commit just makes sure PTEs are marked invalid, so >>> >>>>> if it's causing your faults, then previously the GPU would still have >>> >>>>> been reading/writing invalid data. >>> >>>>> >>> >>>>> Plus, I expect you should probably have seen a VM fault.. >>> >>>> >>> >>>> So these faults are just generic errors? Unrelated to page faults? >>> >>>> >>> >>>>> >>> >>>>> Ben. >>> >>>>>> >>> >>>>>> Maarten. >>> >>>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> -- >>> >>>> Far away from the primal instinct, the song seems to fade away, the >>> >>>> river get wider between your thoughts and the things we do and say. >>> >>>> _______________________________________________ >>> >>>> Nouveau mailing list >>> >>>> Nouveau at lists.freedesktop.org >>> >>>> http://lists.freedesktop.org/mailman/listinfo/nouveau >>> >>> >>> >> >>> >> No this is NV96. The revert definitely helps, but no luck so far in >>> >> finding a plausible cause for the problem. >>> > Hey, >>> > >>> > Ok. Hmm. I thought you had NV86 for some reason! It's a long shot and I'm not entirely convinced it'll help at all, but can you switch graph.tlb_flush pointer to the nv86 version and see if anything changes? >>> >>> I used to have a NV86, but it died more than a year ago in the typical >>> way for that generation of card, due to thermal issues I guess (it was >>> a passively cooled card). I haven't tried using the nv86 tlb flush, >>> out of curiosity, is this something nvidia does (a lot) on nv86? >> Yes, NVIDIA do it on pretty much every card I've looked at traces for, >> we've never seen any need for other chipsets as of yet however. >> Originally, it looked like NVIDIA did this on all pre-NVA3 cards, but, a >> trace of my T510 with recent drivers show that they do it on NVA3+ now >> too. >> >>> >>> > >>> > The *other* possible thing is that the ttm delayed delete queue is causing multiple tlb flushes to happen at the same time. ?I'll add locking for that in the morning, that was a complete oversight. >>> >>> I've had no lockups since you added the spinlocks, so maybe that was >>> it. Time will tell. >> *crosses fingers* >> >> Ben. >>> >>> > >>> > Ben. >>> > >>> >> >>> >> -- >>> >> Far away from the primal instinct, the song seems to fade away, the >>> >> river get wider between your thoughts and the things we do and say. >>> > >>> >>> >>> >> >> >> > > It went alright for quite some time (much longer than before), but i > got another one. I should note this happened at the exact moment X > rendered something over my fullscreen opengl app. So it does smell a > bit fishy. I'll have a look myself at possible causes again. > > Mar ?8 23:30:58 madman kernel: [25325.644794] [drm] nouveau > 0000:01:00.0: PGRAPH - TRAP_CCACHE FAULT > Mar ?8 23:30:58 madman kernel: [25325.644815] [drm] nouveau > 0000:01:00.0: PGRAPH - TRAP_CCACHE 00000080 00000000 00000000 00000000 > 00000000 00000004 00000000 > Mar ?8 23:30:58 madman kernel: [25325.644829] [drm] nouveau > 0000:01:00.0: PGRAPH - TRAP_MP - TP1: Unhandled ustatus 0x00020000 > Mar ?8 23:30:58 madman kernel: [25325.644836] [drm] nouveau > 0000:01:00.0: PGRAPH - TRAP > Mar ?8 23:30:58 madman kernel: [25325.644848] [drm] nouveau > 0000:01:00.0: PGRAPH - ch 2 (0x0000840000) subc 5 class 0x8297 mthd > 0x0f04 data 0x00000000 > Mar ?8 23:30:58 madman kernel: [25325.644865] [drm] nouveau > 0000:01:00.0: VM: trapped read at 0x002000f000 on ch 2 [0x00000840] > PFIFO/PFIFO_READ/SEMAPHORE reason: DMAOBJ_LIMIT > An offset just above the 512 MB mark shouldn't be invalid on a dma object covering the entire VM. I wonder what's going on here. > -- > Far away from the primal instinct, the song seems to fade away, the > river get wider between your thoughts and the things we do and say. > -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. From marcin.slusarz at gmail.com Tue Mar 8 16:14:04 2011 From: marcin.slusarz at gmail.com (Marcin Slusarz) Date: Wed, 9 Mar 2011 01:14:04 +0100 Subject: [PATCH] drm/nouveau: fix __nouveau_fence_wait performance regression In-Reply-To: <871v2hzin7.fsf@xxxxxxxxxx> References: <20110213203804.GA5395@xxxxxxx> <20110304164905.GA2743@xxxxxxx> <AANLkTin_jouzPDGfNnYq_BRqPzbvOW+F6jFNuc7p=p5E@xxxxxxxxxxxxxx> <1299536668.29441.3.camel@nisroch> <20110307232256.GA2680@xxxxxxx> <87lj0qzaut.fsf@xxxxxxxxxx> <20110308121628.GA20238@xxxxxxx> <871v2hzin7.fsf@xxxxxxxxxx> Message-ID: <20110309001404.GA22679@xxxxxxx> On Tue, Mar 08, 2011 at 05:22:52PM +0100, Francisco Jerez wrote: > Marcin Slusarz <marcin.slusarz at gmail.com> writes: > > > On Tue, Mar 08, 2011 at 01:58:50AM +0100, Francisco Jerez wrote: > >> Marcin Slusarz <marcin.slusarz at gmail.com> writes: > >> > >> > On Tue, Mar 08, 2011 at 08:24:26AM +1000, Ben Skeggs wrote: > >> >> On Mon, 2011-03-07 at 18:18 +0000, Maarten Maathuis wrote: > >> >> > On Fri, Mar 4, 2011 at 4:49 PM, Marcin Slusarz <marcin.slusarz at gmail.com> wrote: > >> >> > > On Sun, Feb 13, 2011 at 09:38:04PM +0100, Marcin Slusarz wrote: > >> >> > >> Combination of locking and interchannel synchronization changes > >> >> > >> uncovered poor behaviour of nouveau_fence_wait, which on HZ=100 > >> >> > >> configuration could waste up to 10 ms per call. > >> >> > >> Depending on application, it lead to 10-30% FPS regression. > >> >> > >> To fix it, shorten thread sleep time to 0.1 ms and ensure > >> >> > >> spinning happens for at least one *full* tick. > >> >> > >> > >> >> > >> Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> > >> >> > >> --- > >> >> > >> drivers/gpu/drm/nouveau/nouveau_fence.c | 10 ++++++++-- > >> >> > >> 1 files changed, 8 insertions(+), 2 deletions(-) > >> >> > >> > >> >> > >> diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c > >> >> > >> index 221b846..75ba5e2 100644 > >> >> > >> --- a/drivers/gpu/drm/nouveau/nouveau_fence.c > >> >> > >> +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c > >> >> > >> @@ -27,6 +27,9 @@ > >> >> > >> #include "drmP.h" > >> >> > >> #include "drm.h" > >> >> > >> > >> >> > >> +#include <linux/ktime.h> > >> >> > >> +#include <linux/hrtimer.h> > >> >> > >> + > >> >> > >> #include "nouveau_drv.h" > >> >> > >> #include "nouveau_ramht.h" > >> >> > >> #include "nouveau_dma.h" > >> >> > >> @@ -230,9 +233,12 @@ int > >> >> > >> __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) > >> >> > >> { > >> >> > >> unsigned long timeout = jiffies + (3 * DRM_HZ); > >> >> > >> - unsigned long sleep_time = jiffies + 1; > >> >> > >> + unsigned long sleep_time = jiffies + 2; > >> >> > >> + ktime_t t; > >> >> > >> int ret = 0; > >> >> > >> > >> >> > >> + t = ktime_set(0, NSEC_PER_MSEC / 10); > >> >> > >> + > >> >> > >> while (1) { > >> >> > >> if (__nouveau_fence_signalled(sync_obj, sync_arg)) > >> >> > >> break; > >> >> > >> @@ -245,7 +251,7 @@ __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) > >> >> > >> __set_current_state(intr ? TASK_INTERRUPTIBLE > >> >> > >> : TASK_UNINTERRUPTIBLE); > >> >> > >> if (lazy && time_after_eq(jiffies, sleep_time)) > >> >> > >> - schedule_timeout(1); > >> >> > >> + schedule_hrtimeout(&t, HRTIMER_MODE_REL); > >> >> > >> > >> >> > >> if (intr && signal_pending(current)) { > >> >> > >> ret = -ERESTARTSYS; > >> >> > >> -- > >> >> > >> 1.7.4.rc3 > >> >> > >> > >> >> > > > >> >> > > ping again > >> >> > > _______________________________________________ > >> >> > > Nouveau mailing list > >> >> > > Nouveau at lists.freedesktop.org > >> >> > > http://lists.freedesktop.org/mailman/listinfo/nouveau > >> >> > > > >> >> > > >> >> > This looks ok to me, but I would like to get Ben Skeggs ok on this one > >> >> > as well. So i've CC'ed him, hopefully he'll notice :-) > >> >> Ah sorry, I have actually looked at this quite a while back but came to > >> >> no solid conclusion. > >> >> > >> >> While yes, I did see some minor performance improvement from it, I also > >> >> notice that now we once again get 100% CPU usage while an app is waiting > >> >> for the GPU a lot.. > >> > > >> > It's not "minor" performance improvement: > >> > > >> > without this patch (FPS): > >> > nexuiz: 53 > >> > wop: 181 > >> > tremulous: 157 > >> > wsw0.5: 89 > >> > glxgears: 730 > >> > > >> > with: > >> > nexuiz: 63 (+18%) > >> > wop: 248 (+37%) > >> > tremulous: 156 (-0.6%) > >> > wsw0.5: 91 (+2%) > >> > glxgears: 1054 (+44%) > >> > > >> > > >> > Ok, so you are worried about CPU usage... Let's see what will happen if > >> > I remove spinning added by "drm/nouveau: Spin for a bit in > >> > nouveau_fence_wait() before yielding the CPU". > >> > > >> > reduced version (attached): > >> > nexuiz: 62 > >> > wop: 248 > >> > trem: 157 > >> > wsw0.5: 90 > >> > glxgears: 1055 > >> > > >> > Good enough? > >> > >> Remember to exercise some software fallbacks as well (e.g. something > >> using core fonts), software fallbacks were the main users of the > >> spinning you've removed. > > > > corefonts are pretty fast (measured "time dmesg"): > > > > without (spinning + timeout 10ms): 0.08s > > with (spinning + hrtimeout 0.1ms): 0.08s > > reduced (no spinning + hrtimeout 0.1ms): 0.25s > > old (no spinning + timeout 10ms): 13s > > > Ah, so it's still trading one performance regression for another, and > you could make everyone happy at the same time. > > > So I think "no spinning + hrtimeout 0.1ms" is a reasonable compromise... > > > What's the CPU usage difference between the spinning and the no-spinning > cases? 1 cpu set to performance mode spinning + hrtimeout 0.1ms: FPS usr sys nexuiz: 63 46.60 + 52.36 wop: 248 57.54 + 41.99 trem: 156 92.40 + 7.30 wsw0.5: 91 52.91 + 46.37 glxgears: 1054 10.00 + 90.00 corefonts: 42.86 + 54.29 0.08s(time) So it fills the CPU in almost 100%... no spinning + hrtimeout 0.1ms: FPS usr sys nexuiz: 62 49.97 + 8.42 wop: 248 58.04 + 22.04 trem: 157 92.42 + 6.92 wsw0.5: 90 51.69 + 4.58 glxgears: 1055 11.45 + 11.05 corefonts: 20.52 + 7.82 0.25s OK. So I did some more tests: no spinning + hrtimeout 0.01ms: FPS usr sys nexuiz: 63 49.50 + 14.01 wop: 245 57.21 + 24.66 trem: 148 89.31 + 10.01 wsw0.5: 91 52.92 + 11.10 glxgears: 1055 10.61 + 22.34 corefonts: 38.24 + 27.45 0.09s tremulous FPS is down, sys CPU usage is down, but not so good as in "no spinning, 0.1ms", corefonts are almost as fast --- no spinning + hrtimeout 0.01ms increasing by factor x2, max at 1ms: nexuiz: 62 48.38 + 8.00 wop: 245 56.55 + 19.92 trem: 149 90.46 + 8.86 wsw0.5: 92 52.10 + 4.56 glxgears: 1026 11.68 + 9.87 corefonts: 46.60 + 25.24 0.09s almost like "no spinning + 0.01ms", but glxgears FPS is down --- no spinning + hrtimeout 0.001ms: nexuiz: 63 52.04 + 16.13 wop: 246 58.94 + 22.59 trem: 155 92.73 + 6.38 wsw0.5: 91 54.39 + 16.88 glxgears: 1055 10.62 + 30.55 corefonts: 53.01 + 28.92 0.07s tremulous FPS is back, sys CPU usage is sometimes bigger, sometimes smaller, corefonts are fast, but take a lot of CPU time --- no spinning + hrtimeout 0.001ms increasing by factor x2, max at 1ms nexuiz: 62 49.46 + 6.70 wop: 247 58.80 + 17.95 trem: 156 92.16 + 7.28 wsw0.5: 91 52.79 + 4.03 glxgears: 1050 11.44 + 12.54 corefonts: 36.05 + 32.56 0.07s glxgears FPS is a bit down, sys CPU times are as good (or better) as in "no spinning, 0.1ms", corefonts are fast this is the best, patch below > It's likely to be negligible for most applications aside from the > ones using queries and fallbacks intensively, and in those two cases I > agree with you that optimizing for low CPU usage doesn't make a huge lot > of sense, getting low latency is already hard enough. > > If I'm wrong and the initial spinning affects the overall CPU usage > negatively, then we have two different use cases with different latency > requirements and the DRM API needs to be fixed (though, there're maybe > other solutions to explore first, like, start with a really small > hrtimeout and increase it exponentially up to some cut-off value). > > > BTW, old behaviour (no spinning + timeout 10ms) affects other workloads too > > nexuiz: 50 > > wop: 153 > > tremulous: 155 > > wsw0.5: 89 > > glxgears: 100 (!) > > > >> Anyway, software fallbacks and occlusion queries are the only two places > >> (that I can think of now) where we need the low latency your patch > >> gives, and, as Ben already pointed out, we probably want to keep CPU > >> usage at minimum in every other case. As a middle ground, the "lazy" > >> flag (or rather, a "hog" flag?) could be exposed all the way up to > >> userspace, and those two cases fixed to set the flag differently. > >> > >> What do you think? > > > > I'm not sure. I think optimizing for low CPU usage is not the best what > > we can do right now. 3D performance is still too low behind blob. > > Let's fix 3D perf first and think about CPU usage later. > > > > IMHO, switching to lazy waits was the right choice at this stage, it > doesn't make optimizing for "3D performance" any harder, quite the > opposite, it helps to pinpoint some poorly-pipelining programming > practices by making the already existing performance problem more > obvious. > > >> > > >> > --- > >> > From: Marcin Slusarz <marcin.slusarz at gmail.com> > >> > Subject: [PATCH] drm/nouveau: fix __nouveau_fence_wait performance regression > >> > > >> > Combination of locking and interchannel synchronization changes > >> > uncovered poor behaviour of nouveau_fence_wait, which on HZ=100 > >> > configuration could waste up to 10 ms per call. > >> > Depending on application, it lead to 10-30% FPS regression. > >> > > >> > To fix it, shorten thread sleep time to 0.1 ms. > >> > > >> > Additionally, remove spinning (added by "drm/nouveau: Spin for > >> > a bit in nouveau_fence_wait() before yielding the CPU"), because > >> > it's not needed anymore. > >> > > >> > Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> > >> > --- > >> > drivers/gpu/drm/nouveau/nouveau_fence.c | 11 ++++++++--- > >> > 1 files changed, 8 insertions(+), 3 deletions(-) > >> > > >> > diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c > >> > index a244702..010243b 100644 > >> > --- a/drivers/gpu/drm/nouveau/nouveau_fence.c > >> > +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c > >> > @@ -27,6 +27,9 @@ > >> > #include "drmP.h" > >> > #include "drm.h" > >> > > >> > +#include <linux/ktime.h> > >> > +#include <linux/hrtimer.h> > >> > + > >> > #include "nouveau_drv.h" > >> > #include "nouveau_ramht.h" > >> > #include "nouveau_dma.h" > >> > @@ -229,9 +232,11 @@ int > >> > __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) > >> > { > >> > unsigned long timeout = jiffies + (3 * DRM_HZ); > >> > - unsigned long sleep_time = jiffies + 1; > >> > + ktime_t t; > >> > int ret = 0; > >> > > >> > + t = ktime_set(0, NSEC_PER_MSEC / 10); > >> > + > >> > while (1) { > >> > if (__nouveau_fence_signalled(sync_obj, sync_arg)) > >> > break; > >> > @@ -243,8 +248,8 @@ __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) > >> > > >> > __set_current_state(intr ? TASK_INTERRUPTIBLE > >> > : TASK_UNINTERRUPTIBLE); > >> > - if (lazy && time_after_eq(jiffies, sleep_time)) > >> > - schedule_timeout(1); > >> > + if (lazy) > >> > + schedule_hrtimeout(&t, HRTIMER_MODE_REL); > >> > > >> > if (intr && signal_pending(current)) { > >> > ret = -ERESTARTSYS; --- From: Marcin Slusarz <marcin.slusarz at gmail.com> Subject: [PATCH] drm/nouveau: fix __nouveau_fence_wait performance Commit fcccab2e4eb8d579837481054cc2cb28eea0baef ("drm/nouveau: Use lazy fence waits when doing software interchannel sync") turned on lazy waits. Unfortunately __nouveau_fence_wait was not optimized for this case and on HZ=100 kernel wasted up to 10 ms per call. Depending on application, it lead to 10-30% FPS regression. Fix it. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_fence.c | 17 ++++++++++++++--- 1 files changed, 14 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c index a244702..78d32dd 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fence.c +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c @@ -27,6 +27,9 @@ #include "drmP.h" #include "drm.h" +#include <linux/ktime.h> +#include <linux/hrtimer.h> + #include "nouveau_drv.h" #include "nouveau_ramht.h" #include "nouveau_dma.h" @@ -229,9 +232,12 @@ int __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) { unsigned long timeout = jiffies + (3 * DRM_HZ); - unsigned long sleep_time = jiffies + 1; + unsigned long sleep_time = NSEC_PER_MSEC / 1000; + ktime_t t; int ret = 0; + t = ktime_set(0, sleep_time); + while (1) { if (__nouveau_fence_signalled(sync_obj, sync_arg)) break; @@ -243,8 +249,13 @@ __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) __set_current_state(intr ? TASK_INTERRUPTIBLE : TASK_UNINTERRUPTIBLE); - if (lazy && time_after_eq(jiffies, sleep_time)) - schedule_timeout(1); + if (lazy) { + schedule_hrtimeout(&t, HRTIMER_MODE_REL); + sleep_time *= 2; + if (sleep_time > NSEC_PER_MSEC) + sleep_time = NSEC_PER_MSEC; + t = ktime_set(0, sleep_time); + } if (intr && signal_pending(current)) { ret = -ERESTARTSYS; -- 1.7.4.rc3 From bugzilla-daemon at freedesktop.org Wed Mar 9 01:31:10 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Wed, 9 Mar 2011 01:31:10 -0800 (PST) Subject: [Bug 35133] New: nouveaufb messing UTF-8 characters on tty Message-ID: <bug-35133-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> https://bugs.freedesktop.org/show_bug.cgi?id=35133 Summary: nouveaufb messing UTF-8 characters on tty Product: xorg Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org ReportedBy: appzer0 at free.fr QAContact: xorg-team at lists.x.org Created an attachment (id=44263) --> (https://bugs.freedesktop.org/attachment.cgi?id=44263) dmesg log Since I started using nouveau, nouveaufb is loaded automatically and the UTF-8 characters on my tty are messed up. I notice that while I'm going shutdown/reboot, every accented character are strangely encoded. I tried with AND without the kernel line parameter 'vt.default_utf8=1'. No resolution is specified at boot. KMS is enabled, though I don't see any high resolution before X has launched. tty is in classic VGA (80x25) then switch to X in high and correct reso. locale is "fr_FR.UTF-8". See the dmesg log attached. Video card is NV40 geforce 9500GT. I guess this is the moment where characters are messed up: --- Console: switching to colour frame buffer device 128x48 fb0: nouveaufb frame buffer device --- I can bring more info if needed. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at freedesktop.org Wed Mar 9 01:39:16 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Wed, 9 Mar 2011 01:39:16 -0800 (PST) Subject: [Bug 35135] New: oops on rmmod nouveau with NV46 Message-ID: <bug-35135-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> https://bugs.freedesktop.org/show_bug.cgi?id=35135 Summary: oops on rmmod nouveau with NV46 Product: xorg Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org ReportedBy: francesco.marella at gmail.com QAContact: xorg-team at lists.x.org Created an attachment (id=44264) --> (https://bugs.freedesktop.org/attachment.cgi?id=44264) kernel log when I unload nouveau I get a kernel oops. please note that the laptop doesn't have the lcd panel anymore and it is attached to an external monitor. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at freedesktop.org Wed Mar 9 02:34:25 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Wed, 9 Mar 2011 02:34:25 -0800 (PST) Subject: [Bug 35135] oops on rmmod nouveau with NV46 In-Reply-To: <bug-35135-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> References: <bug-35135-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> Message-ID: <20110309103425.A29A713000C@xxxxxxxxxxxxxxxxxxxxxxxx> https://bugs.freedesktop.org/show_bug.cgi?id=35135 Lucas Stach <dev at lynxeye.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #44264|text/x-log |text/plain mime type| | -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at freedesktop.org Wed Mar 9 08:56:46 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Wed, 9 Mar 2011 08:56:46 -0800 (PST) Subject: [Bug 34508] [grub x86_64-efi] Macbook 5, 2 - conflicting fb hw usage nouveaufb vs EFI VGA - removing generic driver In-Reply-To: <bug-34508-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> References: <bug-34508-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> Message-ID: <20110309165646.7B18413000C@xxxxxxxxxxxxxxxxxxxxxxxx> https://bugs.freedesktop.org/show_bug.cgi?id=34508 --- Comment #2 from Gregory Bellier <dest at gatekeeper.fr> 2011-03-09 08:56:45 PST --- Ok, I confirm there is a problem with Nouveau. As soon as I installed the Nvidia binary, I've been able to boot with refit + grub-efi_x86_64. insmod efi_gop has to be added in the grub entry to be able to boot, like this : menuentry 'Linux without bios dump' { insmod efi_gop search --no-floppy --fs-uuid --set=root d5175c18-7da2-49a9-a3af-844bad27c91d linux /vmlinuz root=UUID=d5175c18-7da2-49a9-a3af-844bad27c91d ro initrd /initrd.img } -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From currojerez at riseup.net Wed Mar 9 09:34:36 2011 From: currojerez at riseup.net (Francisco Jerez) Date: Wed, 09 Mar 2011 18:34:36 +0100 Subject: [PATCH] drm/nouveau: fix __nouveau_fence_wait performance regression In-Reply-To: <20110309001404.GA22679@xxxxxxx> (Marcin Slusarz's message of "Wed, 9 Mar 2011 01:14:04 +0100") References: <20110213203804.GA5395@xxxxxxx> <20110304164905.GA2743@xxxxxxx> <AANLkTin_jouzPDGfNnYq_BRqPzbvOW+F6jFNuc7p=p5E@xxxxxxxxxxxxxx> <1299536668.29441.3.camel@nisroch> <20110307232256.GA2680@xxxxxxx> <87lj0qzaut.fsf@xxxxxxxxxx> <20110308121628.GA20238@xxxxxxx> <871v2hzin7.fsf@xxxxxxxxxx> <20110309001404.GA22679@xxxxxxx> Message-ID: <87fwqwb3kj.fsf@xxxxxxxxxx> Marcin Slusarz <marcin.slusarz at gmail.com> writes: > On Tue, Mar 08, 2011 at 05:22:52PM +0100, Francisco Jerez wrote: >> Marcin Slusarz <marcin.slusarz at gmail.com> writes: >> >> > On Tue, Mar 08, 2011 at 01:58:50AM +0100, Francisco Jerez wrote: >> >> Marcin Slusarz <marcin.slusarz at gmail.com> writes: >> >> >> >> > On Tue, Mar 08, 2011 at 08:24:26AM +1000, Ben Skeggs wrote: >> >> >> On Mon, 2011-03-07 at 18:18 +0000, Maarten Maathuis wrote: >> >> >> > On Fri, Mar 4, 2011 at 4:49 PM, Marcin Slusarz <marcin.slusarz at gmail.com> wrote: >> >> >> > > On Sun, Feb 13, 2011 at 09:38:04PM +0100, Marcin Slusarz wrote: >> >> >> > >> Combination of locking and interchannel synchronization changes >> >> >> > >> uncovered poor behaviour of nouveau_fence_wait, which on HZ=100 >> >> >> > >> configuration could waste up to 10 ms per call. >> >> >> > >> Depending on application, it lead to 10-30% FPS regression. >> >> >> > >> To fix it, shorten thread sleep time to 0.1 ms and ensure >> >> >> > >> spinning happens for at least one *full* tick. >> >> >> > >> >> >> >> > >> Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> >> >> >> > >> --- >> >> >> > >> drivers/gpu/drm/nouveau/nouveau_fence.c | 10 ++++++++-- >> >> >> > >> 1 files changed, 8 insertions(+), 2 deletions(-) >> >> >> > >> >> >> >> > >> diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c >> >> >> > >> index 221b846..75ba5e2 100644 >> >> >> > >> --- a/drivers/gpu/drm/nouveau/nouveau_fence.c >> >> >> > >> +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c >> >> >> > >> @@ -27,6 +27,9 @@ >> >> >> > >> #include "drmP.h" >> >> >> > >> #include "drm.h" >> >> >> > >> >> >> >> > >> +#include <linux/ktime.h> >> >> >> > >> +#include <linux/hrtimer.h> >> >> >> > >> + >> >> >> > >> #include "nouveau_drv.h" >> >> >> > >> #include "nouveau_ramht.h" >> >> >> > >> #include "nouveau_dma.h" >> >> >> > >> @@ -230,9 +233,12 @@ int >> >> >> > >> __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) >> >> >> > >> { >> >> >> > >> unsigned long timeout = jiffies + (3 * DRM_HZ); >> >> >> > >> - unsigned long sleep_time = jiffies + 1; >> >> >> > >> + unsigned long sleep_time = jiffies + 2; >> >> >> > >> + ktime_t t; >> >> >> > >> int ret = 0; >> >> >> > >> >> >> >> > >> + t = ktime_set(0, NSEC_PER_MSEC / 10); >> >> >> > >> + >> >> >> > >> while (1) { >> >> >> > >> if (__nouveau_fence_signalled(sync_obj, sync_arg)) >> >> >> > >> break; >> >> >> > >> @@ -245,7 +251,7 @@ __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) >> >> >> > >> __set_current_state(intr ? TASK_INTERRUPTIBLE >> >> >> > >> : TASK_UNINTERRUPTIBLE); >> >> >> > >> if (lazy && time_after_eq(jiffies, sleep_time)) >> >> >> > >> - schedule_timeout(1); >> >> >> > >> + schedule_hrtimeout(&t, HRTIMER_MODE_REL); >> >> >> > >> >> >> >> > >> if (intr && signal_pending(current)) { >> >> >> > >> ret = -ERESTARTSYS; >> >> >> > >> -- >> >> >> > >> 1.7.4.rc3 >> >> >> > >> >> >> >> > > >> >> >> > > ping again >> >> >> > > _______________________________________________ >> >> >> > > Nouveau mailing list >> >> >> > > Nouveau at lists.freedesktop.org >> >> >> > > http://lists.freedesktop.org/mailman/listinfo/nouveau >> >> >> > > >> >> >> > >> >> >> > This looks ok to me, but I would like to get Ben Skeggs ok on this one >> >> >> > as well. So i've CC'ed him, hopefully he'll notice :-) >> >> >> Ah sorry, I have actually looked at this quite a while back but came to >> >> >> no solid conclusion. >> >> >> >> >> >> While yes, I did see some minor performance improvement from it, I also >> >> >> notice that now we once again get 100% CPU usage while an app is waiting >> >> >> for the GPU a lot.. >> >> > >> >> > It's not "minor" performance improvement: >> >> > >> >> > without this patch (FPS): >> >> > nexuiz: 53 >> >> > wop: 181 >> >> > tremulous: 157 >> >> > wsw0.5: 89 >> >> > glxgears: 730 >> >> > >> >> > with: >> >> > nexuiz: 63 (+18%) >> >> > wop: 248 (+37%) >> >> > tremulous: 156 (-0.6%) >> >> > wsw0.5: 91 (+2%) >> >> > glxgears: 1054 (+44%) >> >> > >> >> > >> >> > Ok, so you are worried about CPU usage... Let's see what will happen if >> >> > I remove spinning added by "drm/nouveau: Spin for a bit in >> >> > nouveau_fence_wait() before yielding the CPU". >> >> > >> >> > reduced version (attached): >> >> > nexuiz: 62 >> >> > wop: 248 >> >> > trem: 157 >> >> > wsw0.5: 90 >> >> > glxgears: 1055 >> >> > >> >> > Good enough? >> >> >> >> Remember to exercise some software fallbacks as well (e.g. something >> >> using core fonts), software fallbacks were the main users of the >> >> spinning you've removed. >> > >> > corefonts are pretty fast (measured "time dmesg"): >> > >> > without (spinning + timeout 10ms): 0.08s >> > with (spinning + hrtimeout 0.1ms): 0.08s >> > reduced (no spinning + hrtimeout 0.1ms): 0.25s >> > old (no spinning + timeout 10ms): 13s >> > >> Ah, so it's still trading one performance regression for another, and >> you could make everyone happy at the same time. >> >> > So I think "no spinning + hrtimeout 0.1ms" is a reasonable compromise... >> > >> What's the CPU usage difference between the spinning and the no-spinning >> cases? > > 1 cpu set to performance mode > > spinning + hrtimeout 0.1ms: > FPS usr sys > nexuiz: 63 46.60 + 52.36 > wop: 248 57.54 + 41.99 > trem: 156 92.40 + 7.30 > wsw0.5: 91 52.91 + 46.37 > glxgears: 1054 10.00 + 90.00 > corefonts: 42.86 + 54.29 0.08s(time) > > So it fills the CPU in almost 100%... > > no spinning + hrtimeout 0.1ms: > FPS usr sys > nexuiz: 62 49.97 + 8.42 > wop: 248 58.04 + 22.04 > trem: 157 92.42 + 6.92 > wsw0.5: 90 51.69 + 4.58 > glxgears: 1055 11.45 + 11.05 > corefonts: 20.52 + 7.82 0.25s > > OK. > So I did some more tests: > > no spinning + hrtimeout 0.01ms: > FPS usr sys > nexuiz: 63 49.50 + 14.01 > wop: 245 57.21 + 24.66 > trem: 148 89.31 + 10.01 > wsw0.5: 91 52.92 + 11.10 > glxgears: 1055 10.61 + 22.34 > corefonts: 38.24 + 27.45 0.09s > > tremulous FPS is down, sys CPU usage is down, but not so good as in > "no spinning, 0.1ms", corefonts are almost as fast > > --- > > no spinning + hrtimeout 0.01ms increasing by factor x2, max at 1ms: > nexuiz: 62 48.38 + 8.00 > wop: 245 56.55 + 19.92 > trem: 149 90.46 + 8.86 > wsw0.5: 92 52.10 + 4.56 > glxgears: 1026 11.68 + 9.87 > corefonts: 46.60 + 25.24 0.09s > > almost like "no spinning + 0.01ms", but glxgears FPS is down > > --- > > no spinning + hrtimeout 0.001ms: > nexuiz: 63 52.04 + 16.13 > wop: 246 58.94 + 22.59 > trem: 155 92.73 + 6.38 > wsw0.5: 91 54.39 + 16.88 > glxgears: 1055 10.62 + 30.55 > corefonts: 53.01 + 28.92 0.07s > > tremulous FPS is back, sys CPU usage is sometimes bigger, sometimes smaller, > corefonts are fast, but take a lot of CPU time > > --- > > no spinning + hrtimeout 0.001ms increasing by factor x2, max at 1ms > nexuiz: 62 49.46 + 6.70 > wop: 247 58.80 + 17.95 > trem: 156 92.16 + 7.28 > wsw0.5: 91 52.79 + 4.03 > glxgears: 1050 11.44 + 12.54 > corefonts: 36.05 + 32.56 0.07s > > glxgears FPS is a bit down, sys CPU times are as good (or better) as in > "no spinning, 0.1ms", corefonts are fast > > this is the best, patch below > >> It's likely to be negligible for most applications aside from the >> ones using queries and fallbacks intensively, and in those two cases I >> agree with you that optimizing for low CPU usage doesn't make a huge lot >> of sense, getting low latency is already hard enough. >> >> If I'm wrong and the initial spinning affects the overall CPU usage >> negatively, then we have two different use cases with different latency >> requirements and the DRM API needs to be fixed (though, there're maybe >> other solutions to explore first, like, start with a really small >> hrtimeout and increase it exponentially up to some cut-off value). >> >> > BTW, old behaviour (no spinning + timeout 10ms) affects other workloads too >> > nexuiz: 50 >> > wop: 153 >> > tremulous: 155 >> > wsw0.5: 89 >> > glxgears: 100 (!) >> > >> >> Anyway, software fallbacks and occlusion queries are the only two places >> >> (that I can think of now) where we need the low latency your patch >> >> gives, and, as Ben already pointed out, we probably want to keep CPU >> >> usage at minimum in every other case. As a middle ground, the "lazy" >> >> flag (or rather, a "hog" flag?) could be exposed all the way up to >> >> userspace, and those two cases fixed to set the flag differently. >> >> >> >> What do you think? >> > >> > I'm not sure. I think optimizing for low CPU usage is not the best what >> > we can do right now. 3D performance is still too low behind blob. >> > Let's fix 3D perf first and think about CPU usage later. >> > >> >> IMHO, switching to lazy waits was the right choice at this stage, it >> doesn't make optimizing for "3D performance" any harder, quite the >> opposite, it helps to pinpoint some poorly-pipelining programming >> practices by making the already existing performance problem more >> obvious. >> >> >> > >> >> > --- >> >> > From: Marcin Slusarz <marcin.slusarz at gmail.com> >> >> > Subject: [PATCH] drm/nouveau: fix __nouveau_fence_wait performance regression >> >> > >> >> > Combination of locking and interchannel synchronization changes >> >> > uncovered poor behaviour of nouveau_fence_wait, which on HZ=100 >> >> > configuration could waste up to 10 ms per call. >> >> > Depending on application, it lead to 10-30% FPS regression. >> >> > >> >> > To fix it, shorten thread sleep time to 0.1 ms. >> >> > >> >> > Additionally, remove spinning (added by "drm/nouveau: Spin for >> >> > a bit in nouveau_fence_wait() before yielding the CPU"), because >> >> > it's not needed anymore. >> >> > >> >> > Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> >> >> > --- >> >> > drivers/gpu/drm/nouveau/nouveau_fence.c | 11 ++++++++--- >> >> > 1 files changed, 8 insertions(+), 3 deletions(-) >> >> > >> >> > diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c >> >> > index a244702..010243b 100644 >> >> > --- a/drivers/gpu/drm/nouveau/nouveau_fence.c >> >> > +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c >> >> > @@ -27,6 +27,9 @@ >> >> > #include "drmP.h" >> >> > #include "drm.h" >> >> > >> >> > +#include <linux/ktime.h> >> >> > +#include <linux/hrtimer.h> >> >> > + >> >> > #include "nouveau_drv.h" >> >> > #include "nouveau_ramht.h" >> >> > #include "nouveau_dma.h" >> >> > @@ -229,9 +232,11 @@ int >> >> > __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) >> >> > { >> >> > unsigned long timeout = jiffies + (3 * DRM_HZ); >> >> > - unsigned long sleep_time = jiffies + 1; >> >> > + ktime_t t; >> >> > int ret = 0; >> >> > >> >> > + t = ktime_set(0, NSEC_PER_MSEC / 10); >> >> > + >> >> > while (1) { >> >> > if (__nouveau_fence_signalled(sync_obj, sync_arg)) >> >> > break; >> >> > @@ -243,8 +248,8 @@ __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) >> >> > >> >> > __set_current_state(intr ? TASK_INTERRUPTIBLE >> >> > : TASK_UNINTERRUPTIBLE); >> >> > - if (lazy && time_after_eq(jiffies, sleep_time)) >> >> > - schedule_timeout(1); >> >> > + if (lazy) >> >> > + schedule_hrtimeout(&t, HRTIMER_MODE_REL); >> >> > >> >> > if (intr && signal_pending(current)) { >> >> > ret = -ERESTARTSYS; > > > > --- > From: Marcin Slusarz <marcin.slusarz at gmail.com> > Subject: [PATCH] drm/nouveau: fix __nouveau_fence_wait performance > > Commit fcccab2e4eb8d579837481054cc2cb28eea0baef > ("drm/nouveau: Use lazy fence waits when doing software interchannel sync") > turned on lazy waits. Unfortunately __nouveau_fence_wait was not optimized > for this case and on HZ=100 kernel wasted up to 10 ms per call. > That patch isn't the culprit of your problem, you're unlikely to be hitting the failure path of nouveau_fence_sync(), and that's the only thing I changed with that commit. Lazy waits were enabled earlier by 21e86c1c8a844bf978f8fc431a59c9f5a578812d. That aside it looks good, I've pushed it after fixing the commit description. Thank you. > Depending on application, it lead to 10-30% FPS regression. > > Fix it. > > Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> > --- > drivers/gpu/drm/nouveau/nouveau_fence.c | 17 ++++++++++++++--- > 1 files changed, 14 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c > index a244702..78d32dd 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_fence.c > +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c > @@ -27,6 +27,9 @@ > #include "drmP.h" > #include "drm.h" > > +#include <linux/ktime.h> > +#include <linux/hrtimer.h> > + > #include "nouveau_drv.h" > #include "nouveau_ramht.h" > #include "nouveau_dma.h" > @@ -229,9 +232,12 @@ int > __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) > { > unsigned long timeout = jiffies + (3 * DRM_HZ); > - unsigned long sleep_time = jiffies + 1; > + unsigned long sleep_time = NSEC_PER_MSEC / 1000; > + ktime_t t; > int ret = 0; > > + t = ktime_set(0, sleep_time); > + > while (1) { > if (__nouveau_fence_signalled(sync_obj, sync_arg)) > break; > @@ -243,8 +249,13 @@ __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) > > __set_current_state(intr ? TASK_INTERRUPTIBLE > : TASK_UNINTERRUPTIBLE); > - if (lazy && time_after_eq(jiffies, sleep_time)) > - schedule_timeout(1); > + if (lazy) { > + schedule_hrtimeout(&t, HRTIMER_MODE_REL); > + sleep_time *= 2; > + if (sleep_time > NSEC_PER_MSEC) > + sleep_time = NSEC_PER_MSEC; > + t = ktime_set(0, sleep_time); > + } > > if (intr && signal_pending(current)) { > ret = -ERESTARTSYS; -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 229 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/nouveau/attachments/20110309/ad9e825c/attachment.pgp> From dj.jankins at gmail.com Tue Mar 8 21:38:55 2011 From: dj.jankins at gmail.com (Donald Jenkins) Date: Wed, 9 Mar 2011 12:38:55 +0700 Subject: Problem setting refresh rate on 8400GS Message-ID: <AANLkTinVNbeYDo_g=4EYVt0BJ=4Cf6SJ02dPmUvw860w@xxxxxxxxxxxxxx> Hello. Having serious problems with all nvidia boards plugged on my PC, now on 8400GS. Xorg with 2D-only nouveau driver sets invalid preferred refresh rate 60hz on SAMTRON 73v, when 75hz needed. output of xrandr: Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 8192 x 8192 DVI-I-1 disconnected (normal left inverted right x axis y axis) VGA-1 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 338mm x 270mm 1280x1024 60.0*+ 75.0 1152x864 75.0 1024x768 75.1 70.1 60.0 832x624 74.6 800x600 72.2 75.0 60.3 56.2 640x480 72.8 75.0 66.7 60.0 720x400 70.1 I can *manually* set correct refresh rate using xrandr -r 75 command (for example, in .xinitrc), but Xorg configuration don't recognize it at all. Some full screen software games reset refresh rate back to 60hz. How I can "hardcode" it in xorg.conf? I really stuck at this point. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/nouveau/attachments/20110309/77a028fb/attachment-0001.htm> From marcin.slusarz at gmail.com Wed Mar 9 10:04:01 2011 From: marcin.slusarz at gmail.com (Marcin Slusarz) Date: Wed, 9 Mar 2011 19:04:01 +0100 Subject: [PATCH] drm/nouveau: fix __nouveau_fence_wait performance regression In-Reply-To: <87fwqwb3kj.fsf@xxxxxxxxxx> References: <20110213203804.GA5395@xxxxxxx> <20110304164905.GA2743@xxxxxxx> <AANLkTin_jouzPDGfNnYq_BRqPzbvOW+F6jFNuc7p=p5E@xxxxxxxxxxxxxx> <1299536668.29441.3.camel@nisroch> <20110307232256.GA2680@xxxxxxx> <87lj0qzaut.fsf@xxxxxxxxxx> <20110308121628.GA20238@xxxxxxx> <871v2hzin7.fsf@xxxxxxxxxx> <20110309001404.GA22679@xxxxxxx> <87fwqwb3kj.fsf@xxxxxxxxxx> Message-ID: <20110309180401.GA2611@xxxxxxx> On Wed, Mar 09, 2011 at 06:34:36PM +0100, Francisco Jerez wrote: > Marcin Slusarz <marcin.slusarz at gmail.com> writes: > > > On Tue, Mar 08, 2011 at 05:22:52PM +0100, Francisco Jerez wrote: > >> Marcin Slusarz <marcin.slusarz at gmail.com> writes: > >> > >> > On Tue, Mar 08, 2011 at 01:58:50AM +0100, Francisco Jerez wrote: > >> >> Marcin Slusarz <marcin.slusarz at gmail.com> writes: > >> >> > >> >> > On Tue, Mar 08, 2011 at 08:24:26AM +1000, Ben Skeggs wrote: > >> >> >> On Mon, 2011-03-07 at 18:18 +0000, Maarten Maathuis wrote: > >> >> >> > On Fri, Mar 4, 2011 at 4:49 PM, Marcin Slusarz <marcin.slusarz at gmail.com> wrote: > >> >> >> > > On Sun, Feb 13, 2011 at 09:38:04PM +0100, Marcin Slusarz wrote: > >> >> >> > >> Combination of locking and interchannel synchronization changes > >> >> >> > >> uncovered poor behaviour of nouveau_fence_wait, which on HZ=100 > >> >> >> > >> configuration could waste up to 10 ms per call. > >> >> >> > >> Depending on application, it lead to 10-30% FPS regression. > >> >> >> > >> To fix it, shorten thread sleep time to 0.1 ms and ensure > >> >> >> > >> spinning happens for at least one *full* tick. > >> >> >> > >> > >> >> >> > >> Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> > >> >> >> > >> --- > >> >> >> > >> drivers/gpu/drm/nouveau/nouveau_fence.c | 10 ++++++++-- > >> >> >> > >> 1 files changed, 8 insertions(+), 2 deletions(-) > >> >> >> > >> > >> >> >> > >> diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c > >> >> >> > >> index 221b846..75ba5e2 100644 > >> >> >> > >> --- a/drivers/gpu/drm/nouveau/nouveau_fence.c > >> >> >> > >> +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c > >> >> >> > >> @@ -27,6 +27,9 @@ > >> >> >> > >> #include "drmP.h" > >> >> >> > >> #include "drm.h" > >> >> >> > >> > >> >> >> > >> +#include <linux/ktime.h> > >> >> >> > >> +#include <linux/hrtimer.h> > >> >> >> > >> + > >> >> >> > >> #include "nouveau_drv.h" > >> >> >> > >> #include "nouveau_ramht.h" > >> >> >> > >> #include "nouveau_dma.h" > >> >> >> > >> @@ -230,9 +233,12 @@ int > >> >> >> > >> __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) > >> >> >> > >> { > >> >> >> > >> unsigned long timeout = jiffies + (3 * DRM_HZ); > >> >> >> > >> - unsigned long sleep_time = jiffies + 1; > >> >> >> > >> + unsigned long sleep_time = jiffies + 2; > >> >> >> > >> + ktime_t t; > >> >> >> > >> int ret = 0; > >> >> >> > >> > >> >> >> > >> + t = ktime_set(0, NSEC_PER_MSEC / 10); > >> >> >> > >> + > >> >> >> > >> while (1) { > >> >> >> > >> if (__nouveau_fence_signalled(sync_obj, sync_arg)) > >> >> >> > >> break; > >> >> >> > >> @@ -245,7 +251,7 @@ __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) > >> >> >> > >> __set_current_state(intr ? TASK_INTERRUPTIBLE > >> >> >> > >> : TASK_UNINTERRUPTIBLE); > >> >> >> > >> if (lazy && time_after_eq(jiffies, sleep_time)) > >> >> >> > >> - schedule_timeout(1); > >> >> >> > >> + schedule_hrtimeout(&t, HRTIMER_MODE_REL); > >> >> >> > >> > >> >> >> > >> if (intr && signal_pending(current)) { > >> >> >> > >> ret = -ERESTARTSYS; > >> >> >> > >> -- > >> >> >> > >> 1.7.4.rc3 > >> >> >> > >> > >> >> >> > > > >> >> >> > > ping again > >> >> >> > > _______________________________________________ > >> >> >> > > Nouveau mailing list > >> >> >> > > Nouveau at lists.freedesktop.org > >> >> >> > > http://lists.freedesktop.org/mailman/listinfo/nouveau > >> >> >> > > > >> >> >> > > >> >> >> > This looks ok to me, but I would like to get Ben Skeggs ok on this one > >> >> >> > as well. So i've CC'ed him, hopefully he'll notice :-) > >> >> >> Ah sorry, I have actually looked at this quite a while back but came to > >> >> >> no solid conclusion. > >> >> >> > >> >> >> While yes, I did see some minor performance improvement from it, I also > >> >> >> notice that now we once again get 100% CPU usage while an app is waiting > >> >> >> for the GPU a lot.. > >> >> > > >> >> > It's not "minor" performance improvement: > >> >> > > >> >> > without this patch (FPS): > >> >> > nexuiz: 53 > >> >> > wop: 181 > >> >> > tremulous: 157 > >> >> > wsw0.5: 89 > >> >> > glxgears: 730 > >> >> > > >> >> > with: > >> >> > nexuiz: 63 (+18%) > >> >> > wop: 248 (+37%) > >> >> > tremulous: 156 (-0.6%) > >> >> > wsw0.5: 91 (+2%) > >> >> > glxgears: 1054 (+44%) > >> >> > > >> >> > > >> >> > Ok, so you are worried about CPU usage... Let's see what will happen if > >> >> > I remove spinning added by "drm/nouveau: Spin for a bit in > >> >> > nouveau_fence_wait() before yielding the CPU". > >> >> > > >> >> > reduced version (attached): > >> >> > nexuiz: 62 > >> >> > wop: 248 > >> >> > trem: 157 > >> >> > wsw0.5: 90 > >> >> > glxgears: 1055 > >> >> > > >> >> > Good enough? > >> >> > >> >> Remember to exercise some software fallbacks as well (e.g. something > >> >> using core fonts), software fallbacks were the main users of the > >> >> spinning you've removed. > >> > > >> > corefonts are pretty fast (measured "time dmesg"): > >> > > >> > without (spinning + timeout 10ms): 0.08s > >> > with (spinning + hrtimeout 0.1ms): 0.08s > >> > reduced (no spinning + hrtimeout 0.1ms): 0.25s > >> > old (no spinning + timeout 10ms): 13s > >> > > >> Ah, so it's still trading one performance regression for another, and > >> you could make everyone happy at the same time. > >> > >> > So I think "no spinning + hrtimeout 0.1ms" is a reasonable compromise... > >> > > >> What's the CPU usage difference between the spinning and the no-spinning > >> cases? > > > > 1 cpu set to performance mode > > > > spinning + hrtimeout 0.1ms: > > FPS usr sys > > nexuiz: 63 46.60 + 52.36 > > wop: 248 57.54 + 41.99 > > trem: 156 92.40 + 7.30 > > wsw0.5: 91 52.91 + 46.37 > > glxgears: 1054 10.00 + 90.00 > > corefonts: 42.86 + 54.29 0.08s(time) > > > > So it fills the CPU in almost 100%... > > > > no spinning + hrtimeout 0.1ms: > > FPS usr sys > > nexuiz: 62 49.97 + 8.42 > > wop: 248 58.04 + 22.04 > > trem: 157 92.42 + 6.92 > > wsw0.5: 90 51.69 + 4.58 > > glxgears: 1055 11.45 + 11.05 > > corefonts: 20.52 + 7.82 0.25s > > > > OK. > > So I did some more tests: > > > > no spinning + hrtimeout 0.01ms: > > FPS usr sys > > nexuiz: 63 49.50 + 14.01 > > wop: 245 57.21 + 24.66 > > trem: 148 89.31 + 10.01 > > wsw0.5: 91 52.92 + 11.10 > > glxgears: 1055 10.61 + 22.34 > > corefonts: 38.24 + 27.45 0.09s > > > > tremulous FPS is down, sys CPU usage is down, but not so good as in > > "no spinning, 0.1ms", corefonts are almost as fast > > > > --- > > > > no spinning + hrtimeout 0.01ms increasing by factor x2, max at 1ms: > > nexuiz: 62 48.38 + 8.00 > > wop: 245 56.55 + 19.92 > > trem: 149 90.46 + 8.86 > > wsw0.5: 92 52.10 + 4.56 > > glxgears: 1026 11.68 + 9.87 > > corefonts: 46.60 + 25.24 0.09s > > > > almost like "no spinning + 0.01ms", but glxgears FPS is down > > > > --- > > > > no spinning + hrtimeout 0.001ms: > > nexuiz: 63 52.04 + 16.13 > > wop: 246 58.94 + 22.59 > > trem: 155 92.73 + 6.38 > > wsw0.5: 91 54.39 + 16.88 > > glxgears: 1055 10.62 + 30.55 > > corefonts: 53.01 + 28.92 0.07s > > > > tremulous FPS is back, sys CPU usage is sometimes bigger, sometimes smaller, > > corefonts are fast, but take a lot of CPU time > > > > --- > > > > no spinning + hrtimeout 0.001ms increasing by factor x2, max at 1ms > > nexuiz: 62 49.46 + 6.70 > > wop: 247 58.80 + 17.95 > > trem: 156 92.16 + 7.28 > > wsw0.5: 91 52.79 + 4.03 > > glxgears: 1050 11.44 + 12.54 > > corefonts: 36.05 + 32.56 0.07s > > > > glxgears FPS is a bit down, sys CPU times are as good (or better) as in > > "no spinning, 0.1ms", corefonts are fast > > > > this is the best, patch below > > > >> It's likely to be negligible for most applications aside from the > >> ones using queries and fallbacks intensively, and in those two cases I > >> agree with you that optimizing for low CPU usage doesn't make a huge lot > >> of sense, getting low latency is already hard enough. > >> > >> If I'm wrong and the initial spinning affects the overall CPU usage > >> negatively, then we have two different use cases with different latency > >> requirements and the DRM API needs to be fixed (though, there're maybe > >> other solutions to explore first, like, start with a really small > >> hrtimeout and increase it exponentially up to some cut-off value). > >> > >> > BTW, old behaviour (no spinning + timeout 10ms) affects other workloads too > >> > nexuiz: 50 > >> > wop: 153 > >> > tremulous: 155 > >> > wsw0.5: 89 > >> > glxgears: 100 (!) > >> > > >> >> Anyway, software fallbacks and occlusion queries are the only two places > >> >> (that I can think of now) where we need the low latency your patch > >> >> gives, and, as Ben already pointed out, we probably want to keep CPU > >> >> usage at minimum in every other case. As a middle ground, the "lazy" > >> >> flag (or rather, a "hog" flag?) could be exposed all the way up to > >> >> userspace, and those two cases fixed to set the flag differently. > >> >> > >> >> What do you think? > >> > > >> > I'm not sure. I think optimizing for low CPU usage is not the best what > >> > we can do right now. 3D performance is still too low behind blob. > >> > Let's fix 3D perf first and think about CPU usage later. > >> > > >> > >> IMHO, switching to lazy waits was the right choice at this stage, it > >> doesn't make optimizing for "3D performance" any harder, quite the > >> opposite, it helps to pinpoint some poorly-pipelining programming > >> practices by making the already existing performance problem more > >> obvious. > >> > >> >> > > >> >> > --- > >> >> > From: Marcin Slusarz <marcin.slusarz at gmail.com> > >> >> > Subject: [PATCH] drm/nouveau: fix __nouveau_fence_wait performance regression > >> >> > > >> >> > Combination of locking and interchannel synchronization changes > >> >> > uncovered poor behaviour of nouveau_fence_wait, which on HZ=100 > >> >> > configuration could waste up to 10 ms per call. > >> >> > Depending on application, it lead to 10-30% FPS regression. > >> >> > > >> >> > To fix it, shorten thread sleep time to 0.1 ms. > >> >> > > >> >> > Additionally, remove spinning (added by "drm/nouveau: Spin for > >> >> > a bit in nouveau_fence_wait() before yielding the CPU"), because > >> >> > it's not needed anymore. > >> >> > > >> >> > Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> > >> >> > --- > >> >> > drivers/gpu/drm/nouveau/nouveau_fence.c | 11 ++++++++--- > >> >> > 1 files changed, 8 insertions(+), 3 deletions(-) > >> >> > > >> >> > diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c b/drivers/gpu/drm/nouveau/nouveau_fence.c > >> >> > index a244702..010243b 100644 > >> >> > --- a/drivers/gpu/drm/nouveau/nouveau_fence.c > >> >> > +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c > >> >> > @@ -27,6 +27,9 @@ > >> >> > #include "drmP.h" > >> >> > #include "drm.h" > >> >> > > >> >> > +#include <linux/ktime.h> > >> >> > +#include <linux/hrtimer.h> > >> >> > + > >> >> > #include "nouveau_drv.h" > >> >> > #include "nouveau_ramht.h" > >> >> > #include "nouveau_dma.h" > >> >> > @@ -229,9 +232,11 @@ int > >> >> > __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) > >> >> > { > >> >> > unsigned long timeout = jiffies + (3 * DRM_HZ); > >> >> > - unsigned long sleep_time = jiffies + 1; > >> >> > + ktime_t t; > >> >> > int ret = 0; > >> >> > > >> >> > + t = ktime_set(0, NSEC_PER_MSEC / 10); > >> >> > + > >> >> > while (1) { > >> >> > if (__nouveau_fence_signalled(sync_obj, sync_arg)) > >> >> > break; > >> >> > @@ -243,8 +248,8 @@ __nouveau_fence_wait(void *sync_obj, void *sync_arg, bool lazy, bool intr) > >> >> > > >> >> > __set_current_state(intr ? TASK_INTERRUPTIBLE > >> >> > : TASK_UNINTERRUPTIBLE); > >> >> > - if (lazy && time_after_eq(jiffies, sleep_time)) > >> >> > - schedule_timeout(1); > >> >> > + if (lazy) > >> >> > + schedule_hrtimeout(&t, HRTIMER_MODE_REL); > >> >> > > >> >> > if (intr && signal_pending(current)) { > >> >> > ret = -ERESTARTSYS; > > > > > > > > --- > > From: Marcin Slusarz <marcin.slusarz at gmail.com> > > Subject: [PATCH] drm/nouveau: fix __nouveau_fence_wait performance > > > > Commit fcccab2e4eb8d579837481054cc2cb28eea0baef > > ("drm/nouveau: Use lazy fence waits when doing software interchannel sync") > > turned on lazy waits. Unfortunately __nouveau_fence_wait was not optimized > > for this case and on HZ=100 kernel wasted up to 10 ms per call. > > > That patch isn't the culprit of your problem, you're unlikely to be > hitting the failure path of nouveau_fence_sync(), and that's the only > thing I changed with that commit. Lazy waits were enabled earlier by > 21e86c1c8a844bf978f8fc431a59c9f5a578812d. > > That aside it looks good, I've pushed it after fixing the commit > description. Thank you. I wasn't sure about this commit. Thanks for fixing it. Marcin From bugzilla-daemon at freedesktop.org Wed Mar 9 10:50:22 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Wed, 9 Mar 2011 10:50:22 -0800 (PST) Subject: [Bug 35157] New: Black Screen while booting Message-ID: <bug-35157-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> https://bugs.freedesktop.org/show_bug.cgi?id=35157 Summary: Black Screen while booting Product: xorg Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org ReportedBy: limaunion at gmail.com QAContact: xorg-team at lists.x.org Hi! I'm getting a black screen _inmediately_after_booting_ the Linux kernel, being unable to access any tty console nor X11 (of course ssh is ok). I'm running a self-compiled kernel from vanilla (2.6.37.2) and am trying to switch from the NVIDIA propietary driver to nouveau. I've followed the following instructions in order to enable the required kernel settings: http://en.gentoo-wiki.com/wiki/Nouveau (the real distro I'm using is Debian testing) I'm not sure if this is a bug or not but let me know any other information required. Thanks in advance. $ cat dmesg | egrep -i '(nouveau|drm)' [ 0.000000] Linux version 2.6.37.2.nouveau (limaunion at debian1) (gcc version 4.4.5 (Debian 4.4.5-12) ) #7 SMP Fri Mar 4 22:35:28 2011 [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.37.2.nouveau root=/dev/sda1 ro vga=775 [ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.37.2.nouveau root=/dev/sda1 ro vga=775 [ 3.633513] [drm] Initialized drm 1.1.0 20060810 [ 3.808087] usb usb1: Manufacturer: Linux 2.6.37.2.nouveau ehci_hcd [ 3.921663] nouveau 0000:02:00.0: PCI INT A -> Link[APC8] -> GSI 16 (level, low) -> IRQ 16 [ 3.921671] nouveau 0000:02:00.0: setting latency timer to 64 [ 3.924642] [drm] nouveau 0000:02:00.0: Detected an NV40 generation card (0x044a00a2) [ 3.925947] [drm] nouveau 0000:02:00.0: Attempting to load BIOS image from PRAMIN [ 4.005997] [drm] nouveau 0000:02:00.0: ... appears to be valid [ 4.006014] [drm] nouveau 0000:02:00.0: BIT BIOS found [ 4.006019] [drm] nouveau 0000:02:00.0: Bios version 05.44.02.67 [ 4.006024] [drm] nouveau 0000:02:00.0: TMDS table version 1.1 [ 4.006028] [drm] nouveau 0000:02:00.0: BIT table 'd' not found [ 4.006033] [drm] nouveau 0000:02:00.0: Found Display Configuration Block version 3.0 [ 4.006039] [drm] nouveau 0000:02:00.0: Raw DCB entry 0: 01000300 00000028 [ 4.006044] [drm] nouveau 0000:02:00.0: Raw DCB entry 1: 02011310 00000028 [ 4.006048] [drm] nouveau 0000:02:00.0: Raw DCB entry 2: 01011312 00000000 [ 4.006052] [drm] nouveau 0000:02:00.0: Raw DCB entry 3: 020223f1 00c0c080 [ 4.006058] [drm] nouveau 0000:02:00.0: DCB connector table: VHER 0x30 5 7 2 [ 4.006063] [drm] nouveau 0000:02:00.0: 0: 0x00000000: type 0x00 idx 0 tag 0xff [ 4.006068] [drm] nouveau 0000:02:00.0: 1: 0x00002130: type 0x30 idx 1 tag 0x08 [ 4.006073] [drm] nouveau 0000:02:00.0: 2: 0x00000210: type 0x10 idx 2 tag 0xff [ 4.006078] [drm] nouveau 0000:02:00.0: 3: 0x00000211: type 0x11 idx 3 tag 0xff [ 4.006083] [drm] nouveau 0000:02:00.0: 4: 0x00000213: type 0x13 idx 4 tag 0xff [ 4.006093] [drm] nouveau 0000:02:00.0: Parsing VBIOS init table 0 at offset 0xDCEA [ 4.006477] [drm] nouveau 0000:02:00.0: Parsing VBIOS init table 1 at offset 0xE04F [ 4.026225] [drm] nouveau 0000:02:00.0: Parsing VBIOS init table 2 at offset 0xE589 [ 4.026243] [drm] nouveau 0000:02:00.0: Parsing VBIOS init table 3 at offset 0xE6DE [ 4.028135] [drm] nouveau 0000:02:00.0: Parsing VBIOS init table 4 at offset 0xE888 [ 4.047489] [drm] nouveau 0000:02:00.0: mem timing table length unknown: 14 [ 4.047495] [drm] nouveau 0000:02:00.0: 1 available performance level(s) [ 4.047501] [drm] nouveau 0000:02:00.0: 0: memory 532MHz core 350MHz fanspeed 100% [ 4.047512] [drm] nouveau 0000:02:00.0: c: memory 401MHz core 200MHz [ 4.047520] [drm] nouveau 0000:02:00.0: Detected 256MiB VRAM [ 4.049196] [drm] nouveau 0000:02:00.0: 64 MiB GART (aperture) [ 4.051165] [drm] nouveau 0000:02:00.0: Allocating FIFO number 0 [ 4.051564] [drm] nouveau 0000:02:00.0: nouveau_channel_alloc: initialised FIFO 0 [ 4.051576] [drm] nouveau 0000:02:00.0: Setting dpms mode 3 on vga encoder (output 0) [ 4.051582] [drm] nouveau 0000:02:00.0: Setting dpms mode 3 on vga encoder (output 1) [ 4.051587] [drm] nouveau 0000:02:00.0: Setting dpms mode 3 on tmds encoder (output 2) [ 4.051593] [drm] nouveau 0000:02:00.0: Setting dpms mode 3 on TV encoder (output 3) [ 4.208627] [drm] nouveau 0000:02:00.0: allocated 1680x1050 fb: 0x49000, bo ffff88007ae81c00 [ 4.208694] fb0: nouveaufb frame buffer device [ 4.208698] drm: registered panic notifier [ 4.208705] [drm] Initialized nouveau 0.0.16 20090420 for 0000:02:00.0 on minor 0 [ 4.488065] usb usb2: Manufacturer: Linux 2.6.37.2.nouveau ohci_hcd $ cat lsmod.out.txt | egrep '(drm|nouveau)' nouveau 464294 0 ttm 42177 1 nouveau drm_kms_helper 21691 1 nouveau drm 141427 3 nouveau,ttm,drm_kms_helper fb 30953 2 nouveau,drm_kms_helper cfbcopyarea 2857 1 nouveau i2c_algo_bit 4103 2 nouveau,bttv cfbimgblt 1897 1 nouveau button 4522 1 nouveau i2c_core 15872 20 tuner,tea5767,tda8290,tda18271,tda827x,tda9887,tuner_simple,tea5761,tvaudio,tda7432,msp3400,nouveau,bttv,drm_kms_helper,v4l2_common,videodev,drm,i2c_algo_bit,tveeprom,i2c_nforce2 cfbfillrect 2917 1 nouveau $ cat Xorg.0.log X.Org X Server 1.7.7 Release Date: 2010-05-04 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.32-5-amd64 x86_64 Debian Current Operating System: Linux debian1 2.6.37.2.nouveau #7 SMP Fri Mar 4 22:35:28 ART 2011 x86_64 Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.37.2.nouveau root=/dev/sda1 ro vga=775 Build Date: 12 January 2011 02:59:50AM xorg-server 2:1.7.7-11 (Cyril Brulebois <kibi at debian.org>) Current version of pixman: 0.16.4 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Fri Mar 4 22:37:43 2011 (==) Using config file: "/etc/X11/xorg.conf" (==) Using system config directory "/usr/share/X11/xorg.conf.d" (==) No Layout section. Using the first Screen section. (==) No screen section available. Using defaults. (**) |-->Screen "Default Screen Section" (0) (**) | |-->Monitor "<default monitor>" (==) No device specified for screen "Default Screen Section". Using the first device section listed. (**) | |-->Device "devname" (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. (==) Automatically adding devices (==) Automatically enabling devices (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. Entry deleted from font path. (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, built-ins (==) ModulePath set to "/usr/lib/xorg/modules" (==) |-->Input Device "Generic Keyboard" (==) No Layout section. Using the first core keyboard device. (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. (WW) AllowEmptyInput is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled. (WW) Disabling Generic Keyboard (II) Loader magic: 0x7c8a00 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 6.0 X.Org XInput driver : 7.0 X.Org Server Extension : 2.0 (++) using VT number 7 (--) PCI: (0:1:7:0) 109e:036e:0000:0000 Brooktree Corporation Bt878 Video Capture rev 17, Mem @ 0xfdfff000/4096 (--) PCI:*(0:2:0:0) 10de:016a:1682:2234 nVidia Corporation NV44 [GeForce 7100 GS] rev 161, Mem @ 0xfa000000/16777216, 0xd0000000/268435456, 0xfb000000/16777216, BIOS @ 0x????????/131072 (II) Open ACPI successful (/var/run/acpid.socket) (II) LoadModule: "extmod" (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so (II) Module extmod: vendor="X.Org Foundation" compiled for 1.7.7, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension SELinux (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "dbe" (II) Loading /usr/lib/xorg/modules/extensions/libdbe.so (II) Module dbe: vendor="X.Org Foundation" compiled for 1.7.7, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "glx" (II) Loading /usr/lib/xorg/modules/extensions/libglx.so (II) Module glx: vendor="NVIDIA Corporation" compiled for 4.0.2, module version = 1.0.0 Module class: X.Org Server Extension (II) NVIDIA GLX Module 260.19.36 Tue Jan 18 17:12:12 PST 2011 (II) Loading extension GLX (II) LoadModule: "record" (II) Loading /usr/lib/xorg/modules/extensions/librecord.so (II) Module record: vendor="X.Org Foundation" compiled for 1.7.7, module version = 1.13.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension RECORD (II) LoadModule: "dri" (II) Loading /usr/lib/xorg/modules/extensions/libdri.so (II) Module dri: vendor="X.Org Foundation" compiled for 1.7.7, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension XFree86-DRI (II) LoadModule: "dri2" (II) Loading /usr/lib/xorg/modules/extensions/libdri2.so (II) Module dri2: vendor="X.Org Foundation" compiled for 1.7.7, module version = 1.1.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DRI2 (II) LoadModule: "nouveau" (II) Loading /usr/lib/xorg/modules/drivers/nouveau_drv.so (II) Module nouveau: vendor="X.Org Foundation" compiled for 1.7.7, module version = 0.0.15 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 6.0 (II) NOUVEAU driver Date: Tue Mar 16 13:08:37 2010 +1000 (II) NOUVEAU driver for NVIDIA chipset families : RIVA TNT (NV04) RIVA TNT2 (NV05) GeForce 256 (NV10) GeForce 2 (NV11, NV15) GeForce 4MX (NV17, NV18) GeForce 3 (NV20) GeForce 4Ti (NV25, NV28) GeForce FX (NV3x) GeForce 6 (NV4x) GeForce 7 (G7x) GeForce 8 (G8x) (II) Primary Device is: PCI 02 at 00:00:0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: Searching for BusID pci:0000:02:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: drmOpenMinor returns 8 drmOpenByBusid: drmGetBusid reports pci:0000:02:00.0 (EE) [drm] failed to open device (EE) No devices detected. Fatal server error: no screens found Please consult the The X.Org Foundation support at http://wiki.x.org for help. Please also check the log file at "/var/log/Xorg.0.log" for additional information. $ lspci -nn 00:00.0 RAM memory [0500]: nVidia Corporation MCP61 Memory Controller [10de:03ea] (rev a1) 00:01.0 ISA bridge [0601]: nVidia Corporation MCP61 LPC Bridge [10de:03e0] (rev a2) 00:01.1 SMBus [0c05]: nVidia Corporation MCP61 SMBus [10de:03eb] (rev a2) 00:01.2 RAM memory [0500]: nVidia Corporation MCP61 Memory Controller [10de:03f5] (rev a2) 00:02.0 USB Controller [0c03]: nVidia Corporation MCP61 USB Controller [10de:03f1] (rev a3) 00:02.1 USB Controller [0c03]: nVidia Corporation MCP61 USB Controller [10de:03f2] (rev a3) 00:04.0 PCI bridge [0604]: nVidia Corporation MCP61 PCI bridge [10de:03f3] (rev a1) 00:05.0 Audio device [0403]: nVidia Corporation MCP61 High Definition Audio [10de:03f0] (rev a2) 00:06.0 IDE interface [0101]: nVidia Corporation MCP61 IDE [10de:03ec] (rev a2) 00:07.0 Bridge [0680]: nVidia Corporation MCP61 Ethernet [10de:03ef] (rev a2) 00:08.0 IDE interface [0101]: nVidia Corporation MCP61 SATA Controller [10de:03f6] (rev a2) 00:09.0 PCI bridge [0604]: nVidia Corporation MCP61 PCI Express bridge [10de:03e8] (rev a2) 00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100] 00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map [1022:1101] 00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller [1022:1102] 00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control [1022:1103] 01:07.0 Multimedia video controller [0400]: Brooktree Corporation Bt878 Video Capture [109e:036e] (rev 11) 01:07.1 Multimedia controller [0480]: Brooktree Corporation Bt878 Audio Capture [109e:0878] (rev 11) 02:00.0 VGA compatible controller [0300]: nVidia Corporation NV44 [GeForce 7100 GS] [10de:016a] (rev a1) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From didier.spaier at epsm.fr Wed Mar 9 11:02:40 2011 From: didier.spaier at epsm.fr (Didier Spaier) Date: Wed, 09 Mar 2011 20:02:40 +0100 Subject: [Bug 35157] New: Black Screen while booting In-Reply-To: <bug-35157-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> References: <bug-35157-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> Message-ID: <4D77CED0.1050402@xxxxxxx> Le 09/03/2011 19:50, bugzilla-daemon at freedesktop.org a ?crit : > https://bugs.freedesktop.org/show_bug.cgi?id=35157 > > Summary: Black Screen while booting > Product: xorg > Version: unspecified > Platform: x86-64 (AMD64) > OS/Version: Linux (All) > Status: NEW > Severity: normal > Priority: medium > Component: Driver/nouveau > AssignedTo: nouveau at lists.freedesktop.org > ReportedBy: limaunion at gmail.com > QAContact: xorg-team at lists.x.org > > > Hi! I'm getting a black screen _inmediately_after_booting_ the Linux kernel, > being unable to access any tty console nor X11 (of course ssh is ok). > Then, how do you get this Xorg.0.log ? > I'm running a self-compiled kernel from vanilla (2.6.37.2) and am trying to > switch from the NVIDIA propietary driver to nouveau. > > I've followed the following instructions in order to enable the required kernel > settings: > http://en.gentoo-wiki.com/wiki/Nouveau (the real distro I'm using is Debian > testing) > I'd suggest looking first at the nouveau wiki, especially this page: http://nouveau.freedesktop.org/wiki/TroubleShooting > I'm not sure if this is a bug or not but let me know any other information > required. > Thanks in advance. > > > $ cat dmesg | egrep -i '(nouveau|drm)' > [ 0.000000] Linux version 2.6.37.2.nouveau (limaunion at debian1) (gcc version > 4.4.5 (Debian 4.4.5-12) ) #7 SMP Fri Mar 4 22:35:28 2011 > [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.37.2.nouveau > root=/dev/sda1 ro vga=775 > [ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.37.2.nouveau > root=/dev/sda1 ro vga=775 > [ 3.633513] [drm] Initialized drm 1.1.0 20060810 > [ 3.808087] usb usb1: Manufacturer: Linux 2.6.37.2.nouveau ehci_hcd > [ 3.921663] nouveau 0000:02:00.0: PCI INT A -> Link[APC8] -> GSI 16 (level, > low) -> IRQ 16 > [ 3.921671] nouveau 0000:02:00.0: setting latency timer to 64 > [ 3.924642] [drm] nouveau 0000:02:00.0: Detected an NV40 generation card > (0x044a00a2) > [ 3.925947] [drm] nouveau 0000:02:00.0: Attempting to load BIOS image from > PRAMIN > [ 4.005997] [drm] nouveau 0000:02:00.0: ... appears to be valid > [ 4.006014] [drm] nouveau 0000:02:00.0: BIT BIOS found > [ 4.006019] [drm] nouveau 0000:02:00.0: Bios version 05.44.02.67 > [ 4.006024] [drm] nouveau 0000:02:00.0: TMDS table version 1.1 > [ 4.006028] [drm] nouveau 0000:02:00.0: BIT table 'd' not found > [ 4.006033] [drm] nouveau 0000:02:00.0: Found Display Configuration Block > version 3.0 > [ 4.006039] [drm] nouveau 0000:02:00.0: Raw DCB entry 0: 01000300 00000028 > [ 4.006044] [drm] nouveau 0000:02:00.0: Raw DCB entry 1: 02011310 00000028 > [ 4.006048] [drm] nouveau 0000:02:00.0: Raw DCB entry 2: 01011312 00000000 > [ 4.006052] [drm] nouveau 0000:02:00.0: Raw DCB entry 3: 020223f1 00c0c080 > [ 4.006058] [drm] nouveau 0000:02:00.0: DCB connector table: VHER 0x30 5 7 2 > [ 4.006063] [drm] nouveau 0000:02:00.0: 0: 0x00000000: type 0x00 idx 0 tag > 0xff > [ 4.006068] [drm] nouveau 0000:02:00.0: 1: 0x00002130: type 0x30 idx 1 tag > 0x08 > [ 4.006073] [drm] nouveau 0000:02:00.0: 2: 0x00000210: type 0x10 idx 2 tag > 0xff > [ 4.006078] [drm] nouveau 0000:02:00.0: 3: 0x00000211: type 0x11 idx 3 tag > 0xff > [ 4.006083] [drm] nouveau 0000:02:00.0: 4: 0x00000213: type 0x13 idx 4 tag > 0xff > [ 4.006093] [drm] nouveau 0000:02:00.0: Parsing VBIOS init table 0 at offset > 0xDCEA > [ 4.006477] [drm] nouveau 0000:02:00.0: Parsing VBIOS init table 1 at offset > 0xE04F > [ 4.026225] [drm] nouveau 0000:02:00.0: Parsing VBIOS init table 2 at offset > 0xE589 > [ 4.026243] [drm] nouveau 0000:02:00.0: Parsing VBIOS init table 3 at offset > 0xE6DE > [ 4.028135] [drm] nouveau 0000:02:00.0: Parsing VBIOS init table 4 at offset > 0xE888 > [ 4.047489] [drm] nouveau 0000:02:00.0: mem timing table length unknown: 14 > [ 4.047495] [drm] nouveau 0000:02:00.0: 1 available performance level(s) > [ 4.047501] [drm] nouveau 0000:02:00.0: 0: memory 532MHz core 350MHz > fanspeed 100% > [ 4.047512] [drm] nouveau 0000:02:00.0: c: memory 401MHz core 200MHz > [ 4.047520] [drm] nouveau 0000:02:00.0: Detected 256MiB VRAM > [ 4.049196] [drm] nouveau 0000:02:00.0: 64 MiB GART (aperture) > [ 4.051165] [drm] nouveau 0000:02:00.0: Allocating FIFO number 0 > [ 4.051564] [drm] nouveau 0000:02:00.0: nouveau_channel_alloc: initialised > FIFO 0 > [ 4.051576] [drm] nouveau 0000:02:00.0: Setting dpms mode 3 on vga encoder > (output 0) > [ 4.051582] [drm] nouveau 0000:02:00.0: Setting dpms mode 3 on vga encoder > (output 1) > [ 4.051587] [drm] nouveau 0000:02:00.0: Setting dpms mode 3 on tmds encoder > (output 2) > [ 4.051593] [drm] nouveau 0000:02:00.0: Setting dpms mode 3 on TV encoder > (output 3) > [ 4.208627] [drm] nouveau 0000:02:00.0: allocated 1680x1050 fb: 0x49000, bo > ffff88007ae81c00 > [ 4.208694] fb0: nouveaufb frame buffer device > [ 4.208698] drm: registered panic notifier > [ 4.208705] [drm] Initialized nouveau 0.0.16 20090420 for 0000:02:00.0 on > minor 0 > [ 4.488065] usb usb2: Manufacturer: Linux 2.6.37.2.nouveau ohci_hcd > > > $ cat lsmod.out.txt | egrep '(drm|nouveau)' > nouveau 464294 0 > ttm 42177 1 nouveau > drm_kms_helper 21691 1 nouveau > drm 141427 3 nouveau,ttm,drm_kms_helper > fb 30953 2 nouveau,drm_kms_helper > cfbcopyarea 2857 1 nouveau > i2c_algo_bit 4103 2 nouveau,bttv > cfbimgblt 1897 1 nouveau > button 4522 1 nouveau > i2c_core 15872 20 > tuner,tea5767,tda8290,tda18271,tda827x,tda9887,tuner_simple,tea5761,tvaudio,tda7432,msp3400,nouveau,bttv,drm_kms_helper,v4l2_common,videodev,drm,i2c_algo_bit,tveeprom,i2c_nforce2 > cfbfillrect 2917 1 nouveau > > > $ cat Xorg.0.log > X.Org X Server 1.7.7 > Release Date: 2010-05-04 > X Protocol Version 11, Revision 0 > Build Operating System: Linux 2.6.32-5-amd64 x86_64 Debian > Current Operating System: Linux debian1 2.6.37.2.nouveau #7 SMP Fri Mar 4 > 22:35:28 ART 2011 x86_64 > Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.37.2.nouveau root=/dev/sda1 > ro vga=775 > Build Date: 12 January 2011 02:59:50AM > xorg-server 2:1.7.7-11 (Cyril Brulebois<kibi at debian.org>) > Current version of pixman: 0.16.4 > Before reporting problems, check http://wiki.x.org > to make sure that you have the latest version. > Markers: (--) probed, (**) from config file, (==) default setting, > (++) from command line, (!!) notice, (II) informational, > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > (==) Log file: "/var/log/Xorg.0.log", Time: Fri Mar 4 22:37:43 2011 > (==) Using config file: "/etc/X11/xorg.conf" > (==) Using system config directory "/usr/share/X11/xorg.conf.d" > (==) No Layout section. Using the first Screen section. > (==) No screen section available. Using defaults. > (**) |-->Screen "Default Screen Section" (0) > (**) | |-->Monitor "<default monitor>" > (==) No device specified for screen "Default Screen Section". > Using the first device section listed. > (**) | |-->Device "devname" > (==) No monitor specified for screen "Default Screen Section". > Using a default monitor configuration. > (==) Automatically adding devices > (==) Automatically enabling devices > (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. > Entry deleted from font path. > (==) FontPath set to: > /usr/share/fonts/X11/misc, > /usr/share/fonts/X11/100dpi/:unscaled, > /usr/share/fonts/X11/75dpi/:unscaled, > /usr/share/fonts/X11/Type1, > /usr/share/fonts/X11/100dpi, > /usr/share/fonts/X11/75dpi, > /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, > built-ins > (==) ModulePath set to "/usr/lib/xorg/modules" > (==) |-->Input Device "Generic Keyboard" > (==) No Layout section. Using the first core keyboard device. > (II) The server relies on udev to provide the list of input devices. > If no devices become available, reconfigure udev or disable > AutoAddDevices. > (WW) AllowEmptyInput is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' > will be disabled. > (WW) Disabling Generic Keyboard > (II) Loader magic: 0x7c8a00 > (II) Module ABI versions: > X.Org ANSI C Emulation: 0.4 > X.Org Video Driver: 6.0 > X.Org XInput driver : 7.0 > X.Org Server Extension : 2.0 > (++) using VT number 7 > (--) PCI: (0:1:7:0) 109e:036e:0000:0000 Brooktree Corporation Bt878 Video > Capture rev 17, Mem @ 0xfdfff000/4096 > (--) PCI:*(0:2:0:0) 10de:016a:1682:2234 nVidia Corporation NV44 [GeForce 7100 > GS] rev 161, Mem @ 0xfa000000/16777216, 0xd0000000/268435456, > 0xfb000000/16777216, BIOS @ 0x????????/131072 > (II) Open ACPI successful (/var/run/acpid.socket) > (II) LoadModule: "extmod" > (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so > (II) Module extmod: vendor="X.Org Foundation" > compiled for 1.7.7, module version = 1.0.0 > Module class: X.Org Server Extension > ABI class: X.Org Server Extension, version 2.0 > (II) Loading extension SELinux > (II) Loading extension MIT-SCREEN-SAVER > (II) Loading extension XFree86-VidModeExtension > (II) Loading extension XFree86-DGA > (II) Loading extension DPMS > (II) Loading extension XVideo > (II) Loading extension XVideo-MotionCompensation > (II) Loading extension X-Resource > (II) LoadModule: "dbe" > (II) Loading /usr/lib/xorg/modules/extensions/libdbe.so > (II) Module dbe: vendor="X.Org Foundation" > compiled for 1.7.7, module version = 1.0.0 > Module class: X.Org Server Extension > ABI class: X.Org Server Extension, version 2.0 > (II) Loading extension DOUBLE-BUFFER > (II) LoadModule: "glx" > (II) Loading /usr/lib/xorg/modules/extensions/libglx.so > (II) Module glx: vendor="NVIDIA Corporation" > compiled for 4.0.2, module version = 1.0.0 > Module class: X.Org Server Extension > (II) NVIDIA GLX Module 260.19.36 Tue Jan 18 17:12:12 PST 2011 > (II) Loading extension GLX > (II) LoadModule: "record" > (II) Loading /usr/lib/xorg/modules/extensions/librecord.so > (II) Module record: vendor="X.Org Foundation" > compiled for 1.7.7, module version = 1.13.0 > Module class: X.Org Server Extension > ABI class: X.Org Server Extension, version 2.0 > (II) Loading extension RECORD > (II) LoadModule: "dri" > (II) Loading /usr/lib/xorg/modules/extensions/libdri.so > (II) Module dri: vendor="X.Org Foundation" > compiled for 1.7.7, module version = 1.0.0 > ABI class: X.Org Server Extension, version 2.0 > (II) Loading extension XFree86-DRI > (II) LoadModule: "dri2" > (II) Loading /usr/lib/xorg/modules/extensions/libdri2.so > (II) Module dri2: vendor="X.Org Foundation" > compiled for 1.7.7, module version = 1.1.0 > ABI class: X.Org Server Extension, version 2.0 > (II) Loading extension DRI2 > (II) LoadModule: "nouveau" > (II) Loading /usr/lib/xorg/modules/drivers/nouveau_drv.so > (II) Module nouveau: vendor="X.Org Foundation" > compiled for 1.7.7, module version = 0.0.15 > Module class: X.Org Video Driver > ABI class: X.Org Video Driver, version 6.0 > (II) NOUVEAU driver Date: Tue Mar 16 13:08:37 2010 +1000 > (II) NOUVEAU driver for NVIDIA chipset families : > RIVA TNT (NV04) > RIVA TNT2 (NV05) > GeForce 256 (NV10) > GeForce 2 (NV11, NV15) > GeForce 4MX (NV17, NV18) > GeForce 3 (NV20) > GeForce 4Ti (NV25, NV28) > GeForce FX (NV3x) > GeForce 6 (NV4x) > GeForce 7 (G7x) > GeForce 8 (G8x) > (II) Primary Device is: PCI 02 at 00:00:0 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 8, (OK) > drmOpenByBusid: Searching for BusID pci:0000:02:00.0 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 8, (OK) > drmOpenByBusid: drmOpenMinor returns 8 > drmOpenByBusid: drmGetBusid reports pci:0000:02:00.0 > (EE) [drm] failed to open device > (EE) No devices detected. > > Fatal server error: > no screens found > I am not a developer but sometimes had to upgrade libdrm (or get it from git) to avoid this. > Please consult the The X.Org Foundation support > at http://wiki.x.org > for help. > Please also check the log file at "/var/log/Xorg.0.log" for additional > information. > > $ lspci -nn > 00:00.0 RAM memory [0500]: nVidia Corporation MCP61 Memory Controller > [10de:03ea] (rev a1) > 00:01.0 ISA bridge [0601]: nVidia Corporation MCP61 LPC Bridge [10de:03e0] (rev > a2) > 00:01.1 SMBus [0c05]: nVidia Corporation MCP61 SMBus [10de:03eb] (rev a2) > 00:01.2 RAM memory [0500]: nVidia Corporation MCP61 Memory Controller > [10de:03f5] (rev a2) > 00:02.0 USB Controller [0c03]: nVidia Corporation MCP61 USB Controller > [10de:03f1] (rev a3) > 00:02.1 USB Controller [0c03]: nVidia Corporation MCP61 USB Controller > [10de:03f2] (rev a3) > 00:04.0 PCI bridge [0604]: nVidia Corporation MCP61 PCI bridge [10de:03f3] (rev > a1) > 00:05.0 Audio device [0403]: nVidia Corporation MCP61 High Definition Audio > [10de:03f0] (rev a2) > 00:06.0 IDE interface [0101]: nVidia Corporation MCP61 IDE [10de:03ec] (rev a2) > 00:07.0 Bridge [0680]: nVidia Corporation MCP61 Ethernet [10de:03ef] (rev a2) > 00:08.0 IDE interface [0101]: nVidia Corporation MCP61 SATA Controller > [10de:03f6] (rev a2) > 00:09.0 PCI bridge [0604]: nVidia Corporation MCP61 PCI Express bridge > [10de:03e8] (rev a2) > 00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > HyperTransport Technology Configuration [1022:1100] > 00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > Address Map [1022:1101] > 00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > DRAM Controller [1022:1102] > 00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > Miscellaneous Control [1022:1103] > 01:07.0 Multimedia video controller [0400]: Brooktree Corporation Bt878 Video > Capture [109e:036e] (rev 11) > 01:07.1 Multimedia controller [0480]: Brooktree Corporation Bt878 Audio Capture > [109e:0878] (rev 11) > 02:00.0 VGA compatible controller [0300]: nVidia Corporation NV44 [GeForce 7100 > GS] [10de:016a] (rev a1) > From Nikolaus at rath.org Wed Mar 9 11:18:27 2011 From: Nikolaus at rath.org (Nikolaus Rath) Date: Wed, 09 Mar 2011 14:18:27 -0500 Subject: Getting bus address of GPU memory Message-ID: <8739mwcdbw.fsf@xxxxxxxxxxxxxxxxxxxxxxxx> Hello, This isn't directly nouveau related, but since I was welcome on the IRC channel I assume that I may post my question on the ML as well. We are trying to use an NVidia Tesla card for highly parallel real time computations. Our problem is to get the data from a custom PCIe device into the GPU fast enough (and back). We need to transfer ~200 bytes every ~10us, so the limiting factor is latency rather than bandwidth. So far, we have transferred the data via the host RAM, but I am trying to find a way to do direct peer-to-peer DMA transfer. The Tesla card supports peer-to-peer transfers to other GPUs, so in principle this should be possible. My idea (but I'm happy to hear others as well) is to determine the bus address of some GPU memory location, and then let the other PCIe card push and pull the data as needed. However, I am not sure how to determine the bus address. A brute force method would be to write a marker string somewhere into GPU memory and then search through all PCIe BARs. However, there is a chance that the marker string does not end up in the mapped memory area. I'm currently trying to figure that out by searching through the BARs with the CPU (see other posting). In case that fails: does anyone have a suggestion how else we might accomplish what we want? Is there a way to change the mapping from BARs to GPU memory? Could one of the nouveau debugging tools be used to figure out how the nvidia driver does the GPU-to-GPU transfer and tap of the bus address? Hackish solutions are quite welcome, we are already working with a patched kernel anyway to share the pinned host memory between drivers. Best, -Nikolaus -- ?Time flies like an arrow, fruit flies like a Banana.? PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C From emil.velikov at yahoo.co.uk Wed Mar 9 11:27:27 2011 From: emil.velikov at yahoo.co.uk (Emil Velikov) Date: Wed, 09 Mar 2011 19:27:27 -0000 Subject: Problem setting refresh rate on 8400GS In-Reply-To: <AANLkTinVNbeYDo_g=4EYVt0BJ=4Cf6SJ02dPmUvw860w@xxxxxxxxxxxxxx> References: <AANLkTinVNbeYDo_g=4EYVt0BJ=4Cf6SJ02dPmUvw860w@xxxxxxxxxxxxxx> Message-ID: <op.vr3cb0lntkuz1w@emo> Hi Donald, See the comments inline On Wed, 09 Mar 2011 05:38:55 -0000, Donald Jenkins <dj.jankins at gmail.com> wrote: > Hello. > Having serious problems with all nvidia boards plugged on my PC, now on > 8400GS. > Xorg with 2D-only nouveau driver sets invalid preferred refresh rate > 60hz on > SAMTRON 73v, when 75hz needed. How old is this monitor ? Did it work correctly using the blob/earlier nouveau ? > output of xrandr: > > Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 8192 x 8192 > DVI-I-1 disconnected (normal left inverted right x axis y axis) > VGA-1 connected 1280x1024+0+0 (normal left inverted right x axis y axis) > 338mm x 270mm > 1280x1024 60.0*+ 75.0 > 1152x864 75.0 > 1024x768 75.1 70.1 60.0 > 832x624 74.6 > 800x600 72.2 75.0 60.3 56.2 > 640x480 72.8 75.0 66.7 60.0 > 720x400 70.1 > > I can *manually* set correct refresh rate using xrandr -r 75 command (for > example, in .xinitrc), but Xorg configuration don't recognize it at all. > Some full screen software games reset refresh rate back to 60hz. > How I can "hardcode" it in xorg.conf? I really stuck at this point. You can find how to "hardcode" the timings/refresh rate, by googling for "xorg modeline". Note 1: The refresh rate change will take place AFTER Xorg is up (i.e. currently there is not way to set it at boot time). Note 2: The generated values may or may not work. What you can try is startup "Xorg --verbose 9" using the blob and it should print the refresh rate/timings used. Then you can add it to xorg.conf > Thanks. P.S. Apologies for any typos Cheers From bugzilla-daemon at freedesktop.org Wed Mar 9 12:06:19 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Wed, 9 Mar 2011 12:06:19 -0800 (PST) Subject: [Bug 35135] oops on rmmod nouveau with NV46 In-Reply-To: <bug-35135-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> References: <bug-35135-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> Message-ID: <20110309200619.38C0013000C@xxxxxxxxxxxxxxxxxxxxxxxx> https://bugs.freedesktop.org/show_bug.cgi?id=35135 --- Comment #1 from Marcin Slusarz <marcin.slusarz at gmail.com> 2011-03-09 12:06:18 PST --- Created an attachment (id=44277) View: https://bugs.freedesktop.org/attachment.cgi?id=44277 Review: https://bugs.freedesktop.org/review?bug=35135&attachment=44277 fix Can you test attached patch? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From Nikolaus at rath.org Wed Mar 9 10:54:55 2011 From: Nikolaus at rath.org (Nikolaus Rath) Date: Wed, 09 Mar 2011 13:54:55 -0500 Subject: How to directly access GPU memory Message-ID: <87bp1kcef4.fsf@xxxxxxxxxxxxxxxxxxxxxxxx> Hello, I would like to directly access some GPU memory. Is there some standard way to do this when using the nouveau driver, e.g. by mmap'ing a specific range of /dev/something, or do I have to write my own kernel module to set up the mapping of the PCIe BARs? If there is a standard way, is that only standard for the nouveau driver or will the same procedure work for other drivers too (in particular the proprietary nvidia driver)? Thanks, -Nikolaus -- ?Time flies like an arrow, fruit flies like a Banana.? PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C From bugzilla-daemon at freedesktop.org Wed Mar 9 19:59:07 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Wed, 9 Mar 2011 19:59:07 -0800 (PST) Subject: [Bug 34220] Detects Load on output and blinks screen every ~30secs In-Reply-To: <bug-34220-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> References: <bug-34220-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> Message-ID: <20110310035907.C791E13004F@xxxxxxxxxxxxxxxxxxxxxxxx> https://bugs.freedesktop.org/show_bug.cgi?id=34220 Gy?rgy Ball? <ballogy at freestart.hu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ballogy at freestart.hu --- Comment #1 from Gy?rgy Ball? <ballogy at freestart.hu> 2011-03-09 19:59:07 PST --- Same here, the screen randomly blinks out in every 30/60/90th? seconds. (I also use Arch Linux) My video card: 01:00.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 MX 440] (rev a3) The error message on each blink from everything.log: kernel: [drm] nouveau 0000:01:00.0: DDC responded, but no EDID for VGA-1 kernel: [drm] nouveau 0000:01:00.0: Load detected on output A Package versions: kernel26 2.6.37.3-1 libdrm 2.4.23-2 xf86-video-nouveau 0.0.16_git20101217-1 xorg-server 1.9.4-1 libgl 7.10.1-1 mesa 7.10.1-1 I reported this bug on Arch Linux bugtracker also: https://bugs.archlinux.org/task/23213 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at freedesktop.org Thu Mar 10 01:24:58 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Thu, 10 Mar 2011 01:24:58 -0800 (PST) Subject: [Bug 35135] oops on rmmod nouveau with NV46 In-Reply-To: <bug-35135-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> References: <bug-35135-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> Message-ID: <20110310092458.5655413000C@xxxxxxxxxxxxxxxxxxxxxxxx> https://bugs.freedesktop.org/show_bug.cgi?id=35135 --- Comment #2 from Francesco Marella <francesco.marella at gmail.com> 2011-03-10 01:24:58 PST --- Marcin, I've tested your patch and it fixes the oops, Thank you. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at freedesktop.org Thu Mar 10 05:03:37 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Thu, 10 Mar 2011 05:03:37 -0800 (PST) Subject: [Bug 35172] New: Nouveau crashes my gnome session Message-ID: <bug-35172-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> https://bugs.freedesktop.org/show_bug.cgi?id=35172 Summary: Nouveau crashes my gnome session Product: xorg Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org ReportedBy: lcid-fire at gmx.net QAContact: xorg-team at lists.x.org It seems like nouveau frequently manages to segfault and takes my whole gnome session with it. Takes me right back into gdm. Attached is a file which contains the syslog messages that occur. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at freedesktop.org Thu Mar 10 09:30:35 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Thu, 10 Mar 2011 09:30:35 -0800 (PST) Subject: [Bug 35172] Nouveau crashes my gnome session In-Reply-To: <bug-35172-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> References: <bug-35172-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> Message-ID: <20110310173036.1163413004E@xxxxxxxxxxxxxxxxxxxxxxxx> https://bugs.freedesktop.org/show_bug.cgi?id=35172 --- Comment #1 from Lucas Stach <dev at lynxeye.de> 2011-03-10 09:30:34 PST --- There is no attachment. Please add, so we can see what's going on. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at freedesktop.org Thu Mar 10 09:31:59 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Thu, 10 Mar 2011 09:31:59 -0800 (PST) Subject: [Bug 35172] Nouveau crashes my gnome session In-Reply-To: <bug-35172-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> References: <bug-35172-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> Message-ID: <20110310173159.44EAB13004E@xxxxxxxxxxxxxxxxxxxxxxxx> https://bugs.freedesktop.org/show_bug.cgi?id=35172 --- Comment #2 from LCID Fire <lcid-fire at gmx.net> 2011-03-10 09:31:59 PST --- Created an attachment (id=44306) --> (https://bugs.freedesktop.org/attachment.cgi?id=44306) Syslog output -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at freedesktop.org Thu Mar 10 09:42:30 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Thu, 10 Mar 2011 09:42:30 -0800 (PST) Subject: [Bug 35172] Nouveau crashes my gnome session In-Reply-To: <bug-35172-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> References: <bug-35172-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> Message-ID: <20110310174230.2E79D13004F@xxxxxxxxxxxxxxxxxxxxxxxx> https://bugs.freedesktop.org/show_bug.cgi?id=35172 --- Comment #3 from Lucas Stach <dev at lynxeye.de> 2011-03-10 09:42:29 PST --- You are using the 3D driver. We do not accept bugs for this, yet. If you are using distro packages please report in the appropiate bugtracker. If you are using a self compiled version try building with debug flags and see if you can figure out where it breaks. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From linux at horizon.com Wed Mar 9 12:06:56 2011 From: linux at horizon.com (George Spelvin) Date: 9 Mar 2011 15:06:56 -0500 Subject: nouveaufb problems with NV18 Message-ID: <20110309200656.23070.qmail@xxxxxxxxxxxxxxxxxxx> I have an NV18 (GeForce4 MX) connected via DVI to a 1920x1080 LCD, and when I try to use the nouveau kernel driver, I get a crappy display. Thanks in advance to anyone who can help. I'm running a recent nouveau git (fa17f241 drm/nv50: fix thinko in vm fault) merged with 2.6.38-rc8. When the driver loads (it's compiled as a module, so this is after init starts), the console shrinks to a 36x90 character box in the upper-left corner of the display. When the system is busy, the screen "flashes" to the right. The console text appears half a screen to the right for a moment. It's particularly annoying right after boot, but settles down once the system goes quescent. The problem is NOT associated with screen updates. I can run "yes" and see the problem very little. hdparm -tT, however, makes the screen almost unusable during *both* phases. Watching during heavy activity, there's a "standard position" to the right where the text tends to appear, but there's also lots of "tearing" and it appears in multiple positions. Still pretty recognizable as text, though; it doesn't seem to change every scanline. X is also screwed up; it fails to start with the messages: [ 214.714] (II) NOUVEAU(0): Opened GPU channel 1 [ 214.715] (II) NOUVEAU(0): [DRI2] Setup complete [ 214.715] (II) NOUVEAU(0): [DRI2] DRI driver: nouveau_vieux [ 214.716] (EE) NOUVEAU(0): Error allocating scanout buffer: 0 [ 214.716] Fatal server error: [ 214.716] AddScreen/ScreenInit failed for driver 0 ... but I figure that's a more advanced problem. I've tried and been unhappy with the nouveau driver on this system in the past (I remember it coming up but having lots of horizontal lines of "snow" on the display), but Debian recently removed the nv driver that worked fine for me from its X distribution, so I'm trying again a bit harder this time. It's a 2 GB Athlon system, small form factor with onboard video. lspci -nn gives: 00:00.0 Host bridge [0600]: nVidia Corporation nForce2 IGP2 [10de:01e0] (rev a2) 00:00.1 RAM memory [0500]: nVidia Corporation nForce2 Memory Controller 1 [10de:01eb] (rev a2) 00:00.2 RAM memory [0500]: nVidia Corporation nForce2 Memory Controller 4 [10de:01ee] (rev a2) 00:00.3 RAM memory [0500]: nVidia Corporation nForce2 Memory Controller 3 [10de:01ed] (rev a2) 00:00.4 RAM memory [0500]: nVidia Corporation nForce2 Memory Controller 2 [10de:01ec] (rev a2) 00:00.5 RAM memory [0500]: nVidia Corporation nForce2 Memory Controller 5 [10de:01ef] (rev a2) 00:01.0 ISA bridge [0601]: nVidia Corporation nForce2 ISA Bridge [10de:0060] (rev a3) 00:01.1 SMBus [0c05]: nVidia Corporation nForce2 SMBus (MCP) [10de:0064] (rev a2) 00:02.0 USB Controller [0c03]: nVidia Corporation nForce2 USB Controller [10de:0067] (rev a3) 00:02.1 USB Controller [0c03]: nVidia Corporation nForce2 USB Controller [10de:0067] (rev a3) 00:02.2 USB Controller [0c03]: nVidia Corporation nForce2 USB Controller [10de:0068] (rev a3) 00:04.0 Ethernet controller [0200]: nVidia Corporation nForce2 Ethernet Controller [10de:0066] (rev a1) 00:05.0 Multimedia audio controller [0401]: nVidia Corporation nForce Audio Processing Unit [10de:006b] (rev a2) 00:06.0 Multimedia audio controller [0401]: nVidia Corporation nForce2 AC97 Audio Controler (MCP) [10de:006a] (rev a1) 00:08.0 PCI bridge [0604]: nVidia Corporation nForce2 External PCI Bridge [10de:006c] (rev a3) 00:09.0 IDE interface [0101]: nVidia Corporation nForce2 IDE [10de:0065] (rev a2) 00:0d.0 FireWire (IEEE 1394) [0c00]: nVidia Corporation nForce2 FireWire (IEEE 1394) Controller [10de:006e] (rev a3) 00:1e.0 PCI bridge [0604]: nVidia Corporation nForce2 AGP [10de:01e8] (rev a2) 01:06.0 CardBus bridge [0607]: Ricoh Co Ltd RL5c476 II [1180:0476] (rev 80) 01:06.1 CardBus bridge [0607]: Ricoh Co Ltd RL5c476 II [1180:0476] (rev 80) 04:00.0 VGA compatible controller [0300]: nVidia Corporation NV18 [GeForce4 MX - nForce GPU] [10de:01f0] (rev a3) Here's the full dmesg output, as requested. [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 2.6.38-rc8+ ($USER@$HOST) (gcc version 4.5.2 (Debian 4.5.2-5) ) #22 Tue Mar 8 21:47:31 EST 2011 [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: 0000000000000000 - 00000000000a0000 (usable) [ 0.000000] BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 000000007dff0000 (usable) [ 0.000000] BIOS-e820: 000000007dff0000 - 000000007dff3000 (ACPI NVS) [ 0.000000] BIOS-e820: 000000007dff3000 - 000000007e000000 (ACPI data) [ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved) [ 0.000000] Notice: NX (Execute Disable) protection missing in CPU! [ 0.000000] DMI 2.2 present. [ 0.000000] DMI: /FN41 , BIOS 6.00 PG 08/23/2004 [ 0.000000] e820 update range: 0000000000000000 - 0000000000001000 (usable) ==> (reserved) [ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable) [ 0.000000] last_pfn = 0x7dff0 max_arch_pfn = 0x100000 [ 0.000000] MTRR default type: uncachable [ 0.000000] MTRR fixed ranges enabled: [ 0.000000] 00000-9FFFF write-back [ 0.000000] A0000-AFFFF uncachable [ 0.000000] B0000-BFFFF write-combining [ 0.000000] C0000-C7FFF write-protect [ 0.000000] C8000-FFFFF uncachable [ 0.000000] MTRR variable ranges enabled: [ 0.000000] 0 base 000000000 mask F80000000 write-back [ 0.000000] 1 base 07E000000 mask FFE000000 uncachable [ 0.000000] 2 base 0E0000000 mask FFC000000 write-combining [ 0.000000] 3 disabled [ 0.000000] 4 disabled [ 0.000000] 5 disabled [ 0.000000] 6 disabled [ 0.000000] 7 disabled [ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [ 0.000000] Scanning 1 areas for low memory corruption [ 0.000000] initial memory mapped : 0 - 01800000 [ 0.000000] init_memory_mapping: 0000000000000000-00000000377fe000 [ 0.000000] 0000000000 - 0000400000 page 4k [ 0.000000] 0000400000 - 0037400000 page 2M [ 0.000000] 0037400000 - 00377fe000 page 4k [ 0.000000] kernel direct mapping tables up to 377fe000 @ 17fb000-1800000 [ 0.000000] ACPI: RSDP 000f6e60 00014 (v00 Nvidia) [ 0.000000] ACPI: RSDT 7dff3000 0002C (v01 Nvidia AWRDACPI 42302E31 AWRD 00000000) [ 0.000000] ACPI: FACP 7dff3040 00074 (v01 Nvidia AWRDACPI 42302E31 AWRD 00000000) [ 0.000000] ACPI: DSDT 7dff30c0 04139 (v01 NVIDIA AWRDACPI 00001000 MSFT 0100000D) [ 0.000000] ACPI: FACS 7dff0000 00040 [ 0.000000] ACPI: APIC 7dff7200 0005A (v01 Nvidia AWRDACPI 42302E31 AWRD 00000000) [ 0.000000] 1127MB HIGHMEM available. [ 0.000000] 887MB LOWMEM available. [ 0.000000] mapped low ram: 0 - 377fe000 [ 0.000000] low ram: 0 - 377fe000 [ 0.000000] Zone PFN ranges: [ 0.000000] DMA 0x00000001 -> 0x00001000 [ 0.000000] Normal 0x00001000 -> 0x000377fe [ 0.000000] HighMem 0x000377fe -> 0x0007dff0 [ 0.000000] Movable zone start PFN for each node [ 0.000000] early_node_map[2] active PFN ranges [ 0.000000] 0: 0x00000001 -> 0x000000a0 [ 0.000000] 0: 0x00000100 -> 0x0007dff0 [ 0.000000] On node 0 totalpages: 515983 [ 0.000000] free_area_init_node: node 0, pgdat c13805c8, node_mem_map f683d020 [ 0.000000] DMA zone: 32 pages used for memmap [ 0.000000] DMA zone: 0 pages reserved [ 0.000000] DMA zone: 3967 pages, LIFO batch:0 [ 0.000000] Normal zone: 1744 pages used for memmap [ 0.000000] Normal zone: 221486 pages, LIFO batch:31 [ 0.000000] HighMem zone: 2256 pages used for memmap [ 0.000000] HighMem zone: 286498 pages, LIFO batch:31 [ 0.000000] ACPI: PM-Timer IO Port: 0x4008 [ 0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000f0000 [ 0.000000] PM: Registered nosave memory: 00000000000f0000 - 0000000000100000 [ 0.000000] Allocating PCI resources starting at 7e000000 (gap: 7e000000:80c00000) [ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [ 0.000000] pcpu-alloc: [0] 0 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 511951 [ 0.000000] Kernel command line: auto BOOT_IMAGE=2.6 ro root=302 [ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes) [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [ 0.000000] Initializing CPU#0 [ 0.000000] Initializing HighMem for node 0 (000377fe:0007dff0) [ 0.000000] Memory: 2042708k/2064320k available (2373k kernel code, 21224k reserved, 1230k data, 276k init, 1155016k highmem) [ 0.000000] virtual kernel memory layout: [ 0.000000] fixmap : 0xfffe4000 - 0xfffff000 ( 108 kB) [ 0.000000] pkmap : 0xff800000 - 0xffc00000 (4096 kB) [ 0.000000] vmalloc : 0xf7ffe000 - 0xff7fe000 ( 120 MB) [ 0.000000] lowmem : 0xc0000000 - 0xf77fe000 ( 887 MB) [ 0.000000] .init : 0xc1385000 - 0xc13ca000 ( 276 kB) [ 0.000000] .data : 0xc12514bf - 0xc1384e40 (1230 kB) [ 0.000000] .text : 0xc1000000 - 0xc12514bf (2373 kB) [ 0.000000] Checking if this processor honours the WP bit even in supervisor mode...Ok. [ 0.000000] SLUB: Genslabs=15, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [ 0.000000] NR_IRQS:16 [ 0.000000] CPU 0 irqstacks, hard=f6008000 soft=f600a000 [ 0.000000] Console: colour VGA+ 80x50 [ 0.000000] console [tty0] enabled [ 0.000000] Fast TSC calibration using PIT [ 0.000000] Detected 1469.907 MHz processor. [ 0.006670] Calibrating delay loop (skipped), value calculated using timer frequency.. 2940.30 BogoMIPS (lpj=4899690) [ 0.006745] pid_max: default: 32768 minimum: 301 [ 0.006838] Mount-cache hash table entries: 512 [ 0.007058] Initializing cgroup subsys blkio [ 0.010034] mce: CPU supports 4 MCE banks [ 0.010087] CPU: AMD Athlon(tm) XP 1700+ stepping 02 [ 0.010275] ACPI: Core revision 20110112 [ 0.014177] ACPI: setting ELCR to 0200 (from 1c28) [ 0.015007] Performance Events: AMD PMU driver. [ 0.015067] ... version: 0 [ 0.015102] ... bit width: 48 [ 0.015137] ... generic registers: 4 [ 0.015172] ... value mask: 0000ffffffffffff [ 0.015208] ... max period: 00007fffffffffff [ 0.015245] ... fixed-purpose events: 0 [ 0.015279] ... event mask: 000000000000000f [ 0.015470] NMI watchdog enabled, takes one hw-pmu counter. [ 0.015959] xor: automatically using best checksumming function: pIII_sse [ 0.030004] pIII_sse : 4164.000 MB/sec [ 0.030040] xor: using function: pIII_sse (4164.000 MB/sec) [ 0.030127] NET: Registered protocol family 16 [ 0.030679] ACPI: bus type pci registered [ 0.066457] PCI: PCI BIOS revision 2.10 entry at 0xfb760, last bus=4 [ 0.066497] PCI: Using configuration type 1 for base access [ 0.072331] bio: create slab <bio-0> at 0 [ 0.126710] raid6: int32x1 514 MB/s [ 0.183333] raid6: int32x2 665 MB/s [ 0.240026] raid6: int32x4 496 MB/s [ 0.296792] raid6: int32x8 380 MB/s [ 0.353327] raid6: mmxx1 1243 MB/s [ 0.409983] raid6: mmxx2 2042 MB/s [ 0.466679] raid6: sse1x1 1151 MB/s [ 0.523334] raid6: sse1x2 1828 MB/s [ 0.523369] raid6: using algorithm sse1x2 (1828 MB/s) [ 0.525044] ACPI: EC: Look up EC in DSDT [ 0.529868] ACPI: Interpreter enabled [ 0.529910] ACPI: (supports S0 S1 S4 S5) [ 0.530068] ACPI: Using PIC for interrupt routing [ 0.541762] PCI: Ignoring host bridge windows from ACPI; if necessary, use "pci=use_crs" and report a bug [ 0.541933] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) [ 0.542209] pci_root PNP0A03:00: host bridge window [io 0x0000-0x0cf7] (ignored) [ 0.542215] pci_root PNP0A03:00: host bridge window [io 0x0d00-0xffff] (ignored) [ 0.542221] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff] (ignored) [ 0.542227] pci_root PNP0A03:00: host bridge window [mem 0x000c0000-0x000dffff] (ignored) [ 0.542232] pci_root PNP0A03:00: host bridge window [mem 0x7e000000-0xfebfffff] (ignored) [ 0.542253] pci 0000:00:00.0: [10de:01e0] type 0 class 0x000600 [ 0.542264] pci 0000:00:00.0: reg 10: [mem 0xe0000000-0xe3ffffff pref] [ 0.542312] pci 0000:00:00.1: [10de:01eb] type 0 class 0x000500 [ 0.542353] pci 0000:00:00.2: [10de:01ee] type 0 class 0x000500 [ 0.542394] pci 0000:00:00.3: [10de:01ed] type 0 class 0x000500 [ 0.542432] pci 0000:00:00.4: [10de:01ec] type 0 class 0x000500 [ 0.542473] pci 0000:00:00.5: [10de:01ef] type 0 class 0x000500 [ 0.542519] pci 0000:00:01.0: [10de:0060] type 0 class 0x000601 [ 0.542604] pci 0000:00:01.1: [10de:0064] type 0 class 0x000c05 [ 0.542621] pci 0000:00:01.1: reg 10: [io 0xc400-0xc41f] [ 0.542679] pci 0000:00:01.1: PME# supported from D3hot D3cold [ 0.542685] pci 0000:00:01.1: PME# disabled [ 0.542711] pci 0000:00:02.0: [10de:0067] type 0 class 0x000c03 [ 0.542727] pci 0000:00:02.0: reg 10: [mem 0xef080000-0xef080fff] [ 0.542784] pci 0000:00:02.0: supports D1 D2 [ 0.542788] pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot D3cold [ 0.542794] pci 0000:00:02.0: PME# disabled [ 0.542815] pci 0000:00:02.1: [10de:0067] type 0 class 0x000c03 [ 0.542831] pci 0000:00:02.1: reg 10: [mem 0xef083000-0xef083fff] [ 0.542888] pci 0000:00:02.1: supports D1 D2 [ 0.542892] pci 0000:00:02.1: PME# supported from D0 D1 D2 D3hot D3cold [ 0.542898] pci 0000:00:02.1: PME# disabled [ 0.542919] pci 0000:00:02.2: [10de:0068] type 0 class 0x000c03 [ 0.542938] pci 0000:00:02.2: reg 10: [mem 0xef086000-0xef0860ff] [ 0.543001] pci 0000:00:02.2: supports D1 D2 [ 0.543005] pci 0000:00:02.2: PME# supported from D0 D1 D2 D3hot D3cold [ 0.543011] pci 0000:00:02.2: PME# disabled [ 0.543038] pci 0000:00:04.0: [10de:0066] type 0 class 0x000200 [ 0.543055] pci 0000:00:04.0: reg 10: [mem 0xef087000-0xef087fff] [ 0.543066] pci 0000:00:04.0: reg 14: [io 0xb000-0xb007] [ 0.543116] pci 0000:00:04.0: supports D1 D2 [ 0.543120] pci 0000:00:04.0: PME# supported from D0 D1 D2 D3hot D3cold [ 0.543126] pci 0000:00:04.0: PME# disabled [ 0.543145] pci 0000:00:05.0: [10de:006b] type 0 class 0x000401 [ 0.543162] pci 0000:00:05.0: reg 10: [mem 0xef000000-0xef07ffff] [ 0.543219] pci 0000:00:05.0: supports D1 D2 [ 0.543238] pci 0000:00:06.0: [10de:006a] type 0 class 0x000401 [ 0.543254] pci 0000:00:06.0: reg 10: [io 0xb400-0xb4ff] [ 0.543265] pci 0000:00:06.0: reg 14: [io 0xb800-0xb87f] [ 0.543276] pci 0000:00:06.0: reg 18: [mem 0xef081000-0xef081fff] [ 0.543350] pci 0000:00:06.0: supports D1 D2 [ 0.543408] pci 0000:00:08.0: [10de:006c] type 1 class 0x000604 [ 0.543452] pci 0000:00:09.0: [10de:0065] type 0 class 0x000101 [ 0.543495] pci 0000:00:09.0: reg 20: [io 0xf000-0xf00f] [ 0.543545] pci 0000:00:0d.0: [10de:006e] type 0 class 0x000c00 [ 0.543562] pci 0000:00:0d.0: reg 10: [mem 0xef084000-0xef0847ff] [ 0.543573] pci 0000:00:0d.0: reg 14: [mem 0xef085000-0xef08503f] [ 0.543624] pci 0000:00:0d.0: supports D1 D2 [ 0.543628] pci 0000:00:0d.0: PME# supported from D0 D1 D2 D3hot D3cold [ 0.543634] pci 0000:00:0d.0: PME# disabled [ 0.543668] pci 0000:00:1e.0: [10de:01e8] type 1 class 0x000604 [ 0.543729] pci 0000:01:06.0: [1180:0476] type 2 class 0x000607 [ 0.543751] pci 0000:01:06.0: reg 10: [mem 0xee000000-0xee000fff] [ 0.543774] pci 0000:01:06.0: supports D1 D2 [ 0.543778] pci 0000:01:06.0: PME# supported from D0 D1 D2 D3hot D3cold [ 0.543785] pci 0000:01:06.0: PME# disabled [ 0.543809] pci 0000:01:06.1: [1180:0476] type 2 class 0x000607 [ 0.543831] pci 0000:01:06.1: reg 10: [mem 0xee005000-0xee005fff] [ 0.543853] pci 0000:01:06.1: supports D1 D2 [ 0.543857] pci 0000:01:06.1: PME# supported from D0 D1 D2 D3hot D3cold [ 0.543864] pci 0000:01:06.1: PME# disabled [ 0.543919] pci 0000:00:08.0: PCI bridge to [bus 01-03] [ 0.543961] pci 0000:00:08.0: bridge window [io 0x9000-0xafff] [ 0.543967] pci 0000:00:08.0: bridge window [mem 0xee000000-0xeeffffff] [ 0.543975] pci 0000:00:08.0: bridge window [mem 0xfff00000-0x000fffff pref] (disabled) [ 0.544059] pci_bus 0000:03: [bus 03-06] partially hidden behind bridge 0000:01 [bus 01-03] [ 0.544135] pci 0000:04:00.0: [10de:01f0] type 0 class 0x000300 [ 0.544153] pci 0000:04:00.0: reg 10: [mem 0xec000000-0xecffffff] [ 0.544163] pci 0000:04:00.0: reg 14: [mem 0xe4000000-0xe7ffffff pref] [ 0.544174] pci 0000:04:00.0: reg 18: [mem 0xe8000000-0xe807ffff pref] [ 0.544202] pci 0000:04:00.0: reg 30: [mem 0x00000000-0x0001ffff pref] [ 0.544254] pci 0000:00:1e.0: PCI bridge to [bus 04-04] [ 0.544294] pci 0000:00:1e.0: bridge window [io 0xf000-0x0000] (disabled) [ 0.544300] pci 0000:00:1e.0: bridge window [mem 0xec000000-0xedffffff] [ 0.544306] pci 0000:00:1e.0: bridge window [mem 0xe4000000-0xebffffff pref] [ 0.544320] pci_bus 0000:00: on NUMA node 0 [ 0.544326] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] [ 0.544523] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT] [ 0.544594] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGPB._PRT] [ 0.587975] ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. [ 0.588338] ACPI: PCI Interrupt Link [LNK2] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. [ 0.588697] ACPI: PCI Interrupt Link [LNK3] (IRQs *3 4 5 6 7 10 11 12 14 15) [ 0.589009] ACPI: PCI Interrupt Link [LNK4] (IRQs 3 4 5 6 7 10 *11 12 14 15) [ 0.589319] ACPI: PCI Interrupt Link [LNK5] (IRQs 3 4 5 6 7 *10 11 12 14 15) [ 0.589628] ACPI: PCI Interrupt Link [LUBA] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. [ 0.590039] ACPI: PCI Interrupt Link [LUBB] (IRQs 3 4 *5 6 7 10 11 12 14 15) [ 0.590353] ACPI: PCI Interrupt Link [LMAC] (IRQs 3 4 5 6 7 10 *11 12 14 15) [ 0.590665] ACPI: PCI Interrupt Link [LAPU] (IRQs 3 4 *5 6 7 10 11 12 14 15) [ 0.590975] ACPI: PCI Interrupt Link [LACI] (IRQs 3 4 5 6 7 10 11 *12 14 15) [ 0.591284] ACPI: PCI Interrupt Link [LMCI] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. [ 0.591638] ACPI: PCI Interrupt Link [LSMB] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. [ 0.591994] ACPI: PCI Interrupt Link [LUB2] (IRQs 3 4 5 6 7 10 11 *12 14 15) [ 0.592305] ACPI: PCI Interrupt Link [LFIR] (IRQs 3 4 5 6 7 *10 11 12 14 15) [ 0.592613] ACPI: PCI Interrupt Link [L3CM] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. [ 0.592967] ACPI: PCI Interrupt Link [LIDE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. [ 0.593371] ACPI: PCI Interrupt Link [APC1] (IRQs *16), disabled. [ 0.593542] ACPI: PCI Interrupt Link [APC2] (IRQs *17), disabled. [ 0.593712] ACPI: PCI Interrupt Link [APC3] (IRQs *18) [ 0.593864] ACPI: PCI Interrupt Link [APC4] (IRQs *19) [ 0.594024] ACPI: PCI Interrupt Link [APCE] (IRQs *16) [ 0.594221] ACPI: PCI Interrupt Link [APCF] (IRQs 20 21 22) *0, disabled. [ 0.594484] ACPI: PCI Interrupt Link [APCG] (IRQs 20 21 22) *0 [ 0.594727] ACPI: PCI Interrupt Link [APCH] (IRQs 20 21 22) *0 [ 0.594969] ACPI: PCI Interrupt Link [APCI] (IRQs 20 21 22) *0 [ 0.595225] ACPI: PCI Interrupt Link [APCJ] (IRQs 20 21 22) *0 [ 0.595468] ACPI: PCI Interrupt Link [APCK] (IRQs 20 21 22) *0, disabled. [ 0.595690] ACPI: PCI Interrupt Link [APCS] (IRQs *23), disabled. [ 0.595899] ACPI: PCI Interrupt Link [APCL] (IRQs 20 21 22) *0 [ 0.596150] ACPI: PCI Interrupt Link [APCM] (IRQs 20 21 22) *0 [ 0.596395] ACPI: PCI Interrupt Link [AP3C] (IRQs 20 21 22) *0, disabled. [ 0.596683] ACPI: PCI Interrupt Link [APCZ] (IRQs 20 21 22) *0, disabled. [ 0.597150] vgaarb: device added: PCI:0000:04:00.0,decodes=io+mem,owns=io+mem,locks=none [ 0.597204] vgaarb: loaded [ 0.597503] SCSI subsystem initialized [ 0.597715] usbcore: registered new interface driver usbfs [ 0.597865] usbcore: registered new interface driver hub [ 0.597978] usbcore: registered new device driver usb [ 0.598376] Advanced Linux Sound Architecture Driver Version 1.0.23. [ 0.598474] PCI: Using ACPI for IRQ routing [ 0.598518] PCI: pci_cache_line_size set to 32 bytes [ 0.598603] reserve RAM buffer: 000000007dff0000 - 000000007fffffff [ 0.598858] Switching to clocksource pit [ 0.599005] pnp: PnP ACPI init [ 0.599058] ACPI: bus type pnp registered [ 0.599462] pnp 00:00: [io 0x4000-0x407f] [ 0.599468] pnp 00:00: [io 0x4080-0x40ff] [ 0.599472] pnp 00:00: [io 0x4400-0x447f] [ 0.599476] pnp 00:00: [io 0x4480-0x44ff] [ 0.599480] pnp 00:00: [io 0x4200-0x427f] [ 0.599484] pnp 00:00: [io 0x4280-0x42ff] [ 0.599609] system 00:00: [io 0x4000-0x407f] has been reserved [ 0.599651] system 00:00: [io 0x4080-0x40ff] has been reserved [ 0.599691] system 00:00: [io 0x4400-0x447f] has been reserved [ 0.599730] system 00:00: [io 0x4480-0x44ff] has been reserved [ 0.599770] system 00:00: [io 0x4200-0x427f] has been reserved [ 0.599809] system 00:00: [io 0x4280-0x42ff] has been reserved [ 0.599850] system 00:00: Plug and Play ACPI device, IDs PNP0c02 (active) [ 0.599872] pnp 00:01: [io 0x5000-0x503f] [ 0.599877] pnp 00:01: [io 0x5100-0x513f] [ 0.599954] system 00:01: [io 0x5000-0x503f] has been reserved [ 0.599954] system 00:01: [io 0x5100-0x513f] has been reserved [ 0.599954] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active) [ 0.599954] system 00:02: Plug and Play ACPI device, IDs PNP0c01 (active) [ 0.599954] pnp 00:03: [bus 00-ff] [ 0.599954] pnp 00:03: [io 0x0cf8-0x0cff] [ 0.599954] pnp 00:03: [io 0x0000-0x0cf7 window] [ 0.599954] pnp 00:03: [io 0x0d00-0xffff window] [ 0.599954] pnp 00:03: [mem 0x000a0000-0x000bffff window] [ 0.599954] pnp 00:03: [mem 0x000c0000-0x000dffff window] [ 0.599954] pnp 00:03: [mem 0x7e000000-0xfebfffff window] [ 0.599954] pnp 00:03: Plug and Play ACPI device, IDs PNP0a03 (active) [ 0.599954] pnp 00:04: [io 0x0010-0x001f] [ 0.599954] pnp 00:04: [io 0x0022-0x003f] [ 0.599954] pnp 00:04: [io 0x0044-0x005f] [ 0.599954] pnp 00:04: [io 0x0062-0x0063] [ 0.599954] pnp 00:04: [io 0x0065-0x006f] [ 0.599954] pnp 00:04: [io 0x0074-0x007f] [ 0.599954] pnp 00:04: [io 0x0091-0x0093] [ 0.599954] pnp 00:04: [io 0x00a2-0x00bf] [ 0.599954] pnp 00:04: [io 0x00e0-0x00ef] [ 0.599954] pnp 00:04: [io 0x04d0-0x04d1] [ 0.599954] pnp 00:04: [io 0x0800-0x0805] [ 0.599954] pnp 00:04: [io 0x0290-0x0297] [ 0.599954] system 00:04: [io 0x04d0-0x04d1] has been reserved [ 0.601173] system 00:04: [io 0x0800-0x0805] has been reserved [ 0.601214] system 00:04: [io 0x0290-0x0297] has been reserved [ 0.601255] system 00:04: Plug and Play ACPI device, IDs PNP0c02 (active) [ 0.601281] pnp 00:05: [dma 4] [ 0.601285] pnp 00:05: [io 0x0000-0x000f] [ 0.601289] pnp 00:05: [io 0x0080-0x0090] [ 0.601293] pnp 00:05: [io 0x0094-0x009f] [ 0.601297] pnp 00:05: [io 0x00c0-0x00df] [ 0.601406] pnp 00:05: Plug and Play ACPI device, IDs PNP0200 (active) [ 0.601430] pnp 00:06: [io 0x0070-0x0073] [ 0.601436] pnp 00:06: [irq 8] [ 0.601534] pnp 00:06: Plug and Play ACPI device, IDs PNP0b00 (active) [ 0.601555] pnp 00:07: [io 0x0061] [ 0.601653] pnp 00:07: Plug and Play ACPI device, IDs PNP0800 (active) [ 0.601674] pnp 00:08: [io 0x00f0-0x00ff] [ 0.601679] pnp 00:08: [irq 13] [ 0.601779] pnp 00:08: Plug and Play ACPI device, IDs PNP0c04 (active) [ 0.602041] pnp 00:09: [io 0x03f0-0x03f5] [ 0.602046] pnp 00:09: [io 0x03f7] [ 0.602050] pnp 00:09: [irq 6] [ 0.602054] pnp 00:09: [dma 2] [ 0.602184] pnp 00:09: Plug and Play ACPI device, IDs PNP0700 (active) [ 0.602514] pnp 00:0a: [io 0x03f8-0x03ff] [ 0.602519] pnp 00:0a: [irq 4] [ 0.602672] pnp 00:0a: Plug and Play ACPI device, IDs PNP0501 (active) [ 0.603474] pnp 00:0b: [io 0x0378-0x037f] [ 0.603479] pnp 00:0b: [io 0x0778-0x077b] [ 0.603484] pnp 00:0b: [irq 7] [ 0.603488] pnp 00:0b: [dma 3] [ 0.603658] pnp 00:0b: Plug and Play ACPI device, IDs PNP0401 (active) [ 0.603753] pnp: PnP ACPI: found 12 devices [ 0.603791] ACPI: ACPI bus type pnp unregistered [ 0.644477] Switching to clocksource acpi_pm [ 0.644594] pci 0000:00:08.0: BAR 9: assigned [mem 0x80000000-0x87ffffff pref] [ 0.644650] pci 0000:01:06.0: BAR 9: assigned [mem 0x80000000-0x83ffffff pref] [ 0.644703] pci 0000:01:06.0: BAR 10: can't assign mem (size 0x4000000) [ 0.644745] pci 0000:01:06.1: BAR 9: assigned [mem 0x84000000-0x87ffffff pref] [ 0.644797] pci 0000:01:06.1: BAR 10: can't assign mem (size 0x4000000) [ 0.644838] pci 0000:01:06.0: BAR 7: assigned [io 0x9000-0x90ff] [ 0.644878] pci 0000:01:06.0: BAR 8: assigned [io 0x9400-0x94ff] [ 0.644918] pci 0000:01:06.1: BAR 7: assigned [io 0x9800-0x98ff] [ 0.644958] pci 0000:01:06.1: BAR 8: assigned [io 0x9c00-0x9cff] [ 0.644997] pci 0000:01:06.0: CardBus bridge to [bus 02-02] [ 0.645036] pci 0000:01:06.0: bridge window [io 0x9000-0x90ff] [ 0.645078] pci 0000:01:06.0: bridge window [io 0x9400-0x94ff] [ 0.645120] pci 0000:01:06.0: bridge window [mem 0x80000000-0x83ffffff pref] [ 0.645174] pci 0000:01:06.1: CardBus bridge to [bus 03-06] [ 0.645212] pci 0000:01:06.1: bridge window [io 0x9800-0x98ff] [ 0.645254] pci 0000:01:06.1: bridge window [io 0x9c00-0x9cff] [ 0.645296] pci 0000:01:06.1: bridge window [mem 0x84000000-0x87ffffff pref] [ 0.645350] pci 0000:00:08.0: PCI bridge to [bus 01-03] [ 0.645389] pci 0000:00:08.0: bridge window [io 0x9000-0xafff] [ 0.645431] pci 0000:00:08.0: bridge window [mem 0xee000000-0xeeffffff] [ 0.645474] pci 0000:00:08.0: bridge window [mem 0x80000000-0x87ffffff pref] [ 0.645531] pci 0000:04:00.0: BAR 6: assigned [mem 0xe8080000-0xe809ffff pref] [ 0.645583] pci 0000:00:1e.0: PCI bridge to [bus 04-04] [ 0.645620] pci 0000:00:1e.0: bridge window [io disabled] [ 0.645661] pci 0000:00:1e.0: bridge window [mem 0xec000000-0xedffffff] [ 0.645703] pci 0000:00:1e.0: bridge window [mem 0xe4000000-0xebffffff pref] [ 0.645768] pci 0000:00:08.0: setting latency timer to 64 [ 0.645980] ACPI: PCI Interrupt Link [LNK3] enabled at IRQ 3 [ 0.646020] PCI: setting IRQ 3 as level-triggered [ 0.646029] pci 0000:01:06.0: PCI INT A -> Link[LNK3] -> GSI 3 (level, low) -> IRQ 3 [ 0.646192] ACPI: PCI Interrupt Link [LNK4] enabled at IRQ 11 [ 0.646231] PCI: setting IRQ 11 as level-triggered [ 0.646239] pci 0000:01:06.1: PCI INT B -> Link[LNK4] -> GSI 11 (level, low) -> IRQ 11 [ 0.646300] pci_bus 0000:00: resource 0 [io 0x0000-0xffff] [ 0.646306] pci_bus 0000:00: resource 1 [mem 0x00000000-0xffffffff] [ 0.646311] pci_bus 0000:01: resource 0 [io 0x9000-0xafff] [ 0.646316] pci_bus 0000:01: resource 1 [mem 0xee000000-0xeeffffff] [ 0.646321] pci_bus 0000:01: resource 2 [mem 0x80000000-0x87ffffff pref] [ 0.646326] pci_bus 0000:02: resource 0 [io 0x9000-0x90ff] [ 0.646330] pci_bus 0000:02: resource 1 [io 0x9400-0x94ff] [ 0.646335] pci_bus 0000:02: resource 2 [mem 0x80000000-0x83ffffff pref] [ 0.646340] pci_bus 0000:03: resource 0 [io 0x9800-0x98ff] [ 0.646344] pci_bus 0000:03: resource 1 [io 0x9c00-0x9cff] [ 0.646349] pci_bus 0000:03: resource 2 [mem 0x84000000-0x87ffffff pref] [ 0.646354] pci_bus 0000:04: resource 1 [mem 0xec000000-0xedffffff] [ 0.646359] pci_bus 0000:04: resource 2 [mem 0xe4000000-0xebffffff pref] [ 0.646424] NET: Registered protocol family 2 [ 0.646538] IP route cache hash table entries: 32768 (order: 5, 131072 bytes) [ 0.647071] TCP established hash table entries: 131072 (order: 8, 1048576 bytes) [ 0.647735] Switched to NOHz mode on CPU #0 [ 0.648782] TCP bind hash table entries: 65536 (order: 6, 262144 bytes) [ 0.649304] TCP: Hash tables configured (established 131072 bind 65536) [ 0.649344] TCP reno registered [ 0.649381] UDP hash table entries: 512 (order: 1, 8192 bytes) [ 0.649432] UDP-Lite hash table entries: 512 (order: 1, 8192 bytes) [ 0.649674] NET: Registered protocol family 1 [ 0.680078] pci 0000:04:00.0: Boot video device [ 0.680084] PCI: CLS 0 bytes, default 32 [ 0.680912] Scanning for low memory corruption every 60 seconds [ 0.681858] highmem bounce pool size: 64 pages [ 0.681902] HugeTLB registered 4 MB page size, pre-allocated 0 pages [ 0.688597] msgmni has been set to 1733 [ 0.688935] alg: No test for stdrng (krng) [ 0.688983] io scheduler noop registered [ 0.689019] io scheduler deadline registered [ 0.689073] io scheduler cfq registered (default) [ 0.689568] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled [ 0.963426] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A [ 0.984674] 00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A [ 0.985153] Linux agpgart interface v0.103 [ 0.985221] agpgart: Detected NVIDIA nForce2 chipset [ 0.991051] agpgart-nvidia 0000:00:00.0: AGP aperture is 64M @ 0xe0000000 [ 0.991345] Floppy drive(s): fd0 is 1.44M [ 1.006848] FDC 0 is a post-1991 82077 [ 1.008156] Uniform Multi-Platform E-IDE driver [ 1.008320] amd74xx 0000:00:09.0: UDMA133 controller [ 1.008361] amd74xx 0000:00:09.0: IDE controller (0x10de:0x0065 rev 0xa2) [ 1.008447] amd74xx 0000:00:09.0: BIOS didn't set cable bits correctly. Enabling workaround. [ 1.008503] amd74xx 0000:00:09.0: not 100% native mode: will probe irqs later [ 1.008548] ide0: BM-DMA at 0xf000-0xf007 [ 1.008591] ide1: BM-DMA at 0xf008-0xf00f [ 1.008631] Probing IDE interface ide0... [ 1.283492] hda: ST3120022A, ATA DISK drive [ 1.683371] Refined TSC clocksource calibration: 1469.999 MHz. [ 1.683412] Switching to clocksource tsc [ 1.923441] hda: host max PIO5 wanted PIO255(auto-tune) selected PIO4 [ 1.923657] hda: UDMA/100 mode selected [ 1.923924] Probing IDE interface ide1... [ 2.463460] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 [ 2.463547] ide1 at 0x170-0x177,0x376 on irq 15 [ 2.463819] ide_generic: please use "probe_mask=0x3f" module parameter for probing all legacy ISA IDE ports [ 2.463875] ide-gd driver 1.18 [ 2.463935] hda: max request size: 512KiB [ 2.473520] hda: 234441648 sectors (120034 MB) w/2048KiB Cache, CHS=16383/255/63 [ 2.473760] hda: cache flushes supported [ 2.488251] hda: hda1 hda2 hda3 hda4 [ 2.488858] ide-cd driver 5.00 [ 2.488971] forcedeth: Reverse Engineered nForce ethernet driver. Version 0.64. [ 2.489248] ACPI: PCI Interrupt Link [LMAC] enabled at IRQ 11 [ 2.489293] forcedeth 0000:00:04.0: PCI INT A -> Link[LMAC] -> GSI 11 (level, low) -> IRQ 11 [ 2.489350] forcedeth 0000:00:04.0: setting latency timer to 64 [ 3.010760] forcedeth 0000:00:04.0: ifname eth0, PHY OUI 0x732 @ 1, addr aa:bb:cc:dd:ee:ff [ 3.010816] forcedeth 0000:00:04.0: timirq lnktim desc-v1 [ 3.011110] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 3.011336] ACPI: PCI Interrupt Link [LUB2] enabled at IRQ 12 [ 3.011376] PCI: setting IRQ 12 as level-triggered [ 3.011384] ehci_hcd 0000:00:02.2: PCI INT C -> Link[LUB2] -> GSI 12 (level, low) -> IRQ 12 [ 3.011455] ehci_hcd 0000:00:02.2: setting latency timer to 64 [ 3.011461] ehci_hcd 0000:00:02.2: EHCI Host Controller [ 3.011611] ehci_hcd 0000:00:02.2: new USB bus registered, assigned bus number 1 [ 3.011713] ehci_hcd 0000:00:02.2: debug port 1 [ 3.011757] ehci_hcd 0000:00:02.2: cache line size of 32 is not supported [ 3.011773] ehci_hcd 0000:00:02.2: irq 12, io mem 0xef086000 [ 3.020024] ehci_hcd 0000:00:02.2: USB 2.0 started, EHCI 1.00 [ 3.020115] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [ 3.020156] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 3.020207] usb usb1: Product: EHCI Host Controller [ 3.020244] usb usb1: Manufacturer: Linux 2.6.38-rc8+ ehci_hcd [ 3.020282] usb usb1: SerialNumber: 0000:00:02.2 [ 3.020523] hub 1-0:1.0: USB hub found [ 3.020566] hub 1-0:1.0: 6 ports detected [ 3.020819] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 3.021044] ACPI: PCI Interrupt Link [LUBA] enabled at IRQ 10 [ 3.021084] PCI: setting IRQ 10 as level-triggered [ 3.021093] ohci_hcd 0000:00:02.0: PCI INT A -> Link[LUBA] -> GSI 10 (level, low) -> IRQ 10 [ 3.021164] ohci_hcd 0000:00:02.0: setting latency timer to 64 [ 3.021169] ohci_hcd 0000:00:02.0: OHCI Host Controller [ 3.021324] ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 2 [ 3.021400] ohci_hcd 0000:00:02.0: irq 10, io mem 0xef080000 [ 3.075384] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001 [ 3.075426] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 3.075477] usb usb2: Product: OHCI Host Controller [ 3.075514] usb usb2: Manufacturer: Linux 2.6.38-rc8+ ohci_hcd [ 3.075552] usb usb2: SerialNumber: 0000:00:02.0 $HOST 3.075782] hub 2-0:1.0: USB hub found [ 3.075826] hub 2-0:1.0: 3 ports detected [ 3.076179] ACPI: PCI Interrupt Link [LUBB] enabled at IRQ 5 [ 3.076218] PCI: setting IRQ 5 as level-triggered [ 3.076227] ohci_hcd 0000:00:02.1: PCI INT B -> Link[LUBB] -> GSI 5 (level, low) -> IRQ 5 [ 3.076295] ohci_hcd 0000:00:02.1: setting latency timer to 64 [ 3.076300] ohci_hcd 0000:00:02.1: OHCI Host Controller [ 3.076447] ohci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 3 [ 3.076522] ohci_hcd 0000:00:02.1: irq 5, io mem 0xef083000 [ 3.128713] usb usb3: New USB device found, idVendor=1d6b, idProduct=0001 [ 3.128755] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 3.128806] usb usb3: Product: OHCI Host Controller [ 3.128843] usb usb3: Manufacturer: Linux 2.6.38-rc8+ ohci_hcd [ 3.128881] usb usb3: SerialNumber: 0000:00:02.1 [ 3.129122] hub 3-0:1.0: USB hub found [ 3.129166] hub 3-0:1.0: 3 ports detected [ 3.129502] usbcore: registered new interface driver libusual [ 3.129776] i8042: PNP: No PS/2 controller found. Probing ports directly. [ 3.274501] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 3.276214] serio: i8042 AUX port at 0x60,0x64 irq 12 [ 3.276648] mousedev: PS/2 mouse device common for all mice [ 3.276922] rtc_cmos 00:06: RTC can wake from S4 [ 3.277080] rtc_cmos 00:06: rtc core: registered rtc_cmos as rtc0 [ 3.277142] rtc0: alarms up to one year, y3k, 242 bytes nvram [ 3.277232] i2c /dev entries driver [ 3.330105] i2c i2c-0: nForce2 SMBus adapter at 0x5000 [ 3.383427] i2c i2c-1: nForce2 SMBus adapter at 0x5100 [ 3.383552] it87: Found IT8712F chip at 0x290, revision 5 [ 3.383669] ACPI: resource it87 [io 0x0295-0x0296] conflicts with ACPI region SPIO [io 0x295-0x296] [ 3.383724] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [ 3.383828] md: raid1 personality registered for level 1 [ 3.383868] md: raid10 personality registered for level 10 [ 3.383905] md: raid6 personality registered for level 6 [ 3.383942] md: raid5 personality registered for level 5 [ 3.383979] md: raid4 personality registered for level 4 [ 3.384017] cpuidle: using governor ladder [ 3.384052] cpuidle: using governor menu [ 3.385759] usbcore: registered new interface driver usbhid [ 3.385799] usbhid: USB HID core driver [ 3.386216] ACPI: PCI Interrupt Link [LACI] enabled at IRQ 12 [ 3.386262] Intel ICH 0000:00:06.0: PCI INT A -> Link[LACI] -> GSI 12 (level, low) -> IRQ 12 [ 3.386356] Intel ICH 0000:00:06.0: setting latency timer to 64 [ 3.620024] usb 2-1: new full speed USB device using ohci_hcd and address 2 [ 3.703359] intel8x0_measure_ac97_clock: measured 52159 usecs (2536 samples) [ 3.703401] intel8x0: clocking to 47387 [ 3.704127] ALSA device list: [ 3.704163] #0: NVidia nForce2 with ALC650E at irq 12 [ 3.704691] TCP cubic registered [ 3.704728] NET: Registered protocol family 17 [ 3.704775] Registering the dns_resolver key type [ 3.705614] registered taskstats version 1 [ 3.706074] rtc_cmos 00:06: setting system clock to 2011-03-09 02:50:24 UTC (1299639024) [ 3.773354] usb 2-1: New USB device found, idVendor=0430, idProduct=100e [ 3.773397] usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 3.776427] hub 2-1:1.0: USB hub found [ 3.779338] hub 2-1:1.0: 4 ports detected [ 4.036692] usb 2-2: new low speed USB device using ohci_hcd and address 3 [ 4.123546] md: Waiting for all devices to be available before autodetect [ 4.123587] md: If you don't use raid, use raid=noautodetect [ 4.123889] md: Autodetecting RAID arrays. [ 4.123926] md: Scanned 0 and added 0 devices. [ 4.123961] md: autorun ... [ 4.123993] md: ... autorun DONE. [ 4.136736] EXT3-fs: barriers not enabled [ 4.150265] kjournald starting. Commit interval 5 seconds [ 4.150328] EXT3-fs (hda2): mounted filesystem with ordered data mode [ 4.150377] VFS: Mounted root (ext3 filesystem) readonly on device 3:2. [ 4.150472] Freeing unused kernel memory: 276k freed [ 4.191326] usb 2-2: New USB device found, idVendor=1241, idProduct=1166 [ 4.191371] usb 2-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 4.205887] input: HID 1241:1166 as /devices/pci0000:00/0000:00:02.0/usb2/2-2/2-2:1.0/input/input0 [ 4.206145] generic-usb 0003:1241:1166.0001: input,hidraw0: USB HID v1.10 Mouse [HID 1241:1166] on usb-0000:00:02.0-2/input0 [ 4.378310] usb 2-1.4: new full speed USB device using ohci_hcd and address 4 [ 4.489306] usb 2-1.4: New USB device found, idVendor=0430, idProduct=00a2 [ 4.489354] usb 2-1.4: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [ 4.489406] usb 2-1.4: Product: Sun USB Keyboard [ 4.498899] input: Sun USB Keyboard as /devices/pci0000:00/0000:00:02.0/usb2/2-1/2-1.4/2-1.4:1.0/input/input1 [ 4.499092] generic-usb 0003:0430:00A2.0002: input,hidraw1: USB HID v1.10 Keyboard [Sun USB Keyboard] on usb-0000:00:02.0-1.4/input0 [ 7.443767] yenta_cardbus 0000:01:06.0: CardBus bridge found [14ef:0202] [ 7.570355] yenta_cardbus 0000:01:06.0: ISA IRQ mask 0x0000, PCI irq 3 [ 7.570404] yenta_cardbus 0000:01:06.0: Socket status: 30000410 [ 7.570454] yenta_cardbus 0000:01:06.0: pcmcia: parent PCI bridge window: [io 0x9000-0xafff] [ 7.570509] yenta_cardbus 0000:01:06.0: pcmcia: parent PCI bridge window: [mem 0xee000000-0xeeffffff] [ 7.570565] pcmcia_socket pcmcia_socket0: cs: memory probe 0xee000000-0xeeffffff: excluding 0xee000000-0xee0fffff [ 7.570685] yenta_cardbus 0000:01:06.0: pcmcia: parent PCI bridge window: [mem 0x80000000-0x87ffffff pref] [ 7.570740] pcmcia_socket pcmcia_socket0: cs: memory probe 0x80000000-0x87ffffff: excluding 0x80000000-0x87ffffff [ 7.571365] yenta_cardbus 0000:01:06.1: CardBus bridge found [14ef:0202] [ 7.577424] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input2 [ 7.578108] ACPI: Power Button [PWRB] [ 7.579148] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input3 [ 7.579423] ACPI: Power Button [PWRF] [ 7.696916] yenta_cardbus 0000:01:06.1: ISA IRQ mask 0x0000, PCI irq 11 [ 7.696966] yenta_cardbus 0000:01:06.1: Socket status: 30000410 [ 7.697007] pci_bus 0000:03: Upper limit for fixing this bridge's parent bridge: #03 [ 7.697069] yenta_cardbus 0000:01:06.1: pcmcia: parent PCI bridge window: [io 0x9000-0xafff] [ 7.697124] yenta_cardbus 0000:01:06.1: pcmcia: parent PCI bridge window: [mem 0xee000000-0xeeffffff] [ 7.697180] pcmcia_socket pcmcia_socket1: cs: memory probe 0xee000000-0xeeffffff: excluding 0xee000000-0xee0fffff [ 7.697300] yenta_cardbus 0000:01:06.1: pcmcia: parent PCI bridge window: [mem 0x80000000-0x87ffffff pref] [ 7.697356] pcmcia_socket pcmcia_socket1: cs: memory probe 0x80000000-0x87ffffff: excluding 0x80000000-0x87ffffff [ 8.536355] [drm] Initialized drm 1.1.0 20060810 [ 9.076711] pcmcia_socket pcmcia_socket0: pccard: PCMCIA card inserted into slot 0 [ 9.076778] pcmcia_socket pcmcia_socket0: cs: memory probe 0xee100000-0xeeffffff: clean. [ 9.082865] pcmcia 0.0: pcmcia: registering new device pcmcia0.0 (IRQ: 3) [ 9.084673] pcmcia_socket pcmcia_socket0: cs: memory probe 0x0c0000-0x0fffff: excluding 0xc0000-0xfffff [ 9.084863] pcmcia_socket pcmcia_socket0: cs: memory probe 0xa0000000-0xa0ffffff: excluding 0xa0000000-0xa0ffffff [ 9.085045] pcmcia_socket pcmcia_socket0: cs: memory probe 0x60000000-0x60ffffff: excluding 0x60000000-0x60ffffff [ 9.123847] ACPI: PCI Interrupt Link [LNK5] enabled at IRQ 10 [ 9.123899] nouveau 0000:04:00.0: PCI INT A -> Link[LNK5] -> GSI 10 (level, low) -> IRQ 10 [ 9.129897] [drm] nouveau 0000:04:00.0: Detected an NV10 generation card (0x01f000a5) [ 9.130763] [drm] nouveau 0000:04:00.0: Attempting to load BIOS image from PRAMIN [ 9.175165] [drm] nouveau 0000:04:00.0: ... BIOS checksum invalid [ 9.175205] [drm] nouveau 0000:04:00.0: Attempting to load BIOS image from PROM [ 9.175259] [drm] nouveau 0000:04:00.0: ... BIOS signature not found [ 9.175298] [drm] nouveau 0000:04:00.0: Attempting to load BIOS image from PCIROM [ 9.175760] [drm] nouveau 0000:04:00.0: ... appears to be valid [ 9.176312] [drm] nouveau 0000:04:00.0: BMP BIOS found [ 9.176350] [drm] nouveau 0000:04:00.0: BMP version 5.21 [ 9.176388] [drm] nouveau 0000:04:00.0: Bios version 04.1f.00.07 [ 9.176428] [drm] nouveau 0000:04:00.0: Found Display Configuration Block version 2.0 [ 9.176482] [drm] nouveau 0000:04:00.0: Raw DCB entry 0: 01000100 000088b8 [ 9.176524] [drm] nouveau 0000:04:00.0: Raw DCB entry 1: 02010210 000088b8 [ 9.176564] [drm] nouveau 0000:04:00.0: Raw DCB entry 2: 01120132 00000000 [ 9.176604] [drm] nouveau 0000:04:00.0: Raw DCB entry 3: 01120232 00000000 [ 9.176644] [drm] nouveau 0000:04:00.0: Raw DCB entry 4: 02010121 00000003 [ 9.176703] [drm] nouveau 0000:04:00.0: Raw DCB entry 5: 02010221 00000003 [ 9.176744] [drm] nouveau 0000:04:00.0: Merging DCB entries 2 and 3 [ 9.176783] [drm] nouveau 0000:04:00.0: Merging DCB entries 4 and 5 [ 9.177322] [drm] nouveau 0000:04:00.0: Parsing VBIOS init table 0 at offset 0xC284 [ 9.177400] [drm] nouveau 0000:04:00.0: Parsing VBIOS init table 1 at offset 0xC4E0 [ 9.177458] [drm] nouveau 0000:04:00.0: Parsing VBIOS init table 2 at offset 0xC2E7 [ 9.192556] [drm] nouveau 0000:04:00.0: Parsing VBIOS init table 3 at offset 0xC632 [ 9.192616] [drm] nouveau 0000:04:00.0: Parsing VBIOS init table 4 at offset 0xC47B [ 9.192670] [drm] nouveau 0000:04:00.0: Unknown memclock table version 0. [ 9.227437] [drm] nouveau 0000:04:00.0: 0 available performance level(s) [ 9.227507] [drm] nouveau 0000:04:00.0: c: memory 200454MHz core 199MHz [ 9.227628] [TTM] Zone kernel: Available graphics memory: 443984 kiB. [ 9.227669] [TTM] Zone highmem: Available graphics memory: 1021492 kiB. [ 9.227708] [TTM] Initializing pool allocator. [ 9.227765] [drm] nouveau 0000:04:00.0: Detected 32MiB VRAM [ 9.228117] agpgart-nvidia 0000:00:00.0: AGP 2.0 bridge [ 9.228185] agpgart-nvidia 0000:00:00.0: putting AGP V2 device into 4x mode [ 9.228298] nouveau 0000:04:00.0: putting AGP V2 device into 4x mode [ 9.228334] [drm] nouveau 0000:04:00.0: 64 MiB GART (aperture) [ 9.228415] [drm] nouveau 0000:04:00.0: Saving VGA fonts [ 9.276657] [drm] nouveau 0000:04:00.0: Detected TMDS transmitter: sil164 [ 9.281254] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 9.281297] [drm] No driver support for vblank timestamp query. [ 9.283437] [drm] nouveau 0000:04:00.0: Setting dpms mode 3 on vga encoder (output 0) [ 9.283491] [drm] nouveau 0000:04:00.0: Setting dpms mode 3 on vga encoder (output 1) [ 9.283535] [drm] nouveau 0000:04:00.0: Setting dpms mode 3 on tmds encoder (output 2) [ 9.283580] [drm] nouveau 0000:04:00.0: Setting dpms mode 3 on TV encoder (output 3) [ 9.513366] [drm] nouveau 0000:04:00.0: Load detected on output B [ 9.514854] [drm] nouveau 0000:04:00.0: allocated 1920x1080 fb: 0x4a000, bo f63f9800 [ 10.178216] [drm] nouveau 0000:04:00.0: Setting dpms mode 0 on tmds encoder (output 2) [ 10.178223] [drm] nouveau 0000:04:00.0: Output DVI-D-1 is running on CRTC 0 using output A [ 10.200240] [drm] nouveau 0000:04:00.0: Setting dpms mode 0 on TV encoder (output 3) [ 10.200249] [drm] nouveau 0000:04:00.0: Output TV-1 is running on CRTC 1 using output B [ 10.201105] Console: switching to colour frame buffer device 90x36 [ 10.205458] fb0: nouveaufb frame buffer device [ 10.205461] drm: registered panic notifier [ 10.206666] [drm] Initialized nouveau 0.0.16 20090420 for 0000:04:00.0 on minor 0 [ 10.683364] pcmcia_socket pcmcia_socket1: pccard: PCMCIA card inserted into slot 1 [ 10.683872] pcmcia_socket pcmcia_socket1: cs: memory probe 0xee100000-0xeeffffff: excluding 0xee100000-0xee1effff [ 10.690439] pcmcia_socket pcmcia_socket1: cs: memory probe 0x0c0000-0x0fffff: excluding 0xc0000-0xfffff [ 10.692000] pcmcia_socket pcmcia_socket1: cs: memory probe 0xa0000000-0xa0ffffff: excluding 0xa0000000-0xa0ffffff [ 10.693091] pcmcia_socket pcmcia_socket1: cs: memory probe 0x60000000-0x60ffffff: excluding 0x60000000-0x60ffffff [ 10.701327] [ 10.702269] pcmcia 1.0: pcmcia: registering new device pcmcia1.0 (IRQ: 11) [ 12.972003] Adding 1951860k swap on /dev/hda1. Priority:-1 extents:1 across:1951860k [ 13.225707] EXT3-fs (hda2): using internal journal [ 13.544190] loop: module loaded [ 14.097220] fuse init (API version 7.16) [ 14.192652] EXT3-fs: barriers not enabled [ 14.200535] kjournald starting. Commit interval 5 seconds [ 14.201183] EXT3-fs (hda3): using internal journal [ 14.201618] EXT3-fs (hda3): mounted filesystem with ordered data mode [ 37.166760] [drm] nouveau 0000:04:00.0: Load detected on output B [ 37.426696] [drm] nouveau 0000:04:00.0: Load detected on output B [ 38.056689] [drm] nouveau 0000:04:00.0: Load detected on output B [ 38.266697] [drm] nouveau 0000:04:00.0: Load detected on output B [ 38.590029] [drm] nouveau 0000:04:00.0: Load detected on output B [ 38.806683] [drm] nouveau 0000:04:00.0: Load detected on output B [ 39.066683] [drm] nouveau 0000:04:00.0: Load detected on output B [ 39.270016] [drm] nouveau 0000:04:00.0: Load detected on output B [ 39.533349] [drm] nouveau 0000:04:00.0: Load detected on output B [ 39.736682] [drm] nouveau 0000:04:00.0: Load detected on output B [ 39.996683] [drm] nouveau 0000:04:00.0: Load detected on output B [ 40.200016] [drm] nouveau 0000:04:00.0: Load detected on output B [ 40.473349] [drm] nouveau 0000:04:00.0: Load detected on output B [ 40.713350] [drm] nouveau 0000:04:00.0: Load detected on output B [ 41.020018] [drm] nouveau 0000:04:00.0: Load detected on output B [ 41.223350] [drm] nouveau 0000:04:00.0: Load detected on output B [ 41.483349] [drm] nouveau 0000:04:00.0: Load detected on output B [ 41.686685] [drm] nouveau 0000:04:00.0: Load detected on output B [ 41.953355] [drm] nouveau 0000:04:00.0: Load detected on output B [ 42.156682] [drm] nouveau 0000:04:00.0: Load detected on output B [ 42.416682] [drm] nouveau 0000:04:00.0: Load detected on output B [ 42.620015] [drm] nouveau 0000:04:00.0: Load detected on output B [ 42.880015] [drm] nouveau 0000:04:00.0: Load detected on output B [ 43.083349] [drm] nouveau 0000:04:00.0: Load detected on output B [ 43.346683] [drm] nouveau 0000:04:00.0: Load detected on output B [ 43.550021] [drm] nouveau 0000:04:00.0: Load detected on output B [ 43.813348] [drm] nouveau 0000:04:00.0: Load detected on output B [ 44.016687] [drm] nouveau 0000:04:00.0: Load detected on output B [ 44.276682] [drm] nouveau 0000:04:00.0: Load detected on output B [ 44.480015] [drm] nouveau 0000:04:00.0: Load detected on output B [ 44.740015] [drm] nouveau 0000:04:00.0: Load detected on output B [ 44.943348] [drm] nouveau 0000:04:00.0: Load detected on output B [ 45.203349] [drm] nouveau 0000:04:00.0: Load detected on output B [ 45.420016] [drm] nouveau 0000:04:00.0: Load detected on output B [ 45.680015] [drm] nouveau 0000:04:00.0: Load detected on output B [ 45.883350] [drm] nouveau 0000:04:00.0: Load detected on output B [ 46.143348] [drm] nouveau 0000:04:00.0: Load detected on output B [ 46.346682] [drm] nouveau 0000:04:00.0: Load detected on output B [ 46.606682] [drm] nouveau 0000:04:00.0: Load detected on output B [ 46.810017] [drm] nouveau 0000:04:00.0: Load detected on output B [ 47.070016] [drm] nouveau 0000:04:00.0: Load detected on output B [ 47.273349] [drm] nouveau 0000:04:00.0: Load detected on output B [ 47.533349] [drm] nouveau 0000:04:00.0: Load detected on output B [ 47.736682] [drm] nouveau 0000:04:00.0: Load detected on output B [ 47.996682] [drm] nouveau 0000:04:00.0: Load detected on output B [ 48.200015] [drm] nouveau 0000:04:00.0: Load detected on output B [ 48.463348] [drm] nouveau 0000:04:00.0: Load detected on output B [ 48.666682] [drm] nouveau 0000:04:00.0: Load detected on output B [ 48.926682] [drm] nouveau 0000:04:00.0: Load detected on output B [ 49.130015] [drm] nouveau 0000:04:00.0: Load detected on output B [ 49.390015] [drm] nouveau 0000:04:00.0: Load detected on output B [ 49.593348] [drm] nouveau 0000:04:00.0: Load detected on output B [ 49.853348] [drm] nouveau 0000:04:00.0: Load detected on output B [ 50.056682] [drm] nouveau 0000:04:00.0: Load detected on output B [ 50.330015] [drm] nouveau 0000:04:00.0: Load detected on output B [ 50.540015] [drm] nouveau 0000:04:00.0: Load detected on output B [ 50.800015] [drm] nouveau 0000:04:00.0: Load detected on output B [ 51.003352] [drm] nouveau 0000:04:00.0: Load detected on output B [ 51.263348] [drm] nouveau 0000:04:00.0: Load detected on output B [ 51.470015] [drm] nouveau 0000:04:00.0: Load detected on output B [ 51.730015] [drm] nouveau 0000:04:00.0: Load detected on output B [ 51.933348] [drm] nouveau 0000:04:00.0: Load detected on output B [ 52.193348] [drm] nouveau 0000:04:00.0: Load detected on output B [ 52.396681] [drm] nouveau 0000:04:00.0: Load detected on output B [ 52.656682] [drm] nouveau 0000:04:00.0: Load detected on output B [ 52.860014] [drm] nouveau 0000:04:00.0: Load detected on output B [ 53.120015] [drm] nouveau 0000:04:00.0: Load detected on output B [ 53.323348] [drm] nouveau 0000:04:00.0: Load detected on output B [ 53.583348] [drm] nouveau 0000:04:00.0: Load detected on output B [ 53.786681] [drm] nouveau 0000:04:00.0: Load detected on output B [ 54.046681] [drm] nouveau 0000:04:00.0: Load detected on output B [ 54.250021] [drm] nouveau 0000:04:00.0: Load detected on output B [ 54.510016] [drm] nouveau 0000:04:00.0: Load detected on output B [ 54.713348] [drm] nouveau 0000:04:00.0: Load detected on output B [ 54.973349] [drm] nouveau 0000:04:00.0: Load detected on output B [ 55.176681] [drm] nouveau 0000:04:00.0: Load detected on output B [ 55.446681] [drm] nouveau 0000:04:00.0: Load detected on output B [ 55.650015] [drm] nouveau 0000:04:00.0: Load detected on output B [ 55.910015] [drm] nouveau 0000:04:00.0: Load detected on output B [ 56.113348] [drm] nouveau 0000:04:00.0: Load detected on output B [ 56.373348] [drm] nouveau 0000:04:00.0: Load detected on output B [ 56.576681] [drm] nouveau 0000:04:00.0: Load detected on output B [ 56.836682] [drm] nouveau 0000:04:00.0: Load detected on output B [ 57.040015] [drm] nouveau 0000:04:00.0: Load detected on output B [ 57.303348] [drm] nouveau 0000:04:00.0: Load detected on output B [ 57.506681] [drm] nouveau 0000:04:00.0: Load detected on output B [ 57.766681] [drm] nouveau 0000:04:00.0: Load detected on output B [ 57.970017] [drm] nouveau 0000:04:00.0: Load detected on output B [ 58.230014] [drm] nouveau 0000:04:00.0: Load detected on output B [ 58.433348] [drm] nouveau 0000:04:00.0: Load detected on output B [ 58.693348] [drm] nouveau 0000:04:00.0: Load detected on output B [ 58.896681] [drm] nouveau 0000:04:00.0: Load detected on output B [ 59.156681] [drm] nouveau 0000:04:00.0: Load detected on output B [ 59.360024] [drm] nouveau 0000:04:00.0: Load detected on output B [ 59.620014] [drm] nouveau 0000:04:00.0: Load detected on output B [ 59.823347] [drm] nouveau 0000:04:00.0: Load detected on output B [ 60.083348] [drm] nouveau 0000:04:00.0: Load detected on output B [ 60.286680] [drm] nouveau 0000:04:00.0: Load detected on output B [ 60.560014] [drm] nouveau 0000:04:00.0: Load detected on output B [ 60.763347] [drm] nouveau 0000:04:00.0: Load detected on output B [ 61.023348] [drm] nouveau 0000:04:00.0: Load detected on output B [ 61.226681] [drm] nouveau 0000:04:00.0: Load detected on output B [ 61.486680] [drm] nouveau 0000:04:00.0: Load detected on output B [ 61.690016] [drm] nouveau 0000:04:00.0: Load detected on output B [ 61.950014] [drm] nouveau 0000:04:00.0: Load detected on output B [ 62.153347] [drm] nouveau 0000:04:00.0: Load detected on output B [ 62.413348] [drm] nouveau 0000:04:00.0: Load detected on output B [ 62.616680] [drm] nouveau 0000:04:00.0: Load detected on output B [ 62.876681] [drm] nouveau 0000:04:00.0: Load detected on output B [ 63.080014] [drm] nouveau 0000:04:00.0: Load detected on output B [ 63.340014] [drm] nouveau 0000:04:00.0: Load detected on output B [ 63.543347] [drm] nouveau 0000:04:00.0: Load detected on output B [ 63.803347] [drm] nouveau 0000:04:00.0: Load detected on output B [ 64.006681] [drm] nouveau 0000:04:00.0: Load detected on output B [ 64.266680] [drm] nouveau 0000:04:00.0: Load detected on output B [ 64.470013] [drm] nouveau 0000:04:00.0: Load detected on output B [ 64.730013] [drm] nouveau 0000:04:00.0: Load detected on output B [ 64.933347] [drm] nouveau 0000:04:00.0: Load detected on output B [ 65.193347] [drm] nouveau 0000:04:00.0: Load detected on output B [ 65.396680] [drm] nouveau 0000:04:00.0: Load detected on output B [ 65.656681] [drm] nouveau 0000:04:00.0: Load detected on output B [ 65.860013] [drm] nouveau 0000:04:00.0: Load detected on output B [ 66.120013] [drm] nouveau 0000:04:00.0: Load detected on output B [ 66.323346] [drm] nouveau 0000:04:00.0: Load detected on output B [ 66.583346] [drm] nouveau 0000:04:00.0: Load detected on output B [ 66.786680] [drm] nouveau 0000:04:00.0: Load detected on output B [ 67.046680] [drm] nouveau 0000:04:00.0: Load detected on output B [ 67.250012] [drm] nouveau 0000:04:00.0: Load detected on output B [ 67.510013] [drm] nouveau 0000:04:00.0: Load detected on output B [ 67.713346] [drm] nouveau 0000:04:00.0: Load detected on output B [ 67.973348] [drm] nouveau 0000:04:00.0: Load detected on output B [ 68.176680] [drm] nouveau 0000:04:00.0: Load detected on output B [ 68.436680] [drm] nouveau 0000:04:00.0: Load detected on output B [ 68.640013] [drm] nouveau 0000:04:00.0: Load detected on output B [ 68.900013] [drm] nouveau 0000:04:00.0: Load detected on output B [ 69.103345] [drm] nouveau 0000:04:00.0: Load detected on output B [ 69.363347] [drm] nouveau 0000:04:00.0: Load detected on output B [ 69.566680] [drm] nouveau 0000:04:00.0: Load detected on output B [ 69.826679] [drm] nouveau 0000:04:00.0: Load detected on output B [ 70.030013] [drm] nouveau 0000:04:00.0: Load detected on output B [ 70.290013] [drm] nouveau 0000:04:00.0: Load detected on output B [ 70.500018] [drm] nouveau 0000:04:00.0: Load detected on output B [ 70.760013] [drm] nouveau 0000:04:00.0: Load detected on output B [ 70.963346] [drm] nouveau 0000:04:00.0: Load detected on output B [ 71.223347] [drm] nouveau 0000:04:00.0: Load detected on output B [ 71.426680] [drm] nouveau 0000:04:00.0: Load detected on output B [ 71.686682] [drm] nouveau 0000:04:00.0: Load detected on output B [ 71.890012] [drm] nouveau 0000:04:00.0: Load detected on output B [ 72.150013] [drm] nouveau 0000:04:00.0: Load detected on output B [ 72.353346] [drm] nouveau 0000:04:00.0: Load detected on output B [ 72.613346] [drm] nouveau 0000:04:00.0: Load detected on output B [ 72.816679] [drm] nouveau 0000:04:00.0: Load detected on output B [ 73.076680] [drm] nouveau 0000:04:00.0: Load detected on output B [ 73.280012] [drm] nouveau 0000:04:00.0: Load detected on output B [ 73.540016] [drm] nouveau 0000:04:00.0: Load detected on output B [ 73.743346] [drm] nouveau 0000:04:00.0: Load detected on output B [ 74.003349] [drm] nouveau 0000:04:00.0: Load detected on output B [ 74.206705] [drm] nouveau 0000:04:00.0: Load detected on output B [ 74.466679] [drm] nouveau 0000:04:00.0: Load detected on output B [ 74.670014] [drm] nouveau 0000:04:00.0: Load detected on output B [ 74.930013] [drm] nouveau 0000:04:00.0: Load detected on output B [ 75.133346] [drm] nouveau 0000:04:00.0: Load detected on output B [ 75.393351] [drm] nouveau 0000:04:00.0: Load detected on output B [ 75.606680] [drm] nouveau 0000:04:00.0: Load detected on output B [ 75.866678] [drm] nouveau 0000:04:00.0: Load detected on output B [ 76.070012] [drm] nouveau 0000:04:00.0: Load detected on output B [ 76.330012] [drm] nouveau 0000:04:00.0: Load detected on output B [ 76.533355] [drm] nouveau 0000:04:00.0: Load detected on output B [ 76.793346] [drm] nouveau 0000:04:00.0: Load detected on output B [ 76.996681] [drm] nouveau 0000:04:00.0: Load detected on output B [ 77.260012] [drm] nouveau 0000:04:00.0: Load detected on output B [ 77.463345] [drm] nouveau 0000:04:00.0: Load detected on output B [ 77.723346] [drm] nouveau 0000:04:00.0: Load detected on output B [ 77.926680] [drm] nouveau 0000:04:00.0: Load detected on output B [ 78.186682] [drm] nouveau 0000:04:00.0: Load detected on output B [ 78.390012] [drm] nouveau 0000:04:00.0: Load detected on output B [ 78.650012] [drm] nouveau 0000:04:00.0: Load detected on output B [ 78.853345] [drm] nouveau 0000:04:00.0: Load detected on output B [ 79.113345] [drm] nouveau 0000:04:00.0: Load detected on output B [ 79.316678] [drm] nouveau 0000:04:00.0: Load detected on output B [ 79.576679] [drm] nouveau 0000:04:00.0: Load detected on output B [ 79.780011] [drm] nouveau 0000:04:00.0: Load detected on output B [ 80.040012] [drm] nouveau 0000:04:00.0: Load detected on output B [ 80.243346] [drm] nouveau 0000:04:00.0: Load detected on output B [ 80.503346] [drm] nouveau 0000:04:00.0: Load detected on output B [ 80.723344] [drm] nouveau 0000:04:00.0: Load detected on output B [ 80.983346] [drm] nouveau 0000:04:00.0: Load detected on output B [ 81.186681] [drm] nouveau 0000:04:00.0: Load detected on output B [ 81.446679] [drm] nouveau 0000:04:00.0: Load detected on output B [ 81.650012] [drm] nouveau 0000:04:00.0: Load detected on output B [ 81.910012] [drm] nouveau 0000:04:00.0: Load detected on output B [ 82.113348] [drm] nouveau 0000:04:00.0: Load detected on output B [ 82.373345] [drm] nouveau 0000:04:00.0: Load detected on output B [ 82.580011] [drm] nouveau 0000:04:00.0: Load detected on output B [ 82.840012] [drm] nouveau 0000:04:00.0: Load detected on output B [ 83.043345] [drm] nouveau 0000:04:00.0: Load detected on output B [ 83.303346] [drm] nouveau 0000:04:00.0: Load detected on output B [ 83.506678] [drm] nouveau 0000:04:00.0: Load detected on output B [ 83.766679] [drm] nouveau 0000:04:00.0: Load detected on output B [ 83.970012] [drm] nouveau 0000:04:00.0: Load detected on output B [ 84.230012] [drm] nouveau 0000:04:00.0: Load detected on output B [ 84.433345] [drm] nouveau 0000:04:00.0: Load detected on output B [ 84.693346] [drm] nouveau 0000:04:00.0: Load detected on output B [ 84.896677] [drm] nouveau 0000:04:00.0: Load detected on output B [ 85.156678] [drm] nouveau 0000:04:00.0: Load detected on output B [ 85.360011] [drm] nouveau 0000:04:00.0: Load detected on output B [ 85.633345] [drm] nouveau 0000:04:00.0: Load detected on output B [ 85.836678] [drm] nouveau 0000:04:00.0: Load detected on output B [ 86.096678] [drm] nouveau 0000:04:00.0: Load detected on output B [ 86.300011] [drm] nouveau 0000:04:00.0: Load detected on output B [ 86.560012] [drm] nouveau 0000:04:00.0: Load detected on output B [ 86.763344] [drm] nouveau 0000:04:00.0: Load detected on output B [ 87.023347] [drm] nouveau 0000:04:00.0: Load detected on output B [ 87.226678] [drm] nouveau 0000:04:00.0: Load detected on output B [ 87.486678] [drm] nouveau 0000:04:00.0: Load detected on output B [ 87.690014] [drm] nouveau 0000:04:00.0: Load detected on output B [ 87.950012] [drm] nouveau 0000:04:00.0: Load detected on output B [ 88.153344] [drm] nouveau 0000:04:00.0: Load detected on output B [ 88.413345] [drm] nouveau 0000:04:00.0: Load detected on output B [ 88.616678] [drm] nouveau 0000:04:00.0: Load detected on output B [ 88.876678] [drm] nouveau 0000:04:00.0: Load detected on output B [ 89.080012] [drm] nouveau 0000:04:00.0: Load detected on output B [ 89.340012] [drm] nouveau 0000:04:00.0: Load detected on output B [ 89.543349] [drm] nouveau 0000:04:00.0: Load detected on output B [ 89.803345] [drm] nouveau 0000:04:00.0: Load detected on output B [ 90.006679] [drm] nouveau 0000:04:00.0: Load detected on output B [ 90.266678] [drm] nouveau 0000:04:00.0: Load detected on output B [ 90.470010] [drm] nouveau 0000:04:00.0: Load detected on output B [ 90.750012] [drm] nouveau 0000:04:00.0: Load detected on output B [ 90.953343] [drm] nouveau 0000:04:00.0: Load detected on output B [ 91.213349] [drm] nouveau 0000:04:00.0: Load detected on output B [ 91.416678] [drm] nouveau 0000:04:00.0: Load detected on output B [ 91.676678] [drm] nouveau 0000:04:00.0: Load detected on output B [ 91.880010] [drm] nouveau 0000:04:00.0: Load detected on output B [ 92.140011] [drm] nouveau 0000:04:00.0: Load detected on output B [ 92.343344] [drm] nouveau 0000:04:00.0: Load detected on output B [ 92.603344] [drm] nouveau 0000:04:00.0: Load detected on output B [ 92.806677] [drm] nouveau 0000:04:00.0: Load detected on output B [ 93.066678] [drm] nouveau 0000:04:00.0: Load detected on output B [ 93.270020] [drm] nouveau 0000:04:00.0: Load detected on output B [ 93.530011] [drm] nouveau 0000:04:00.0: Load detected on output B [ 93.733344] [drm] nouveau 0000:04:00.0: Load detected on output B [ 93.993344] [drm] nouveau 0000:04:00.0: Load detected on output B [ 94.196677] [drm] nouveau 0000:04:00.0: Load detected on output B [ 94.456677] [drm] nouveau 0000:04:00.0: Load detected on output B [ 94.660010] [drm] nouveau 0000:04:00.0: Load detected on output B [ 94.920010] [drm] nouveau 0000:04:00.0: Load detected on output B [ 95.123344] [drm] nouveau 0000:04:00.0: Load detected on output B [ 95.383344] [drm] nouveau 0000:04:00.0: Load detected on output B [ 95.586677] [drm] nouveau 0000:04:00.0: Load detected on output B [ 95.850011] [drm] nouveau 0000:04:00.0: Load detected on output B [ 96.053344] [drm] nouveau 0000:04:00.0: Load detected on output B [ 96.313345] [drm] nouveau 0000:04:00.0: Load detected on output B [ 96.516676] [drm] nouveau 0000:04:00.0: Load detected on output B [ 96.776677] [drm] nouveau 0000:04:00.0: Load detected on output B [ 96.980010] [drm] nouveau 0000:04:00.0: Load detected on output B [ 97.240011] [drm] nouveau 0000:04:00.0: Load detected on output B [ 97.443344] [drm] nouveau 0000:04:00.0: Load detected on output B [ 97.703344] [drm] nouveau 0000:04:00.0: Load detected on output B [ 97.906676] [drm] nouveau 0000:04:00.0: Load detected on output B [ 98.166677] [drm] nouveau 0000:04:00.0: Load detected on output B [ 98.370010] [drm] nouveau 0000:04:00.0: Load detected on output B [ 98.630011] [drm] nouveau 0000:04:00.0: Load detected on output B [ 98.833344] [drm] nouveau 0000:04:00.0: Load detected on output B [ 99.093343] [drm] nouveau 0000:04:00.0: Load detected on output B [ 99.296677] [drm] nouveau 0000:04:00.0: Load detected on output B [ 99.556678] [drm] nouveau 0000:04:00.0: Load detected on output B [ 99.760010] [drm] nouveau 0000:04:00.0: Load detected on output B [ 100.020014] [drm] nouveau 0000:04:00.0: Load detected on output B [ 100.223344] [drm] nouveau 0000:04:00.0: Load detected on output B [ 100.483344] [drm] nouveau 0000:04:00.0: Load detected on output B [ 100.703344] [drm] nouveau 0000:04:00.0: Load detected on output B [ 100.963344] [drm] nouveau 0000:04:00.0: Load detected on output B [ 101.166676] [drm] nouveau 0000:04:00.0: Load detected on output B [ 101.430010] [drm] nouveau 0000:04:00.0: Load detected on output B [ 101.633350] [drm] nouveau 0000:04:00.0: Load detected on output B [ 101.893343] [drm] nouveau 0000:04:00.0: Load detected on output B [ 102.096677] [drm] nouveau 0000:04:00.0: Load detected on output B [ 102.356677] [drm] nouveau 0000:04:00.0: Load detected on output B [ 102.560010] [drm] nouveau 0000:04:00.0: Load detected on output B [ 102.820010] [drm] nouveau 0000:04:00.0: Load detected on output B [ 103.023347] [drm] nouveau 0000:04:00.0: Load detected on output B [ 103.283346] [drm] nouveau 0000:04:00.0: Load detected on output B [ 103.486676] [drm] nouveau 0000:04:00.0: Load detected on output B [ 103.746677] [drm] nouveau 0000:04:00.0: Load detected on output B [ 103.950013] [drm] nouveau 0000:04:00.0: Load detected on output B [ 104.210014] [drm] nouveau 0000:04:00.0: Load detected on output B [ 104.413342] [drm] nouveau 0000:04:00.0: Load detected on output B [ 104.673344] [drm] nouveau 0000:04:00.0: Load detected on output B [ 104.876679] [drm] nouveau 0000:04:00.0: Load detected on output B [ 105.136676] [drm] nouveau 0000:04:00.0: Load detected on output B [ 105.340010] [drm] nouveau 0000:04:00.0: Load detected on output B [ 105.600010] [drm] nouveau 0000:04:00.0: Load detected on output B [ 105.813343] [drm] nouveau 0000:04:00.0: Load detected on output B [ 106.073343] [drm] nouveau 0000:04:00.0: Load detected on output B [ 106.276677] [drm] nouveau 0000:04:00.0: Load detected on output B [ 106.536676] [drm] nouveau 0000:04:00.0: Load detected on output B [ 106.740010] [drm] nouveau 0000:04:00.0: Load detected on output B [ 107.000010] [drm] nouveau 0000:04:00.0: Load detected on output B [ 107.203343] [drm] nouveau 0000:04:00.0: Load detected on output B [ 107.463343] [drm] nouveau 0000:04:00.0: Load detected on output B [ 107.666676] [drm] nouveau 0000:04:00.0: Load detected on output B [ 107.926676] [drm] nouveau 0000:04:00.0: Load detected on output B [ 108.130009] [drm] nouveau 0000:04:00.0: Load detected on output B [ 108.390010] [drm] nouveau 0000:04:00.0: Load detected on output B [ 108.593342] [drm] nouveau 0000:04:00.0: Load detected on output B [ 108.853343] [drm] nouveau 0000:04:00.0: Load detected on output B [ 109.056676] [drm] nouveau 0000:04:00.0: Load detected on output B [ 109.316676] [drm] nouveau 0000:04:00.0: Load detected on output B [ 109.520009] [drm] nouveau 0000:04:00.0: Load detected on output B [ 109.780010] [drm] nouveau 0000:04:00.0: Load detected on output B [ 109.983342] [drm] nouveau 0000:04:00.0: Load detected on output B [ 110.246677] [drm] nouveau 0000:04:00.0: Load detected on output B [ 110.450009] [drm] nouveau 0000:04:00.0: Load detected on output B [ 110.730010] [drm] nouveau 0000:04:00.0: Load detected on output B [ 110.933342] [drm] nouveau 0000:04:00.0: Load detected on output B [ 111.193343] [drm] nouveau 0000:04:00.0: Load detected on output B [ 111.396676] [drm] nouveau 0000:04:00.0: Load detected on output B [ 111.656676] [drm] nouveau 0000:04:00.0: Load detected on output B [ 111.860008] [drm] nouveau 0000:04:00.0: Load detected on output B [ 112.120009] [drm] nouveau 0000:04:00.0: Load detected on output B [ 112.323342] [drm] nouveau 0000:04:00.0: Load detected on output B [ 112.583342] [drm] nouveau 0000:04:00.0: Load detected on output B [ 112.786676] [drm] nouveau 0000:04:00.0: Load detected on output B [ 113.046676] [drm] nouveau 0000:04:00.0: Load detected on output B [ 113.250014] [drm] nouveau 0000:04:00.0: Load detected on output B [ 113.513342] [drm] nouveau 0000:04:00.0: Load detected on output B [ 113.716675] [drm] nouveau 0000:04:00.0: Load detected on output B [ 113.976676] [drm] nouveau 0000:04:00.0: Load detected on output B [ 114.180010] [drm] nouveau 0000:04:00.0: Load detected on output B [ 114.440009] [drm] nouveau 0000:04:00.0: Load detected on output B [ 114.643342] [drm] nouveau 0000:04:00.0: Load detected on output B [ 114.903342] [drm] nouveau 0000:04:00.0: Load detected on output B [ 115.106675] [drm] nouveau 0000:04:00.0: Load detected on output B [ 115.366676] [drm] nouveau 0000:04:00.0: Load detected on output B [ 115.570010] [drm] nouveau 0000:04:00.0: Load detected on output B [ 115.840009] [drm] nouveau 0000:04:00.0: Load detected on output B [ 116.043343] [drm] nouveau 0000:04:00.0: Load detected on output B [ 116.303342] [drm] nouveau 0000:04:00.0: Load detected on output B [ 116.506675] [drm] nouveau 0000:04:00.0: Load detected on output B [ 116.766676] [drm] nouveau 0000:04:00.0: Load detected on output B [ 116.970008] [drm] nouveau 0000:04:00.0: Load detected on output B [ 117.230009] [drm] nouveau 0000:04:00.0: Load detected on output B [ 117.433341] [drm] nouveau 0000:04:00.0: Load detected on output B [ 117.693343] [drm] nouveau 0000:04:00.0: Load detected on output B [ 117.896677] [drm] nouveau 0000:04:00.0: Load detected on output B [ 118.156676] [drm] nouveau 0000:04:00.0: Load detected on output B [ 118.360009] [drm] nouveau 0000:04:00.0: Load detected on output B [ 118.620008] [drm] nouveau 0000:04:00.0: Load detected on output B [ 118.823342] [drm] nouveau 0000:04:00.0: Load detected on output B [ 119.083341] [drm] nouveau 0000:04:00.0: Load detected on output B [ 119.286675] [drm] nouveau 0000:04:00.0: Load detected on output B [ 119.546676] [drm] nouveau 0000:04:00.0: Load detected on output B [ 119.750008] [drm] nouveau 0000:04:00.0: Load detected on output B [ 120.010007] [drm] nouveau 0000:04:00.0: Load detected on output B [ 120.213346] [drm] nouveau 0000:04:00.0: Load detected on output B [ 120.473342] [drm] nouveau 0000:04:00.0: Load detected on output B [ 120.683347] [drm] nouveau 0000:04:00.0: Load detected on output B [ 120.946675] [drm] nouveau 0000:04:00.0: Load detected on output B [ 121.150008] [drm] nouveau 0000:04:00.0: Load detected on output B [ 121.410008] [drm] nouveau 0000:04:00.0: Load detected on output B [ 121.613342] [drm] nouveau 0000:04:00.0: Load detected on output B [ 121.873341] [drm] nouveau 0000:04:00.0: Load detected on output B [ 122.076675] [drm] nouveau 0000:04:00.0: Load detected on output B [ 122.336675] [drm] nouveau 0000:04:00.0: Load detected on output B [ 122.540008] [drm] nouveau 0000:04:00.0: Load detected on output B [ 122.800008] [drm] nouveau 0000:04:00.0: Load detected on output B [ 123.003343] [drm] nouveau 0000:04:00.0: Load detected on output B [ 123.263346] [drm] nouveau 0000:04:00.0: Load detected on output B [ 123.466675] [drm] nouveau 0000:04:00.0: Load detected on output B [ 123.726675] [drm] nouveau 0000:04:00.0: Load detected on output B [ 123.930007] [drm] nouveau 0000:04:00.0: Load detected on output B [ 124.190011] [drm] nouveau 0000:04:00.0: Load detected on output B [ 124.393341] [drm] nouveau 0000:04:00.0: Load detected on output B [ 124.653344] [drm] nouveau 0000:04:00.0: Load detected on output B [ 124.856674] [drm] nouveau 0000:04:00.0: Load detected on output B [ 125.116675] [drm] nouveau 0000:04:00.0: Load detected on output B [ 125.320008] [drm] nouveau 0000:04:00.0: Load detected on output B [ 125.580008] [drm] nouveau 0000:04:00.0: Load detected on output B [ 125.793342] [drm] nouveau 0000:04:00.0: Load detected on output B [ 126.053341] [drm] nouveau 0000:04:00.0: Load detected on output B [ 126.256677] [drm] nouveau 0000:04:00.0: Load detected on output B [ 126.516675] [drm] nouveau 0000:04:00.0: Load detected on output B [ 126.720008] [drm] nouveau 0000:04:00.0: Load detected on output B [ 126.980009] [drm] nouveau 0000:04:00.0: Load detected on output B [ 127.183348] [drm] nouveau 0000:04:00.0: Load detected on output B [ 127.443341] [drm] nouveau 0000:04:00.0: Load detected on output B [ 127.646674] [drm] nouveau 0000:04:00.0: Load detected on output B [ 127.906677] [drm] nouveau 0000:04:00.0: Load detected on output B [ 128.110007] [drm] nouveau 0000:04:00.0: Load detected on output B [ 128.370007] [drm] nouveau 0000:04:00.0: Load detected on output B [ 128.573341] [drm] nouveau 0000:04:00.0: Load detected on output B [ 128.833341] [drm] nouveau 0000:04:00.0: Load detected on output B [ 129.036674] [drm] nouveau 0000:04:00.0: Load detected on output B [ 129.296675] [drm] nouveau 0000:04:00.0: Load detected on output B [ 129.500006] [drm] nouveau 0000:04:00.0: Load detected on output B [ 129.760007] [drm] nouveau 0000:04:00.0: Load detected on output B [ 129.963340] [drm] nouveau 0000:04:00.0: Load detected on output B [ 130.223343] [drm] nouveau 0000:04:00.0: Load detected on output B [ 130.426674] [drm] nouveau 0000:04:00.0: Load detected on output B [ 130.686677] [drm] nouveau 0000:04:00.0: Load detected on output B [ 130.916675] [drm] nouveau 0000:04:00.0: Load detected on output B [ 131.176674] [drm] nouveau 0000:04:00.0: Load detected on output B [ 131.380008] [drm] nouveau 0000:04:00.0: Load detected on output B [ 131.640008] [drm] nouveau 0000:04:00.0: Load detected on output B [ 131.843340] [drm] nouveau 0000:04:00.0: Load detected on output B [ 132.103341] [drm] nouveau 0000:04:00.0: Load detected on output B [ 132.306674] [drm] nouveau 0000:04:00.0: Load detected on output B [ 132.566681] [drm] nouveau 0000:04:00.0: Load detected on output B [ 132.770007] [drm] nouveau 0000:04:00.0: Load detected on output B [ 133.030011] [drm] nouveau 0000:04:00.0: Load detected on output B [ 133.233340] [drm] nouveau 0000:04:00.0: Load detected on output B [ 133.493341] [drm] nouveau 0000:04:00.0: Load detected on output B [ 133.696673] [drm] nouveau 0000:04:00.0: Load detected on output B [ 133.956674] [drm] nouveau 0000:04:00.0: Load detected on output B [ 134.160007] [drm] nouveau 0000:04:00.0: Load detected on output B [ 134.420007] [drm] nouveau 0000:04:00.0: Load detected on output B [ 134.623341] [drm] nouveau 0000:04:00.0: Load detected on output B [ 134.883343] [drm] nouveau 0000:04:00.0: Load detected on output B [ 135.086674] [drm] nouveau 0000:04:00.0: Load detected on output B [ 135.346674] [drm] nouveau 0000:04:00.0: Load detected on output B [ 135.550006] [drm] nouveau 0000:04:00.0: Load detected on output B [ 135.823341] [drm] nouveau 0000:04:00.0: Load detected on output B [ 136.026674] [drm] nouveau 0000:04:00.0: Load detected on output B [ 136.286674] [drm] nouveau 0000:04:00.0: Load detected on output B [ 136.490006] [drm] nouveau 0000:04:00.0: Load detected on output B [ 136.750008] [drm] nouveau 0000:04:00.0: Load detected on output B [ 136.953340] [drm] nouveau 0000:04:00.0: Load detected on output B [ 137.213344] [drm] nouveau 0000:04:00.0: Load detected on output B [ 137.416673] [drm] nouveau 0000:04:00.0: Load detected on output B [ 137.676674] [drm] nouveau 0000:04:00.0: Load detected on output B [ 137.880006] [drm] nouveau 0000:04:00.0: Load detected on output B [ 138.140007] [drm] nouveau 0000:04:00.0: Load detected on output B [ 138.343341] [drm] nouveau 0000:04:00.0: Load detected on output B [ 138.603341] [drm] nouveau 0000:04:00.0: Load detected on output B [ 138.806673] [drm] nouveau 0000:04:00.0: Load detected on output B [ 139.066673] [drm] nouveau 0000:04:00.0: Load detected on output B [ 139.270007] [drm] nouveau 0000:04:00.0: Load detected on output B [ 139.530007] [drm] nouveau 0000:04:00.0: Load detected on output B [ 139.733340] [drm] nouveau 0000:04:00.0: Load detected on output B [ 139.993341] [drm] nouveau 0000:04:00.0: Load detected on output B [ 140.196674] [drm] nouveau 0000:04:00.0: Load detected on output B [ 140.456673] [drm] nouveau 0000:04:00.0: Load detected on output B [ 140.660007] [drm] nouveau 0000:04:00.0: Load detected on output B [ 140.943390] [drm] nouveau 0000:04:00.0: Load detected on output B [ 141.146675] [drm] nouveau 0000:04:00.0: Load detected on output B [ 141.406672] [drm] nouveau 0000:04:00.0: Load detected on output B [ 141.610006] [drm] nouveau 0000:04:00.0: Load detected on output B [ 141.870006] [drm] nouveau 0000:04:00.0: Load detected on output B [ 142.073342] [drm] nouveau 0000:04:00.0: Load detected on output B [ 142.333340] [drm] nouveau 0000:04:00.0: Load detected on output B [ 142.536673] [drm] nouveau 0000:04:00.0: Load detected on output B [ 142.796674] [drm] nouveau 0000:04:00.0: Load detected on output B [ 143.000008] [drm] nouveau 0000:04:00.0: Load detected on output B [ 143.263340] [drm] nouveau 0000:04:00.0: Load detected on output B [ 143.466672] [drm] nouveau 0000:04:00.0: Load detected on output B [ 143.726673] [drm] nouveau 0000:04:00.0: Load detected on output B [ 143.930006] [drm] nouveau 0000:04:00.0: Load detected on output B [ 144.190010] [drm] nouveau 0000:04:00.0: Load detected on output B [ 144.393340] [drm] nouveau 0000:04:00.0: Load detected on output B [ 144.656672] [drm] nouveau 0000:04:00.0: Load detected on output B [ 144.860006] [drm] nouveau 0000:04:00.0: Load detected on output B [ 145.120007] [drm] nouveau 0000:04:00.0: Load detected on output B [ 145.323340] [drm] nouveau 0000:04:00.0: Load detected on output B [ 145.583342] [drm] nouveau 0000:04:00.0: Load detected on output B [ 145.786672] [drm] nouveau 0000:04:00.0: Load detected on output B [ 146.060006] [drm] nouveau 0000:04:00.0: Load detected on output B [ 146.263339] [drm] nouveau 0000:04:00.0: Load detected on output B [ 146.523341] [drm] nouveau 0000:04:00.0: Load detected on output B [ 146.726673] [drm] nouveau 0000:04:00.0: Load detected on output B [ 146.986673] [drm] nouveau 0000:04:00.0: Load detected on output B [ 147.190009] [drm] nouveau 0000:04:00.0: Load detected on output B [ 147.450006] [drm] nouveau 0000:04:00.0: Load detected on output B [ 147.653339] [drm] nouveau 0000:04:00.0: Load detected on output B [ 147.913339] [drm] nouveau 0000:04:00.0: Load detected on output B [ 148.116673] [drm] nouveau 0000:04:00.0: Load detected on output B [ 148.376673] [drm] nouveau 0000:04:00.0: Load detected on output B [ 148.580011] [drm] nouveau 0000:04:00.0: Load detected on output B [ 148.840006] [drm] nouveau 0000:04:00.0: Load detected on output B [ 149.043339] [drm] nouveau 0000:04:00.0: Load detected on output B [ 149.303339] [drm] nouveau 0000:04:00.0: Load detected on output B [ 149.506672] [drm] nouveau 0000:04:00.0: Load detected on output B [ 149.766672] [drm] nouveau 0000:04:00.0: Load detected on output B [ 149.970005] [drm] nouveau 0000:04:00.0: Load detected on output B [ 150.230006] [drm] nouveau 0000:04:00.0: Load detected on output B [ 150.433339] [drm] nouveau 0000:04:00.0: Load detected on output B [ 150.693339] [drm] nouveau 0000:04:00.0: Load detected on output B [ 150.913340] [drm] nouveau 0000:04:00.0: Load detected on output B [ 151.173339] [drm] nouveau 0000:04:00.0: Load detected on output B [ 151.376672] [drm] nouveau 0000:04:00.0: Load detected on output B [ 151.636672] [drm] nouveau 0000:04:00.0: Load detected on output B [ 151.840005] [drm] nouveau 0000:04:00.0: Load detected on output B [ 152.100006] [drm] nouveau 0000:04:00.0: Load detected on output B [ 152.303339] [drm] nouveau 0000:04:00.0: Load detected on output B [ 152.563339] [drm] nouveau 0000:04:00.0: Load detected on output B [ 152.766671] [drm] nouveau 0000:04:00.0: Load detected on output B [ 153.026673] [drm] nouveau 0000:04:00.0: Load detected on output B [ 153.230007] [drm] nouveau 0000:04:00.0: Load detected on output B [ 153.490006] [drm] nouveau 0000:04:00.0: Load detected on output B [ 153.693339] [drm] nouveau 0000:04:00.0: Load detected on output B [ 153.953342] [drm] nouveau 0000:04:00.0: Load detected on output B [ 154.156672] [drm] nouveau 0000:04:00.0: Load detected on output B [ 154.416672] [drm] nouveau 0000:04:00.0: Load detected on output B [ 154.620006] [drm] nouveau 0000:04:00.0: Load detected on output B [ 154.880005] [drm] nouveau 0000:04:00.0: Load detected on output B [ 155.083339] [drm] nouveau 0000:04:00.0: Load detected on output B [ 155.343339] [drm] nouveau 0000:04:00.0: Load detected on output B [ 155.546671] [drm] nouveau 0000:04:00.0: Load detected on output B [ 155.806672] [drm] nouveau 0000:04:00.0: Load detected on output B [ 156.020005] [drm] nouveau 0000:04:00.0: Load detected on output B [ 156.280005] [drm] nouveau 0000:04:00.0: Load detected on output B [ 156.483338] [drm] nouveau 0000:04:00.0: Load detected on output B [ 156.743338] [drm] nouveau 0000:04:00.0: Load detected on output B [ 156.946672] [drm] nouveau 0000:04:00.0: Load detected on output B [ 157.206678] [drm] nouveau 0000:04:00.0: Load detected on output B [ 157.410005] [drm] nouveau 0000:04:00.0: Load detected on output B [ 157.670006] [drm] nouveau 0000:04:00.0: Load detected on output B [ 157.873338] [drm] nouveau 0000:04:00.0: Load detected on output B [ 158.133338] [drm] nouveau 0000:04:00.0: Load detected on output B [ 158.336672] [drm] nouveau 0000:04:00.0: Load detected on output B [ 158.596672] [drm] nouveau 0000:04:00.0: Load detected on output B [ 158.800004] [drm] nouveau 0000:04:00.0: Load detected on output B [ 159.060009] [drm] nouveau 0000:04:00.0: Load detected on output B [ 159.263338] [drm] nouveau 0000:04:00.0: Load detected on output B [ 159.523339] [drm] nouveau 0000:04:00.0: Load detected on output B [ 159.726671] [drm] nouveau 0000:04:00.0: Load detected on output B [ 159.986671] [drm] nouveau 0000:04:00.0: Load detected on output B [ 160.190008] [drm] nouveau 0000:04:00.0: Load detected on output B [ 160.450005] [drm] nouveau 0000:04:00.0: Load detected on output B [ 160.653338] [drm] nouveau 0000:04:00.0: Load detected on output B [ 160.940005] [drm] nouveau 0000:04:00.0: Load detected on output B [ 161.143339] [drm] nouveau 0000:04:00.0: Load detected on output B [ 161.403338] [drm] nouveau 0000:04:00.0: Load detected on output B [ 161.606671] [drm] nouveau 0000:04:00.0: Load detected on output B [ 161.866672] [drm] nouveau 0000:04:00.0: Load detected on output B [ 162.070005] [drm] nouveau 0000:04:00.0: Load detected on output B [ 162.330005] [drm] nouveau 0000:04:00.0: Load detected on output B [ 162.533337] [drm] nouveau 0000:04:00.0: Load detected on output B [ 162.793338] [drm] nouveau 0000:04:00.0: Load detected on output B [ 162.996670] [drm] nouveau 0000:04:00.0: Load detected on output B [ 163.256671] [drm] nouveau 0000:04:00.0: Load detected on output B [ 163.460004] [drm] nouveau 0000:04:00.0: Load detected on output B [ 163.720004] [drm] nouveau 0000:04:00.0: Load detected on output B [ 163.923337] [drm] nouveau 0000:04:00.0: Load detected on output B [ 164.183345] [drm] nouveau 0000:04:00.0: Load detected on output B [ 164.386670] [drm] nouveau 0000:04:00.0: Load detected on output B [ 164.646670] [drm] nouveau 0000:04:00.0: Load detected on output B [ 164.850004] [drm] nouveau 0000:04:00.0: Load detected on output B [ 165.110004] [drm] nouveau 0000:04:00.0: Load detected on output B [ 165.313338] [drm] nouveau 0000:04:00.0: Load detected on output B [ 165.573337] [drm] nouveau 0000:04:00.0: Load detected on output B [ 165.776671] [drm] nouveau 0000:04:00.0: Load detected on output B [ 166.050004] [drm] nouveau 0000:04:00.0: Load detected on output B [ 166.253337] [drm] nouveau 0000:04:00.0: Load detected on output B [ 166.513337] [drm] nouveau 0000:04:00.0: Load detected on output B [ 166.716670] [drm] nouveau 0000:04:00.0: Load detected on output B [ 166.976670] [drm] nouveau 0000:04:00.0: Load detected on output B [ 167.180003] [drm] nouveau 0000:04:00.0: Load detected on output B [ 167.440004] [drm] nouveau 0000:04:00.0: Load detected on output B [ 167.643337] [drm] nouveau 0000:04:00.0: Load detected on output B [ 167.903338] [drm] nouveau 0000:04:00.0: Load detected on output B [ 168.106670] [drm] nouveau 0000:04:00.0: Load detected on output B [ 168.366671] [drm] nouveau 0000:04:00.0: Load detected on output B [ 168.570004] [drm] nouveau 0000:04:00.0: Load detected on output B [ 168.830004] [drm] nouveau 0000:04:00.0: Load detected on output B [ 169.033341] [drm] nouveau 0000:04:00.0: Load detected on output B [ 169.293337] [drm] nouveau 0000:04:00.0: Load detected on output B [ 169.496671] [drm] nouveau 0000:04:00.0: Load detected on output B [ 169.756671] [drm] nouveau 0000:04:00.0: Load detected on output B [ 169.960004] [drm] nouveau 0000:04:00.0: Load detected on output B [ 170.220004] [drm] nouveau 0000:04:00.0: Load detected on output B [ 170.423337] [drm] nouveau 0000:04:00.0: Load detected on output B [ 170.683340] [drm] nouveau 0000:04:00.0: Load detected on output B [ 170.893337] [drm] nouveau 0000:04:00.0: Load detected on output B [ 171.166670] [drm] nouveau 0000:04:00.0: Load detected on output B [ 171.370004] [drm] nouveau 0000:04:00.0: Load detected on output B [ 171.630372] [drm] nouveau 0000:04:00.0: Load detected on output B [ 171.833337] [drm] nouveau 0000:04:00.0: Load detected on output B [ 172.093337] [drm] nouveau 0000:04:00.0: Load detected on output B [ 172.296671] [drm] nouveau 0000:04:00.0: Load detected on output B [ 172.560004] [drm] nouveau 0000:04:00.0: Load detected on output B [ 172.763337] [drm] nouveau 0000:04:00.0: Load detected on output B [ 173.026734] [drm] nouveau 0000:04:00.0: Load detected on output B [ 173.230005] [drm] nouveau 0000:04:00.0: Load detected on output B [ 173.490004] [drm] nouveau 0000:04:00.0: Load detected on output B [ 173.693337] [drm] nouveau 0000:04:00.0: Load detected on output B [ 173.953344] [drm] nouveau 0000:04:00.0: Load detected on output B [ 174.156670] [drm] nouveau 0000:04:00.0: Load detected on output B [ 174.416670] [drm] nouveau 0000:04:00.0: Load detected on output B [ 174.620016] [drm] nouveau 0000:04:00.0: Load detected on output B [ 174.896681] [drm] nouveau 0000:04:00.0: Load detected on output B [ 175.100009] [drm] nouveau 0000:04:00.0: Load detected on output B [ 175.366676] [drm] nouveau 0000:04:00.0: Load detected on output B [ 175.573343] [drm] nouveau 0000:04:00.0: Load detected on output B [ 175.840007] [drm] nouveau 0000:04:00.0: Load detected on output B [ 176.150008] [drm] nouveau 0000:04:00.0: Load detected on output B [ 176.426680] [drm] nouveau 0000:04:00.0: Load detected on output B [ 176.636679] [drm] nouveau 0000:04:00.0: Load detected on output B [ 176.966735] [drm] nouveau 0000:04:00.0: Load detected on output B [ 177.273405] [drm] nouveau 0000:04:00.0: Load detected on output B [ 177.683361] [drm] nouveau 0000:04:00.0: Load detected on output B [ 177.940012] [drm] nouveau 0000:04:00.0: Load detected on output B [ 178.210009] [drm] nouveau 0000:04:00.0: Load detected on output B [ 178.430014] [drm] nouveau 0000:04:00.0: Load detected on output B [ 178.733345] [drm] nouveau 0000:04:00.0: Load detected on output B [ 178.970027] [drm] nouveau 0000:04:00.0: Load detected on output B [ 179.313350] [drm] nouveau 0000:04:00.0: Load detected on output B [ 179.550045] [drm] nouveau 0000:04:00.0: Load detected on output B [ 179.850015] [drm] nouveau 0000:04:00.0: Load detected on output B [ 180.083345] [drm] nouveau 0000:04:00.0: Load detected on output B [ 180.396681] [drm] nouveau 0000:04:00.0: Load detected on output B [ 180.626753] [drm] nouveau 0000:04:00.0: Load detected on output B [ 180.943371] [drm] nouveau 0000:04:00.0: Load detected on output B [ 181.233347] [drm] nouveau 0000:04:00.0: Load detected on output B [ 181.530021] [drm] nouveau 0000:04:00.0: Load detected on output B [ 181.766714] [drm] nouveau 0000:04:00.0: Load detected on output B [ 182.073386] [drm] nouveau 0000:04:00.0: Load detected on output B [ 182.295416] [drm] nouveau 0000:04:00.0: Load detected on output B [ 182.593349] [drm] nouveau 0000:04:00.0: Load detected on output B [ 182.810828] [drm] nouveau 0000:04:00.0: Load detected on output B [ 183.103343] [drm] nouveau 0000:04:00.0: Load detected on output B [ 183.340012] [drm] nouveau 0000:04:00.0: Load detected on output B [ 183.630029] [drm] nouveau 0000:04:00.0: Load detected on output B [ 183.850063] [drm] nouveau 0000:04:00.0: Load detected on output B [ 184.146676] [drm] nouveau 0000:04:00.0: Load detected on output B [ 184.366748] [drm] nouveau 0000:04:00.0: Load detected on output B [ 184.663341] [drm] nouveau 0000:04:00.0: Load detected on output B [ 184.886694] [drm] nouveau 0000:04:00.0: Load detected on output B [ 185.176674] [drm] nouveau 0000:04:00.0: Load detected on output B [ 185.396683] [drm] nouveau 0000:04:00.0: Load detected on output B [ 185.686678] [drm] nouveau 0000:04:00.0: Load detected on output B [ 185.920013] [drm] nouveau 0000:04:00.0: Load detected on output B [ 186.236716] [drm] nouveau 0000:04:00.0: Load detected on output B [ 186.453346] [drm] nouveau 0000:04:00.0: Load detected on output B [ 186.750020] [drm] nouveau 0000:04:00.0: Load detected on output B [ 186.970013] [drm] nouveau 0000:04:00.0: Load detected on output B [ 187.260014] [drm] nouveau 0000:04:00.0: Load detected on output B [ 187.490026] [drm] nouveau 0000:04:00.0: Load detected on output B [ 187.796728] [drm] nouveau 0000:04:00.0: Load detected on output B [ 188.023387] [drm] nouveau 0000:04:00.0: Load detected on output B [ 188.330014] [drm] nouveau 0000:04:00.0: Load detected on output B [ 188.556678] [drm] nouveau 0000:04:00.0: Load detected on output B [ 188.870045] [drm] nouveau 0000:04:00.0: Load detected on output B [ 189.103345] [drm] nouveau 0000:04:00.0: Load detected on output B [ 189.406712] [drm] nouveau 0000:04:00.0: Load detected on output B [ 189.626743] [drm] nouveau 0000:04:00.0: Load detected on output B [ 189.920262] [drm] nouveau 0000:04:00.0: Load detected on output B [ 190.150055] [drm] nouveau 0000:04:00.0: Load detected on output B [ 190.466679] [drm] nouveau 0000:04:00.0: Load detected on output B [ 190.700020] [drm] nouveau 0000:04:00.0: Load detected on output B [ 190.980013] [drm] nouveau 0000:04:00.0: Load detected on output B [ 191.196807] [drm] nouveau 0000:04:00.0: Load detected on output B [ 191.510015] [drm] nouveau 0000:04:00.0: Load detected on output B [ 191.736674] [drm] nouveau 0000:04:00.0: Load detected on output B [ 192.046674] [drm] nouveau 0000:04:00.0: Load detected on output B [ 192.270061] [drm] nouveau 0000:04:00.0: Load detected on output B [ 192.563391] [drm] nouveau 0000:04:00.0: Load detected on output B [ 192.816721] [drm] nouveau 0000:04:00.0: Load detected on output B [ 193.120010] [drm] nouveau 0000:04:00.0: Load detected on output B [ 193.360015] [drm] nouveau 0000:04:00.0: Load detected on output B [ 193.680070] [drm] nouveau 0000:04:00.0: Load detected on output B [ 193.923345] [drm] nouveau 0000:04:00.0: Load detected on output B [ 194.230017] [drm] nouveau 0000:04:00.0: Load detected on output B [ 194.460010] [drm] nouveau 0000:04:00.0: Load detected on output B [ 194.770029] [drm] nouveau 0000:04:00.0: Load detected on output B [ 195.013375] [drm] nouveau 0000:04:00.0: Load detected on output B [ 195.326683] [drm] nouveau 0000:04:00.0: Load detected on output B [ 195.576716] [drm] nouveau 0000:04:00.0: Load detected on output B [ 195.880012] [drm] nouveau 0000:04:00.0: Load detected on output B [ 196.170015] [drm] nouveau 0000:04:00.0: Load detected on output B [ 196.476672] [drm] nouveau 0000:04:00.0: Load detected on output B [ 196.690009] [drm] nouveau 0000:04:00.0: Load detected on output B [ 196.976672] [drm] nouveau 0000:04:00.0: Load detected on output B [ 197.200009] [drm] nouveau 0000:04:00.0: Load detected on output B [ 197.470007] [drm] nouveau 0000:04:00.0: Load detected on output B [ 197.676674] [drm] nouveau 0000:04:00.0: Load detected on output B [ 197.943343] [drm] nouveau 0000:04:00.0: Load detected on output B [ 198.153340] [drm] nouveau 0000:04:00.0: Load detected on output B [ 198.433356] [drm] nouveau 0000:04:00.0: Load detected on output B [ 198.650005] [drm] nouveau 0000:04:00.0: Load detected on output B [ 198.923338] [drm] nouveau 0000:04:00.0: Load detected on output B [ 199.130012] [drm] nouveau 0000:04:00.0: Load detected on output B [ 199.403339] [drm] nouveau 0000:04:00.0: Load detected on output B [ 199.613338] [drm] nouveau 0000:04:00.0: Load detected on output B [ 199.886677] [drm] nouveau 0000:04:00.0: Load detected on output B [ 200.093372] [drm] nouveau 0000:04:00.0: Load detected on output B [ 200.370011] [drm] nouveau 0000:04:00.0: Load detected on output B [ 200.600014] [drm] nouveau 0000:04:00.0: Load detected on output B [ 200.880006] [drm] nouveau 0000:04:00.0: Load detected on output B [ 201.096677] [drm] nouveau 0000:04:00.0: Load detected on output B [ 201.630004] [drm] nouveau 0000:04:00.0: Load detected on output B [ 201.840006] [drm] nouveau 0000:04:00.0: Load detected on output B [ 202.113341] [drm] nouveau 0000:04:00.0: Load detected on output B [ 202.326675] [drm] nouveau 0000:04:00.0: Load detected on output B [ 202.600106] [drm] nouveau 0000:04:00.0: Load detected on output B [ 202.806673] [drm] nouveau 0000:04:00.0: Load detected on output B [ 203.080007] [drm] nouveau 0000:04:00.0: Load detected on output B [ 203.290006] [drm] nouveau 0000:04:00.0: Load detected on output B [ 203.563341] [drm] nouveau 0000:04:00.0: Load detected on output B [ 203.770009] [drm] nouveau 0000:04:00.0: Load detected on output B [ 204.043338] [drm] nouveau 0000:04:00.0: Load detected on output B [ 204.256671] [drm] nouveau 0000:04:00.0: Load detected on output B [ 204.526679] [drm] nouveau 0000:04:00.0: Load detected on output B [ 204.750008] [drm] nouveau 0000:04:00.0: Load detected on output B [ 205.033712] [drm] nouveau 0000:04:00.0: Load detected on output B [ 205.250012] [drm] nouveau 0000:04:00.0: Load detected on output B [ 205.533341] [drm] nouveau 0000:04:00.0: Load detected on output B [ 205.773347] [drm] nouveau 0000:04:00.0: Load detected on output B [ 206.100013] [drm] nouveau 0000:04:00.0: Load detected on output B [ 207.500009] [drm] nouveau 0000:04:00.0: Load detected on output B [ 207.773339] [drm] nouveau 0000:04:00.0: Load detected on output B [ 207.983342] [drm] nouveau 0000:04:00.0: Load detected on output B [ 208.253341] [drm] nouveau 0000:04:00.0: Load detected on output B [ 208.460013] [drm] nouveau 0000:04:00.0: Load detected on output B [ 208.733351] [drm] nouveau 0000:04:00.0: Load detected on output B [ 208.936671] [drm] nouveau 0000:04:00.0: Load detected on output B [ 209.203340] [drm] nouveau 0000:04:00.0: Load detected on output B [ 209.406680] [drm] nouveau 0000:04:00.0: Load detected on output B [ 209.676672] [drm] nouveau 0000:04:00.0: Load detected on output B [ 209.883349] [drm] nouveau 0000:04:00.0: Load detected on output B [ 210.156674] [drm] nouveau 0000:04:00.0: Load detected on output B [ 210.363346] [drm] nouveau 0000:04:00.0: Load detected on output B [ 210.640015] [drm] nouveau 0000:04:00.0: Load detected on output B [ 210.843339] [drm] nouveau 0000:04:00.0: Load detected on output B [ 211.116675] [drm] nouveau 0000:04:00.0: Load detected on output B [ 214.710077] [drm] nouveau 0000:04:00.0: Load detected on output B [ 2020.319903] [drm] nouveau 0000:04:00.0: Setting dpms mode 1 on tmds encoder (output 2) [ 2020.329920] [drm] nouveau 0000:04:00.0: Setting dpms mode 1 on TV encoder (output 3) [56527.565289] [drm] nouveau 0000:04:00.0: Setting dpms mode 0 on tmds encoder (output 2) [56527.575301] [drm] nouveau 0000:04:00.0: Setting dpms mode 0 on TV encoder (output 3) From younes.m at gmail.com Thu Mar 10 11:48:11 2011 From: younes.m at gmail.com (younes.m at gmail.com) Date: Thu, 10 Mar 2011 19:48:11 +0000 Subject: nouveaufb problems with NV18 In-Reply-To: <20110309200656.23070.qmail@xxxxxxxxxxxxxxxxxxx> Message-ID: <000e0cd488aa1f9936049e26203c@xxxxxxxxxx> On , George Spelvin <linux at horizon.com> wrote: > I have an NV18 (GeForce4 MX) connected via DVI to a 1920x1080 LCD, > and when I try to use the nouveau kernel driver, I get a crappy display. > Thanks in advance to anyone who can help. > I'm running a recent nouveau git (fa17f241 drm/nv50: fix thinko in vm > fault) > merged with 2.6.38-rc8. > When the driver loads (it's compiled as a module, so this is after init > starts), the console shrinks to a 36x90 character box in the upper-left > corner of the display. > When the system is busy, the screen "flashes" to the right. > The console text appears half a screen to the right for a moment. > It's particularly annoying right after boot, but settles down once the > system goes quescent. > The problem is NOT associated with screen updates. I can run "yes" > and see the problem very little. hdparm -tT, however, makes the screen > almost unusable during *both* phases. > Watching during heavy activity, there's a "standard position" to the > right where the text tends to appear, but there's also lots of "tearing" > and it appears in multiple positions. Still pretty recognizable as text, > though; it doesn't seem to change every scanline. > X is also screwed up; it fails to start with the messages: > [ 214.714] (II) NOUVEAU(0): Opened GPU channel 1 > [ 214.715] (II) NOUVEAU(0): [DRI2] Setup complete > [ 214.715] (II) NOUVEAU(0): [DRI2] DRI driver: nouveau_vieux > [ 214.716] (EE) NOUVEAU(0): Error allocating scanout buffer: 0 > [ 214.716] > Fatal server error: > [ 214.716] AddScreen/ScreenInit failed for driver 0 > ... but I figure that's a more advanced problem. > I've tried and been unhappy with the nouveau driver on this system in > the past (I remember it coming up but having lots of horizontal lines of > "snow" on the display), but Debian recently removed the nv driver that > worked fine for me from its X distribution, so I'm trying again a bit > harder this time. > It's a 2 GB Athlon system, small form factor with onboard video. > lspci -nn gives: Is there anything at all connected to the other output (referred to as TV-1 in your log)? You can try disabling TV detection with the tv_disable nouveau.ko module parameter if a non-existent TV is somehow being detected. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/nouveau/attachments/20110310/fc555200/attachment.htm> From bugzilla-daemon at freedesktop.org Thu Mar 10 12:28:58 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Thu, 10 Mar 2011 12:28:58 -0800 (PST) Subject: [Bug 35171] x11-drivers/xf86-video-nouveau does not work with Quadro FX1800 on HP elitebook 8540w In-Reply-To: <bug-35171-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> References: <bug-35171-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> Message-ID: <20110310202858.BC6FB13000C@xxxxxxxxxxxxxxxxxxxxxxxx> https://bugs.freedesktop.org/show_bug.cgi?id=35171 Aaron Plattner <aplattner at nvidia.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Driver/nVidia (open) |Driver/nouveau AssignedTo|aplattner at nvidia.com |nouveau at lists.freedesktop.o | |rg -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From marcin.slusarz at gmail.com Thu Mar 10 13:43:25 2011 From: marcin.slusarz at gmail.com (Marcin Slusarz) Date: Thu, 10 Mar 2011 22:43:25 +0100 Subject: [PATCH] drm/nouveau: fix oops on unload with disabled LVDS panel Message-ID: <20110310214325.GA18211@xxxxxxx> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=35135 BUG: unable to handle kernel NULL pointer dereference at 000002d8 IP: [<f83694af>] nv04_dfp_restore+0x7f/0xd0 [nouveau] (...) Call Trace: [<f8372208>] nv04_display_destroy+0xa8/0x140 [nouveau] [<f830344a>] nouveau_unload+0x2a/0x160 [nouveau] [<f80d98fb>] drm_put_dev+0xbb/0x1b0 [drm] [<f8301025>] nouveau_pci_remove+0x15/0x20 [nouveau] [<c1292ad4>] pci_device_remove+0x44/0xf0 [<c13339d1>] __device_release_driver+0x51/0xb0 [<c133401f>] driver_detach+0x8f/0xa0 [<c13338a3>] bus_remove_driver+0x63/0xa0 [<c13340a9>] driver_unregister+0x49/0x80 [<c1182f84>] ? sysfs_remove_file+0x14/0x20 [<c1292bb2>] pci_unregister_driver+0x32/0x90 [<c109b1da>] ? __stop_machine+0x5a/0x70 [<f80d3f93>] drm_exit+0x83/0x90 [drm] [<f837875d>] nouveau_exit+0x1b/0x8be [nouveau] [<c1087b5b>] sys_delete_module+0x13b/0x1f0 [<c1104c3e>] ? do_munmap+0x1fe/0x280 [<c1104780>] ? arch_unmap_area_topdown+0x0/0x20 [<c15096f4>] syscall_call+0x7/0xb Reported-by: Francesco Marella <francesco.marella at gmail.com> Tested-by: Francesco Marella <francesco.marella at gmail.com> Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- drivers/gpu/drm/nouveau/nv04_dfp.c | 20 +++++++++++++++----- 1 files changed, 15 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nv04_dfp.c b/drivers/gpu/drm/nouveau/nv04_dfp.c index c82db37..b985ab3 100644 --- a/drivers/gpu/drm/nouveau/nv04_dfp.c +++ b/drivers/gpu/drm/nouveau/nv04_dfp.c @@ -579,15 +579,24 @@ static void nv04_dfp_restore(struct drm_encoder *encoder) struct drm_device *dev = encoder->dev; struct drm_nouveau_private *dev_priv = dev->dev_private; int head = nv_encoder->restore.head; + struct nouveau_connector *connector; + struct drm_display_mode *native_mode; if (nv_encoder->dcb->type == OUTPUT_LVDS) { - struct drm_display_mode *native_mode = nouveau_encoder_connector_get(nv_encoder)->native_mode; - if (native_mode) - call_lvds_script(dev, nv_encoder->dcb, head, LVDS_PANEL_ON, - native_mode->clock); - else + connector = nouveau_encoder_connector_get(nv_encoder); + if (!connector) { + NV_ERROR(dev, "No connector for LVDS encoder. Skipping restore.\n"); + goto out; + } + + native_mode = connector->native_mode; + if (!native_mode) { NV_ERROR(dev, "Not restoring LVDS without native mode\n"); + goto out; + } + call_lvds_script(dev, nv_encoder->dcb, head, LVDS_PANEL_ON, + native_mode->clock); } else if (nv_encoder->dcb->type == OUTPUT_TMDS) { int clock = nouveau_hw_pllvals_to_clk (&dev_priv->saved_reg.crtc_reg[head].pllvals); @@ -595,6 +604,7 @@ static void nv04_dfp_restore(struct drm_encoder *encoder) run_tmds_table(dev, nv_encoder->dcb, head, clock); } +out: nv_encoder->last_dpms = NV_DPMS_CLEARED; } -- 1.7.4.rc3 From bugzilla-daemon at freedesktop.org Thu Mar 10 18:47:14 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Thu, 10 Mar 2011 18:47:14 -0800 (PST) Subject: [Bug 27501] nVidia 9600M GT (Macbook Pro current model) is unable to boot In-Reply-To: <bug-27501-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> References: <bug-27501-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> Message-ID: <20110311024714.5867713004F@xxxxxxxxxxxxxxxxxxxxxxxx> https://bugs.freedesktop.org/show_bug.cgi?id=27501 --- Comment #6 from Alex Murray <murray.alex at gmail.com> 2011-03-10 18:47:13 PST --- I can also confirm the latest Fedora Alpha 15 LiveCD does not boot either without nouveau.noaccel=1 - boot locks up with PRAMIN flush timeout as well. Any chance this bug can get some attention? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From linux at horizon.com Fri Mar 11 07:27:18 2011 From: linux at horizon.com (George Spelvin) Date: 11 Mar 2011 10:27:18 -0500 Subject: nouveaufb problems with NV18 In-Reply-To: <000e0cd488aa1f9936049e26203c@xxxxxxxxxx> Message-ID: <20110311152718.19243.qmail@xxxxxxxxxxxxxxxxxxx> Thanks for the reply! Sorry it took me a day to respond. > Is there anything at all connected to the other output (referred to as TV-1 > in your log)? You can try disabling TV detection with the tv_disable > nouveau.ko module parameter if a non-existent TV is somehow being detected. No, nothing. Adding the parameter (it's actually tv_disable=1; required a couple of reboots since the module's loaded early and can't be unloaded) produced a full-screen console (67x240), but with the same "flashing" to the right on system activity. (I don't get it on VC switch now, however!) Also, the display (DVI-D) appears to be half a line low. Tall characters ($ and ^) on the top line have their topmost row of pixels replicated into a vertical stripe, and the bottom row of text is only half visible. (Actually a little more than half; both bars of = are visible.) X still refuses to start; messages attached. [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 2.6.38-rc8+ ($USER@$HOST) (gcc version 4.5.2 (Debian 4.5.2-5) ) #22 Tue Mar 8 21:47:31 EST 2011 [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: 0000000000000000 - 00000000000a0000 (usable) [ 0.000000] BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 000000007dff0000 (usable) [ 0.000000] BIOS-e820: 000000007dff0000 - 000000007dff3000 (ACPI NVS) [ 0.000000] BIOS-e820: 000000007dff3000 - 000000007e000000 (ACPI data) [ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved) [ 0.000000] Notice: NX (Execute Disable) protection missing in CPU! [ 0.000000] DMI 2.2 present. [ 0.000000] DMI: /FN41 , BIOS 6.00 PG 08/23/2004 [ 0.000000] e820 update range: 0000000000000000 - 0000000000001000 (usable) ==> (reserved) [ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable) [ 0.000000] last_pfn = 0x7dff0 max_arch_pfn = 0x100000 [ 0.000000] MTRR default type: uncachable [ 0.000000] MTRR fixed ranges enabled: [ 0.000000] 00000-9FFFF write-back [ 0.000000] A0000-AFFFF uncachable [ 0.000000] B0000-BFFFF write-combining [ 0.000000] C0000-C7FFF write-protect [ 0.000000] C8000-FFFFF uncachable [ 0.000000] MTRR variable ranges enabled: [ 0.000000] 0 base 000000000 mask F80000000 write-back [ 0.000000] 1 base 07E000000 mask FFE000000 uncachable [ 0.000000] 2 base 0E0000000 mask FFC000000 write-combining [ 0.000000] 3 disabled [ 0.000000] 4 disabled [ 0.000000] 5 disabled [ 0.000000] 6 disabled [ 0.000000] 7 disabled [ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [ 0.000000] Scanning 1 areas for low memory corruption [ 0.000000] initial memory mapped : 0 - 01800000 [ 0.000000] init_memory_mapping: 0000000000000000-00000000377fe000 [ 0.000000] 0000000000 - 0000400000 page 4k [ 0.000000] 0000400000 - 0037400000 page 2M [ 0.000000] 0037400000 - 00377fe000 page 4k [ 0.000000] kernel direct mapping tables up to 377fe000 @ 17fb000-1800000 [ 0.000000] ACPI: RSDP 000f6e60 00014 (v00 Nvidia) [ 0.000000] ACPI: RSDT 7dff3000 0002C (v01 Nvidia AWRDACPI 42302E31 AWRD 00000000) [ 0.000000] ACPI: FACP 7dff3040 00074 (v01 Nvidia AWRDACPI 42302E31 AWRD 00000000) [ 0.000000] ACPI: DSDT 7dff30c0 04139 (v01 NVIDIA AWRDACPI 00001000 MSFT 0100000D) [ 0.000000] ACPI: FACS 7dff0000 00040 [ 0.000000] ACPI: APIC 7dff7200 0005A (v01 Nvidia AWRDACPI 42302E31 AWRD 00000000) [ 0.000000] 1127MB HIGHMEM available. [ 0.000000] 887MB LOWMEM available. [ 0.000000] mapped low ram: 0 - 377fe000 [ 0.000000] low ram: 0 - 377fe000 [ 0.000000] Zone PFN ranges: [ 0.000000] DMA 0x00000001 -> 0x00001000 [ 0.000000] Normal 0x00001000 -> 0x000377fe [ 0.000000] HighMem 0x000377fe -> 0x0007dff0 [ 0.000000] Movable zone start PFN for each node [ 0.000000] early_node_map[2] active PFN ranges [ 0.000000] 0: 0x00000001 -> 0x000000a0 [ 0.000000] 0: 0x00000100 -> 0x0007dff0 [ 0.000000] On node 0 totalpages: 515983 [ 0.000000] free_area_init_node: node 0, pgdat c13805c8, node_mem_map f683d020 [ 0.000000] DMA zone: 32 pages used for memmap [ 0.000000] DMA zone: 0 pages reserved [ 0.000000] DMA zone: 3967 pages, LIFO batch:0 [ 0.000000] Normal zone: 1744 pages used for memmap [ 0.000000] Normal zone: 221486 pages, LIFO batch:31 [ 0.000000] HighMem zone: 2256 pages used for memmap [ 0.000000] HighMem zone: 286498 pages, LIFO batch:31 [ 0.000000] ACPI: PM-Timer IO Port: 0x4008 [ 0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000f0000 [ 0.000000] PM: Registered nosave memory: 00000000000f0000 - 0000000000100000 [ 0.000000] Allocating PCI resources starting at 7e000000 (gap: 7e000000:80c00000) [ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [ 0.000000] pcpu-alloc: [0] 0 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 511951 [ 0.000000] Kernel command line: auto BOOT_IMAGE=2.6 ro root=302 [ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes) [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [ 0.000000] Initializing CPU#0 [ 0.000000] Initializing HighMem for node 0 (000377fe:0007dff0) [ 0.000000] Memory: 2042708k/2064320k available (2373k kernel code, 21224k reserved, 1230k data, 276k init, 1155016k highmem) [ 0.000000] virtual kernel memory layout: [ 0.000000] fixmap : 0xfffe4000 - 0xfffff000 ( 108 kB) [ 0.000000] pkmap : 0xff800000 - 0xffc00000 (4096 kB) [ 0.000000] vmalloc : 0xf7ffe000 - 0xff7fe000 ( 120 MB) [ 0.000000] lowmem : 0xc0000000 - 0xf77fe000 ( 887 MB) [ 0.000000] .init : 0xc1385000 - 0xc13ca000 ( 276 kB) [ 0.000000] .data : 0xc12514bf - 0xc1384e40 (1230 kB) [ 0.000000] .text : 0xc1000000 - 0xc12514bf (2373 kB) [ 0.000000] Checking if this processor honours the WP bit even in supervisor mode...Ok. [ 0.000000] SLUB: Genslabs=15, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [ 0.000000] NR_IRQS:16 [ 0.000000] CPU 0 irqstacks, hard=f6008000 soft=f600a000 [ 0.000000] Console: colour VGA+ 80x50 [ 0.000000] console [tty0] enabled [ 0.000000] Fast TSC calibration using PIT [ 0.000000] Detected 1469.814 MHz processor. [ 0.006670] Calibrating delay loop (skipped), value calculated using timer frequency.. 2940.11 BogoMIPS (lpj=4899380) [ 0.006744] pid_max: default: 32768 minimum: 301 [ 0.006837] Mount-cache hash table entries: 512 [ 0.010164] Initializing cgroup subsys blkio [ 0.010246] mce: CPU supports 4 MCE banks [ 0.010299] CPU: AMD Athlon(tm) XP 1700+ stepping 02 [ 0.010487] ACPI: Core revision 20110112 [ 0.014391] ACPI: setting ELCR to 0200 (from 1c28) [ 0.015222] Performance Events: AMD PMU driver. [ 0.015282] ... version: 0 [ 0.015317] ... bit width: 48 [ 0.015351] ... generic registers: 4 [ 0.015386] ... value mask: 0000ffffffffffff [ 0.015422] ... max period: 00007fffffffffff [ 0.015459] ... fixed-purpose events: 0 [ 0.015493] ... event mask: 000000000000000f [ 0.015685] NMI watchdog enabled, takes one hw-pmu counter. [ 0.016172] xor: automatically using best checksumming function: pIII_sse [ 0.030004] pIII_sse : 4162.800 MB/sec [ 0.030040] xor: using function: pIII_sse (4162.800 MB/sec) [ 0.030127] NET: Registered protocol family 16 [ 0.030677] ACPI: bus type pci registered [ 0.066458] PCI: PCI BIOS revision 2.10 entry at 0xfb760, last bus=4 [ 0.066498] PCI: Using configuration type 1 for base access [ 0.072308] bio: create slab <bio-0> at 0 [ 0.126700] raid6: int32x1 515 MB/s [ 0.183398] raid6: int32x2 667 MB/s [ 0.240033] raid6: int32x4 498 MB/s [ 0.296675] raid6: int32x8 380 MB/s [ 0.353356] raid6: mmxx1 1231 MB/s [ 0.409992] raid6: mmxx2 2035 MB/s [ 0.466675] raid6: sse1x1 1153 MB/s [ 0.523310] raid6: sse1x2 1828 MB/s [ 0.523345] raid6: using algorithm sse1x2 (1828 MB/s) [ 0.525010] ACPI: EC: Look up EC in DSDT [ 0.529866] ACPI: Interpreter enabled [ 0.529909] ACPI: (supports S0 S1 S4 S5) [ 0.530067] ACPI: Using PIC for interrupt routing [ 0.541787] PCI: Ignoring host bridge windows from ACPI; if necessary, use "pci=use_crs" and report a bug [ 0.541958] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) [ 0.542239] pci_root PNP0A03:00: host bridge window [io 0x0000-0x0cf7] (ignored) [ 0.542245] pci_root PNP0A03:00: host bridge window [io 0x0d00-0xffff] (ignored) [ 0.542251] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff] (ignored) [ 0.542256] pci_root PNP0A03:00: host bridge window [mem 0x000c0000-0x000dffff] (ignored) [ 0.542262] pci_root PNP0A03:00: host bridge window [mem 0x7e000000-0xfebfffff] (ignored) [ 0.542283] pci 0000:00:00.0: [10de:01e0] type 0 class 0x000600 [ 0.542295] pci 0000:00:00.0: reg 10: [mem 0xe0000000-0xe3ffffff pref] [ 0.542342] pci 0000:00:00.1: [10de:01eb] type 0 class 0x000500 [ 0.542384] pci 0000:00:00.2: [10de:01ee] type 0 class 0x000500 [ 0.542425] pci 0000:00:00.3: [10de:01ed] type 0 class 0x000500 [ 0.542463] pci 0000:00:00.4: [10de:01ec] type 0 class 0x000500 [ 0.542504] pci 0000:00:00.5: [10de:01ef] type 0 class 0x000500 [ 0.542550] pci 0000:00:01.0: [10de:0060] type 0 class 0x000601 [ 0.542636] pci 0000:00:01.1: [10de:0064] type 0 class 0x000c05 [ 0.542653] pci 0000:00:01.1: reg 10: [io 0xc400-0xc41f] [ 0.542710] pci 0000:00:01.1: PME# supported from D3hot D3cold [ 0.542717] pci 0000:00:01.1: PME# disabled [ 0.542742] pci 0000:00:02.0: [10de:0067] type 0 class 0x000c03 [ 0.542759] pci 0000:00:02.0: reg 10: [mem 0xef080000-0xef080fff] [ 0.542816] pci 0000:00:02.0: supports D1 D2 [ 0.542820] pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot D3cold [ 0.542826] pci 0000:00:02.0: PME# disabled [ 0.542846] pci 0000:00:02.1: [10de:0067] type 0 class 0x000c03 [ 0.542863] pci 0000:00:02.1: reg 10: [mem 0xef083000-0xef083fff] [ 0.542920] pci 0000:00:02.1: supports D1 D2 [ 0.542924] pci 0000:00:02.1: PME# supported from D0 D1 D2 D3hot D3cold [ 0.542930] pci 0000:00:02.1: PME# disabled [ 0.542951] pci 0000:00:02.2: [10de:0068] type 0 class 0x000c03 [ 0.542970] pci 0000:00:02.2: reg 10: [mem 0xef086000-0xef0860ff] [ 0.543033] pci 0000:00:02.2: supports D1 D2 [ 0.543037] pci 0000:00:02.2: PME# supported from D0 D1 D2 D3hot D3cold [ 0.543044] pci 0000:00:02.2: PME# disabled [ 0.543071] pci 0000:00:04.0: [10de:0066] type 0 class 0x000200 [ 0.543088] pci 0000:00:04.0: reg 10: [mem 0xef087000-0xef087fff] [ 0.543099] pci 0000:00:04.0: reg 14: [io 0xb000-0xb007] [ 0.543149] pci 0000:00:04.0: supports D1 D2 [ 0.543153] pci 0000:00:04.0: PME# supported from D0 D1 D2 D3hot D3cold [ 0.543159] pci 0000:00:04.0: PME# disabled [ 0.543178] pci 0000:00:05.0: [10de:006b] type 0 class 0x000401 [ 0.543195] pci 0000:00:05.0: reg 10: [mem 0xef000000-0xef07ffff] [ 0.543251] pci 0000:00:05.0: supports D1 D2 [ 0.543270] pci 0000:00:06.0: [10de:006a] type 0 class 0x000401 [ 0.543316] pci 0000:00:06.0: reg 10: [io 0xb400-0xb4ff] [ 0.543328] pci 0000:00:06.0: reg 14: [io 0xb800-0xb87f] [ 0.543339] pci 0000:00:06.0: reg 18: [mem 0xef081000-0xef081fff] [ 0.543383] pci 0000:00:06.0: supports D1 D2 [ 0.543440] pci 0000:00:08.0: [10de:006c] type 1 class 0x000604 [ 0.543483] pci 0000:00:09.0: [10de:0065] type 0 class 0x000101 [ 0.543526] pci 0000:00:09.0: reg 20: [io 0xf000-0xf00f] [ 0.543575] pci 0000:00:0d.0: [10de:006e] type 0 class 0x000c00 [ 0.543592] pci 0000:00:0d.0: reg 10: [mem 0xef084000-0xef0847ff] [ 0.543604] pci 0000:00:0d.0: reg 14: [mem 0xef085000-0xef08503f] [ 0.543654] pci 0000:00:0d.0: supports D1 D2 [ 0.543658] pci 0000:00:0d.0: PME# supported from D0 D1 D2 D3hot D3cold [ 0.543664] pci 0000:00:0d.0: PME# disabled [ 0.543698] pci 0000:00:1e.0: [10de:01e8] type 1 class 0x000604 [ 0.543759] pci 0000:01:06.0: [1180:0476] type 2 class 0x000607 [ 0.543781] pci 0000:01:06.0: reg 10: [mem 0xee000000-0xee000fff] [ 0.543804] pci 0000:01:06.0: supports D1 D2 [ 0.543808] pci 0000:01:06.0: PME# supported from D0 D1 D2 D3hot D3cold [ 0.543815] pci 0000:01:06.0: PME# disabled [ 0.543838] pci 0000:01:06.1: [1180:0476] type 2 class 0x000607 [ 0.543860] pci 0000:01:06.1: reg 10: [mem 0xee005000-0xee005fff] [ 0.543882] pci 0000:01:06.1: supports D1 D2 [ 0.543886] pci 0000:01:06.1: PME# supported from D0 D1 D2 D3hot D3cold [ 0.543893] pci 0000:01:06.1: PME# disabled [ 0.543947] pci 0000:00:08.0: PCI bridge to [bus 01-03] [ 0.543989] pci 0000:00:08.0: bridge window [io 0x9000-0xafff] [ 0.543996] pci 0000:00:08.0: bridge window [mem 0xee000000-0xeeffffff] [ 0.544003] pci 0000:00:08.0: bridge window [mem 0xfff00000-0x000fffff pref] (disabled) [ 0.544087] pci_bus 0000:03: [bus 03-06] partially hidden behind bridge 0000:01 [bus 01-03] [ 0.544163] pci 0000:04:00.0: [10de:01f0] type 0 class 0x000300 [ 0.544180] pci 0000:04:00.0: reg 10: [mem 0xec000000-0xecffffff] [ 0.544191] pci 0000:04:00.0: reg 14: [mem 0xe4000000-0xe7ffffff pref] [ 0.544201] pci 0000:04:00.0: reg 18: [mem 0xe8000000-0xe807ffff pref] [ 0.544229] pci 0000:04:00.0: reg 30: [mem 0x00000000-0x0001ffff pref] [ 0.544281] pci 0000:00:1e.0: PCI bridge to [bus 04-04] [ 0.544320] pci 0000:00:1e.0: bridge window [io 0xf000-0x0000] (disabled) [ 0.544326] pci 0000:00:1e.0: bridge window [mem 0xec000000-0xedffffff] [ 0.544333] pci 0000:00:1e.0: bridge window [mem 0xe4000000-0xebffffff pref] [ 0.544346] pci_bus 0000:00: on NUMA node 0 [ 0.544352] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] [ 0.544550] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT] [ 0.544620] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGPB._PRT] [ 0.587825] ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. [ 0.588187] ACPI: PCI Interrupt Link [LNK2] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. [ 0.588545] ACPI: PCI Interrupt Link [LNK3] (IRQs *3 4 5 6 7 10 11 12 14 15) [ 0.588854] ACPI: PCI Interrupt Link [LNK4] (IRQs 3 4 5 6 7 10 *11 12 14 15) [ 0.589164] ACPI: PCI Interrupt Link [LNK5] (IRQs 3 4 5 6 7 *10 11 12 14 15) [ 0.589471] ACPI: PCI Interrupt Link [LUBA] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. [ 0.589825] ACPI: PCI Interrupt Link [LUBB] (IRQs 3 4 *5 6 7 10 11 12 14 15) [ 0.590189] ACPI: PCI Interrupt Link [LMAC] (IRQs 3 4 5 6 7 10 *11 12 14 15) [ 0.590501] ACPI: PCI Interrupt Link [LAPU] (IRQs 3 4 *5 6 7 10 11 12 14 15) [ 0.590810] ACPI: PCI Interrupt Link [LACI] (IRQs 3 4 5 6 7 10 11 *12 14 15) [ 0.591118] ACPI: PCI Interrupt Link [LMCI] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. [ 0.591470] ACPI: PCI Interrupt Link [LSMB] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. [ 0.591825] ACPI: PCI Interrupt Link [LUB2] (IRQs 3 4 5 6 7 10 11 *12 14 15) [ 0.592134] ACPI: PCI Interrupt Link [LFIR] (IRQs 3 4 5 6 7 *10 11 12 14 15) [ 0.592441] ACPI: PCI Interrupt Link [L3CM] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. [ 0.592794] ACPI: PCI Interrupt Link [LIDE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. [ 0.593156] ACPI: PCI Interrupt Link [APC1] (IRQs *16), disabled. [ 0.593366] ACPI: PCI Interrupt Link [APC2] (IRQs *17), disabled. [ 0.593537] ACPI: PCI Interrupt Link [APC3] (IRQs *18) [ 0.593688] ACPI: PCI Interrupt Link [APC4] (IRQs *19) [ 0.593848] ACPI: PCI Interrupt Link [APCE] (IRQs *16) [ 0.594044] ACPI: PCI Interrupt Link [APCF] (IRQs 20 21 22) *0, disabled. [ 0.594305] ACPI: PCI Interrupt Link [APCG] (IRQs 20 21 22) *0 [ 0.594547] ACPI: PCI Interrupt Link [APCH] (IRQs 20 21 22) *0 [ 0.594788] ACPI: PCI Interrupt Link [APCI] (IRQs 20 21 22) *0 [ 0.595043] ACPI: PCI Interrupt Link [APCJ] (IRQs 20 21 22) *0 [ 0.595284] ACPI: PCI Interrupt Link [APCK] (IRQs 20 21 22) *0, disabled. [ 0.595505] ACPI: PCI Interrupt Link [APCS] (IRQs *23), disabled. [ 0.595713] ACPI: PCI Interrupt Link [APCL] (IRQs 20 21 22) *0 [ 0.595964] ACPI: PCI Interrupt Link [APCM] (IRQs 20 21 22) *0 [ 0.596205] ACPI: PCI Interrupt Link [AP3C] (IRQs 20 21 22) *0, disabled. [ 0.596465] ACPI: PCI Interrupt Link [APCZ] (IRQs 20 21 22) *0, disabled. [ 0.596955] vgaarb: device added: PCI:0000:04:00.0,decodes=io+mem,owns=io+mem,locks=none [ 0.597009] vgaarb: loaded [ 0.597310] SCSI subsystem initialized [ 0.597521] usbcore: registered new interface driver usbfs [ 0.597670] usbcore: registered new interface driver hub [ 0.597784] usbcore: registered new device driver usb [ 0.598182] Advanced Linux Sound Architecture Driver Version 1.0.23. [ 0.598280] PCI: Using ACPI for IRQ routing [ 0.598324] PCI: pci_cache_line_size set to 32 bytes [ 0.598408] reserve RAM buffer: 000000007dff0000 - 000000007fffffff [ 0.598660] Switching to clocksource pit [ 0.598808] pnp: PnP ACPI init [ 0.598860] ACPI: bus type pnp registered [ 0.599263] pnp 00:00: [io 0x4000-0x407f] [ 0.599269] pnp 00:00: [io 0x4080-0x40ff] [ 0.599273] pnp 00:00: [io 0x4400-0x447f] [ 0.599277] pnp 00:00: [io 0x4480-0x44ff] [ 0.599281] pnp 00:00: [io 0x4200-0x427f] [ 0.599285] pnp 00:00: [io 0x4280-0x42ff] [ 0.599409] system 00:00: [io 0x4000-0x407f] has been reserved [ 0.599450] system 00:00: [io 0x4080-0x40ff] has been reserved [ 0.599490] system 00:00: [io 0x4400-0x447f] has been reserved [ 0.599530] system 00:00: [io 0x4480-0x44ff] has been reserved [ 0.599569] system 00:00: [io 0x4200-0x427f] has been reserved [ 0.599609] system 00:00: [io 0x4280-0x42ff] has been reserved [ 0.599650] system 00:00: Plug and Play ACPI device, IDs PNP0c02 (active) [ 0.599672] pnp 00:01: [io 0x5000-0x503f] [ 0.599677] pnp 00:01: [io 0x5100-0x513f] [ 0.599781] system 00:01: [io 0x5000-0x503f] has been reserved [ 0.599823] system 00:01: [io 0x5100-0x513f] has been reserved [ 0.599863] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active) [ 0.599952] system 00:02: Plug and Play ACPI device, IDs PNP0c01 (active) [ 0.599952] pnp 00:03: [bus 00-ff] [ 0.599952] pnp 00:03: [io 0x0cf8-0x0cff] [ 0.599952] pnp 00:03: [io 0x0000-0x0cf7 window] [ 0.599952] pnp 00:03: [io 0x0d00-0xffff window] [ 0.599952] pnp 00:03: [mem 0x000a0000-0x000bffff window] [ 0.599952] pnp 00:03: [mem 0x000c0000-0x000dffff window] [ 0.599952] pnp 00:03: [mem 0x7e000000-0xfebfffff window] [ 0.599952] pnp 00:03: Plug and Play ACPI device, IDs PNP0a03 (active) [ 0.599952] pnp 00:04: [io 0x0010-0x001f] [ 0.599952] pnp 00:04: [io 0x0022-0x003f] [ 0.599952] pnp 00:04: [io 0x0044-0x005f] [ 0.599952] pnp 00:04: [io 0x0062-0x0063] [ 0.599952] pnp 00:04: [io 0x0065-0x006f] [ 0.599952] pnp 00:04: [io 0x0074-0x007f] [ 0.599952] pnp 00:04: [io 0x0091-0x0093] [ 0.599952] pnp 00:04: [io 0x00a2-0x00bf] [ 0.599952] pnp 00:04: [io 0x00e0-0x00ef] [ 0.599952] pnp 00:04: [io 0x04d0-0x04d1] [ 0.599952] pnp 00:04: [io 0x0800-0x0805] [ 0.599952] pnp 00:04: [io 0x0290-0x0297] [ 0.599952] system 00:04: [io 0x04d0-0x04d1] has been reserved [ 0.601116] system 00:04: [io 0x0800-0x0805] has been reserved [ 0.601156] system 00:04: [io 0x0290-0x0297] has been reserved [ 0.601196] system 00:04: Plug and Play ACPI device, IDs PNP0c02 (active) [ 0.601278] pnp 00:05: [dma 4] [ 0.601283] pnp 00:05: [io 0x0000-0x000f] [ 0.601287] pnp 00:05: [io 0x0080-0x0090] [ 0.601291] pnp 00:05: [io 0x0094-0x009f] [ 0.601295] pnp 00:05: [io 0x00c0-0x00df] [ 0.601397] pnp 00:05: Plug and Play ACPI device, IDs PNP0200 (active) [ 0.601421] pnp 00:06: [io 0x0070-0x0073] [ 0.601427] pnp 00:06: [irq 8] [ 0.601530] pnp 00:06: Plug and Play ACPI device, IDs PNP0b00 (active) [ 0.601551] pnp 00:07: [io 0x0061] [ 0.601649] pnp 00:07: Plug and Play ACPI device, IDs PNP0800 (active) [ 0.601671] pnp 00:08: [io 0x00f0-0x00ff] [ 0.601676] pnp 00:08: [irq 13] [ 0.601776] pnp 00:08: Plug and Play ACPI device, IDs PNP0c04 (active) [ 0.602041] pnp 00:09: [io 0x03f0-0x03f5] [ 0.602046] pnp 00:09: [io 0x03f7] [ 0.602050] pnp 00:09: [irq 6] [ 0.602054] pnp 00:09: [dma 2] [ 0.602186] pnp 00:09: Plug and Play ACPI device, IDs PNP0700 (active) [ 0.602515] pnp 00:0a: [io 0x03f8-0x03ff] [ 0.602521] pnp 00:0a: [irq 4] [ 0.602674] pnp 00:0a: Plug and Play ACPI device, IDs PNP0501 (active) [ 0.603480] pnp 00:0b: [io 0x0378-0x037f] [ 0.603485] pnp 00:0b: [io 0x0778-0x077b] [ 0.603490] pnp 00:0b: [irq 7] [ 0.603494] pnp 00:0b: [dma 3] [ 0.603668] pnp 00:0b: Plug and Play ACPI device, IDs PNP0401 (active) [ 0.603763] pnp: PnP ACPI: found 12 devices [ 0.603801] ACPI: ACPI bus type pnp unregistered [ 0.644436] Switching to clocksource acpi_pm [ 0.644568] Switched to NOHz mode on CPU #0 [ 0.644623] pci 0000:00:08.0: BAR 9: assigned [mem 0x80000000-0x87ffffff pref] [ 0.644695] pci 0000:01:06.0: BAR 9: assigned [mem 0x80000000-0x83ffffff pref] [ 0.644748] pci 0000:01:06.0: BAR 10: can't assign mem (size 0x4000000) [ 0.644790] pci 0000:01:06.1: BAR 9: assigned [mem 0x84000000-0x87ffffff pref] [ 0.644842] pci 0000:01:06.1: BAR 10: can't assign mem (size 0x4000000) [ 0.644883] pci 0000:01:06.0: BAR 7: assigned [io 0x9000-0x90ff] [ 0.644923] pci 0000:01:06.0: BAR 8: assigned [io 0x9400-0x94ff] [ 0.644963] pci 0000:01:06.1: BAR 7: assigned [io 0x9800-0x98ff] [ 0.645003] pci 0000:01:06.1: BAR 8: assigned [io 0x9c00-0x9cff] [ 0.645042] pci 0000:01:06.0: CardBus bridge to [bus 02-02] [ 0.645080] pci 0000:01:06.0: bridge window [io 0x9000-0x90ff] [ 0.645123] pci 0000:01:06.0: bridge window [io 0x9400-0x94ff] [ 0.645165] pci 0000:01:06.0: bridge window [mem 0x80000000-0x83ffffff pref] [ 0.645219] pci 0000:01:06.1: CardBus bridge to [bus 03-06] [ 0.645257] pci 0000:01:06.1: bridge window [io 0x9800-0x98ff] [ 0.645298] pci 0000:01:06.1: bridge window [io 0x9c00-0x9cff] [ 0.645340] pci 0000:01:06.1: bridge window [mem 0x84000000-0x87ffffff pref] [ 0.645394] pci 0000:00:08.0: PCI bridge to [bus 01-03] [ 0.645432] pci 0000:00:08.0: bridge window [io 0x9000-0xafff] [ 0.645475] pci 0000:00:08.0: bridge window [mem 0xee000000-0xeeffffff] [ 0.645517] pci 0000:00:08.0: bridge window [mem 0x80000000-0x87ffffff pref] [ 0.645574] pci 0000:04:00.0: BAR 6: assigned [mem 0xe8080000-0xe809ffff pref] [ 0.645626] pci 0000:00:1e.0: PCI bridge to [bus 04-04] [ 0.645663] pci 0000:00:1e.0: bridge window [io disabled] [ 0.645704] pci 0000:00:1e.0: bridge window [mem 0xec000000-0xedffffff] [ 0.645745] pci 0000:00:1e.0: bridge window [mem 0xe4000000-0xebffffff pref] [ 0.645811] pci 0000:00:08.0: setting latency timer to 64 [ 0.646021] ACPI: PCI Interrupt Link [LNK3] enabled at IRQ 3 [ 0.646061] PCI: setting IRQ 3 as level-triggered [ 0.646070] pci 0000:01:06.0: PCI INT A -> Link[LNK3] -> GSI 3 (level, low) -> IRQ 3 [ 0.646234] ACPI: PCI Interrupt Link [LNK4] enabled at IRQ 11 [ 0.646272] PCI: setting IRQ 11 as level-triggered [ 0.646281] pci 0000:01:06.1: PCI INT B -> Link[LNK4] -> GSI 11 (level, low) -> IRQ 11 [ 0.646341] pci_bus 0000:00: resource 0 [io 0x0000-0xffff] [ 0.646347] pci_bus 0000:00: resource 1 [mem 0x00000000-0xffffffff] [ 0.646352] pci_bus 0000:01: resource 0 [io 0x9000-0xafff] [ 0.646357] pci_bus 0000:01: resource 1 [mem 0xee000000-0xeeffffff] [ 0.646362] pci_bus 0000:01: resource 2 [mem 0x80000000-0x87ffffff pref] [ 0.646367] pci_bus 0000:02: resource 0 [io 0x9000-0x90ff] [ 0.646372] pci_bus 0000:02: resource 1 [io 0x9400-0x94ff] [ 0.646377] pci_bus 0000:02: resource 2 [mem 0x80000000-0x83ffffff pref] [ 0.646382] pci_bus 0000:03: resource 0 [io 0x9800-0x98ff] [ 0.646386] pci_bus 0000:03: resource 1 [io 0x9c00-0x9cff] [ 0.646391] pci_bus 0000:03: resource 2 [mem 0x84000000-0x87ffffff pref] [ 0.646396] pci_bus 0000:04: resource 1 [mem 0xec000000-0xedffffff] [ 0.646401] pci_bus 0000:04: resource 2 [mem 0xe4000000-0xebffffff pref] [ 0.646467] NET: Registered protocol family 2 [ 0.646580] IP route cache hash table entries: 32768 (order: 5, 131072 bytes) [ 0.647145] TCP established hash table entries: 131072 (order: 8, 1048576 bytes) [ 0.648738] TCP bind hash table entries: 65536 (order: 6, 262144 bytes) [ 0.649259] TCP: Hash tables configured (established 131072 bind 65536) [ 0.649300] TCP reno registered [ 0.649336] UDP hash table entries: 512 (order: 1, 8192 bytes) [ 0.649388] UDP-Lite hash table entries: 512 (order: 1, 8192 bytes) [ 0.649552] NET: Registered protocol family 1 [ 0.680077] pci 0000:04:00.0: Boot video device [ 0.680083] PCI: CLS 0 bytes, default 32 [ 0.680914] Scanning for low memory corruption every 60 seconds [ 0.681865] highmem bounce pool size: 64 pages [ 0.681909] HugeTLB registered 4 MB page size, pre-allocated 0 pages [ 0.688621] msgmni has been set to 1733 [ 0.688957] alg: No test for stdrng (krng) [ 0.689005] io scheduler noop registered [ 0.689041] io scheduler deadline registered [ 0.689095] io scheduler cfq registered (default) [ 0.689591] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled [ 0.963426] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A [ 0.984674] 00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A [ 0.985156] Linux agpgart interface v0.103 [ 0.985225] agpgart: Detected NVIDIA nForce2 chipset [ 0.991055] agpgart-nvidia 0000:00:00.0: AGP aperture is 64M @ 0xe0000000 [ 0.991347] Floppy drive(s): fd0 is 1.44M [ 1.006844] FDC 0 is a post-1991 82077 [ 1.008152] Uniform Multi-Platform E-IDE driver [ 1.008316] amd74xx 0000:00:09.0: UDMA133 controller [ 1.008357] amd74xx 0000:00:09.0: IDE controller (0x10de:0x0065 rev 0xa2) [ 1.008442] amd74xx 0000:00:09.0: BIOS didn't set cable bits correctly. Enabling workaround. [ 1.008498] amd74xx 0000:00:09.0: not 100% native mode: will probe irqs later [ 1.008543] ide0: BM-DMA at 0xf000-0xf007 [ 1.008586] ide1: BM-DMA at 0xf008-0xf00f [ 1.008626] Probing IDE interface ide0... [ 1.283492] hda: ST3120022A, ATA DISK drive [ 1.683368] Refined TSC clocksource calibration: 1469.999 MHz. [ 1.683409] Switching to clocksource tsc [ 1.923441] hda: host max PIO5 wanted PIO255(auto-tune) selected PIO4 [ 1.923917] hda: UDMA/100 mode selected [ 1.924214] Probing IDE interface ide1... [ 2.463459] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 [ 2.463546] ide1 at 0x170-0x177,0x376 on irq 15 [ 2.463817] ide_generic: please use "probe_mask=0x3f" module parameter for probing all legacy ISA IDE ports [ 2.463873] ide-gd driver 1.18 [ 2.463932] hda: max request size: 512KiB [ 2.473767] hda: 234441648 sectors (120034 MB) w/2048KiB Cache, CHS=16383/255/63 [ 2.474000] hda: cache flushes supported [ 2.484046] hda: hda1 hda2 hda3 hda4 [ 2.484652] ide-cd driver 5.00 [ 2.484766] forcedeth: Reverse Engineered nForce ethernet driver. Version 0.64. [ 2.485043] ACPI: PCI Interrupt Link [LMAC] enabled at IRQ 11 [ 2.485088] forcedeth 0000:00:04.0: PCI INT A -> Link[LMAC] -> GSI 11 (level, low) -> IRQ 11 [ 2.485145] forcedeth 0000:00:04.0: setting latency timer to 64 [ 3.000743] forcedeth 0000:00:04.0: ifname eth0, PHY OUI 0x732 @ 1, addr aa:bb:cc:dd:ee:ff [ 3.000799] forcedeth 0000:00:04.0: timirq lnktim desc-v1 [ 3.001094] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 3.001319] ACPI: PCI Interrupt Link [LUB2] enabled at IRQ 12 [ 3.001359] PCI: setting IRQ 12 as level-triggered [ 3.001368] ehci_hcd 0000:00:02.2: PCI INT C -> Link[LUB2] -> GSI 12 (level, low) -> IRQ 12 [ 3.001440] ehci_hcd 0000:00:02.2: setting latency timer to 64 [ 3.001445] ehci_hcd 0000:00:02.2: EHCI Host Controller [ 3.001595] ehci_hcd 0000:00:02.2: new USB bus registered, assigned bus number 1 [ 3.001695] ehci_hcd 0000:00:02.2: debug port 1 [ 3.001740] ehci_hcd 0000:00:02.2: cache line size of 32 is not supported [ 3.001755] ehci_hcd 0000:00:02.2: irq 12, io mem 0xef086000 [ 3.010024] ehci_hcd 0000:00:02.2: USB 2.0 started, EHCI 1.00 [ 3.010115] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [ 3.010156] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 3.010208] usb usb1: Product: EHCI Host Controller [ 3.010244] usb usb1: Manufacturer: Linux 2.6.38-rc8+ ehci_hcd [ 3.010282] usb usb1: SerialNumber: 0000:00:02.2 [ 3.010522] hub 1-0:1.0: USB hub found [ 3.010564] hub 1-0:1.0: 6 ports detected [ 3.010818] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 3.011044] ACPI: PCI Interrupt Link [LUBA] enabled at IRQ 10 [ 3.011084] PCI: setting IRQ 10 as level-triggered [ 3.011093] ohci_hcd 0000:00:02.0: PCI INT A -> Link[LUBA] -> GSI 10 (level, low) -> IRQ 10 [ 3.011165] ohci_hcd 0000:00:02.0: setting latency timer to 64 [ 3.011171] ohci_hcd 0000:00:02.0: OHCI Host Controller [ 3.011327] ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 2 [ 3.011404] ohci_hcd 0000:00:02.0: irq 10, io mem 0xef080000 [ 3.065383] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001 [ 3.065425] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 3.065477] usb usb2: Product: OHCI Host Controller [ 3.065513] usb usb2: Manufacturer: Linux 2.6.38-rc8+ ohci_hcd [ 3.065551] usb usb2: SerialNumber: 0000:00:02.0 [ 3.065784] hub 2-0:1.0: USB hub found [ 3.065829] hub 2-0:1.0: 3 ports detected [ 3.066187] ACPI: PCI Interrupt Link [LUBB] enabled at IRQ 5 [ 3.066227] PCI: setting IRQ 5 as level-triggered [ 3.066236] ohci_hcd 0000:00:02.1: PCI INT B -> Link[LUBB] -> GSI 5 (level, low) -> IRQ 5 [ 3.066304] ohci_hcd 0000:00:02.1: setting latency timer to 64 [ 3.066309] ohci_hcd 0000:00:02.1: OHCI Host Controller [ 3.066453] ohci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 3 [ 3.066528] ohci_hcd 0000:00:02.1: irq 5, io mem 0xef083000 [ 3.118713] usb usb3: New USB device found, idVendor=1d6b, idProduct=0001 [ 3.118756] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 3.118806] usb usb3: Product: OHCI Host Controller [ 3.118843] usb usb3: Manufacturer: Linux 2.6.38-rc8+ ohci_hcd [ 3.118881] usb usb3: SerialNumber: 0000:00:02.1 [ 3.119120] hub 3-0:1.0: USB hub found [ 3.119164] hub 3-0:1.0: 3 ports detected [ 3.119497] usbcore: registered new interface driver libusual [ 3.119772] i8042: PNP: No PS/2 controller found. Probing ports directly. [ 3.264501] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 3.266208] serio: i8042 AUX port at 0x60,0x64 irq 12 [ 3.266638] mousedev: PS/2 mouse device common for all mice [ 3.266912] rtc_cmos 00:06: RTC can wake from S4 [ 3.267070] rtc_cmos 00:06: rtc core: registered rtc_cmos as rtc0 [ 3.267131] rtc0: alarms up to one year, y3k, 242 bytes nvram [ 3.267220] i2c /dev entries driver [ 3.320106] i2c i2c-0: nForce2 SMBus adapter at 0x5000 [ 3.373427] i2c i2c-1: nForce2 SMBus adapter at 0x5100 [ 3.373553] it87: Found IT8712F chip at 0x290, revision 5 [ 3.373669] ACPI: resource it87 [io 0x0295-0x0296] conflicts with ACPI region SPIO [io 0x295-0x296] [ 3.373724] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [ 3.373827] md: raid1 personality registered for level 1 [ 3.373867] md: raid10 personality registered for level 10 [ 3.373905] md: raid6 personality registered for level 6 [ 3.373942] md: raid5 personality registered for level 5 [ 3.373979] md: raid4 personality registered for level 4 [ 3.374017] cpuidle: using governor ladder [ 3.374052] cpuidle: using governor menu [ 3.375757] usbcore: registered new interface driver usbhid [ 3.375797] usbhid: USB HID core driver [ 3.376221] ACPI: PCI Interrupt Link [LACI] enabled at IRQ 12 [ 3.376266] Intel ICH 0000:00:06.0: PCI INT A -> Link[LACI] -> GSI 12 (level, low) -> IRQ 12 [ 3.376362] Intel ICH 0000:00:06.0: setting latency timer to 64 [ 3.610024] usb 2-1: new full speed USB device using ohci_hcd and address 2 [ 3.693358] intel8x0_measure_ac97_clock: measured 52172 usecs (2536 samples) [ 3.693399] intel8x0: clocking to 47399 [ 3.694128] ALSA device list: [ 3.694163] #0: NVidia nForce2 with ALC650E at irq 12 [ 3.694690] TCP cubic registered [ 3.694727] NET: Registered protocol family 17 [ 3.694774] Registering the dns_resolver key type [ 3.695430] registered taskstats version 1 [ 3.695891] rtc_cmos 00:06: setting system clock to 2011-03-11 03:38:08 UTC (1299814688) [ 3.763354] usb 2-1: New USB device found, idVendor=0430, idProduct=100e [ 3.763396] usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 3.766428] hub 2-1:1.0: USB hub found [ 3.769338] hub 2-1:1.0: 4 ports detected [ 4.026693] usb 2-2: new low speed USB device using ohci_hcd and address 3 [ 4.113545] md: Waiting for all devices to be available before autodetect [ 4.113586] md: If you don't use raid, use raid=noautodetect [ 4.113887] md: Autodetecting RAID arrays. [ 4.113924] md: Scanned 0 and added 0 devices. [ 4.113959] md: autorun ... [ 4.113992] md: ... autorun DONE. [ 4.132630] EXT3-fs: barriers not enabled [ 4.146154] kjournald starting. Commit interval 5 seconds [ 4.146216] EXT3-fs (hda2): mounted filesystem with ordered data mode [ 4.146266] VFS: Mounted root (ext3 filesystem) readonly on device 3:2. [ 4.146361] Freeing unused kernel memory: 276k freed [ 4.181327] usb 2-2: New USB device found, idVendor=1241, idProduct=1166 [ 4.181372] usb 2-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 4.195896] input: HID 1241:1166 as /devices/pci0000:00/0000:00:02.0/usb2/2-2/2-2:1.0/input/input0 [ 4.196157] generic-usb 0003:1241:1166.0001: input,hidraw0: USB HID v1.10 Mouse [HID 1241:1166] on usb-0000:00:02.0-2/input0 [ 4.368309] usb 2-1.4: new full speed USB device using ohci_hcd and address 4 [ 4.479305] usb 2-1.4: New USB device found, idVendor=0430, idProduct=00a2 [ 4.479353] usb 2-1.4: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [ 4.479405] usb 2-1.4: Product: Sun USB Keyboard [ 4.488889] input: Sun USB Keyboard as /devices/pci0000:00/0000:00:02.0/usb2/2-1/2-1.4/2-1.4:1.0/input/input1 [ 4.489081] generic-usb 0003:0430:00A2.0002: input,hidraw1: USB HID v1.10 Keyboard [Sun USB Keyboard] on usb-0000:00:02.0-1.4/input0 [ 7.597586] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input2 [ 7.597654] ACPI: Power Button [PWRB] [ 7.598746] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input3 [ 7.598810] ACPI: Power Button [PWRF] [ 7.648290] yenta_cardbus 0000:01:06.0: CardBus bridge found [14ef:0202] [ 7.773689] yenta_cardbus 0000:01:06.0: ISA IRQ mask 0x0000, PCI irq 3 [ 7.773739] yenta_cardbus 0000:01:06.0: Socket status: 30000410 [ 7.773791] yenta_cardbus 0000:01:06.0: pcmcia: parent PCI bridge window: [io 0x9000-0xafff] [ 7.773846] yenta_cardbus 0000:01:06.0: pcmcia: parent PCI bridge window: [mem 0xee000000-0xeeffffff] [ 7.773902] pcmcia_socket pcmcia_socket0: cs: memory probe 0xee000000-0xeeffffff: excluding 0xee000000-0xee0fffff [ 7.774023] yenta_cardbus 0000:01:06.0: pcmcia: parent PCI bridge window: [mem 0x80000000-0x87ffffff pref] [ 7.774079] pcmcia_socket pcmcia_socket0: cs: memory probe 0x80000000-0x87ffffff: excluding 0x80000000-0x87ffffff [ 7.774760] yenta_cardbus 0000:01:06.1: CardBus bridge found [14ef:0202] [ 7.900247] yenta_cardbus 0000:01:06.1: ISA IRQ mask 0x0000, PCI irq 11 [ 7.900296] yenta_cardbus 0000:01:06.1: Socket status: 30000410 [ 7.900337] pci_bus 0000:03: Upper limit for fixing this bridge's parent bridge: #03 [ 7.900400] yenta_cardbus 0000:01:06.1: pcmcia: parent PCI bridge window: [io 0x9000-0xafff] [ 7.900455] yenta_cardbus 0000:01:06.1: pcmcia: parent PCI bridge window: [mem 0xee000000-0xeeffffff] [ 7.900511] pcmcia_socket pcmcia_socket1: cs: memory probe 0xee000000-0xeeffffff: excluding 0xee000000-0xee0fffff [ 7.900632] yenta_cardbus 0000:01:06.1: pcmcia: parent PCI bridge window: [mem 0x80000000-0x87ffffff pref] [ 7.900687] pcmcia_socket pcmcia_socket1: cs: memory probe 0x80000000-0x87ffffff: excluding 0x80000000-0x87ffffff [ 8.890947] [drm] Initialized drm 1.1.0 20060810 [ 9.160733] ACPI: PCI Interrupt Link [LNK5] enabled at IRQ 10 [ 9.160785] nouveau 0000:04:00.0: PCI INT A -> Link[LNK5] -> GSI 10 (level, low) -> IRQ 10 [ 9.166856] [drm] nouveau 0000:04:00.0: Detected an NV10 generation card (0x01f000a5) [ 9.167185] [drm] nouveau 0000:04:00.0: Attempting to load BIOS image from PRAMIN [ 9.211562] [drm] nouveau 0000:04:00.0: ... BIOS checksum invalid [ 9.211602] [drm] nouveau 0000:04:00.0: Attempting to load BIOS image from PROM [ 9.211655] [drm] nouveau 0000:04:00.0: ... BIOS signature not found [ 9.211693] [drm] nouveau 0000:04:00.0: Attempting to load BIOS image from PCIROM [ 9.212159] [drm] nouveau 0000:04:00.0: ... appears to be valid [ 9.212711] [drm] nouveau 0000:04:00.0: BMP BIOS found [ 9.212749] [drm] nouveau 0000:04:00.0: BMP version 5.21 [ 9.212787] [drm] nouveau 0000:04:00.0: Bios version 04.1f.00.07 [ 9.212827] [drm] nouveau 0000:04:00.0: Found Display Configuration Block version 2.0 [ 9.212881] [drm] nouveau 0000:04:00.0: Raw DCB entry 0: 01000100 000088b8 [ 9.212923] [drm] nouveau 0000:04:00.0: Raw DCB entry 1: 02010210 000088b8 [ 9.212964] [drm] nouveau 0000:04:00.0: Raw DCB entry 2: 01120132 00000000 [ 9.213004] [drm] nouveau 0000:04:00.0: Raw DCB entry 3: 01120232 00000000 [ 9.213044] [drm] nouveau 0000:04:00.0: Raw DCB entry 4: 02010121 00000003 [ 9.213085] [drm] nouveau 0000:04:00.0: Raw DCB entry 5: 02010221 00000003 [ 9.213125] [drm] nouveau 0000:04:00.0: Merging DCB entries 2 and 3 [ 9.213164] [drm] nouveau 0000:04:00.0: Merging DCB entries 4 and 5 [ 9.213721] [drm] nouveau 0000:04:00.0: Parsing VBIOS init table 0 at offset 0xC284 [ 9.213800] [drm] nouveau 0000:04:00.0: Parsing VBIOS init table 1 at offset 0xC4E0 [ 9.213859] [drm] nouveau 0000:04:00.0: Parsing VBIOS init table 2 at offset 0xC2E7 [ 9.228955] [drm] nouveau 0000:04:00.0: Parsing VBIOS init table 3 at offset 0xC632 [ 9.229015] [drm] nouveau 0000:04:00.0: Parsing VBIOS init table 4 at offset 0xC47B [ 9.229069] [drm] nouveau 0000:04:00.0: Unknown memclock table version 0. [ 9.259928] [drm] nouveau 0000:04:00.0: 0 available performance level(s) [ 9.259997] [drm] nouveau 0000:04:00.0: c: memory 200454MHz core 199MHz [ 9.260177] [TTM] Zone kernel: Available graphics memory: 443984 kiB. [ 9.260218] [TTM] Zone highmem: Available graphics memory: 1021492 kiB. [ 9.260257] [TTM] Initializing pool allocator. [ 9.260315] [drm] nouveau 0000:04:00.0: Detected 32MiB VRAM [ 9.260667] agpgart-nvidia 0000:00:00.0: AGP 2.0 bridge [ 9.260735] agpgart-nvidia 0000:00:00.0: putting AGP V2 device into 4x mode [ 9.260849] nouveau 0000:04:00.0: putting AGP V2 device into 4x mode [ 9.260884] [drm] nouveau 0000:04:00.0: 64 MiB GART (aperture) [ 9.260961] [drm] nouveau 0000:04:00.0: Saving VGA fonts [ 9.308950] [drm] nouveau 0000:04:00.0: Detected TMDS transmitter: sil164 [ 9.314989] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 9.315032] [drm] No driver support for vblank timestamp query. [ 9.317176] [drm] nouveau 0000:04:00.0: Setting dpms mode 3 on vga encoder (output 0) [ 9.317230] [drm] nouveau 0000:04:00.0: Setting dpms mode 3 on vga encoder (output 1) [ 9.317274] [drm] nouveau 0000:04:00.0: Setting dpms mode 3 on tmds encoder (output 2) [ 9.317318] [drm] nouveau 0000:04:00.0: Setting dpms mode 3 on TV encoder (output 3) [ 9.337394] pcmcia_socket pcmcia_socket0: pccard: PCMCIA card inserted into slot 0 [ 9.337442] pcmcia_socket pcmcia_socket0: cs: memory probe 0xee100000-0xeeffffff: clean. [ 9.343201] pcmcia 0.0: pcmcia: registering new device pcmcia0.0 (IRQ: 3) [ 9.347323] pcmcia_socket pcmcia_socket0: cs: memory probe 0x0c0000-0x0fffff: excluding 0xc0000-0xfffff [ 9.347501] pcmcia_socket pcmcia_socket0: cs: memory probe 0xa0000000-0xa0ffffff: excluding 0xa0000000-0xa0ffffff [ 9.347673] pcmcia_socket pcmcia_socket0: cs: memory probe 0x60000000-0x60ffffff: excluding 0x60000000-0x60ffffff [ 9.522119] [drm] nouveau 0000:04:00.0: allocated 1920x1080 fb: 0x4a000, bo f6004000 [ 10.185624] [drm] nouveau 0000:04:00.0: Setting dpms mode 0 on tmds encoder (output 2) [ 10.185631] [drm] nouveau 0000:04:00.0: Output DVI-D-1 is running on CRTC 0 using output A [ 10.188075] Console: switching to colour frame buffer device 240x67 [ 10.190146] fb0: nouveaufb frame buffer device [ 10.190149] drm: registered panic notifier [ 10.190187] [drm] Initialized nouveau 0.0.16 20090420 for 0000:04:00.0 on minor 0 [ 10.896694] pcmcia_socket pcmcia_socket1: pccard: PCMCIA card inserted into slot 1 [ 10.896729] pcmcia_socket pcmcia_socket1: cs: memory probe 0xee100000-0xeeffffff: excluding 0xee100000-0xee1effff [ 10.904003] pcmcia_socket pcmcia_socket1: cs: memory probe 0x0c0000-0x0fffff: excluding 0xc0000-0xfffff [ 10.904123] pcmcia_socket pcmcia_socket1: cs: memory probe 0xa0000000-0xa0ffffff: excluding 0xa0000000-0xa0ffffff [ 10.904238] pcmcia_socket pcmcia_socket1: cs: memory probe 0x60000000-0x60ffffff: excluding 0x60000000-0x60ffffff [ 10.910323] [ 10.910761] pcmcia 1.0: pcmcia: registering new device pcmcia1.0 (IRQ: 11) [ 13.076997] Adding 1951860k swap on /dev/hda1. Priority:-1 extents:1 across:1951860k [ 13.349114] EXT3-fs (hda2): using internal journal [ 13.665513] loop: module loaded [ 14.251954] fuse init (API version 7.16) [ 14.347416] EXT3-fs: barriers not enabled [ 14.355296] kjournald starting. Commit interval 5 seconds [ 14.356633] EXT3-fs (hda3): using internal journal [ 14.357749] EXT3-fs (hda3): mounted filesystem with ordered data mode [ 1842.826524] [drm] nouveau 0000:04:00.0: Setting dpms mode 1 on tmds encoder (output 2) [40548.282031] [drm] nouveau 0000:04:00.0: Setting dpms mode 0 on tmds encoder (output 2) [ 40725.600] _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 [ 40725.600] _XSERVTransOpen: transport open failed for inet6/$HOST:0 [ 40725.600] _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 [ 40725.602] X.Org X Server 1.9.4.901 (1.9.5 RC 1) Release Date: 2011-03-04 [ 40725.602] X Protocol Version 11, Revision 0 [ 40725.602] Build Operating System: Linux 2.6.26-2-amd64 i686 Debian [ 40725.602] Current Operating System: Linux $HOST 2.6.38-rc8+ #22 Tue Mar 8 21:47:31 EST 2011 i686 [ 40725.602] Kernel command line: auto BOOT_IMAGE=2.6 ro root=302 [ 40725.602] Build Date: 07 March 2011 05:01:39PM [ 40725.603] xorg-server 2:1.9.4.901-1 (Cyril Brulebois <kibi at debian.org>) [ 40725.603] Current version of pixman: 0.21.4 [ 40725.603] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 40725.603] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 40725.603] (==) Log file: "/var/log/Xorg.0.log", Time: Fri Mar 11 09:56:50 2011 [ 40725.603] (==) Using config file: "/etc/X11/xorg.conf" [ 40725.603] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 40725.604] (==) ServerLayout "Default Layout" [ 40725.604] (**) |-->Screen "Default Screen" (0) [ 40725.604] (**) | |-->Monitor "2243SWX" [ 40725.604] (**) Option "ReducedBlanking" [ 40725.604] (==) No device specified for screen "Default Screen". Using the first device section listed. [ 40725.604] (**) | |-->Device "Configured Video Device" [ 40725.604] (**) Option "DontZap" "off" [ 40725.604] (**) Option "AllowMouseOpenFail" "off" [ 40725.605] (==) Automatically adding devices [ 40725.605] (==) Automatically enabling devices [ 40725.605] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [ 40725.605] Entry deleted from font path. [ 40725.605] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, built-ins [ 40725.605] (==) ModulePath set to "/usr/lib/xorg/modules" [ 40725.605] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 40725.605] (II) Loader magic: 0x81f9fc0 [ 40725.605] (II) Module ABI versions: [ 40725.605] X.Org ANSI C Emulation: 0.4 [ 40725.605] X.Org Video Driver: 8.0 [ 40725.605] X.Org XInput driver : 11.0 [ 40725.605] X.Org Server Extension : 4.0 [ 40725.606] (--) PCI:*(0:4:0:0) 10de:01f0:0000:0000 rev 163, Mem @ 0xec000000/16777216, 0xe4000000/67108864, 0xe8000000/524288, BIOS @ 0x????????/131072 [ 40725.607] (II) Open ACPI successful (/var/run/acpid.socket) [ 40725.607] (II) LoadModule: "extmod" [ 40725.608] (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so [ 40725.608] (II) Module extmod: vendor="X.Org Foundation" [ 40725.608] compiled for 1.9.4.901, module version = 1.0.0 [ 40725.608] Module class: X.Org Server Extension [ 40725.608] ABI class: X.Org Server Extension, version 4.0 [ 40725.608] (II) Loading extension SELinux [ 40725.608] (II) Loading extension MIT-SCREEN-SAVER [ 40725.608] (II) Loading extension XFree86-VidModeExtension [ 40725.609] (II) Loading extension XFree86-DGA [ 40725.609] (II) Loading extension DPMS [ 40725.609] (II) Loading extension XVideo [ 40725.609] (II) Loading extension XVideo-MotionCompensation [ 40725.609] (II) Loading extension X-Resource [ 40725.609] (II) LoadModule: "dbe" [ 40725.609] (II) Loading /usr/lib/xorg/modules/extensions/libdbe.so [ 40725.609] (II) Module dbe: vendor="X.Org Foundation" [ 40725.609] compiled for 1.9.4.901, module version = 1.0.0 [ 40725.609] Module class: X.Org Server Extension [ 40725.609] ABI class: X.Org Server Extension, version 4.0 [ 40725.609] (II) Loading extension DOUBLE-BUFFER [ 40725.609] (II) LoadModule: "glx" [ 40725.610] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [ 40725.610] (II) Module glx: vendor="X.Org Foundation" [ 40725.610] compiled for 1.9.4.901, module version = 1.0.0 [ 40725.610] ABI class: X.Org Server Extension, version 4.0 [ 40725.610] (==) AIGLX enabled [ 40725.610] (II) Loading extension GLX [ 40725.610] (II) LoadModule: "record" [ 40725.610] (II) Loading /usr/lib/xorg/modules/extensions/librecord.so [ 40725.611] (II) Module record: vendor="X.Org Foundation" [ 40725.611] compiled for 1.9.4.901, module version = 1.13.0 [ 40725.611] Module class: X.Org Server Extension [ 40725.611] ABI class: X.Org Server Extension, version 4.0 [ 40725.611] (II) Loading extension RECORD [ 40725.611] (II) LoadModule: "dri" [ 40725.611] (II) Loading /usr/lib/xorg/modules/extensions/libdri.so [ 40725.611] (II) Module dri: vendor="X.Org Foundation" [ 40725.611] compiled for 1.9.4.901, module version = 1.0.0 [ 40725.611] ABI class: X.Org Server Extension, version 4.0 [ 40725.611] (II) Loading extension XFree86-DRI [ 40725.611] (II) LoadModule: "dri2" [ 40725.612] (II) Loading /usr/lib/xorg/modules/extensions/libdri2.so [ 40725.612] (II) Module dri2: vendor="X.Org Foundation" [ 40725.612] compiled for 1.9.4.901, module version = 1.2.0 [ 40725.612] ABI class: X.Org Server Extension, version 4.0 [ 40725.612] (II) Loading extension DRI2 [ 40725.612] (II) LoadModule: "nouveau" [ 40725.612] (II) Loading /usr/lib/xorg/modules/drivers/nouveau_drv.so [ 40725.613] (II) Module nouveau: vendor="X.Org Foundation" [ 40725.613] compiled for 1.9.4, module version = 0.0.16 [ 40725.613] Module class: X.Org Video Driver [ 40725.613] ABI class: X.Org Video Driver, version 8.0 [ 40725.613] (II) NOUVEAU driver Date: Tue Nov 30 15:27:36 2010 +1000 [ 40725.613] (II) NOUVEAU driver for NVIDIA chipset families : [ 40725.613] RIVA TNT (NV04) [ 40725.613] RIVA TNT2 (NV05) [ 40725.613] GeForce 256 (NV10) [ 40725.613] GeForce 2 (NV11, NV15) [ 40725.613] GeForce 4MX (NV17, NV18) [ 40725.613] GeForce 3 (NV20) [ 40725.613] GeForce 4Ti (NV25, NV28) [ 40725.613] GeForce FX (NV3x) [ 40725.613] GeForce 6 (NV4x) [ 40725.613] GeForce 7 (G7x) [ 40725.613] GeForce 8 (G8x) [ 40725.613] (--) using VT number 7 [ 40725.616] drmOpenDevice: node name is /dev/dri/card0 [ 40725.617] drmOpenDevice: open result is 9, (OK) [ 40725.617] drmOpenByBusid: Searching for BusID pci:0000:04:00.0 [ 40725.617] drmOpenDevice: node name is /dev/dri/card0 [ 40725.617] drmOpenDevice: open result is 9, (OK) [ 40725.617] drmOpenByBusid: drmOpenMinor returns 9 [ 40725.617] drmOpenByBusid: drmGetBusid reports pci:0000:04:00.0 [ 40725.617] (II) [drm] nouveau interface version: 0.0.16 [ 40725.617] (II) Loading sub module "dri" [ 40725.617] (II) LoadModule: "dri" [ 40725.617] (II) Reloading /usr/lib/xorg/modules/extensions/libdri.so [ 40725.618] (II) NOUVEAU(0): Loaded DRI module [ 40725.618] drmOpenDevice: node name is /dev/dri/card0 [ 40725.618] drmOpenDevice: open result is 10, (OK) [ 40725.618] drmOpenDevice: node name is /dev/dri/card0 [ 40725.618] drmOpenDevice: open result is 10, (OK) [ 40725.618] drmOpenByBusid: Searching for BusID pci:0000:04:00.0 [ 40725.618] drmOpenDevice: node name is /dev/dri/card0 [ 40725.618] drmOpenDevice: open result is 10, (OK) [ 40725.618] drmOpenByBusid: drmOpenMinor returns 10 [ 40725.618] drmOpenByBusid: drmGetBusid reports pci:0000:04:00.0 [ 40725.618] (II) [drm] DRM interface version 1.4 [ 40725.618] (II) [drm] DRM open master succeeded. [ 40725.618] (--) NOUVEAU(0): Chipset: "NVIDIA NV1f" [ 40725.618] (**) NOUVEAU(0): Depth 24, (--) framebuffer bpp 32 [ 40725.618] (==) NOUVEAU(0): RGB weight 888 [ 40725.618] (==) NOUVEAU(0): Default visual is TrueColor [ 40725.618] (==) NOUVEAU(0): Using HW cursor [ 40725.618] (==) NOUVEAU(0): GLX sync to VBlank disabled. [ 40725.686] (II) NOUVEAU(0): Output VGA-1 using monitor section 2243SWX [ 40725.745] (II) NOUVEAU(0): Output VGA-2 has no monitor section [ 40725.853] (II) NOUVEAU(0): Output DVI-D-1 has no monitor section [ 40725.853] (II) NOUVEAU(0): Output TV-1 has no monitor section [ 40725.912] (II) NOUVEAU(0): EDID for output VGA-1 [ 40725.972] (II) NOUVEAU(0): EDID for output VGA-2 [ 40726.080] (II) NOUVEAU(0): EDID for output DVI-D-1 [ 40726.080] (II) NOUVEAU(0): Manufacturer: SAM Model: 4e7 Serial#: 1297691186 [ 40726.080] (II) NOUVEAU(0): Year: 2009 Week: 14 [ 40726.080] (II) NOUVEAU(0): EDID Version: 1.3 [ 40726.080] (II) NOUVEAU(0): Digital Display Input [ 40726.080] (II) NOUVEAU(0): Max Image Size [cm]: horiz.: 48 vert.: 27 [ 40726.080] (II) NOUVEAU(0): Gamma: 2.20 [ 40726.080] (II) NOUVEAU(0): DPMS capabilities: Off [ 40726.080] (II) NOUVEAU(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4 [ 40726.080] (II) NOUVEAU(0): First detailed timing is preferred mode [ 40726.080] (II) NOUVEAU(0): redX: 0.649 redY: 0.335 greenX: 0.283 greenY: 0.605 [ 40726.080] (II) NOUVEAU(0): blueX: 0.151 blueY: 0.073 whiteX: 0.312 whiteY: 0.329 [ 40726.080] (II) NOUVEAU(0): Supported established timings: [ 40726.080] (II) NOUVEAU(0): 640x480 at 60Hz [ 40726.080] (II) NOUVEAU(0): 800x600 at 56Hz [ 40726.080] (II) NOUVEAU(0): 800x600 at 60Hz [ 40726.080] (II) NOUVEAU(0): 1024x768 at 60Hz [ 40726.080] (II) NOUVEAU(0): Manufacturer's mask: 0 [ 40726.080] (II) NOUVEAU(0): Supported standard timings: [ 40726.080] (II) NOUVEAU(0): #0: hsize: 1280 vsize 800 refresh: 60 vid: 129 [ 40726.080] (II) NOUVEAU(0): #1: hsize: 1280 vsize 960 refresh: 60 vid: 16513 [ 40726.080] (II) NOUVEAU(0): #2: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 [ 40726.080] (II) NOUVEAU(0): #3: hsize: 1440 vsize 900 refresh: 60 vid: 149 [ 40726.080] (II) NOUVEAU(0): #4: hsize: 1680 vsize 1050 refresh: 60 vid: 179 [ 40726.080] (II) NOUVEAU(0): #5: hsize: 1600 vsize 1200 refresh: 60 vid: 16553 [ 40726.080] (II) NOUVEAU(0): Supported detailed timing: [ 40726.080] (II) NOUVEAU(0): clock: 138.5 MHz Image Size: 477 x 268 mm [ 40726.080] (II) NOUVEAU(0): h_active: 1920 h_sync: 1968 h_sync_end 2000 h_blank_end 2080 h_border: 0 [ 40726.080] (II) NOUVEAU(0): v_active: 1080 v_sync: 1083 v_sync_end 1088 v_blanking: 1111 v_border: 0 [ 40726.080] (II) NOUVEAU(0): Ranges: V min: 56 V max: 61 Hz, H min: 30 H max: 75 kHz, PixClock max 175 MHz [ 40726.080] (II) NOUVEAU(0): Monitor name: SyncMaster [ 40726.080] (II) NOUVEAU(0): Serial No: H9NS400521 [ 40726.080] (II) NOUVEAU(0): EDID (in hex): [ 40726.080] (II) NOUVEAU(0): 00ffffffffffff004c2de7043232594d [ 40726.081] (II) NOUVEAU(0): 0e13010380301b782a78f1a655489b26 [ 40726.081] (II) NOUVEAU(0): 1250542308008100814081809500b300 [ 40726.081] (II) NOUVEAU(0): a940010101011a3680a070381f403020 [ 40726.081] (II) NOUVEAU(0): 3500dd0c1100001a000000fd00383d1e [ 40726.081] (II) NOUVEAU(0): 4b11000a202020202020000000fc0053 [ 40726.081] (II) NOUVEAU(0): 796e634d61737465720a2020000000ff [ 40726.081] (II) NOUVEAU(0): 0048394e533430303532310a20200094 [ 40726.081] (II) NOUVEAU(0): Printing probed modes for output DVI-D-1 [ 40726.081] (II) NOUVEAU(0): Modeline "1920x1080"x59.9 138.50 1920 1968 2000 2080 1080 1083 1088 1111 +hsync -vsync (66.6 kHz) [ 40726.081] (II) NOUVEAU(0): Modeline "1600x1200"x60.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz) [ 40726.081] (II) NOUVEAU(0): Modeline "1680x1050"x60.0 146.25 1680 1784 1960 2240 1050 1053 1059 1089 -hsync +vsync (65.3 kHz) [ 40726.081] (II) NOUVEAU(0): Modeline "1280x1024"x60.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz) [ 40726.081] (II) NOUVEAU(0): Modeline "1440x900"x59.9 106.50 1440 1520 1672 1904 900 903 909 934 -hsync +vsync (55.9 kHz) [ 40726.081] (II) NOUVEAU(0): Modeline "1280x960"x60.0 108.00 1280 1376 1488 1800 960 961 964 1000 +hsync +vsync (60.0 kHz) [ 40726.081] (II) NOUVEAU(0): Modeline "1280x800"x59.8 83.50 1280 1352 1480 1680 800 803 809 831 +hsync -vsync (49.7 kHz) [ 40726.081] (II) NOUVEAU(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) [ 40726.081] (II) NOUVEAU(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) [ 40726.081] (II) NOUVEAU(0): Modeline "800x600"x56.2 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) [ 40726.081] (II) NOUVEAU(0): Modeline "640x480"x60.0 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) [ 40726.081] (II) NOUVEAU(0): EDID for output TV-1 [ 40726.081] (II) NOUVEAU(0): Output VGA-1 disconnected [ 40726.081] (II) NOUVEAU(0): Output VGA-2 disconnected [ 40726.081] (II) NOUVEAU(0): Output DVI-D-1 connected [ 40726.081] (II) NOUVEAU(0): Output TV-1 disconnected [ 40726.081] (II) NOUVEAU(0): Using user preference for initial modes [ 40726.081] (II) NOUVEAU(0): Output DVI-D-1 using initial mode 1920x1080 [ 40726.081] (II) NOUVEAU(0): Using default gamma of (1.0, 1.0, 1.0) unless otherwise stated. [ 40726.081] (--) NOUVEAU(0): Virtual size is 1920x1080 (pitch 0) [ 40726.081] (**) NOUVEAU(0): Driver mode "1920x1080": 138.5 MHz (scaled from 0.0 MHz), 66.6 kHz, 59.9 Hz [ 40726.081] (II) NOUVEAU(0): Modeline "1920x1080"x59.9 138.50 1920 1968 2000 2080 1080 1083 1088 1111 +hsync -vsync (66.6 kHz) [ 40726.081] (**) NOUVEAU(0): Driver mode "1600x1200": 162.0 MHz (scaled from 0.0 MHz), 75.0 kHz, 60.0 Hz [ 40726.081] (II) NOUVEAU(0): Modeline "1600x1200"x60.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz) [ 40726.082] (**) NOUVEAU(0): Driver mode "1680x1050": 146.2 MHz (scaled from 0.0 MHz), 65.3 kHz, 60.0 Hz [ 40726.082] (II) NOUVEAU(0): Modeline "1680x1050"x60.0 146.25 1680 1784 1960 2240 1050 1053 1059 1089 -hsync +vsync (65.3 kHz) [ 40726.082] (**) NOUVEAU(0): Driver mode "1280x1024": 108.0 MHz (scaled from 0.0 MHz), 64.0 kHz, 60.0 Hz [ 40726.082] (II) NOUVEAU(0): Modeline "1280x1024"x60.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz) [ 40726.082] (**) NOUVEAU(0): Driver mode "1440x900": 106.5 MHz (scaled from 0.0 MHz), 55.9 kHz, 59.9 Hz [ 40726.082] (II) NOUVEAU(0): Modeline "1440x900"x59.9 106.50 1440 1520 1672 1904 900 903 909 934 -hsync +vsync (55.9 kHz) [ 40726.082] (**) NOUVEAU(0): Driver mode "1280x960": 108.0 MHz (scaled from 0.0 MHz), 60.0 kHz, 60.0 Hz [ 40726.082] (II) NOUVEAU(0): Modeline "1280x960"x60.0 108.00 1280 1376 1488 1800 960 961 964 1000 +hsync +vsync (60.0 kHz) [ 40726.082] (**) NOUVEAU(0): Driver mode "1280x800": 83.5 MHz (scaled from 0.0 MHz), 49.7 kHz, 59.8 Hz [ 40726.082] (II) NOUVEAU(0): Modeline "1280x800"x59.8 83.50 1280 1352 1480 1680 800 803 809 831 +hsync -vsync (49.7 kHz) [ 40726.082] (**) NOUVEAU(0): Driver mode "1024x768": 65.0 MHz (scaled from 0.0 MHz), 48.4 kHz, 60.0 Hz [ 40726.082] (II) NOUVEAU(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) [ 40726.082] (**) NOUVEAU(0): Driver mode "800x600": 40.0 MHz (scaled from 0.0 MHz), 37.9 kHz, 60.3 Hz [ 40726.082] (II) NOUVEAU(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) [ 40726.082] (**) NOUVEAU(0): Driver mode "800x600": 36.0 MHz (scaled from 0.0 MHz), 35.2 kHz, 56.2 Hz [ 40726.082] (II) NOUVEAU(0): Modeline "800x600"x56.2 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) [ 40726.082] (**) NOUVEAU(0): Driver mode "640x480": 25.2 MHz (scaled from 0.0 MHz), 31.5 kHz, 60.0 Hz [ 40726.082] (II) NOUVEAU(0): Modeline "640x480"x60.0 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) [ 40726.082] (**) NOUVEAU(0): Display dimensions: (477, 268) mm [ 40726.082] (**) NOUVEAU(0): DPI set to (102, 102) [ 40726.082] (II) Loading sub module "fb" [ 40726.082] (II) LoadModule: "fb" [ 40726.082] (II) Loading /usr/lib/xorg/modules/libfb.so [ 40726.083] (II) Module fb: vendor="X.Org Foundation" [ 40726.083] compiled for 1.9.4.901, module version = 1.0.0 [ 40726.083] ABI class: X.Org ANSI C Emulation, version 0.4 [ 40726.083] (II) Loading sub module "exa" [ 40726.083] (II) LoadModule: "exa" [ 40726.083] (II) Loading /usr/lib/xorg/modules/libexa.so [ 40726.083] (II) Module exa: vendor="X.Org Foundation" [ 40726.083] compiled for 1.9.4.901, module version = 2.5.0 [ 40726.083] ABI class: X.Org Video Driver, version 8.0 [ 40726.083] (II) Loading sub module "shadowfb" [ 40726.083] (II) LoadModule: "shadowfb" [ 40726.083] (II) Loading /usr/lib/xorg/modules/libshadowfb.so [ 40726.084] (II) Module shadowfb: vendor="X.Org Foundation" [ 40726.084] compiled for 1.9.4.901, module version = 1.0.0 [ 40726.084] ABI class: X.Org ANSI C Emulation, version 0.4 [ 40726.084] (--) Depth 24 pixmap format is 32 bpp [ 40726.085] (II) NOUVEAU(0): Opened GPU channel 1 [ 40726.086] (II) NOUVEAU(0): [DRI2] Setup complete [ 40726.086] (II) NOUVEAU(0): [DRI2] DRI driver: nouveau_vieux [ 40726.087] (EE) NOUVEAU(0): Error allocating scanout buffer: 0 [ 40726.087] Fatal server error: [ 40726.087] AddScreen/ScreenInit failed for driver 0 [ 40726.087] [ 40726.087] Please consult the The X.Org Foundation support at http://wiki.x.org for help. [ 40726.087] Please also check the log file at "/var/log/Xorg.0.log" for additional information. [ 40726.087] From dj.jankins at gmail.com Fri Mar 11 08:37:24 2011 From: dj.jankins at gmail.com (Donald Jenkins) Date: Fri, 11 Mar 2011 23:37:24 +0700 Subject: Problem setting refresh rate on 8400GS In-Reply-To: <op.vr3cb0lntkuz1w@emo> References: <AANLkTinVNbeYDo_g=4EYVt0BJ=4Cf6SJ02dPmUvw860w@xxxxxxxxxxxxxx> <op.vr3cb0lntkuz1w@emo> Message-ID: <AANLkTimKVcOoJayrPo71k7XM34z85XVaDauo=ew6KQ_Y@xxxxxxxxxxxxxx> I start Xorg manually by typing "startx" at the terminal. I use this rarely, because I put the computer in sleep state often. Modeline did not helped. I'm correct if I try to use a sample modeline given in Xorg.*.log for 75hz refresh? I got the board recently, I never used blob and never will be. I also do not rely on Gallium 3D today, so I use safe environ now. I had some tests with newer nvidia board, with same result. All works OK except this terrible behaviour. The monitor is capable to use 80Ghz/75Hz refresh rate, I use(d) ati before, before it goes mad sometimes. The refresh rate picked up correctly on ati, I used this for years. I can boot up into framebuffer console with 75hz normally via video= kernel command line parameter. When startx, all drops down to 60hz, and can be only manually set up with xrandr. Sorry for incorrect English and thanks alot for your answer. On Thu, Mar 10, 2011 at 2:27 AM, Emil Velikov <emil.velikov at yahoo.co.uk>wrote: > > Hi Donald, > See the comments inline > > > On Wed, 09 Mar 2011 05:38:55 -0000, Donald Jenkins <dj.jankins at gmail.com> > wrote: > >> Hello. >> Having serious problems with all nvidia boards plugged on my PC, now on >> 8400GS. >> Xorg with 2D-only nouveau driver sets invalid preferred refresh rate 60hz >> on >> SAMTRON 73v, when 75hz needed. >> > > How old is this monitor ? Did it work correctly using the blob/earlier > nouveau ? > > > output of xrandr: >> >> Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 8192 x 8192 >> DVI-I-1 disconnected (normal left inverted right x axis y axis) >> VGA-1 connected 1280x1024+0+0 (normal left inverted right x axis y axis) >> 338mm x 270mm >> 1280x1024 60.0*+ 75.0 >> 1152x864 75.0 >> 1024x768 75.1 70.1 60.0 >> 832x624 74.6 >> 800x600 72.2 75.0 60.3 56.2 >> 640x480 72.8 75.0 66.7 60.0 >> 720x400 70.1 >> >> I can *manually* set correct refresh rate using xrandr -r 75 command (for >> example, in .xinitrc), but Xorg configuration don't recognize it at all. >> Some full screen software games reset refresh rate back to 60hz. >> How I can "hardcode" it in xorg.conf? I really stuck at this point. >> > > You can find how to "hardcode" the timings/refresh rate, by googling for > "xorg modeline". > > Note 1: The refresh rate change will take place AFTER Xorg is up (i.e. > currently there is not way to set it at boot time). > Note 2: The generated values may or may not work. What you can try is > startup "Xorg --verbose 9" using the blob and it should print the refresh > rate/timings used. Then you can add it to xorg.conf > > Thanks. >> > > P.S. Apologies for any typos > > Cheers > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/nouveau/attachments/20110311/e746eff1/attachment.htm> From bugzilla-daemon at freedesktop.org Fri Mar 11 10:53:27 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Fri, 11 Mar 2011 10:53:27 -0800 (PST) Subject: [Bug 35222] New: xvideo : NV17 Video Texture support Message-ID: <bug-35222-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> https://bugs.freedesktop.org/show_bug.cgi?id=35222 Summary: xvideo : NV17 Video Texture support Product: xorg Version: git Platform: All OS/Version: Linux (All) Status: NEW Severity: enhancement Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org ReportedBy: castet.matthieu at free.fr QAContact: xorg-team at lists.x.org The close source driver support a Texture overlay. It is better than the blitter one and need less work than the overlay one. It could be interesting to add it for nv17-n2x cards. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at freedesktop.org Fri Mar 11 11:58:01 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Fri, 11 Mar 2011 11:58:01 -0800 (PST) Subject: [Bug 34508] [grub x86_64-efi] Macbook 5, 2 - conflicting fb hw usage nouveaufb vs EFI VGA - removing generic driver In-Reply-To: <bug-34508-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> References: <bug-34508-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> Message-ID: <20110311195801.3880313004F@xxxxxxxxxxxxxxxxxxxxxxxx> https://bugs.freedesktop.org/show_bug.cgi?id=34508 --- Comment #3 from Pekka Paalanen <pq at iki.fi> 2011-03-11 11:58:00 PST --- (In reply to comment #0) > I hit a > bug with this error: "fb: conflicting fb hw usage nouveaufb vs EFI VGA - > removing generic driver". FWIW, that message is not an error in itself, the system is simply doing the right thing: a generic driver (efifb) is being kicked out, so a hardware-specific driver (nouveau) can start driving the hardware. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From younes.m at gmail.com Fri Mar 11 12:16:38 2011 From: younes.m at gmail.com (younes.m at gmail.com) Date: Fri, 11 Mar 2011 20:16:38 +0000 Subject: nouveaufb problems with NV18 In-Reply-To: <20110311152718.19243.qmail@xxxxxxxxxxxxxxxxxxx> Message-ID: <20cf304346f0aae407049e3aa3fa@xxxxxxxxxx> On , George Spelvin <linux at horizon.com> wrote: > Thanks for the reply! Sorry it took me a day to respond. > > Is there anything at all connected to the other output (referred to as > TV-1 > > in your log)? You can try disabling TV detection with the tv_disable > > nouveau.ko module parameter if a non-existent TV is somehow being > detected. > No, nothing. Adding the parameter (it's actually tv_disable=1; required > a couple of reboots since the module's loaded early and can't be unloaded) > produced a full-screen console (67x240), but with the same "flashing" > to the right on system activity. (I don't get it on VC switch now, > however!) > Also, the display (DVI-D) appears to be half a line low. Tall characters > ($ and ^) on the top line have their topmost row of pixels replicated > into a > vertical stripe, and the bottom row of text is only half visible. > (Actually a little more than half; both bars of = are visible.) > X still refuses to start; messages attached. > ... > [ 40726.087] (EE) NOUVEAU(0): Error allocating scanout buffer: 0 > ... I think someone else had the above problem on an NV1x card as well recently and tried to debug it. Not sure about your fb related issues though, that might be a separate issue. You can open a bug against nouveau at bugs.freedesktop.org, hopefully someone can assist you further. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/nouveau/attachments/20110311/a5e8844f/attachment.html> From glseba at yahoo.com Fri Mar 11 12:22:12 2011 From: glseba at yahoo.com (Sebastian Glita) Date: Fri, 11 Mar 2011 12:22:12 -0800 (PST) Subject: VGA output unavailable G72M [NVS 110M] Message-ID: <808641.58337.qm@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> Hi, Doing localhost ~ # xrandr --output VGA-1 --auto does not connect VGA-1 output. Cannot activate VGA-1 at all. Relevant details follow. Appreciate any suggestions. regard s. localhost ~ # Xorg -version This is a pre-release version of the X server from The X.Org Foundation. It is not supported in any way. Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. Select the "xorg" product for bugs you find in this release. Before reporting bugs in pre-release versions please check the latest version in the X.Org Foundation git repository. See http://wiki.x.org/wiki/GitPage for git access instructions. X.Org X Server 1.10.99.1 Release Date: unreleased X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.37-pf5 x86_64 Gentoo Current Operating System: Linux localhost 2.6.37-pf5 #1 SMP Sat Mar 5 10:28:40 EET 2011 x86_64 Kernel command line: ... Build Date: 10 March 2011 05:05:44AM Current version of pixman: 0.21.7 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. localhost ~ # lspci -vknn 01:00.0 VGA compatible controller [0300]: nVidia Corporation G72M [Quadro NVS 110M/GeForce Go 7300] [10de:01d7] (rev a1) (prog-if 00 [VGA controller]) Subsystem: Toshiba America Info Systems Device [1179:ff02] Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at dd000000 (32-bit, non-prefetchable) [size=16M] Memory at c0000000 (64-bit, prefetchable) [size=256M] Memory at dc000000 (64-bit, non-prefetchable) [size=16M] Capabilities: [60] Power Management version 2 Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [78] Express Endpoint, MSI 00 Capabilities: [100] Virtual Channel Capabilities: [128] Power Budgeting <?> Kernel driver in use: nouveau Kernel modules: nouveau localhost ~ # cat /var/log/Xorg.0.log [ 50.007] This is a pre-release version of the X server from The X.Org Foundation. It is not supported in any way. Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. Select the "xorg" product for bugs you find in this release. Before reporting bugs in pre-release versions please check the latest version in the X.Org Foundation git repository. See http://wiki.x.org/wiki/GitPage for git access instructions. [ 50.007] X.Org X Server 1.10.99.1 Release Date: unreleased [ 50.007] X Protocol Version 11, Revision 0 [ 50.007] Build Operating System: Linux 2.6.37-pf5 x86_64 Gentoo [ 50.007] Current Operating System: Linux localhost 2.6.37-pf5 #1 SMP Sat Mar 5 10:28:40 EET 2011 x86_64 [ 50.007] Kernel command line: ... [ 50.008] Build Date: 10 March 2011 05:05:44AM [ 50.008] [ 50.008] Current version of pixman: 0.21.7 [ 50.008] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 50.008] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 50.008] (==) Log file: "/var/log/Xorg.0.log", Time: Fri Mar 11 09:41:05 2011 [ 50.048] (==) Using config file: "/etc/X11/xorg.conf" [ 50.048] (==) Using config directory: "/etc/X11/xorg.conf.d" [ 50.048] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 50.113] (**) Option "defaultserverlayout" "SV" [ 50.113] (++) ServerLayout "SV1" .... [ 51.758] (II) NOUVEAU(0): EDID for output LVDS-1 [ 51.758] (II) NOUVEAU(0): Manufacturer: SEC Model: 3633 Serial#: 0 [ 51.758] (II) NOUVEAU(0): Year: 2005 Week: 0 [ 51.758] (II) NOUVEAU(0): EDID Version: 1.3 [ 51.758] (II) NOUVEAU(0): Digital Display Input [ 51.758] (II) NOUVEAU(0): Max Image Size [cm]: horiz.: 33 vert.: 21 [ 51.758] (II) NOUVEAU(0): Gamma: 2.20 [ 51.758] (II) NOUVEAU(0): No DPMS capabilities specified [ 51.758] (II) NOUVEAU(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4 [ 51.758] (II) NOUVEAU(0): First detailed timing is preferred mode [ 51.758] (II) NOUVEAU(0): redX: 0.580 redY: 0.340 greenX: 0.310 greenY: 0.550 [ 51.758] (II) NOUVEAU(0): blueX: 0.155 blueY: 0.155 whiteX: 0.313 whiteY: 0.329 [ 51.758] (II) NOUVEAU(0): Manufacturer's mask: 0 [ 51.758] (II) NOUVEAU(0): Supported detailed timing: [ 51.758] (II) NOUVEAU(0): clock: 68.9 MHz Image Size: 331 x 207 mm [ 51.758] (II) NOUVEAU(0): h_active: 1280 h_sync: 1296 h_sync_end 1344 h_blank_end 1 408 h_border: 0 [ 51.758] (II) NOUVEAU(0): v_active: 800 v_sync: 801 v_sync_end 804 v_blanking: 816 v_border: 0 [ 51.758] (II) NOUVEAU(0): Unknown vendor-specific block f [ 51.758] (II) NOUVEAU(0): SAMSUNG [ 51.758] (II) NOUVEAU(0): LTN154X3-L06 [ 51.758] (II) NOUVEAU(0): EDID (in hex): [ 51.758] (II) NOUVEAU(0): 00ffffffffffff004ca3333600000000 [ 51.758] (II) NOUVEAU(0): 000f0103802115780a87f594574f8c27 [ 51.758] (II) NOUVEAU(0): 27505400000001010101010101010101 [ 51.758] (II) NOUVEAU(0): 010101010101ee1a0080502010301030 [ 51.758] (II) NOUVEAU(0): 13004bcf100000190000000f00000000 [ 51.758] (II) NOUVEAU(0): 00000000002387026402000000fe0053 [ 51.758] (II) NOUVEAU(0): 414d53554e470a2020202020000000fe [ 51.758] (II) NOUVEAU(0): 004c544e31353458332d4c30360a0070 [ 51.758] (II) NOUVEAU(0): EDID vendor "SEC", prod id 13875 [ 51.758] (II) NOUVEAU(0): Printing DDC gathered Modelines: [ 51.758] (II) NOUVEAU(0): Modeline "1280x800"x0.0 68.94 1280 1296 1344 1408 800 801 804 816 -hsync -vsync (49.0 kHz) [ 51.758] (II) NOUVEAU(0): Printing probed modes for output LVDS-1 [ 51.758] (II) NOUVEAU(0): Modeline "1280x800"x60.0 68.94 1280 1296 1344 1408 800 801 804 816 -hsync -vsync (49.0 kHz) [ 51.758] (II) NOUVEAU(0): Modeline "1024x768"x59.9 63.50 1024 1072 1176 1328 768 771 775 798 -hsync +vsync (47.8 kHz) [ 51.758] (II) NOUVEAU(0): Modeline "800x600"x59.9 38.25 800 832 912 1024 600 603 607 624 -hsync +vsync (37.4 kHz) [ 51.758] (II) NOUVEAU(0): Modeline "640x480"x59.4 23.75 640 664 720 800 480 483 487 500 -hsync +vsync (29.7 kHz) [ 51.758] (II) NOUVEAU(0): Modeline "720x400"x59.6 22.25 720 744 808 896 400 403 413 417 -hsync +vsync (24.8 kHz) [ 51.758] (II) NOUVEAU(0): Modeline "640x400"x60.0 20.00 640 664 720 800 400 403 409 417 -hsync +vsync (25.0 kHz) [ 51.758] (II) NOUVEAU(0): Modeline "640x350"x59.8 17.50 640 664 720 800 350 353 363 366 -hsync +vsync (21.9 kHz) [ 51.792] (II) NOUVEAU(0): EDID for output VGA-1 [ 51.818] (II) NOUVEAU(0): EDID for output TV-1 [ 51.818] (II) NOUVEAU(0): Output LVDS-1 disconnected [ 51.818] (II) NOUVEAU(0): Output VGA-1 disconnected [ 51.818] (II) NOUVEAU(0): Output TV-1 disconnected [ 51.818] (WW) NOUVEAU(0): No outputs definitely connected, trying again... [ 51.818] (II) NOUVEAU(0): Output LVDS-1 connected [ 51.818] (II) NOUVEAU(0): Output VGA-1 disconnected [ 51.818] (II) NOUVEAU(0): Output TV-1 disconnected [ 51.818] (II) NOUVEAU(0): Using user preference for initial modes [ 51.818] (II) NOUVEAU(0): Output LVDS-1 using initial mode 1280x800 localhost ~ # xdpyinfo name of display: :0 version number: 11.0 vendor string: The X.Org Foundation vendor release number: 11099001 X.Org version: 1.10.99.1 maximum request size: 16777212 bytes motion buffer size: 256 bitmap unit, bit order, padding: 32, LSBFirst, 32 image byte order: LSBFirst number of supported pixmap formats: 7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 keycode range: minimum 8, maximum 255 focus: window 0x5e00004, revert to PointerRoot number of extensions: 26 BIG-REQUESTS Composite DAMAGE DOUBLE-BUFFER DPMS DRI2 GLX Generic Event Extension MIT-SCREEN-SAVER MIT-SHM RANDR RECORD RENDER SGI-GLX SHAPE SYNC X-Resource XC-MISC XFIXES XFree86-VidModeExtension XINERAMA XInputExtension XKEYBOARD XTEST XVideo XVideo-MotionCompensation default screen number: 0 number of screens: 1 screen #0: dimensions: 800x1280 pixels (270x432 millimeters) resolution: 75x75 dots per inch depths (7): 24, 1, 4, 8, 15, 16, 32 root window id: 0x18d depth of root window: 24 planes number of colormaps: minimum 1, maximum 1 default colormap: 0x20 default number of colormap cells: 256 preallocated pixels: black 0, white 16777215 options: backing-store NO, save-unders NO largest cursor: 64x64 localhost ~ # cat /etc/X11/xorg.conf Section "Screen" Identifier "Console1" Device "NVIDIA C. Quadro NVS 110M (DualFeet)" Monitor "LCD 15.4'' WXGA" DefaultDepth 24 SubSection "Display" Visual "TrueColor Depth 24 Modes "1280x800" ViewPort 0 0 Virtual 2880 2880 EndSubSection EndSection Section "Screen" Identifier "Monitor2" Device "NVIDIA C. Quadro NVS 110M (DualFeet)" Monitor "Monitor" DefaultDepth 24 SubSection "Display" Visual "TrueColor" Depth 24 Modes "1600x1200" ViewPort 0 0 Virtual 2880 2880 EndSubSection EndSection Section "DRI" Group "video" Mode 0660 EndSection Section "ServerLayout" Identifier "SV1" Screen "Console1" Absolute 0 0 Screen "Monitor2" EndSection Section "Monitor" Identifier "LCD 15.4'' WXGA" EndSection Section "Monitor" Identifier "Monitor" Option "RightOf" "LVDS-1" Option "PreferredMode" "1600x1200 at 60" UseModes "VGA" EndSection Section "Modes" Identifier "VGA" Modeline "1280x1024 at 60" 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync Modeline "1600x1200 at 60" 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync EndSection Section "Device" Identifier "NVIDIA C. Quadro NVS 110M (DualFeet)" VendorName "NVIDIA Corp" Driver "nouveau" Option "Monitor-LVDS-1" "LCD 15.4'' WXGA" Option "Monitor-VGA-1" "Monitor" Option "HW_cursor" "true" EndSection -- a lens, a ray, a screen: a projection; an ocean, the sky, a projection... and glasses. From bugzilla-daemon at freedesktop.org Fri Mar 11 12:34:24 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Fri, 11 Mar 2011 12:34:24 -0800 (PST) Subject: [Bug 35171] x11-drivers/xf86-video-nouveau does not work with Quadro FX1800 on HP elitebook 8540w In-Reply-To: <bug-35171-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> References: <bug-35171-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> Message-ID: <20110311203424.1DD0F13000C@xxxxxxxxxxxxxxxxxxxxxxxx> https://bugs.freedesktop.org/show_bug.cgi?id=35171 --- Comment #1 from Jiri Pittner <jiri at pittnerovi.com> 2011-03-11 12:34:23 PST --- If I give up hardware acceleration, with nouveau.noaccel=1 it works, also with external DVI monitor. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at freedesktop.org Fri Mar 11 13:53:00 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Fri, 11 Mar 2011 13:53:00 -0800 (PST) Subject: [Bug 35172] Nouveau crashes my gnome session In-Reply-To: <bug-35172-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> References: <bug-35172-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> Message-ID: <20110311215300.31AB413004E@xxxxxxxxxxxxxxxxxxxxxxxx> https://bugs.freedesktop.org/show_bug.cgi?id=35172 LCID Fire <lcid-fire at gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #44306|0 |1 is obsolete| | --- Comment #4 from LCID Fire <lcid-fire at gmx.net> 2011-03-11 13:52:59 PST --- Created an attachment (id=44368) --> (https://bugs.freedesktop.org/attachment.cgi?id=44368) More detailed syslog -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at freedesktop.org Fri Mar 11 13:56:06 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Fri, 11 Mar 2011 13:56:06 -0800 (PST) Subject: [Bug 35172] Nouveau crashes my gnome session In-Reply-To: <bug-35172-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> References: <bug-35172-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> Message-ID: <20110311215606.7D4AD13004E@xxxxxxxxxxxxxxxxxxxxxxxx> https://bugs.freedesktop.org/show_bug.cgi?id=35172 --- Comment #5 from LCID Fire <lcid-fire at gmx.net> 2011-03-11 13:56:06 PST --- Attached a log using debug symbols. Don't worry I don't have any illusion that this will be fixed anytime soon - but I rather pass the information to you guys than file a pointless bug downstream (not that the maintainers will or could fix anything). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at freedesktop.org Fri Mar 11 21:44:14 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Fri, 11 Mar 2011 21:44:14 -0800 (PST) Subject: [Bug 30086] Nouveau fails with unreadable EDID In-Reply-To: <bug-30086-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> References: <bug-30086-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> Message-ID: <20110312054414.E4B9D13000C@xxxxxxxxxxxxxxxxxxxxxxxx> https://bugs.freedesktop.org/show_bug.cgi?id=30086 alci at mecadu.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #25 from alci at mecadu.org 2011-03-11 21:44:13 PST --- Last upgrade did fix the issue for me. As I was the initial reporter and the problem was supposed to be resolved, I close it again. Many thanks to all. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at freedesktop.org Sun Mar 13 03:50:05 2011 From: bugzilla-daemon at freedesktop.org (bugzilla-daemon at freedesktop.org) Date: Sun, 13 Mar 2011 03:50:05 -0700 (PDT) Subject: [Bug 35267] New: nouveau fails to load BIOS on EFI boot. Message-ID: <bug-35267-8800@xxxxxxxxxxxxxxxxxxxxxxxxx/> https://bugs.freedesktop.org/show_bug.cgi?id=35267 Summary: nouveau fails to load BIOS on EFI boot. Product: xorg Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org ReportedBy: freedesktop.org at spahan.ch QAContact: xorg-team at lists.x.org Created an attachment (id=44410) --> (https://bugs.freedesktop.org/attachment.cgi?id=44410) full dmesg output I try use nouveau on my gentoo. As this is a MacBook, i installed Grub2 and boot directly in EFI mode (eg, no BIOS simulation.... i think). At loading the nouveau driver, it fails due to no valid BIOS found. The relevant error message is (dmesg output attached):nouveau 0000:01:00.0: enabling device (0002 -> 0003) nouveau 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 nouveau 0000:01:00.0: setting latency timer to 64 [drm] nouveau 0000:01:00.0: Detected an NV50 generation card (0x084700a2) checking generic (80060000 960000) vs hw (80000000 10000000) fb: conflicting fb hw usage nouveaufb vs EFI VGA - removing generic driver Console: switching to colour dummy device 80x25 [drm] nouveau 0000:01:00.0: Attempting to load BIOS image from PRAMIN [drm] nouveau 0000:01:00.0: ... BIOS signature not found [drm] nouveau 0000:01:00.0: Attempting to load BIOS image from PROM [drm] nouveau 0000:01:00.0: ... BIOS signature not found [drm] nouveau 0000:01:00.0: Attempting to load BIOS image from PCIROM nouveau 0000:01:00.0: Invalid ROM contents [drm] nouveau 0000:01:00.0: ... BIOS signature not found [drm] nouveau 0000:01:00.0: Attempting to load BIOS image from ACPI [drm] nouveau 0000:01:00.0: ... BIOS signature not found [drm] nouveau 0000:01:00.0: No valid BIOS image found nouveau 0000:01:00.0: PCI INT A disabled
