Re: nouveau/ NV11: 3.12 freezes if X.org is started headless
On Wed, Nov 27, 2013 at 12:15 PM, Ilia Mirkin wrote: > On Tue, Nov 26, 2013 at 8:35 PM, Stefan Lippers-Hollmann wrote: >> Hi >> >> On Wednesday 27 November 2013, Ilia Mirkin wrote: >>> On Tue, Nov 26, 2013 at 7:18 PM, Stefan Lippers-Hollmann >>> wrote: >>> > Hi >>> > >>> > On Tuesday 26 November 2013, Ilia Mirkin wrote: >>> >> On Tue, Nov 26, 2013 at 6:03 PM, Stefan Lippers-Hollmann >>> >> wrote: >>> >> > v3.11 is fine, with and without monitor attached. >>> >> > v3.12 is fine as long as X.org isn't started (but may fail to reboot >>> >> > cleanly). If a monitor is connected I don't observe any problems, >>> >> > it freezes without a monitor connected. >>> >> > v3.13-rc1-95-gb975dc3 appears not to freeze without a monitor anymore >>> >> > (I didn't confirm that it's fine with a monitor attached), but I >>> >> > end up with the following Oops (this is before X.org is started). >>> >>> One more idea -- try it with nouveau.runpm=0 -- I've had some odd >>> results with it on my older cards (but I don't remember hangs, but I >>> also didn't spend a lot of time on it, just plopped the option in and >>> moved on). This is a feature that got in in 3.12, and is really the >>> only major nouveau-affecting change in that kernel for your card >>> revision. >> >> You're spot on, that does the trick. > > Great to hear! > >> >> # cat /sys/module/nouveau/parameters/agpmode >> -1 >> # cat /sys/module/nouveau/parameters/runpm >> 0 >> >> v3.13-rc1-95-gb975dc3 >> + >> http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=0397009092427dc60aea8b3c21c00526d8ba >> + nouveau.runpm=0 >> is now stable, with and without a monitor attached; as is >> >> 3.12.1 || v3.12.1-62-g4615252 (stable-queue.git) >> + nouveau.runpm=0 >> > > Dave, looking at the code, it seems like runtime pm should only be > getting activated by default for optimus systems. Stefan's is clearly > not one of those, neither is mine. Unfortunately I have no clue how > the runtime pm subsystem works, but it seems like runtime_suspend() > may be getting called directly, e.g. if there are no monitors attached > to nouveau, perhaps as a result of nouveau_crtc_set_config in > dispnv04/crtc.c. Does the same if (runpm == -1 && !optimus) return > -EBUSY check belong in the runtime_suspend callback? Either that or it needs to be calling some of the other runtime interfaces instead of runtime_autosuspend maybe that last pm_runtime_put_autosuspend should be just pm_runtime_put, but that might need testing on an optimus system. Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nouveau/ NV11: 3.12 freezes if X.org is started headless
On Tue, Nov 26, 2013 at 8:35 PM, Stefan Lippers-Hollmann wrote: > Hi > > On Wednesday 27 November 2013, Ilia Mirkin wrote: >> On Tue, Nov 26, 2013 at 7:18 PM, Stefan Lippers-Hollmann >> wrote: >> > Hi >> > >> > On Tuesday 26 November 2013, Ilia Mirkin wrote: >> >> On Tue, Nov 26, 2013 at 6:03 PM, Stefan Lippers-Hollmann >> >> wrote: >> >> > v3.11 is fine, with and without monitor attached. >> >> > v3.12 is fine as long as X.org isn't started (but may fail to reboot >> >> > cleanly). If a monitor is connected I don't observe any problems, >> >> > it freezes without a monitor connected. >> >> > v3.13-rc1-95-gb975dc3 appears not to freeze without a monitor anymore >> >> > (I didn't confirm that it's fine with a monitor attached), but I >> >> > end up with the following Oops (this is before X.org is started). >> >> One more idea -- try it with nouveau.runpm=0 -- I've had some odd >> results with it on my older cards (but I don't remember hangs, but I >> also didn't spend a lot of time on it, just plopped the option in and >> moved on). This is a feature that got in in 3.12, and is really the >> only major nouveau-affecting change in that kernel for your card >> revision. > > You're spot on, that does the trick. Great to hear! > > # cat /sys/module/nouveau/parameters/agpmode > -1 > # cat /sys/module/nouveau/parameters/runpm > 0 > > v3.13-rc1-95-gb975dc3 > + > http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=0397009092427dc60aea8b3c21c00526d8ba > + nouveau.runpm=0 > is now stable, with and without a monitor attached; as is > > 3.12.1 || v3.12.1-62-g4615252 (stable-queue.git) > + nouveau.runpm=0 > Dave, looking at the code, it seems like runtime pm should only be getting activated by default for optimus systems. Stefan's is clearly not one of those, neither is mine. Unfortunately I have no clue how the runtime pm subsystem works, but it seems like runtime_suspend() may be getting called directly, e.g. if there are no monitors attached to nouveau, perhaps as a result of nouveau_crtc_set_config in dispnv04/crtc.c. Does the same if (runpm == -1 && !optimus) return -EBUSY check belong in the runtime_suspend callback? -ilia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nouveau/ NV11: 3.12 freezes if X.org is started headless
Hi On Wednesday 27 November 2013, Ilia Mirkin wrote: > On Tue, Nov 26, 2013 at 7:18 PM, Stefan Lippers-Hollmann wrote: > > Hi > > > > On Tuesday 26 November 2013, Ilia Mirkin wrote: > >> On Tue, Nov 26, 2013 at 6:03 PM, Stefan Lippers-Hollmann > >> wrote: > >> > v3.11 is fine, with and without monitor attached. > >> > v3.12 is fine as long as X.org isn't started (but may fail to reboot > >> > cleanly). If a monitor is connected I don't observe any problems, > >> > it freezes without a monitor connected. > >> > v3.13-rc1-95-gb975dc3 appears not to freeze without a monitor anymore > >> > (I didn't confirm that it's fine with a monitor attached), but I > >> > end up with the following Oops (this is before X.org is started). > > One more idea -- try it with nouveau.runpm=0 -- I've had some odd > results with it on my older cards (but I don't remember hangs, but I > also didn't spend a lot of time on it, just plopped the option in and > moved on). This is a feature that got in in 3.12, and is really the > only major nouveau-affecting change in that kernel for your card > revision. You're spot on, that does the trick. # cat /sys/module/nouveau/parameters/agpmode -1 # cat /sys/module/nouveau/parameters/runpm 0 v3.13-rc1-95-gb975dc3 + http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=0397009092427dc60aea8b3c21c00526d8ba + nouveau.runpm=0 is now stable, with and without a monitor attached; as is 3.12.1 || v3.12.1-62-g4615252 (stable-queue.git) + nouveau.runpm=0 I don't need to override the agpmode parameter. Thanks a lot! Regards Stefan Lippers-Hollmann -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nouveau/ NV11: 3.12 freezes if X.org is started headless
On Tue, Nov 26, 2013 at 7:18 PM, Stefan Lippers-Hollmann wrote: > Hi > > On Tuesday 26 November 2013, Ilia Mirkin wrote: >> On Tue, Nov 26, 2013 at 6:03 PM, Stefan Lippers-Hollmann >> wrote: >> > v3.11 is fine, with and without monitor attached. >> > v3.12 is fine as long as X.org isn't started (but may fail to reboot >> > cleanly). If a monitor is connected I don't observe any problems, >> > it freezes without a monitor connected. >> > v3.13-rc1-95-gb975dc3 appears not to freeze without a monitor anymore >> > (I didn't confirm that it's fine with a monitor attached), but I >> > end up with the following Oops (this is before X.org is started). One more idea -- try it with nouveau.runpm=0 -- I've had some odd results with it on my older cards (but I don't remember hangs, but I also didn't spend a lot of time on it, just plopped the option in and moved on). This is a feature that got in in 3.12, and is really the only major nouveau-affecting change in that kernel for your card revision. -ilia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nouveau/ NV11: 3.12 freezes if X.org is started headless
Hi On Tuesday 26 November 2013, Ilia Mirkin wrote: > On Tue, Nov 26, 2013 at 6:03 PM, Stefan Lippers-Hollmann wrote: > > v3.11 is fine, with and without monitor attached. > > v3.12 is fine as long as X.org isn't started (but may fail to reboot > > cleanly). If a monitor is connected I don't observe any problems, > > it freezes without a monitor connected. > > v3.13-rc1-95-gb975dc3 appears not to freeze without a monitor anymore > > (I didn't confirm that it's fine with a monitor attached), but I > > end up with the following Oops (this is before X.org is started). […] > > BUG: unable to handle kernel NULL pointer dereference at (null) > > IP: [] _nouveau_clock_init+0x2a/0xaf [nouveau] […] > The oops in 3.13-rc1 should be fixed by applying the equivalent of > http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=0397009092427dc60aea8b3c21c00526d8ba As you expected, the Oops is gone after applying the afforementioned patch, 3.13~ now behaves as 3.12 (it freezes, if X.org is started without a monitor attached). > . Also note that libdrm had a bug when compiled with gcc-4.8 for > pre-nv50 cards, not sure if the fixes have made it to Debian/unstable, > but you need libdrm-2.4.48+ (or compile it with gcc-4.7/clang). The libdrm2 version is 2.4.49-2, which -although it has been compiled with gcc 4.8.2-5[1]- should be unaffected by this issue. According to the ChangeLog the version is at 7ddc98f92f92560e2b52287ae8cf816ca4a057de and no significant patches[2] have been applied. > Lastly, another thing to try if you're getting random hangs is booting > with nouveau.agpmode=0 (and if that helps, seeing if =1 or =2 still > work ok). If that helps, it can be added to the quirks list. Unfortunately this doesn't appear to have an effect, with 3.13~ and the previous patch applied: # cat /sys/module/nouveau/parameters/agpmode 0 # init 5 [ 73.708490] nouveau W[ PTIMER][:01:00.0] unknown input clock freq system frozen. Regards Stefan Lippers-Hollmann [1] https://buildd.debian.org/status/fetch.php?pkg=libdrm=i386=2.4.49-2=1385480211 [2] http://anonscm.debian.org/gitweb/?p=pkg-xorg/lib/libdrm.git;a=blob;f=debian/patches/01_default_perms.diff;h=cdba93e19edf40b2b0b56d951a6416c68a0af6f0;hb=HEAD http://anonscm.debian.org/gitweb/?p=pkg-xorg/lib/libdrm.git;a=blob;f=debian/patches/02_kbsd_modeset.diff;h=260260925fc692c71d955d6490dabf87905abb51;hb=HEAD -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nouveau/ NV11: 3.12 freezes if X.org is started headless
On Tue, Nov 26, 2013 at 6:03 PM, Stefan Lippers-Hollmann wrote: > v3.11 is fine, with and without monitor attached. > v3.12 is fine as long as X.org isn't started (but may fail to reboot > cleanly). If a monitor is connected I don't observe any problems, > it freezes without a monitor connected. > v3.13-rc1-95-gb975dc3 appears not to freeze without a monitor anymore > (I didn't confirm that it's fine with a monitor attached), but I > end up with the following Oops (this is before X.org is started). > > [drm] hdmi device not found 1 0 1 > nouveau [ DEVICE][:01:00.0] BOOT0 : 0x011000a1 > nouveau [ DEVICE][:01:00.0] Chipset: NV11 (NV11) > nouveau [ DEVICE][:01:00.0] Family : NV11 > nouveau [ VBIOS][:01:00.0] checking PRAMIN for image... > nouveau [ VBIOS][:01:00.0] ... appears to be valid > nouveau [ VBIOS][:01:00.0] using image from PRAMIN > nouveau [ VBIOS][:01:00.0] BMP version 5.11 > nouveau [ VBIOS][:01:00.0] version 03.11.00.18.00 > nouveau W[ VBIOS][:01:00.0] DCB contains no useful data > nouveau W[ VBIOS][:01:00.0] DCB contains no useful data > nouveau W[ VBIOS][:01:00.0] DCB contains no useful data > nouveau W[ VBIOS][:01:00.0] DCB contains no useful data > nouveau W[ PTIMER][:01:00.0] unknown input clock freq > nouveau [ PFB][:01:00.0] RAM type: SDRAM > nouveau [ PFB][:01:00.0] RAM size: 32 MiB > nouveau [ PFB][:01:00.0]ZCOMP: 0 tags > BUG: unable to handle kernel NULL pointer dereference at (null) > IP: [] _nouveau_clock_init+0x2a/0xaf [nouveau] > *pde = > Oops: [#1] PREEMPT SMP > Modules linked in: snd arc4 psmouse serio_raw pcspkr i2c_viapro soundcore > nouveau(+) video rtl8180 mxm_wmi eeprom_93cx6 wmi mac80211 i2c_algo_bit > drm_kms_helper ttm cfg80211 parport_pc processor button parport drm rfkill > via_agp ext4 crc16 mbcache jbd2 dm_mod sg sd_mod sr_mod crc_t10dif cdrom > crct10dif_common ata_generic pata_acpi 8139too 8139cp mii uhci_hcd ehci_pci > ehci_hcd floppy pata_via libata usbcore usb_common scsi_mod > CPU: 0 PID: 360 Comm: modprobe Not tainted 3.13.0-rc1-00095-gb975dc3 #42 > Hardware name:/GA-7VT600, BIOS F5 08/16/2004 > task: dee1e880 ti: de33c000 task.ti: de33c000 > EIP: 0060:[] EFLAGS: 00010246 CPU: 0 > EIP is at _nouveau_clock_init+0x2a/0xaf [nouveau] > EAX: de19c94c EBX: de19c900 ECX: EDX: e0f3689c > ESI: EDI: de19c9c8 EBP: de19c944 ESP: de33db90 > DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 > CR0: 8005003b CR2: CR3: 1e078000 CR4: 0790 > Stack: > 0013 e0ebe0da de29d600 0005 de19c900 de29d600 0013 > e0ebe17d de19c900 0005 e0f2e8ca 0001 0012 0012 e0ee7f01 > 0012 de2caa38 000c 00c0 de33dc00 > Call Trace: > [] ? nouveau_object_inc+0x30/0x15a [nouveau] > [] ? nouveau_object_inc+0xd3/0x15a [nouveau] > [] ? nouveau_devobj_ctor+0x58c/0x5cd [nouveau] > [] ? nouveau_object_ctor+0x31/0xb7 [nouveau] > [] ? nouveau_object_new+0x14e/0x1e8 [nouveau] > [] ? nouveau_object_ref+0x67/0x98 [nouveau] > [] ? nouveau_drm_load+0x1ea/0x724 [nouveau] > [] ? drm_dev_register+0xd6/0x16c [drm] > [] ? drm_get_pci_dev+0x8c/0x110 [drm] > [] ? pci_read_config_byte+0x14/0x17 > [] ? nouveau_drm_probe+0x17c/0x19e [nouveau] > [] ? pci_device_probe+0x50/0x9d > [] ? sysfs_create_link+0x24/0x2d > [] ? driver_probe_device+0x8c/0x191 > [] ? kobject_add_internal+0x105/0x1ae > [] ? pci_match_id+0x18/0x36 > [] ? __driver_attach+0x44/0x5f > [] ? bus_for_each_dev+0x50/0x5a > [] ? driver_attach+0x14/0x16 > [] ? __device_attach+0x28/0x28 > [] ? bus_add_driver+0xd9/0x190 > [] ? driver_register+0x77/0xab > [] ? 0xe0a83fff > [] ? 0xe0a83fff > [] ? do_one_initcall+0x8f/0x12c > [] ? jump_label_module_notify+0x139/0x15a > [] ? notifier_call_chain+0x29/0x42 > [] ? __blocking_notifier_call_chain+0x45/0x51 > [] ? load_module+0x13e3/0x18e1 > [] ? SyS_init_module+0x72/0x88 > [] ? sysenter_do_call+0x12/0x28 > Code: d2 55 b9 21 00 00 00 57 56 53 89 c3 8d 68 44 83 ec 10 8b 70 40 89 ef 31 > c0 f3 ab 8d 43 4c 89 43 4c 89 43 50 c6 83 c4 00 00 00 ff <8b> 16 83 fa 19 74 > 39 89 d8 ff 93 e8 00 00 00 89 c7 8b 06 85 ff > EIP: [] _nouveau_clock_init+0x2a/0xaf [nouveau] SS:ESP 0068:de33db90 > CR2: > ---[ end trace 0f90bffd76312ecf ]--- The oops in 3.13-rc1 should be fixed by applying the equivalent of http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=0397009092427dc60aea8b3c21c00526d8ba . Also note that libdrm had a bug when compiled with gcc-4.8 for pre-nv50 cards, not sure if the fixes have made it to Debian/unstable, but you need libdrm-2.4.48+ (or compile it with gcc-4.7/clang). Lastly, another thing to try if you're getting random hangs is booting with nouveau.agpmode=0 (and if that helps, seeing if =1 or =2 still work ok). If that helps, it can be added to the quirks list. -- To unsubscribe from this list: send
Re: nouveau/ NV11: 3.12 freezes if X.org is started headless
On Tue, Nov 26, 2013 at 6:03 PM, Stefan Lippers-Hollmann s@gmx.de wrote: v3.11 is fine, with and without monitor attached. v3.12 is fine as long as X.org isn't started (but may fail to reboot cleanly). If a monitor is connected I don't observe any problems, it freezes without a monitor connected. v3.13-rc1-95-gb975dc3 appears not to freeze without a monitor anymore (I didn't confirm that it's fine with a monitor attached), but I end up with the following Oops (this is before X.org is started). [drm] hdmi device not found 1 0 1 nouveau [ DEVICE][:01:00.0] BOOT0 : 0x011000a1 nouveau [ DEVICE][:01:00.0] Chipset: NV11 (NV11) nouveau [ DEVICE][:01:00.0] Family : NV11 nouveau [ VBIOS][:01:00.0] checking PRAMIN for image... nouveau [ VBIOS][:01:00.0] ... appears to be valid nouveau [ VBIOS][:01:00.0] using image from PRAMIN nouveau [ VBIOS][:01:00.0] BMP version 5.11 nouveau [ VBIOS][:01:00.0] version 03.11.00.18.00 nouveau W[ VBIOS][:01:00.0] DCB contains no useful data nouveau W[ VBIOS][:01:00.0] DCB contains no useful data nouveau W[ VBIOS][:01:00.0] DCB contains no useful data nouveau W[ VBIOS][:01:00.0] DCB contains no useful data nouveau W[ PTIMER][:01:00.0] unknown input clock freq nouveau [ PFB][:01:00.0] RAM type: SDRAM nouveau [ PFB][:01:00.0] RAM size: 32 MiB nouveau [ PFB][:01:00.0]ZCOMP: 0 tags BUG: unable to handle kernel NULL pointer dereference at (null) IP: [e0ecaa4e] _nouveau_clock_init+0x2a/0xaf [nouveau] *pde = Oops: [#1] PREEMPT SMP Modules linked in: snd arc4 psmouse serio_raw pcspkr i2c_viapro soundcore nouveau(+) video rtl8180 mxm_wmi eeprom_93cx6 wmi mac80211 i2c_algo_bit drm_kms_helper ttm cfg80211 parport_pc processor button parport drm rfkill via_agp ext4 crc16 mbcache jbd2 dm_mod sg sd_mod sr_mod crc_t10dif cdrom crct10dif_common ata_generic pata_acpi 8139too 8139cp mii uhci_hcd ehci_pci ehci_hcd floppy pata_via libata usbcore usb_common scsi_mod CPU: 0 PID: 360 Comm: modprobe Not tainted 3.13.0-rc1-00095-gb975dc3 #42 Hardware name:/GA-7VT600, BIOS F5 08/16/2004 task: dee1e880 ti: de33c000 task.ti: de33c000 EIP: 0060:[e0ecaa4e] EFLAGS: 00010246 CPU: 0 EIP is at _nouveau_clock_init+0x2a/0xaf [nouveau] EAX: de19c94c EBX: de19c900 ECX: EDX: e0f3689c ESI: EDI: de19c9c8 EBP: de19c944 ESP: de33db90 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 CR0: 8005003b CR2: CR3: 1e078000 CR4: 0790 Stack: 0013 e0ebe0da de29d600 0005 de19c900 de29d600 0013 e0ebe17d de19c900 0005 e0f2e8ca 0001 0012 0012 e0ee7f01 0012 de2caa38 000c 00c0 de33dc00 Call Trace: [e0ebe0da] ? nouveau_object_inc+0x30/0x15a [nouveau] [e0ebe17d] ? nouveau_object_inc+0xd3/0x15a [nouveau] [e0ee7f01] ? nouveau_devobj_ctor+0x58c/0x5cd [nouveau] [e0ebdc3b] ? nouveau_object_ctor+0x31/0xb7 [nouveau] [e0ebe352] ? nouveau_object_new+0x14e/0x1e8 [nouveau] [e0ebdd28] ? nouveau_object_ref+0x67/0x98 [nouveau] [e0f0d12b] ? nouveau_drm_load+0x1ea/0x724 [nouveau] [e0803e3c] ? drm_dev_register+0xd6/0x16c [drm] [e0805311] ? drm_get_pci_dev+0x8c/0x110 [drm] [c1189d00] ? pci_read_config_byte+0x14/0x17 [e0f0d7e1] ? nouveau_drm_probe+0x17c/0x19e [nouveau] [c118da65] ? pci_device_probe+0x50/0x9d [c1117aeb] ? sysfs_create_link+0x24/0x2d [c120a714] ? driver_probe_device+0x8c/0x191 [c116897f] ? kobject_add_internal+0x105/0x1ae [c118d5c0] ? pci_match_id+0x18/0x36 [c120a885] ? __driver_attach+0x44/0x5f [c120947d] ? bus_for_each_dev+0x50/0x5a [c120a379] ? driver_attach+0x14/0x16 [c120a841] ? __device_attach+0x28/0x28 [c120a0e1] ? bus_add_driver+0xd9/0x190 [c120ad08] ? driver_register+0x77/0xab [e0a84000] ? 0xe0a83fff [e0a84000] ? 0xe0a83fff [c100043f] ? do_one_initcall+0x8f/0x12c [c1094f2d] ? jump_label_module_notify+0x139/0x15a [c1048c79] ? notifier_call_chain+0x29/0x42 [c1048e72] ? __blocking_notifier_call_chain+0x45/0x51 [c1076dcb] ? load_module+0x13e3/0x18e1 [c107733b] ? SyS_init_module+0x72/0x88 [c12ed88d] ? sysenter_do_call+0x12/0x28 Code: d2 55 b9 21 00 00 00 57 56 53 89 c3 8d 68 44 83 ec 10 8b 70 40 89 ef 31 c0 f3 ab 8d 43 4c 89 43 4c 89 43 50 c6 83 c4 00 00 00 ff 8b 16 83 fa 19 74 39 89 d8 ff 93 e8 00 00 00 89 c7 8b 06 85 ff EIP: [e0ecaa4e] _nouveau_clock_init+0x2a/0xaf [nouveau] SS:ESP 0068:de33db90 CR2: ---[ end trace 0f90bffd76312ecf ]--- The oops in 3.13-rc1 should be fixed by applying the equivalent of http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=0397009092427dc60aea8b3c21c00526d8ba . Also note that libdrm had a bug when compiled with gcc-4.8 for pre-nv50 cards, not sure if the fixes have made it to Debian/unstable, but you need libdrm-2.4.48+ (or compile it with gcc-4.7/clang). Lastly, another thing to try if you're
Re: nouveau/ NV11: 3.12 freezes if X.org is started headless
Hi On Tuesday 26 November 2013, Ilia Mirkin wrote: On Tue, Nov 26, 2013 at 6:03 PM, Stefan Lippers-Hollmann s@gmx.de wrote: v3.11 is fine, with and without monitor attached. v3.12 is fine as long as X.org isn't started (but may fail to reboot cleanly). If a monitor is connected I don't observe any problems, it freezes without a monitor connected. v3.13-rc1-95-gb975dc3 appears not to freeze without a monitor anymore (I didn't confirm that it's fine with a monitor attached), but I end up with the following Oops (this is before X.org is started). […] BUG: unable to handle kernel NULL pointer dereference at (null) IP: [e0ecaa4e] _nouveau_clock_init+0x2a/0xaf [nouveau] […] The oops in 3.13-rc1 should be fixed by applying the equivalent of http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=0397009092427dc60aea8b3c21c00526d8ba As you expected, the Oops is gone after applying the afforementioned patch, 3.13~ now behaves as 3.12 (it freezes, if X.org is started without a monitor attached). . Also note that libdrm had a bug when compiled with gcc-4.8 for pre-nv50 cards, not sure if the fixes have made it to Debian/unstable, but you need libdrm-2.4.48+ (or compile it with gcc-4.7/clang). The libdrm2 version is 2.4.49-2, which -although it has been compiled with gcc 4.8.2-5[1]- should be unaffected by this issue. According to the ChangeLog the version is at 7ddc98f92f92560e2b52287ae8cf816ca4a057de and no significant patches[2] have been applied. Lastly, another thing to try if you're getting random hangs is booting with nouveau.agpmode=0 (and if that helps, seeing if =1 or =2 still work ok). If that helps, it can be added to the quirks list. Unfortunately this doesn't appear to have an effect, with 3.13~ and the previous patch applied: # cat /sys/module/nouveau/parameters/agpmode 0 # init 5 [ 73.708490] nouveau W[ PTIMER][:01:00.0] unknown input clock freq system frozen. Regards Stefan Lippers-Hollmann [1] https://buildd.debian.org/status/fetch.php?pkg=libdrmarch=i386ver=2.4.49-2stamp=1385480211 [2] http://anonscm.debian.org/gitweb/?p=pkg-xorg/lib/libdrm.git;a=blob;f=debian/patches/01_default_perms.diff;h=cdba93e19edf40b2b0b56d951a6416c68a0af6f0;hb=HEAD http://anonscm.debian.org/gitweb/?p=pkg-xorg/lib/libdrm.git;a=blob;f=debian/patches/02_kbsd_modeset.diff;h=260260925fc692c71d955d6490dabf87905abb51;hb=HEAD -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nouveau/ NV11: 3.12 freezes if X.org is started headless
On Tue, Nov 26, 2013 at 7:18 PM, Stefan Lippers-Hollmann s@gmx.de wrote: Hi On Tuesday 26 November 2013, Ilia Mirkin wrote: On Tue, Nov 26, 2013 at 6:03 PM, Stefan Lippers-Hollmann s@gmx.de wrote: v3.11 is fine, with and without monitor attached. v3.12 is fine as long as X.org isn't started (but may fail to reboot cleanly). If a monitor is connected I don't observe any problems, it freezes without a monitor connected. v3.13-rc1-95-gb975dc3 appears not to freeze without a monitor anymore (I didn't confirm that it's fine with a monitor attached), but I end up with the following Oops (this is before X.org is started). One more idea -- try it with nouveau.runpm=0 -- I've had some odd results with it on my older cards (but I don't remember hangs, but I also didn't spend a lot of time on it, just plopped the option in and moved on). This is a feature that got in in 3.12, and is really the only major nouveau-affecting change in that kernel for your card revision. -ilia -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nouveau/ NV11: 3.12 freezes if X.org is started headless
Hi On Wednesday 27 November 2013, Ilia Mirkin wrote: On Tue, Nov 26, 2013 at 7:18 PM, Stefan Lippers-Hollmann s@gmx.de wrote: Hi On Tuesday 26 November 2013, Ilia Mirkin wrote: On Tue, Nov 26, 2013 at 6:03 PM, Stefan Lippers-Hollmann s@gmx.de wrote: v3.11 is fine, with and without monitor attached. v3.12 is fine as long as X.org isn't started (but may fail to reboot cleanly). If a monitor is connected I don't observe any problems, it freezes without a monitor connected. v3.13-rc1-95-gb975dc3 appears not to freeze without a monitor anymore (I didn't confirm that it's fine with a monitor attached), but I end up with the following Oops (this is before X.org is started). One more idea -- try it with nouveau.runpm=0 -- I've had some odd results with it on my older cards (but I don't remember hangs, but I also didn't spend a lot of time on it, just plopped the option in and moved on). This is a feature that got in in 3.12, and is really the only major nouveau-affecting change in that kernel for your card revision. You're spot on, that does the trick. # cat /sys/module/nouveau/parameters/agpmode -1 # cat /sys/module/nouveau/parameters/runpm 0 v3.13-rc1-95-gb975dc3 + http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=0397009092427dc60aea8b3c21c00526d8ba + nouveau.runpm=0 is now stable, with and without a monitor attached; as is 3.12.1 || v3.12.1-62-g4615252 (stable-queue.git) + nouveau.runpm=0 I don't need to override the agpmode parameter. Thanks a lot! Regards Stefan Lippers-Hollmann -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nouveau/ NV11: 3.12 freezes if X.org is started headless
On Tue, Nov 26, 2013 at 8:35 PM, Stefan Lippers-Hollmann s@gmx.de wrote: Hi On Wednesday 27 November 2013, Ilia Mirkin wrote: On Tue, Nov 26, 2013 at 7:18 PM, Stefan Lippers-Hollmann s@gmx.de wrote: Hi On Tuesday 26 November 2013, Ilia Mirkin wrote: On Tue, Nov 26, 2013 at 6:03 PM, Stefan Lippers-Hollmann s@gmx.de wrote: v3.11 is fine, with and without monitor attached. v3.12 is fine as long as X.org isn't started (but may fail to reboot cleanly). If a monitor is connected I don't observe any problems, it freezes without a monitor connected. v3.13-rc1-95-gb975dc3 appears not to freeze without a monitor anymore (I didn't confirm that it's fine with a monitor attached), but I end up with the following Oops (this is before X.org is started). One more idea -- try it with nouveau.runpm=0 -- I've had some odd results with it on my older cards (but I don't remember hangs, but I also didn't spend a lot of time on it, just plopped the option in and moved on). This is a feature that got in in 3.12, and is really the only major nouveau-affecting change in that kernel for your card revision. You're spot on, that does the trick. Great to hear! # cat /sys/module/nouveau/parameters/agpmode -1 # cat /sys/module/nouveau/parameters/runpm 0 v3.13-rc1-95-gb975dc3 + http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=0397009092427dc60aea8b3c21c00526d8ba + nouveau.runpm=0 is now stable, with and without a monitor attached; as is 3.12.1 || v3.12.1-62-g4615252 (stable-queue.git) + nouveau.runpm=0 Dave, looking at the code, it seems like runtime pm should only be getting activated by default for optimus systems. Stefan's is clearly not one of those, neither is mine. Unfortunately I have no clue how the runtime pm subsystem works, but it seems like runtime_suspend() may be getting called directly, e.g. if there are no monitors attached to nouveau, perhaps as a result of nouveau_crtc_set_config in dispnv04/crtc.c. Does the same if (runpm == -1 !optimus) return -EBUSY check belong in the runtime_suspend callback? -ilia -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nouveau/ NV11: 3.12 freezes if X.org is started headless
On Wed, Nov 27, 2013 at 12:15 PM, Ilia Mirkin imir...@alum.mit.edu wrote: On Tue, Nov 26, 2013 at 8:35 PM, Stefan Lippers-Hollmann s@gmx.de wrote: Hi On Wednesday 27 November 2013, Ilia Mirkin wrote: On Tue, Nov 26, 2013 at 7:18 PM, Stefan Lippers-Hollmann s@gmx.de wrote: Hi On Tuesday 26 November 2013, Ilia Mirkin wrote: On Tue, Nov 26, 2013 at 6:03 PM, Stefan Lippers-Hollmann s@gmx.de wrote: v3.11 is fine, with and without monitor attached. v3.12 is fine as long as X.org isn't started (but may fail to reboot cleanly). If a monitor is connected I don't observe any problems, it freezes without a monitor connected. v3.13-rc1-95-gb975dc3 appears not to freeze without a monitor anymore (I didn't confirm that it's fine with a monitor attached), but I end up with the following Oops (this is before X.org is started). One more idea -- try it with nouveau.runpm=0 -- I've had some odd results with it on my older cards (but I don't remember hangs, but I also didn't spend a lot of time on it, just plopped the option in and moved on). This is a feature that got in in 3.12, and is really the only major nouveau-affecting change in that kernel for your card revision. You're spot on, that does the trick. Great to hear! # cat /sys/module/nouveau/parameters/agpmode -1 # cat /sys/module/nouveau/parameters/runpm 0 v3.13-rc1-95-gb975dc3 + http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=0397009092427dc60aea8b3c21c00526d8ba + nouveau.runpm=0 is now stable, with and without a monitor attached; as is 3.12.1 || v3.12.1-62-g4615252 (stable-queue.git) + nouveau.runpm=0 Dave, looking at the code, it seems like runtime pm should only be getting activated by default for optimus systems. Stefan's is clearly not one of those, neither is mine. Unfortunately I have no clue how the runtime pm subsystem works, but it seems like runtime_suspend() may be getting called directly, e.g. if there are no monitors attached to nouveau, perhaps as a result of nouveau_crtc_set_config in dispnv04/crtc.c. Does the same if (runpm == -1 !optimus) return -EBUSY check belong in the runtime_suspend callback? Either that or it needs to be calling some of the other runtime interfaces instead of runtime_autosuspend maybe that last pm_runtime_put_autosuspend should be just pm_runtime_put, but that might need testing on an optimus system. Dave. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
