34-rc4-mmotm0415 - OOPS in nouveau driver
Dell Latitude E6500, with NVidia graphics: 01:00.0 VGA compatible controller: nVidia Corporation G98M [Quadro NVS 160M] (rev a1) http://hubblesite.org/newscenter/archive/releases/2003/15/image/a/warn/ Nice 6116x7014 jpeg on there. Opened it in firefox, and it opened the squished up fit-in-window version. Clicked on it to expand it to full size, and kablam dead X server. I think it got indigestion on the pixmap size. dmesg says: [29070.917875] [drm] nouveau :01:00.0: PFIFO_DMA_PUSHER - Ch 2 [29073.917082] BUG: unable to handle kernel NULL pointer dereference at 0028 [29073.917089] IP: [] ttm_bo_pci_offset+0x56/0x76 [29073.917098] PGD 11f7e7067 PUD 11a291067 PMD 0 [29073.917103] Oops: [#1] PREEMPT SMP [29073.917109] last sysfs file: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0/charge_full [29073.917113] CPU 0 [29073.917114] Modules linked in: sunrpc [last unloaded: scsi_wait_scan] [29073.917120] [29073.917124] Pid: 3670, comm: Xorg Not tainted 2.6.34-rc4-mm1 #1 0X564R/Latitude E6500 [29073.917127] RIP: 0010:[] [] ttm_bo_pci_offset+0x56/0x76 [29073.917132] RSP: 0018:88011e7298e8 EFLAGS: 00010202 [29073.917134] RAX: RBX: 88011e729b68 RCX: 88011e729910 [29073.917137] RDX: 88011e729900 RSI: 88011e729b68 RDI: 88011dd00118 [29073.917140] RBP: 88011e7298e8 R08: 88011e729908 R09: 0160 [29073.917142] R10: 0002 R11: 0002 R12: 88011e7299e8 [29073.917145] R13: 88011dd00118 R14: 0002 R15: 88010ec99100 [29073.917148] FS: 7f96fa760840() GS:88000260() knlGS: [29073.917151] CS: 0010 DS: ES: CR0: 8005003b [29073.917154] CR2: 0028 CR3: 00011cb2b000 CR4: 000406f0 [29073.917157] DR0: DR1: DR2: [29073.917159] DR3: DR6: 0ff0 DR7: 0400 [29073.917162] Process Xorg (pid: 3670, threadinfo 88011e728000, task 88011e714340) [29073.917164] Stack: [29073.917166] 88011e729948 812b76de 0282 e000 [29073.917172] <0> 0142 8800b7a137c0 88011e729b68 [29073.917178] <0> 88010ec99000 88010ec99100 [29073.917186] Call Trace: [29073.917191] [] ttm_mem_reg_ioremap+0x36/0xa7 [29073.917195] [] ttm_bo_move_memcpy+0x74/0x3bc [29073.917199] [] ? kref_put+0x9b/0xba [29073.917204] [] ? nouveau_fence_unref+0x24/0x2f [29073.917208] [] ? nouveau_bo_move_m2mf+0x34f/0x361 [29073.917212] [] nouveau_bo_move+0x3a6/0x433 [29073.917217] [] ? unmap_mapping_range+0x15c/0x16b [29073.917221] [] ttm_bo_handle_move_mem+0x1a8/0x2b0 [29073.917226] [] ttm_bo_move_buffer+0xd2/0x122 [29073.917229] [] ? ttm_bo_reserve+0x33/0x111 [29073.917233] [] ttm_bo_validate+0xe0/0x130 [29073.917237] [] validate_list+0x1ba/0x2e4 [29073.917241] [] nouveau_gem_ioctl_pushbuf+0x6d8/0xfb6 [29073.917248] [] drm_ioctl+0x27b/0x349 [29073.917251] [] ? nouveau_gem_ioctl_pushbuf+0x0/0xfb6 [29073.917257] [] vfs_ioctl+0x2d/0xa1 [29073.917260] [] do_vfs_ioctl+0x4b8/0x4fe [29073.917264] [] sys_ioctl+0x57/0x95 [29073.917269] [] system_call_fastpath+0x16/0x1b [29073.917272] Code: 69 c0 b0 00 00 00 8b 44 07 54 a8 01 75 13 45 85 d2 74 0a a8 08 75 06 f6 46 22 01 74 04 31 c0 c9 c3 48 8b 06 4d 69 c9 b0 00 00 00 <48> 8b 40 28 48 c1 e0 0c 48 89 01 48 8b 46 10 48 c1 e0 0c 49 89 [29073.917337] RIP [] ttm_bo_pci_offset+0x56/0x76 [29073.917342] RSP [29073.917344] CR2: 0028 [29073.917347] ---[ end trace dec9a802bd56f54b ]--- pgp0EMt2C3piN.pgp Description: PGP signature -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, 05 Mar 2010 18:04:34 +0200, Daniel Stone said: > So you're saying that there's no way to develop any reasonable body of > code for the Linux kernel without committing to keeping your ABI > absolutely rock-solid stable for eternity, no exceptions, ever? Cool, > that worked really well for Xlib. Amen to that. I can remember the X10.4->X11 conversion in 1987. And a heck of a lot of source-level stability since then (even with the libX11 getting redone with libxcb under it. 23 years and still going strong is one hell of a good run for an ABI. pgpWWcYO5fyi6.pgp Description: PGP signature -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Making Xorg easier to test (was Re: [git pull] drm request 3)
On Fri, 05 Mar 2010 11:00:30 +0100, "Carlos R. Mafra" said: > Why can't there be a 'Linus Torvalds' for Xorg accepting patches from various > maintainers and keeping the whole thing tied up? Why can't it mimic the > 'make menuconfig' way of selecting what to compile to have the guarantee that > the whole thing will simply work nicely together? Feel free to do so. Note that you'll hit 2 problems: 1) In the kernel, the sysadmin can almost always get away with saying "I have no XYZ devices" or "I only have ext4 filesystems" or similar choices, and have the resulting kernel still support basically all the syscalls (unless you start going into CONFIG_EMBEDDED and doing some *major* surgury). Over on the X side of the fence, there aren't as many options that don't involve dropping major chunks of the functionality. You *sure* that nothing on your system depends on the XRandR extension? ;) 2) Lately, the X server is *already* highly modular and different components built from different source trees. Note that the base X server is only about half the size of the kernel RPM - there really isn't much left to trim out of the base server anymore. ncftp ...velopment/source/SRPMS > dir kern* xorg* -rw-r--r--1 263 263 66965350 Feb 26 18:03 kernel-2.6.34-0.4.rc0.git2.fc14.src.rpm -rw-r--r--1 263 26344300 Feb 27 01:39 xorg-sgml-doctools-1.1.1-4.fc12.src.rpm -rw-r--r--2 263 263 2229508 Feb 11 02:23 xorg-x11-apps-7.4-10.fc13.src.rpm -rw-r--r--1 263 263 8250097 Feb 27 00:06 xorg-x11-docs-1.3-6.fc12.src.rpm -rw-r--r--1 263 263 9718 Feb 27 03:27 xorg-x11-drivers-7.3-13.fc12.src.rpm -rw-r--r--2 263 263 263291 Feb 5 21:40 xorg-x11-drv-acecad-1.4.0-3.fc13.src.rpm -rw-r--r--2 263 263 271426 Feb 5 23:03 xorg-x11-drv-aiptek-1.3.0-3.fc13.src.rpm -rw-r--r--1 263 263 293991 Feb 27 01:02 xorg-x11-drv-apm-1.2.2-1.fc12.src.rpm -rw-r--r--2 263 263 247603 Feb 5 19:49 xorg-x11-drv-ark-0.7.2-2.fc13.src.rpm -rw-r--r--1 263 263 273849 Feb 26 20:22 xorg-x11-drv-ast-0.89.9-1.fc12.src.rpm -rw-r--r--1 263 263 475771 Feb 19 00:50 xorg-x11-drv-ati-6.13.0-0.23.20100219gite68d3a389.fc14.src.rpm -rw-r--r--1 263 263 354400 Feb 27 01:17 xorg-x11-drv-chips-1.2.2-1.fc12.src.rpm -rw-r--r--2 263 263 296790 Feb 5 16:10 xorg-x11-drv-cirrus-1.3.2-2.fc13.src.rpm -rw-r--r--2 263 263 257700 Feb 5 19:48 xorg-x11-drv-dummy-0.3.3-2.fc13.src.rpm -rw-r--r--2 263 263 260227 Feb 5 16:26 xorg-x11-drv-elographics-1.2.3-6.fc13.src.rpm -rw-r--r--2 263 263 537577 Feb 5 21:59 xorg-x11-drv-evdev-2.3.99-2.20100108.fc13.src.rpm -rw-r--r--2 263 263 254313 Feb 9 13:19 xorg-x11-drv-fbdev-0.4.1-3.fc13.src.rpm -rw-r--r--1 263 263 252387 Feb 17 05:13 xorg-x11-drv-fpit-1.3.0-8.fc14.src.rpm -rw-r--r--2 263 263 608480 Feb 5 23:07 xorg-x11-drv-geode-2.11.4.1-2.fc13.src.rpm -rw-r--r--2 263 263 361698 Feb 5 21:40 xorg-x11-drv-glint-1.2.4-2.fc13.src.rpm -rw-r--r--2 263 263 244962 Feb 9 13:48 xorg-x11-drv-hyperpen-1.3.0-4.fc13.src.rpm -rw-r--r--2 263 263 289677 Feb 5 22:38 xorg-x11-drv-i128-1.3.3-2.fc13.src.rpm -rw-r--r--2 263 263 281904 Feb 5 20:33 xorg-x11-drv-i740-1.3.2-2.fc13.src.rpm -rw-r--r--1 263 263 978993 Feb 12 07:15 xorg-x11-drv-intel-2.10.0-4.fc13.src.rpm -rw-r--r--2 263 263 305926 Feb 5 19:26 xorg-x11-drv-ivtv-1.1.1-1.fc13.src.rpm -rw-r--r--2 263 263 296974 Feb 5 19:22 xorg-x11-drv-keyboard-1.4.0-4.fc13.src.rpm -rw-r--r--2 263 263 492204 Feb 5 20:02 xorg-x11-drv-mach64-6.8.2-2.fc13.src.rpm -rw-r--r--2 263 263 427579 Feb 5 20:39 xorg-x11-drv-mga-1.4.11-2.fc13.src.rpm -rw-r--r--2 263 263 318263 Feb 9 13:52 xorg-x11-drv-mouse-1.5.0-4.fc13.src.rpm -rw-r--r--2 263 263 254590 Feb 5 20:17 xorg-x11-drv-mutouch-1.2.1-6.fc13.src.rpm -rw-r--r--2 263 263 290495 Feb 5 22:02 xorg-x11-drv-neomagic-1.2.4-3.fc13.src.rpm -rw-r--r--2 263 26391334 Feb 18 16:59 xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.src.rpm -rw-r--r--2 263 263 449803 Feb 9 12:19 xorg-x11-drv-nv-2.1.15-5.fc13.src.rpm -rw-r--r--2 263 263 475028 Feb 9 12:26 xorg-x11-drv-openchrome-0.2.904-2.fc13.src.rpm -rw-r--r--2 263 263 248668 Feb 9 12:27 xorg-x11-drv-penmount-1.4.0-6.fc13.src.rpm -rw-r--r--2 263 263 280184 Feb 5 22:08 xorg-x11-drv-qxl-0.0.9-0.1.fc13.src.rpm -rw-r--r--2 263 263 424771 Feb 5 19:36 xorg-x11-drv-r128-6.8.1-3.fc13.src.rpm -rw-r--r--2 263 26
Re: From Eric Anholt:
On Wed, 12 May 2004 00:20:51 BST, Dave Airlie said: > I just looked at drm.h and nearly all the ioctls use int, this file is > included in user-space applications also at the moment, I'm worried > changing all ints to __u32 will break some of these, anyone on DRI list > care to comment? Is this a case where somebody is *really* including kernel headers in userspace and we need to smack them, or are they using a copy that's been sanitized (and possibly fixed)? pgp0.pgp Description: PGP signature
