start_thread question...
I'm implementing start_thread for the VAX port and am wondering does start_thread have to return to load_elf_binary? I'm working on the init thread and what is happening is it is returning the whole way back to the execve caller .. which I know shouldn't happen. so I suppose what I'm looking for is the point where the user space code gets control... is it when the registers are set in the start_thread? if so how does start_thread return On the VAX we have to call a return from interrupt to get to user space and I'm trying to figure out where this should happen... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / [EMAIL PROTECTED] pam_smb / Linux DecStation / Linux VAX / ILUG person - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LV] start_thread question...
Okay I think I've gotten it solved most of the way, we weren't calling execve via the system call interface, so once I made it go via the system call and I fill out pc, sp and psl registers in start_thread, it seems to go further.. Thanks for all the help... Dave. On Sun, 20 May 2001, Kenn Humborg wrote: On Sun, May 20, 2001 at 05:24:48PM +0100, Dave Airlie wrote: I'm implementing start_thread for the VAX port and am wondering does start_thread have to return to load_elf_binary? I'm working on the init thread and what is happening is it is returning the whole way back to the execve caller .. which I know shouldn't happen. so I suppose what I'm looking for is the point where the user space code gets control... is it when the registers are set in the start_thread? if so how does start_thread return On the VAX we have to call a return from interrupt to get to user space and I'm trying to figure out where this should happen... I haven't got time to look at this in detail, but you could probably do it by frobbing the saved registers that will be restored by the ret_from_syscall in entry.S. Do you have a pt_regs *regs function argument at the right point? If so, it should point to these saved registers. Later, Kenn -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / [EMAIL PROTECTED] pam_smb / Linux DecStation / Linux VAX / ILUG person - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux/VAX booting to a shell.
Hi all, (mind crossposts on follow ups..) attached below is a bootlog from the Linux/VAX port, booting up, loading up busybox/uClibc sh and cat /proc/cpuinfo, from my VAXStation 3100m38, Thanks to the other two members of the core VAX porting team, Andy Phillips and Kenn Humborg and others on the linux-vax list who've given their help, this is the second major milestone for the project, (gcc porting was the first) now to get it working on a few other systems and move into userspace... Regards, Dave. p.s. who said the Irish didn't hack kernels :-) -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / [EMAIL PROTECTED] pam_smb / Linux DecStation / Linux VAX / ILUG person -ESA0 CPU type: KA42 Boot Head.S loaded at address 9600 rpb/bootr5/ap/sp 0348 8A00 relocated at phys address 001001B2 CPU type: 0A05 sidex: 04010102 Starting VM Linux/VAX ([EMAIL PROTECTED]) IO mapped phys addr iomap_base 0x2008, 0x0001 pages at virt 0x80fe4000 (IOMAP PTE index 0x) IO unmapping 0x0001 pages at PTE index 0x IO mapped phys addr iomap_base 0x200a, 0x0001 pages at virt 0x80fe4000 (IOMAP PTE index 0x) RPB info: l_pfncnt: 7f1f, .l_vmb_version: 0a000400 .l_badpgs: Physical memory: 7f1f HW pagelets, 0fe3 pages (16271KB) CPU type: KA42, SID: calling start_kernel... Linux version 2.4.2-20010307 (airlied@radon) (gcc version 2.95.2-linuxvax-20001231 (release)) #622 Sat Jun 16 13:32:20 IST 2001 bootmap size = 0200 calling free_bootmem(start=0200, len=000ffe00) calling free_bootmem(start=001f88b8, len=00dea748) On node 0 totalpages: 4067 zone(0): 4067 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: root=/dev/nfs rw nfsroot=/tftpboot/vaxroot console=/dev/ttyS Calibrating delay loop... 5.42 BogoMIPS max low pfn is FE3000 VMALLOC_START is 810e4000 vmallocmap_base is 8020FE18, sbr 801EE198, diff 10E4000 Memory: 15000k/16268k available Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 4096 (order: 2, 16384 bytes) Inode-cache hash table entries: 1024 (order: 1, 8192 bytes) POSIX conformance testing by UNIFIX kernel_thread: calling thread function at 80100824 IO mapped phys addr iomap_base 0x2008, 0x0001 pages at virt 0x80fe5000 (IOMAP PTE index 0x0001) vsbus: interrupt mask 0 Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 kernel_thread: calling thread function at 8010d250 Starting kswapd v1.8 kernel_thread: calling thread function at 80118636 kernel_thread: calling thread function at 80120b00 kernel_thread: calling thread function at 80118790 kernel_thread: calling thread function at 80120c08 pty: 256 Unix98 ptys configured block: queued sectors max/low 9685kB/3228kB, 64 slots per queue Serial driver version 5.02 (2000-08-09) with no serial options enabled DECstation DZ serial driver version 1.02 ttyS0 at 0x80fe4000 (irq = 176, 177) ttyS1 at 0x80fe4000 (irq = 176, 177) ttyS2 at 0x80fe4000 (irq = 176, 177) ttyS3 at 0x80fe4000 (irq = 176, 177) vaxlance.c: v0.008 by Linux Mips DECstation task force + [EMAIL PROTECTED] IO mapped phys addr iomap_base 0x200e, 0x0001 pages at virt 0x80fe6000 (IOMAP PTE index 0x0002) IO mapped phys addr iomap_base 0x2009, 0x0001 pages at virt 0x80fe7000 (IOMAP PTE index 0x0003) Ethernet address in ROM: 08:00:2b:17:0a:7f IO unmapping 0x0001 pages at PTE index 0x0003 Autoprobing LANCE interrupt vector... probed IRQ 148 NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 512 bind 512) Sending BOOTP requests OK IP-Config: Got BOOTP answer from 192.168.2.15, my address is 192.168.2.55 NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. Looking up port of RPC 13/2 on 192.168.2.15 Looking up port of RPC 15/2 on 192.168.2.15 kernel_thread: calling thread function at 80186ef8 VFS: Mounted root (nfs filesystem). Freeing unused kernel memory: 28k freed In CHRDEV_OPEN 5 1 80151fb6 dz opening line 3 page 80042d24, num 3964 ,pte_val A4C07BE0 k_platform is 76 61 78 00 u_platform is 76 61 78 00 starting thread14B10 7F80 80051F50 BusyBox v0.51 (2001.06.16-11:59+) Built-in shell (lash) Enter 'help' for a list of built-in commands. / # mount -t proc none /proc / # cat /proc/cpuinfo cpu : VAX cpu type: cpu sidex : 0 page size : 4096 BogoMIPS: 5.42 / # - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[OOPS] 2.2.19 USB and Digianswer/Tektronix sniffer
when boot Linux 2.2.19 with a Digianswer Bluetooth Sniffer plugged into
the USB I get the following oops ... I know the device isn't supported but
I'd like to be able to leave it plugged in without oopsen between
Linux/Windows..
Regards,
Dave.
ksymoops 0.7c on i686 2.2.19. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.2.19/ (default)
-m /usr/src/linux/System.map (default)
Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
Unable to handle kernel NULL pointer dereference at virtual address
current-tss.cr3 = 00101000, %cr3 = 00101000
*pde =
Oops: 0002
CPU:0
EIP:0010:[c0120825]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax: 0039 ebx: c40fc080 ecx: c01a2c68 edx: cf422000
esi: c1f69120 edi: 0202 ebp: esp: c6f95f1c
ds: 0018 es: 0018 ss: 0018
Process khubd (pid: 1646, process nr: 100, stackpage=c6f95000)
Stack: c1f6915c c01bed26 d09695ea c1f69120 ce79c600 0010
cf73d25c d0976b8d ce79c600 d0968ad0 ce79c600
ce79c600 d096993e ce79c600 ce79c600 0001
Call Trace: [d09695ea] [d0976b8d] [d0968ad0] [d096993e] [d096b659]
[d096b719] [d09710e7]
[d0970001] [d097253c] [d096b8bd] [d0968050] [c0107b8b] [d0968000]
Code: c7 05 00 00 00 00 00 00 00 00 eb 1b 8d 76 00 56 68 22 b0 18
EIP; c0120825 kfree+179/1a8 =
Trace; d09695ea [usbcore]usb_destroy_configuration+66/1a8
Trace; d0976b8d [usb-uhci]uhci_free_dev+29/30
Trace; d0968ad0 [usbcore]usb_free_dev+24/30
Trace; d096993e [usbcore]usb_disconnect+ea/f4
Trace; d096b659 [usbcore]usb_hub_port_connect_change+2f9/324
Trace; d096b719 [usbcore]usb_hub_events+95/1f0
Trace; d09710e7 [usbcore]usb_bandwidth_option+18a7/20b4
Trace; d0970001 [usbcore]usb_bandwidth_option+7c1/20b4
Trace; d097253c [usbcore]__ksymtab_usb_inc_dev_use+4/8
Trace; d096b8bd [usbcore]usb_hub_thread+49/6c
Trace; d0968050 [usbcore].text.start+4/8c
Trace; c0107b8b kernel_thread+23/30
Trace; d0968000 [serial].bss.end+778d/77d9
Code; c0120825 kfree+179/1a8
_EIP:
Code; c0120825 kfree+179/1a8 =
0: c7 05 00 00 00 00 00 movl $0x0,0x0 =
Code; c012082c kfree+180/1a8
7: 00 00 00
Code; c012082f kfree+183/1a8
a: eb 1b jmp27 _EIP+0x27 c012084c kfree+1a0/1a8
Code; c0120831 kfree+185/1a8
c: 8d 76 00 lea0x0(%esi),%esi
Code; c0120834 kfree+188/1a8
f: 56push %esi
Code; c0120835 kfree+189/1a8
10: 68 22 b0 18 00push $0x18b022
1 warning issued. Results may not be reliable.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / [EMAIL PROTECTED]
pam_smb / Linux DecStation / Linux VAX / ILUG person
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [OOPS] 2.2.19 USB and Digianswer/Tektronix sniffer
And of course the olibgatory self-followup... usb-uhci.c: USB UHCI at I/O 0x1080, IRQ 9 usb-uhci.c: Detected 2 ports usb.c: new USB bus registered, assigned bus number 1 usb.c: USB new device connect, assigned device number 1 hub.c: USB hub found hub.c: 2 ports detected usb.c: USB new device connect, assigned device number 2 usb-uhci.c: interrupt, status 2, frame# 879 usb-uhci.c: interrupt, status 2, frame# 881 usb-uhci.c: interrupt, status 2, frame# 883 usb-uhci.c: interrupt, status 2, frame# 885 usb-uhci.c: interrupt, status 2, frame# 887 usb.c: couldn't get all of config descriptors usb.c: unable to get configuration (error=-84) usb.c: USB new device connect, assigned device number -1 usb.c: USB device not responding, giving up (error=-90) usb.c: USB disconnect on device -1 kmem_free: Bad obj addr (objp=c1f69120, name=size-32) forgot people might want to see this bit as well.. Dave. On Thu, 29 Mar 2001, Dave Airlie wrote: when boot Linux 2.2.19 with a Digianswer Bluetooth Sniffer plugged into the USB I get the following oops ... I know the device isn't supported but I'd like to be able to leave it plugged in without oopsen between Linux/Windows.. Regards, Dave. ksymoops 0.7c on i686 2.2.19. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.2.19/ (default) -m /usr/src/linux/System.map (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Unable to handle kernel NULL pointer dereference at virtual address current-tss.cr3 = 00101000, %cr3 = 00101000 *pde = Oops: 0002 CPU:0 EIP:0010:[c0120825] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010202 eax: 0039 ebx: c40fc080 ecx: c01a2c68 edx: cf422000 esi: c1f69120 edi: 0202 ebp: esp: c6f95f1c ds: 0018 es: 0018 ss: 0018 Process khubd (pid: 1646, process nr: 100, stackpage=c6f95000) Stack: c1f6915c c01bed26 d09695ea c1f69120 ce79c600 0010 cf73d25c d0976b8d ce79c600 d0968ad0 ce79c600 ce79c600 d096993e ce79c600 ce79c600 0001 Call Trace: [d09695ea] [d0976b8d] [d0968ad0] [d096993e] [d096b659] [d096b719] [d09710e7] [d0970001] [d097253c] [d096b8bd] [d0968050] [c0107b8b] [d0968000] Code: c7 05 00 00 00 00 00 00 00 00 eb 1b 8d 76 00 56 68 22 b0 18 EIP; c0120825 kfree+179/1a8 = Trace; d09695ea [usbcore]usb_destroy_configuration+66/1a8 Trace; d0976b8d [usb-uhci]uhci_free_dev+29/30 Trace; d0968ad0 [usbcore]usb_free_dev+24/30 Trace; d096993e [usbcore]usb_disconnect+ea/f4 Trace; d096b659 [usbcore]usb_hub_port_connect_change+2f9/324 Trace; d096b719 [usbcore]usb_hub_events+95/1f0 Trace; d09710e7 [usbcore]usb_bandwidth_option+18a7/20b4 Trace; d0970001 [usbcore]usb_bandwidth_option+7c1/20b4 Trace; d097253c [usbcore]__ksymtab_usb_inc_dev_use+4/8 Trace; d096b8bd [usbcore]usb_hub_thread+49/6c Trace; d0968050 [usbcore].text.start+4/8c Trace; c0107b8b kernel_thread+23/30 Trace; d0968000 [serial].bss.end+778d/77d9 Code; c0120825 kfree+179/1a8 _EIP: Code; c0120825 kfree+179/1a8 = 0: c7 05 00 00 00 00 00 movl $0x0,0x0 = Code; c012082c kfree+180/1a8 7: 00 00 00 Code; c012082f kfree+183/1a8 a: eb 1b jmp27 _EIP+0x27 c012084c kfree+1a0/1a8 Code; c0120831 kfree+185/1a8 c: 8d 76 00 lea0x0(%esi),%esi Code; c0120834 kfree+188/1a8 f: 56push %esi Code; c0120835 kfree+189/1a8 10: 68 22 b0 18 00push $0x18b022 1 warning issued. Results may not be reliable. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / [EMAIL PROTECTED] pam_smb / Linux DecStation / Linux VAX / ILUG person - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: skb allocation problems (More Brain damage!)
What compiler are you using to compile the kernel? Dave. On Wed, 11 Apr 2001 [EMAIL PROTECTED] wrote: Well, I don't know then. You have to debug it. It's probably something stupid (if fundamental services like alloc_skb/kfree_skb were completely buggy someone surely would have noticed earlier) yep, at first i thought it was because of sume stupidity in my module...but now it seems that actually it is not my code which is doing something stupidjust now i have found out that even simple ping faces similar problems here is the output that i get when i ping from the host 192.168.102.29 (runs 2.4.1) to 192.168.102.22 (runs 2.4.3) (Note:I don't insert any kernel modules of my own on these machines): PING 192.168.102.22 (192.168.102.22) from 192.168.102.29 : 100(128) bytes of data. 108 bytes from hobbes.sr.ntc.nokia.com (192.168.102.22): icmp_seq=0 ttl=255 time=36.5 ms wrong data byte #36 should be 0x24 but was 0x45 19 45 d4 3a e 7a a 0 8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 45 0 0 80 0 0 40 0 ff 1 2d f8 c0 a8 66 16 c0 a8 66 1d 0 0 0 0 4 c 0 0 19 45 d4 3a e 7a a 0 8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b --- 192.168.102.22 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 36.5/36.5/36.5 ms Note that the problem starts with byte #36 which goes on like " 45 0 0 80 0 ..." which is in fact the outer IP header!! So certainly there are buffer overruns on the other end (host 192.168.102.22) And as a I said earlier, only ping packets with size within certain range create this problem..Something is terribly wrong here!! But as I am not a Linux mm guru, i can't tell what is wrong here! regards, imran -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / [EMAIL PROTECTED] pam_smb / Linux DecStation / Linux VAX / ILUG person - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-mm2
- git-drm.patch is still in disgrace Okay I think I've fixed it up, some of the locking code from the DRM git devel repo was completely integrated.. Dave. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/6] fault vs truncate/invalidate race fix
the new fault hander made the memory manager code a lot cleaner and very less hacky in a lot of cases. so I'd rather merge the clean code than have to fight with the current code... Note that you can probably get away with NOPFN_REFAULT etc... like I did for the SPEs in the meantime. Indeed, Thomas has done this work and I'm just lining up a TTM tree to start the merge process.. Dave. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/7] DRM: correct PCI domain setting for ALPHA
NAK I already have this queued in the DRM git tree.. Ivan, Jay can you check an -mm kernel contains it? it'll go in the next merge window.. Dave. On 4/11/07, Ivan Kokshaysky [EMAIL PROTECTED] wrote: Files: drivers/char/drm/drmP.h The PCI domain is the hose's index, not the hose's root bus number. Note that this code only applies to ALPHA. Signed-off-by: Jay Estabrook [EMAIL PROTECTED] Signed-off-by: Ivan Kokshaysky [EMAIL PROTECTED] --- diff -Naurp a/drivers/char/drm/drmP.h b/drivers/char/drm/drmP.h --- a/drivers/char/drm/drmP.h 2007-04-02 13:03:24.0 -0400 +++ b/drivers/char/drm/drmP.h 2007-04-02 13:49:38.0 -0400 @@ -764,7 +764,7 @@ static __inline__ int drm_core_check_fea } #ifdef __alpha__ -#define drm_get_pci_domain(dev) dev-hose-bus-number +#define drm_get_pci_domain(dev) dev-hose-index #else #define drm_get_pci_domain(dev) 0 #endif - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Video GL rendering worked only between 2.6.20 and 2.6.21-rc1
The machine is a Centrino laptop with an i810 card. So I guess those are the responsible files: drivers/char/drm/i810_*.c drivers/video/i810/* drivers/char/agp/i810* and drivers/char/drm/i915* are most likely.. but it could be anything in the DRM or AGP subdirs.. perhaps two X.org logs showing the difference.. Dave. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/6] fault vs truncate/invalidate race fix
I've also got rid of the horrible populate API, and integrated nonlinear pages properly with the page fault path. Downside is that this adds one more vector through which the buffered write deadlock can occur. However this is just a very tiny one (pte being unmapped for reclaim), compared to all the other ways that deadlock can occur (unmap, reclaim, truncate, invalidate). I doubt it will be noticable. At any rate, it is better than data corruption. I hope these can get merged (at least into -mm) soon. Have these been put into mm? can I expect them in the next -mm so I can start merging up the drm memory manager code to my -mm tree.. Dave. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/6] fault vs truncate/invalidate race fix
On 2/27/07, Andrew Morton [EMAIL PROTECTED] wrote: On Tue, 27 Feb 2007 15:36:03 +1100 Dave Airlie [EMAIL PROTECTED] wrote: I've also got rid of the horrible populate API, and integrated nonlinear pages properly with the page fault path. Downside is that this adds one more vector through which the buffered write deadlock can occur. However this is just a very tiny one (pte being unmapped for reclaim), compared to all the other ways that deadlock can occur (unmap, reclaim, truncate, invalidate). I doubt it will be noticable. At any rate, it is better than data corruption. I hope these can get merged (at least into -mm) soon. Have these been put into mm? Not yet - I need to get back on the correct continent, review the code, stuff like that. It still hurts that this work makes the write() deadlock harder to hit, and we haven't worked out how to fix that. can I expect them in the next -mm so I can start merging up the drm memory manager code to my -mm tree.. What is the linkage between these patches and DRM? the new fault hander made the memory manager code a lot cleaner and very less hacky in a lot of cases. so I'd rather merge the clean code than have to fight with the current code... Dave. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
drm + 4GB RAM + swiotlb = drm craps out
Okay I've got a bug reported before and now again about 4GB + radeon blows up the DRM... on Intel hw... What the drm currently does for the PCI GART table is it allocates a chunk of memory (8MB) with vmalloc_32(), then when it decides to use it it goes through every page of it calls pci_map_single() (with PCI_DMA_TODEVICE, which is probably wrong...) with every page from the vmalloc mapping and puts the bus addresses of the pages into the PCI GART table on the GPU. So when swiotlb happens, as you can guess it all falls apart as the drm never calls sync functions at any stage... The main problem is the ring buffer and scratch write back, these values are read/write from both the CPU and GPU quite a lot, so this leads me to think I should really just be using dma_alloc_coherent for the whole lot, however this is an 8MB mapping and possibly could be getting larger in the future and dynamic as we do dynamic PCIEGART support for the radeons... So I suppose I'm asking for ideas on the correct way to do this, and perhaps any quick way to patch up the problem I'm seeing now by making swiotlb not get involved Regards, Dave. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: drm + 4GB RAM + swiotlb = drm craps out
So when swiotlb happens, as you can guess it all falls apart as the drm never calls sync functions at any stage... You would have hit this on any platform that does caching in the PCI controller as well. We must not have a great intersect of radeon and such systems.. Coherent memory was created for precisely the case where the cpu and the device frequently access the memory. 8MB is indeed a lot for the kind of allocation that the coherent DMA implementation uses. Does it really have to be all in one big 8MB chunk? I doubt it. Perhaps you can therefore create multiple DMA pools instead? See include/linux/dmapool.h It currently is required to be in a big 8MB chunk as it gets chopped up by the X server not the kernel, so kernel needs to allocate pages to back it when X inits, yes this is ugly, no it can't be fixed without time-travelling and fixing deployed X servers... Really we probably only need the ring buffer to be in coherent memory, the rest of the stuff is used for DMA buffers which are mainly filled by the CPU and read by the GPU. However I cannot change this without breaking X, the solution is really to use TTM for this sort of stuff I'm a bit worried as the AGP driver now uses vmalloc_32 which really is a meaningless interface on 64-bit systems.. Dave. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: drm + 4GB RAM + swiotlb = drm craps out
It might explain why my machine hung when I tried to use radeon with DRM on my sparc64 workstation :-) I have investigating that on my todo list. True, maybe the intersection is me + hw like that + radeon :-) I don't know what to recommend to you, getting 8MB of linear memory really just isn't practical. This is the thing it doesn't need to be linear, I have a GART onboard the radeon that I can fill in, I just need internally in the kernel to access it linearly and in userspace to map it linearly, but it doesn't need to be physcially linear, vmalloc_32 + map_single should in theory be possible if.. see below... Perhaps we'll have to create something ugly like vmalloc_nobounce(). Remind me again why you're ending up with swiotlb'd pages? vmalloc_32() uses GFP_KERNEL which should use entirely lowmem and thus RAM below 4GB and not anything which should need bounce buffering. On a 64-bit machine GFP_KERNEL can give me any memory... it all works fine on 32-bit highmem kernel as I don't get highmem... I really need __GFP_DMA32 memory but we don't have a generic allocator that gives this out that I can see.. Are you expecting to be able to virtually remap these pages in PCI space as one huge 8MB chunk too and that's how swiotlb gets involved? That won't work, sorry... Well I feed the bus address for each page into a GART table in the GPU and it does the linear stuff internally in the GPU memory controller... I suppose I want __GFP_I_D_RATHER_DIE_THAN_BOUNCE. Dave. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: drm + 4GB RAM + swiotlb = drm craps out
On a 64-bit machine GFP_KERNEL can give me any memory... it all works fine on 32-bit highmem kernel as I don't get highmem... I really need __GFP_DMA32 memory but we don't have a generic allocator that gives this out that I can see.. __get_free_pages(..., __GFP_DMA32) on 64bit or __GFP_KERNEL or i386 (only gives you ~900MB) Doesn't __get_free_pages give me physically linear memory, which while nice it isn't essential for what I need, so if I can't get my full allocation I could in theory just start to fallback down the orders and calling it multiple times to actually get the amount of memory I need, this just seems overly cumbersome when what I really want is vmalloc_32 to just work correctly on 64-bit systems... (why doesn't vmalloc_32 pass __GFP_DMA32 to the allocator) Not sure what you mean? __alloc_pages never bounces by itself. The nearest you can get is __GFP_DMA/__GFP_DMA32, but these have their own 16MB/4GB zones and don't use the swiotlb pools. And of course it only gives you plain memory, but doesn't remap or copy anything. Yes I want __GFP_DMA32 but I'd like it with vmalloc not with __get_free_pages and I've no great need for physically linear page allocations and as I'm after quite a large order I can see this failing ... granted with a 4GB system maybe not that quickly.. Dave. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: drm + 4GB RAM + swiotlb = drm craps out
need, this just seems overly cumbersome when what I really want is vmalloc_32 to just work correctly on 64-bit systems... (why doesn't vmalloc_32 pass __GFP_DMA32 to the allocator) It probably should, but see second part of sentence above. And please never put closed lists in cc of l-k posts. Evil cc dropped. Ah okay I'll just do an allocator based on single pages and see if I can fix the kernel side to have the sg knowledge btw Its not a closed list, it's is a moderated list, all the posts do get through to it and the people on it are probably interested... Dave. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Replacement for page fault notifiers?
On Jan 9, 2008 6:32 AM, Christoph Hellwig [EMAIL PROTECTED] wrote: On Tue, Jan 08, 2008 at 09:06:38PM +0200, Pekka Paalanen wrote: - Is there anything coming to replace register_page_fault_notifier()? no. - Has someone found another way to accomplish the same without patching the kernel? no. - Should I start writing a patch to bring back the notifiers, based on the commit that removed them? no. People started to complain to me that mmio-trace does not compile for 2.6.24. At least the Nouveau project is a regular user of mmio-trace for reverse-engineering, and the tool should be easy to use. Therefore I would prefer not to force casual contributors to patch their kernels as it might be too much for some. I am hoping that 2.6.25, if not 2.6.24, would contain a mechanism to accomplish what I need. Please make mmio tracing generic enough so it works for every device and submit it for inclusion as a config option. Christoph, it is generic code, it works by patching the module you load and is in no way nvidia specific, I think we should revert your chance as the notifiers have a valid user and one it has been planned to upstream.. Dave. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/3] drm: nopage
Well they're all gone.. ;) There is a nopfn method which I converted in a subsequent patch I sent you. Maybe that's what you mean? Ah thats what it was, we added a nopfn not a nopage.. Thanks, Dave. Thanks, Nick Dave. Anyway, please apply. -- drm: nopage Convert drm from nopage to fault. Remove redundant vma range checks. Signed-off-by: Nick Piggin [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Cc: linux-kernel@vger.kernel.org --- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/3] drm: nopage
Dave, this patch is against 2.6.24-rc6-mm1. You said git-drm had rewritten
this area,
but the patch didn't have any rejects and seems to run fine here (although
I'm not
exactly sure how to exercise drm too well).
Hi Nick,
there should be a new nopage method added though which you need to
convert..
Dave.
Anyway, please apply.
--
drm: nopage
Convert drm from nopage to fault.
Remove redundant vma range checks.
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Cc: linux-kernel@vger.kernel.org
---
drivers/char/drm/drm_vm.c | 131
+-
1 file changed, 61 insertions(+), 70 deletions(-)
Index: linux-2.6/drivers/char/drm/drm_vm.c
===
--- linux-2.6.orig/drivers/char/drm/drm_vm.c
+++ linux-2.6/drivers/char/drm/drm_vm.c
@@ -70,7 +70,7 @@ static pgprot_t drm_io_prot(uint32_t map
}
/**
- * \c nopage method for AGP virtual memory.
+ * \c fault method for AGP virtual memory.
*
* \param vma virtual memory area.
* \param address access address.
@@ -80,8 +80,8 @@ static pgprot_t drm_io_prot(uint32_t map
* map, get the page, increment the use count and return it.
*/
#if __OS_HAS_AGP
-static __inline__ struct page *drm_do_vm_nopage(struct vm_area_struct *vma,
- unsigned long address)
+static __inline__ int drm_do_vm_fault(struct vm_area_struct *vma,
+ struct vm_fault *vmf)
{
struct drm_file *priv = vma-vm_file-private_data;
struct drm_device *dev = priv-head-dev;
@@ -93,19 +93,24 @@ static __inline__ struct page *drm_do_vm
* Find the right map
*/
if (!drm_core_has_AGP(dev))
- goto vm_nopage_error;
+ goto vm_fault_error;
if (!dev-agp || !dev-agp-cant_use_aperture)
- goto vm_nopage_error;
+ goto vm_fault_error;
if (drm_ht_find_item(dev-map_hash, vma-vm_pgoff, hash))
- goto vm_nopage_error;
+ goto vm_fault_error;
r_list = drm_hash_entry(hash, struct drm_map_list, hash);
map = r_list-map;
if (map map-type == _DRM_AGP) {
- unsigned long offset = address - vma-vm_start;
+ /*
+ * Using vm_pgoff as a selector forces us to use this unusual
+ * addressing scheme.
+ */
+ unsigned long offset = (unsigned long)vmf-virtual_address -
+ vma-vm_start;
unsigned long baddr = map-offset + offset;
struct drm_agp_mem *agpmem;
struct page *page;
@@ -127,7 +132,7 @@ static __inline__ struct page *drm_do_vm
}
if (!agpmem)
- goto vm_nopage_error;
+ goto vm_fault_error;
/*
* Get the page, inc the use count, and return it
@@ -135,27 +140,28 @@ static __inline__ struct page *drm_do_vm
offset = (baddr - agpmem-bound) PAGE_SHIFT;
page = virt_to_page(__va(agpmem-memory-memory[offset]));
get_page(page);
+ vmf-page = page;
DRM_DEBUG
(baddr = 0x%lx page = 0x%p, offset = 0x%lx, count=%d\n,
baddr, __va(agpmem-memory-memory[offset]), offset,
page_count(page));
- return page;
+ return 0;
}
- vm_nopage_error:
- return NOPAGE_SIGBUS; /* Disallow mremap */
+ vm_fault_error:
+ return VM_FAULT_SIGBUS; /* Disallow mremap */
}
#else/* __OS_HAS_AGP */
-static __inline__ struct page *drm_do_vm_nopage(struct vm_area_struct *vma,
- unsigned long address)
+static __inline__ int drm_do_vm_fault(struct vm_area_struct *vma,
+ struct vm_fault *vmf)
{
- return NOPAGE_SIGBUS;
+ return VM_FAULT_SIGBUS;
}
#endif /* __OS_HAS_AGP */
/**
- * \c nopage method for shared virtual memory.
+ * \c fault method for shared virtual memory.
*
* \param vma virtual memory area.
* \param address access address.
@@ -164,28 +170,27 @@ static __inline__ struct page *drm_do_vm
* Get the mapping, find the real physical page to map, get the page, and
* return it.
*/
-static __inline__ struct page *drm_do_vm_shm_nopage(struct vm_area_struct
*vma,
- unsigned long address)
+static __inline__ int drm_do_vm_shm_fault(struct vm_area_struct *vma,
+ struct vm_fault *vmf)
{
struct drm_map *map = (struct drm_map *) vma-vm_private_data;
unsigned long offset;
unsigned
[PATCH] Revert x86: optimize page faults like all other achitectures and kill notifier cruft
[This an initial RFC but I'd like to have this patch in before 2.6.24 goes
final as it really breaks this useful feature]
mmiotrace the MMIO access tracer used to reverse engineer binary blobs
used this notifier interface and is planned on being pushed upstream.
Having users able to just use the tracer module without having to rebuild
their kernel to add in a page fault handler hack means we get a lot
greater coverage for reverse engineering efforts.
Signed-off-by: David Airlie [EMAIL PROTECTED]
This reverts commit 74a0b5762713a26496db72eac34fbbed46f20fce.
Conflicts:
include/asm-avr32/kprobes.h
include/asm-ia64/kprobes.h
include/asm-s390/kprobes.h
include/asm-x86/kdebug_32.h
include/asm-x86/kdebug_64.h
include/asm-x86/kprobes_64.h
---
arch/x86/kernel/kprobes_32.c |3 +-
arch/x86/kernel/kprobes_64.c |1 +
arch/x86/mm/fault_32.c| 43 ++-
arch/x86/mm/fault_64.c| 44 +++-
include/asm-avr32/kdebug.h| 16 ++
include/asm-avr32/kprobes.h |1 +
include/asm-ia64/kdebug.h | 15 ++
include/asm-ia64/kprobes.h|1 +
include/asm-powerpc/kdebug.h | 19 +
include/asm-powerpc/kprobes.h |1 +
include/asm-s390/kdebug.h | 15 ++
include/asm-s390/kprobes.h|1 +
include/asm-sh/kdebug.h |2 +
include/asm-sparc64/kdebug.h | 18
include/asm-sparc64/kprobes.h |1 +
include/asm-x86/kdebug.h |3 ++
include/asm-x86/kprobes_32.h |2 +-
include/asm-x86/kprobes_64.h |1 +
kernel/kprobes.c | 39 +--
19 files changed, 183 insertions(+), 43 deletions(-)
diff --git a/arch/x86/kernel/kprobes_32.c b/arch/x86/kernel/kprobes_32.c
index 3a020f7..1ba8fee 100644
--- a/arch/x86/kernel/kprobes_32.c
+++ b/arch/x86/kernel/kprobes_32.c
@@ -586,7 +586,7 @@ out:
return 1;
}
-int __kprobes kprobe_fault_handler(struct pt_regs *regs, int trapnr)
+static int __kprobes kprobe_fault_handler(struct pt_regs *regs, int trapnr)
{
struct kprobe *cur = kprobe_running();
struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
@@ -668,6 +668,7 @@ int __kprobes kprobe_exceptions_notify(struct
notifier_block *self,
ret = NOTIFY_STOP;
break;
case DIE_GPF:
+ case DIE_PAGE_FAULT:
/* kprobe_running() needs smp_processor_id() */
preempt_disable();
if (kprobe_running()
diff --git a/arch/x86/kernel/kprobes_64.c b/arch/x86/kernel/kprobes_64.c
index 5df19a9..279cea7 100644
--- a/arch/x86/kernel/kprobes_64.c
+++ b/arch/x86/kernel/kprobes_64.c
@@ -654,6 +654,7 @@ int __kprobes kprobe_exceptions_notify(struct
notifier_block *self,
ret = NOTIFY_STOP;
break;
case DIE_GPF:
+ case DIE_PAGE_FAULT:
/* kprobe_running() needs smp_processor_id() */
preempt_disable();
if (kprobe_running()
diff --git a/arch/x86/mm/fault_32.c b/arch/x86/mm/fault_32.c
index a2273d4..f03cc93 100644
--- a/arch/x86/mm/fault_32.c
+++ b/arch/x86/mm/fault_32.c
@@ -25,7 +25,6 @@
#include linux/kprobes.h
#include linux/uaccess.h
#include linux/kdebug.h
-#include linux/kprobes.h
#include asm/system.h
#include asm/desc.h
@@ -33,27 +32,33 @@
extern void die(const char *,struct pt_regs *,long);
-#ifdef CONFIG_KPROBES
-static inline int notify_page_fault(struct pt_regs *regs)
+static ATOMIC_NOTIFIER_HEAD(notify_page_fault_chain);
+
+int register_page_fault_notifier(struct notifier_block *nb)
{
- int ret = 0;
-
- /* kprobe_running() needs smp_processor_id() */
- if (!user_mode_vm(regs)) {
- preempt_disable();
- if (kprobe_running() kprobe_fault_handler(regs, 14))
- ret = 1;
- preempt_enable();
- }
+ vmalloc_sync_all();
+ return atomic_notifier_chain_register(notify_page_fault_chain, nb);
+}
+EXPORT_SYMBOL_GPL(register_page_fault_notifier);
- return ret;
+int unregister_page_fault_notifier(struct notifier_block *nb)
+{
+ return atomic_notifier_chain_unregister(notify_page_fault_chain, nb);
}
-#else
-static inline int notify_page_fault(struct pt_regs *regs)
+EXPORT_SYMBOL_GPL(unregister_page_fault_notifier);
+
+static inline int notify_page_fault(struct pt_regs *regs, long err)
{
- return 0;
+ struct die_args args = {
+ .regs = regs,
+ .str = page fault,
+ .err = err,
+ .trapnr = 14,
+ .signr = SIGSEGV
+ };
+ return atomic_notifier_call_chain(notify_page_fault_chain,
+ DIE_PAGE_FAULT, args);
}
-#endif
/*
* Return EIP plus the CS segment base. The segment limit is also
@@ -331,7 +336,7
Re: [patch 1/1] Convert drivers in drivers/char/drm to use .unlocked_ioctl
The drm drivers in this patch all used drm_ioctl to perform their
ioctl calls. The common function is converted to use lock_kernel()
and unlock_kernel() and the drivers are converted to use .unlocked_ioctl
NAK
I've started looking at this already in the drm git tree, I'm going to
provide both locked and unlocked paths for drivers to choose, as we need
to audit the drivers on a per-driver basis, the other option is to provide
wrappers in each driver to do the lock/unlock kernel and leave drm_ioctl
alone..
I'll take a look kmalloc failure case sounds like a bug though..
Dave.
Signed-off-by: Kevin Winchester [EMAIL PROTECTED]
---
I also noted that in the failed kmalloc case in drm_ioctl(), the function
immediately returns -ENOMEM, rather than following the error path that
calls atomic_dec(dev-ioctl_count);. I'm not sure if the ioctl_count
is just not important in the -ENOMEM case, or if this is a bug.
drivers/char/drm/drmP.h |3 +--
drivers/char/drm/drm_drv.c| 10 ++
drivers/char/drm/i810_dma.c |2 +-
drivers/char/drm/i810_drv.c |2 +-
drivers/char/drm/i830_dma.c |2 +-
drivers/char/drm/i830_drv.c |2 +-
drivers/char/drm/i915_drv.c |2 +-
drivers/char/drm/mga_drv.c|2 +-
drivers/char/drm/r128_drv.c |2 +-
drivers/char/drm/radeon_drv.c |2 +-
drivers/char/drm/savage_drv.c |2 +-
drivers/char/drm/sis_drv.c|2 +-
drivers/char/drm/tdfx_drv.c |2 +-
drivers/char/drm/via_drv.c|2 +-
14 files changed, 19 insertions(+), 18 deletions(-)
Index: v2.6.24-rc7/drivers/char/drm/drmP.h
===
--- v2.6.24-rc7.orig/drivers/char/drm/drmP.h
+++ v2.6.24-rc7/drivers/char/drm/drmP.h
@@ -833,8 +833,7 @@ static inline int drm_mtrr_del(int handl
/* Driver support (drm_drv.h) */
extern int drm_init(struct drm_driver *driver);
extern void drm_exit(struct drm_driver *driver);
-extern int drm_ioctl(struct inode *inode, struct file *filp,
- unsigned int cmd, unsigned long arg);
+extern long drm_ioctl(struct file *filp, unsigned int cmd, unsigned long
arg);
extern long drm_compat_ioctl(struct file *filp,
unsigned int cmd, unsigned long arg);
extern int drm_lastclose(struct drm_device *dev);
Index: v2.6.24-rc7/drivers/char/drm/drm_drv.c
===
--- v2.6.24-rc7.orig/drivers/char/drm/drm_drv.c
+++ v2.6.24-rc7/drivers/char/drm/drm_drv.c
@@ -438,7 +438,6 @@ static int drm_version(struct drm_device
/**
* Called whenever a process performs an ioctl on /dev/drm.
*
- * \param inode device inode.
* \param file_priv DRM file private.
* \param cmd command.
* \param arg user argument.
@@ -447,8 +446,7 @@ static int drm_version(struct drm_device
* Looks up the ioctl function in the ::ioctls table, checking for root
* previleges if so required, and dispatches to the respective function.
*/
-int drm_ioctl(struct inode *inode, struct file *filp,
- unsigned int cmd, unsigned long arg)
+long drm_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
{
struct drm_file *file_priv = filp-private_data;
struct drm_device *dev = file_priv-head-dev;
@@ -458,6 +456,7 @@ int drm_ioctl(struct inode *inode, struc
int retcode = -EINVAL;
char *kdata = NULL;
+ lock_kernel();
atomic_inc(dev-ioctl_count);
atomic_inc(dev-counts[_DRM_STAT_IOCTLS]);
++file_priv-ioctl_count;
@@ -494,8 +493,10 @@ int drm_ioctl(struct inode *inode, struc
} else {
if (cmd (IOC_IN | IOC_OUT)) {
kdata = kmalloc(_IOC_SIZE(cmd), GFP_KERNEL);
- if (!kdata)
+ if (!kdata) {
+ unlock_kernel();
return -ENOMEM;
+ }
}
if (cmd IOC_IN) {
@@ -520,6 +521,7 @@ int drm_ioctl(struct inode *inode, struc
atomic_dec(dev-ioctl_count);
if (retcode)
DRM_DEBUG(ret = %x\n, retcode);
+ unlock_kernel();
return retcode;
}
Index: v2.6.24-rc7/drivers/char/drm/i810_dma.c
===
--- v2.6.24-rc7.orig/drivers/char/drm/i810_dma.c
+++ v2.6.24-rc7/drivers/char/drm/i810_dma.c
@@ -115,7 +115,7 @@ static int i810_mmap_buffers(struct file
static const struct file_operations i810_buffer_fops = {
.open = drm_open,
.release = drm_release,
- .ioctl = drm_ioctl,
+ .unlocked_ioctl = drm_ioctl,
.mmap = i810_mmap_buffers,
.fasync = drm_fasync,
};
Index: v2.6.24-rc7/drivers/char/drm/i810_drv.c
===
--- v2.6.24-rc7.orig/drivers/char/drm/i810_drv.c
+++
Re: [PATCH] Revert x86: optimize page faults like all other achitectures and kill notifier cruft
An alternative might be to come up with something decent and target 2.6.24.x I don't see mmiotrace getting merged into a stable kernel... how do however see it getting cleaned up for 2.6.25 now that people know how fragile the kernel hooks for it are.. We put the crappy code back in for 2.6.24 then take it out immediately after 2.6.24 and put something else in to support mmiotrace and perhaps the other new mystery features to which you refer below. hm. (I think the other mystery feature is actually a Novell kernel debugger but I'm not sure, madwifi use it for similiar reasons to mmiotrace I think..) all that crap } But that's all speculation. Has anyone actually measured the pagefault latency impact of this change? Message-Id: [EMAIL PROTECTED] Subject: [patch 20/38] Minor fault path optimization. Date: Fri, 27 Apr 2007 16:05:23 +0200 was a patch to do exactly that.. hch decided the feature wasn't useful and posted a patch to remove it.. That change has been in the mainline tree for nearly three months. All these affected parties have left it until the eve of 2.6.24 to actually tell us about it. This is causing me sympathy problems :( Jan first complained on the 4th Decemeber last year, I'm just posting this now because Linus said send him a patch to revert regressions rather than just complain, I've prepared the patch to put back the old behaviour from 2.6.23. This was only brought to my notice this morning but I'm not going to let that stop me from trying to find a correct fix rather than just ripping the feature out.. I think we could apply the page fault cleanup patch I mentioned earlier on top of this patch and get back the 300 cycles and that would make people happy, it makes sense for mmiotrace to use kprobes hooks and not have to do this stuff directly but if that is what is wanted the mmiotrace guys can do it directly in the future. Dave. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/1] Convert drivers in drivers/char/drm to use .unlocked_ioctl
On Wed, Jan 09, 2008 at 03:37:50AM +, Dave Airlie wrote: The drm drivers in this patch all used drm_ioctl to perform their ioctl calls. The common function is converted to use lock_kernel() and unlock_kernel() and the drivers are converted to use .unlocked_ioctl NAK Did you actually read Kevin's patch? Kevin's patch adds the lock/unlock to drm_ioctl which is exactly what I don't want, I want to have drm_ioctl become drm_unlocked_ioctl, and drm_ioctl to wrap it with the lock/unlocks, then the drivers can all use unlocked_ioctl like Kevins patch pointing to drm_ioctl, and can migrate over to drm_unlocked_ioctl post lock auditing, the new latest i915 driver seems to be fine with unlocked ioctls so far.. Yes I can use Kevin's patch as a base most likely, but it doesn't do what I want yet, and I've already started to do it properly in the drm upstream trees Dave. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CPA patchset
finally managed to get the time to review your CPA patchset, and i fundamentally agree with most of the detail changes done in it. But here are a few structural high-level observations: - firstly, there's no rationale given. So we'll change ioremap()/etc. from doing a cflush-range instruction instead of a WBINVD. But why? WBINVD isnt particular fast (takes a few msecs), but why is that a problem? Drivers dont do high-frequency ioremap-ing. It's typically only done at driver/device startup and that's it. Whether module load time takes 1254 msecs instead of 1250 msecs is no big deal. read graphics drivers, even though I think we may avoid the whole path if we can and end up doing some of this in the drivers when they know more about the situation so can avoid safeties.. but I still see this being used in AGP a fair bit at some point on some drivers.. Dave. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CPA patchset
On Jan 10, 2008 7:55 PM, Andi Kleen [EMAIL PROTECTED] wrote: On Thu, Jan 10, 2008 at 07:44:03PM +1000, Dave Airlie wrote: finally managed to get the time to review your CPA patchset, and i fundamentally agree with most of the detail changes done in it. But here are a few structural high-level observations: - firstly, there's no rationale given. So we'll change ioremap()/etc. from doing a cflush-range instruction instead of a WBINVD. But why? WBINVD isnt particular fast (takes a few msecs), but why is that a problem? Drivers dont do high-frequency ioremap-ing. It's typically only done at driver/device startup and that's it. Whether module load time takes 1254 msecs instead of 1250 msecs is no big deal. read graphics drivers, even though I think we may avoid the whole path You mean avoid change_page_attr() ? yes in some cases... if we can and end up doing some of this in the drivers when they know more about the situation so can avoid safeties.. Please explain, but it sounds very dubious. So on Intel 9xx hardware we know how to flush the whole pipe from chip to chipset to RAM, so when in the Intel driver we can leave pages mapped cached, and just flush all stages before having the GPU access them, This is only possible as long as we know all the parts involved, for example on AMD we have problems with that over-eager prefetching so for drivers on AMD chipsets we have to do something else more than likely using change_page_attr. Well GARTs and those are widely used even without AGP busses. Yes mainly we have used this scheme with Intel GARTs (also the only driver we have done with the new GPU system) by working closely with Intel engineers.. Dave. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: X-freeze after clflush changes [Was: 2.6.23-rc6-mm1]
On 9/20/07, Andi Kleen [EMAIL PROTECTED] wrote:
On Wed, Sep 19, 2007 at 12:10:17PM -0700, Andrew Morton wrote:
On Wed, 19 Sep 2007 16:59:04 +0200 Jiri Slaby [EMAIL PROTECTED] wrote:
-8-8-8-8-8-8
That means
void agp_generic_destroy_page(void *addr)
{
struct page *page;
if (addr == NULL)
return;
page = virt_to_page(addr);
(1) unmap_page_from_agp(page);
put_page(page);
(2) free_page((unsigned long)addr);
atomic_dec(agp_bridge-current_memory_agp);
}
(1) unmap_page_from_agp - change_page_attr - change_page_attr_addr -
__change_page_attr - save_page - list_add(fpage-lru, deferred_pages);
(2) free_page - free_pages - __free_pages - free_hot_page -
free_hot_cold_page - list_add(page-lru, pcp-list);
that'll hurt.
any ideas how to fix this?
We should hold a single reference on the page for its membership in
deferred_pages.
The code is broken anyways. If you free pages without flushing
them first some other innocent user allocating them will end up
with possible uncached pages for some time.
Does this simple patch help?
-Andi
Flush uncached AGP pages before freeing
In theory this should be handled by the caller, so as to avoid the
overhead of continuous flushing however I can see a potential race
condition here if the pages are put back into the kernel before the
caller flushes the mappings..
Do we need some sort of two step approach here? as flushing after each
page would be a major overhead for dynamic agp stuff in the new memory
manager..
Dave.
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
Index: linux/drivers/char/agp/generic.c
===
--- linux.orig/drivers/char/agp/generic.c
+++ linux/drivers/char/agp/generic.c
@@ -1185,6 +1185,7 @@ void agp_generic_destroy_page(void *addr
page = virt_to_page(addr);
unmap_page_from_agp(page);
+ flush_agp_mappings();
put_page(page);
free_page((unsigned long)addr);
atomic_dec(agp_bridge-current_memory_agp);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: X-freeze after clflush changes [Was: 2.6.23-rc6-mm1]
The code is broken anyways. If you free pages without flushing
them first some other innocent user allocating them will end up
with possible uncached pages for some time.
Does this simple patch help?
I've attached a more complicated patch that does a 2 stage effort to
unmapping and freeing pages. My kernel no longer hangs with this
patch...
Jiri can you confirm?
I'll look at the other issue separately..
Dave.
From 225696d75e7ec0bafbb47b935bd700e3fbeefbde Mon Sep 17 00:00:00 2001
From: Dave Airlie [EMAIL PROTECTED]
Date: Thu, 20 Sep 2007 11:30:41 +1000
Subject: [PATCH] agp: fix race condition between unmapping and freeing pages
With Andi's clflush fixup, we were getting hangs on server exit, flushing
the mappings after freeing each page helped.
This showed up a race condition where the pages after being freed could be
reused before the agp mappings had been flushed. Flushing after each single
page is a bad thing for future drm work, so make the page destroy a two pass
unmapping all the pages, flushing the mappings, and then destroying the pages.
Signed-off-by: Dave Airlie [EMAIL PROTECTED]
---
drivers/char/agp/agp.h |7 +--
drivers/char/agp/ali-agp.c | 29 +
drivers/char/agp/backend.c | 12
drivers/char/agp/generic.c | 20 ++--
drivers/char/agp/i460-agp.c |4 ++--
drivers/char/agp/intel-agp.c |6 --
6 files changed, 50 insertions(+), 28 deletions(-)
diff --git a/drivers/char/agp/agp.h b/drivers/char/agp/agp.h
index 8955e7f..b83824c 100644
--- a/drivers/char/agp/agp.h
+++ b/drivers/char/agp/agp.h
@@ -58,6 +58,9 @@ struct gatt_mask {
* devices this will probably be ignored */
};
+#define AGP_PAGE_DESTROY_UNMAP 1
+#define AGP_PAGE_DESTROY_FREE 2
+
struct aper_size_info_8 {
int size;
int num_entries;
@@ -113,7 +116,7 @@ struct agp_bridge_driver {
struct agp_memory *(*alloc_by_type) (size_t, int);
void (*free_by_type)(struct agp_memory *);
void *(*agp_alloc_page)(struct agp_bridge_data *);
- void (*agp_destroy_page)(void *);
+ void (*agp_destroy_page)(void *, int flags);
int (*agp_type_to_mask_type) (struct agp_bridge_data *, int);
};
@@ -267,7 +270,7 @@ int agp_generic_remove_memory(struct agp_memory *mem, off_t pg_start, int type);
struct agp_memory *agp_generic_alloc_by_type(size_t page_count, int type);
void agp_generic_free_by_type(struct agp_memory *curr);
void *agp_generic_alloc_page(struct agp_bridge_data *bridge);
-void agp_generic_destroy_page(void *addr);
+void agp_generic_destroy_page(void *addr, int flags);
void agp_free_key(int key);
int agp_num_entries(void);
u32 agp_collect_device_status(struct agp_bridge_data *bridge, u32 mode, u32 command);
diff --git a/drivers/char/agp/ali-agp.c b/drivers/char/agp/ali-agp.c
index 4941ddb..2b65155 100644
--- a/drivers/char/agp/ali-agp.c
+++ b/drivers/char/agp/ali-agp.c
@@ -156,29 +156,34 @@ static void *m1541_alloc_page(struct agp_bridge_data *bridge)
return addr;
}
-static void ali_destroy_page(void * addr)
+static void ali_destroy_page(void * addr, int flags)
{
if (addr) {
- global_cache_flush(); /* is this really needed? --hch */
- agp_generic_destroy_page(addr);
- global_flush_tlb();
+ if (flags AGP_PAGE_DESTROY_UNMAP) {
+ global_cache_flush(); /* is this really needed? --hch */
+ agp_generic_destroy_page(addr, flags);
+ global_flush_tlb();
+ } else
+ agp_generic_destroy_page(addr, flags);
}
}
-static void m1541_destroy_page(void * addr)
+static void m1541_destroy_page(void * addr, int flags)
{
u32 temp;
if (addr == NULL)
return;
- global_cache_flush();
-
- pci_read_config_dword(agp_bridge-dev, ALI_CACHE_FLUSH_CTRL, temp);
- pci_write_config_dword(agp_bridge-dev, ALI_CACHE_FLUSH_CTRL,
- (((temp ALI_CACHE_FLUSH_ADDR_MASK) |
- virt_to_gart(addr)) | ALI_CACHE_FLUSH_EN));
- agp_generic_destroy_page(addr);
+ if (flags AGP_PAGE_DESTROY_UNMAP) {
+ global_cache_flush();
+
+ pci_read_config_dword(agp_bridge-dev, ALI_CACHE_FLUSH_CTRL, temp);
+ pci_write_config_dword(agp_bridge-dev, ALI_CACHE_FLUSH_CTRL,
+ (((temp ALI_CACHE_FLUSH_ADDR_MASK) |
+ virt_to_gart(addr)) | ALI_CACHE_FLUSH_EN));
+ }
+ agp_generic_destroy_page(addr, flags);
}
diff --git a/drivers/char/agp/backend.c b/drivers/char/agp/backend.c
index 1b47c89..832ded2 100644
--- a/drivers/char/agp/backend.c
+++ b/drivers/char/agp/backend.c
@@ -189,9 +189,11 @@ static int agp_backend_initialize(struct agp_bridge_data *bridge)
err_out:
if (bridge-driver-needs_scratch_page) {
- bridge-driver-agp_destroy_page(
-gart_to_virt(bridge-scratch_page_real));
+ bridge-driver-agp_destroy_page(gart_to_virt(bridge-scratch_page_real),
+ AGP_PAGE_DESTROY_UNMAP);
flush_agp_mappings();
+ bridge-driver-agp_destroy_page(gart_to_virt(bridge-scratch_page_real),
+ AGP_PAGE_DESTROY_FREE);
}
if (got_gatt)
bridge-driver-free_gatt_table(bridge);
@@ -215,9 +217,11 @@ static void
Re: X-freeze after clflush changes [Was: 2.6.23-rc6-mm1]
On 9/20/07, Jiri Slaby [EMAIL PROTECTED] wrote: On 09/19/2007 09:54 PM, Andi Kleen wrote: Yeah. (But X doesn't run -- this is maybe the known issue in this release). What do you mean with not run? (II) intel(0): Initializing HW Cursor (II) intel(0): xf86BindGARTMemory: bind key 0 at 0x005ff000 (pgoffset 1535) (WW) intel(0): xf86BindGARTMemory: binding of gart memory with key 0 at offset 0x5ff000 failed (Invalid argument) Fatal server error: Couldn't bind memory for front buffer I thought I'd seen a thread about this issue, but I can't find it now. Is it known or am I seeing ghosts yet, Andrew? Can you send me a complete Xorg log file? and lspci -vv? my 945 works fine with my drm tree on top of Linus with clflush + my agp fix I just sent out .. Dave. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: X-freeze after clflush changes [Was: 2.6.23-rc6-mm1]
Fatal server error: Couldn't bind memory for front buffer I thought I'd seen a thread about this issue, but I can't find it now. Is it known or am I seeing ghosts yet, Andrew? Can you send me a complete Xorg log file? Maybe you are rather interested in these dmesg lines: Linux agpgart interface v0.102 agpgart: suspend/resume problematic: resume with 3D/DRI active may lockup X.Org on some chipset/BIOS combos (see DEBUG_AGP_PM in intel-agp.c) agpgart: Detected an Intel G33 Chipset. agpgart: Detected 8192K stolen memory. agpgart: AGP aperture is 256M @ 0xd000 [drm] Initialized drm 1.1.0 20060810 ACPI: PCI Interrupt :00:02.0[A] - GSI 16 (level, low) - IRQ 16 [drm] Initialized i915 1.6.0 20060119 on minor 0 ... set status page addr 0x00033000 agpgart: pg_start == 0x05ff,intel_private.gtt_entries == 0x0800 agpgart: Trying to insert into local/stolen memory So the problem is, that X passes too low start. The X log: http://www.fi.muni.cz/~xslaby/sklad/Xorg.0.log.old I've cc'd Zhenyu who might be able to shed some light on this? can you try 2.6.23-rc7 as maybe the G33 support still needs some work.. or maybe I'm missing a patch in the drm.. Dave. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Prospects of DRM TTM making it into 2.6.24?
What are the prospects of the DRM TTM changes making it into 2.6.24? I noticed that Andrew has them [1] in his mm tree... any chance of that getting pushed into Linus' tree for 2.6.24? No the merge window for 2.6.24 closed a few weeks ago. TTM wasn't in -mm for the 2.6.23 cycle as we hadn't finished the API stabilisation work in time. So I don't expect we'll see it before 2.6.25. I also have a few AGP changes I need to line up to support the chipset flushing work I've done to support TTM properly.. Dave. On Mon, 19 Nov 2007, Bastian, Waldo wrote: Cheers, Waldo [1] http://userweb.kernel.org/~akpm/mmotm/broken-out/git-drm.patch Intel Corporation - Platform Software Engineering, UMG - Hillsboro, Oregon - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 03/18] drm: nopage
Convert drm from nopage to fault.
Remove redundant vma range checks.
Hi Nick,
can you rebase against the -mm tree? or are you pushing this for before
then? if so can you supply me a patch against -mm?
The drm git tree has a new VM user for the memory manager..
Dave.
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Cc: linux-kernel@vger.kernel.org
---
drivers/char/drm/drm_vm.c | 131
+-
1 file changed, 61 insertions(+), 70 deletions(-)
Index: linux-2.6/drivers/char/drm/drm_vm.c
===
--- linux-2.6.orig/drivers/char/drm/drm_vm.c
+++ linux-2.6/drivers/char/drm/drm_vm.c
@@ -66,7 +66,7 @@ static pgprot_t drm_io_prot(uint32_t map
}
/**
- * \c nopage method for AGP virtual memory.
+ * \c fault method for AGP virtual memory.
*
* \param vma virtual memory area.
* \param address access address.
@@ -76,8 +76,8 @@ static pgprot_t drm_io_prot(uint32_t map
* map, get the page, increment the use count and return it.
*/
#if __OS_HAS_AGP
-static __inline__ struct page *drm_do_vm_nopage(struct vm_area_struct *vma,
- unsigned long address)
+static __inline__ int drm_do_vm_fault(struct vm_area_struct *vma,
+ struct vm_fault *vmf)
{
struct drm_file *priv = vma-vm_file-private_data;
struct drm_device *dev = priv-head-dev;
@@ -89,19 +89,24 @@ static __inline__ struct page *drm_do_vm
* Find the right map
*/
if (!drm_core_has_AGP(dev))
- goto vm_nopage_error;
+ goto vm_fault_error;
if (!dev-agp || !dev-agp-cant_use_aperture)
- goto vm_nopage_error;
+ goto vm_fault_error;
if (drm_ht_find_item(dev-map_hash, vma-vm_pgoff, hash))
- goto vm_nopage_error;
+ goto vm_fault_error;
r_list = drm_hash_entry(hash, struct drm_map_list, hash);
map = r_list-map;
if (map map-type == _DRM_AGP) {
- unsigned long offset = address - vma-vm_start;
+ /*
+ * Using vm_pgoff as a selector forces us to use this unusual
+ * addressing scheme.
+ */
+ unsigned long offset = (unsigned long)vmf-virtual_address -
+ vma-vm_start;
unsigned long baddr = map-offset + offset;
struct drm_agp_mem *agpmem;
struct page *page;
@@ -123,7 +128,7 @@ static __inline__ struct page *drm_do_vm
}
if (!agpmem)
- goto vm_nopage_error;
+ goto vm_fault_error;
/*
* Get the page, inc the use count, and return it
@@ -131,27 +136,28 @@ static __inline__ struct page *drm_do_vm
offset = (baddr - agpmem-bound) PAGE_SHIFT;
page = virt_to_page(__va(agpmem-memory-memory[offset]));
get_page(page);
+ vmf-page = page;
DRM_DEBUG
(baddr = 0x%lx page = 0x%p, offset = 0x%lx, count=%d\n,
baddr, __va(agpmem-memory-memory[offset]), offset,
page_count(page));
- return page;
+ return 0;
}
- vm_nopage_error:
- return NOPAGE_SIGBUS; /* Disallow mremap */
+ vm_fault_error:
+ return VM_FAULT_SIGBUS; /* Disallow mremap */
}
#else/* __OS_HAS_AGP */
-static __inline__ struct page *drm_do_vm_nopage(struct vm_area_struct *vma,
- unsigned long address)
+static __inline__ int drm_do_vm_fault(struct vm_area_struct *vma,
+ struct vm_fault *vmf)
{
- return NOPAGE_SIGBUS;
+ return VM_FAULT_SIGBUS;
}
#endif /* __OS_HAS_AGP */
/**
- * \c nopage method for shared virtual memory.
+ * \c fault method for shared virtual memory.
*
* \param vma virtual memory area.
* \param address access address.
@@ -160,28 +166,27 @@ static __inline__ struct page *drm_do_vm
* Get the mapping, find the real physical page to map, get the page, and
* return it.
*/
-static __inline__ struct page *drm_do_vm_shm_nopage(struct vm_area_struct
*vma,
- unsigned long address)
+static __inline__ int drm_do_vm_shm_fault(struct vm_area_struct *vma,
+ struct vm_fault *vmf)
{
struct drm_map *map = (struct drm_map *) vma-vm_private_data;
unsigned long offset;
unsigned long i;
struct page *page;
- if (address vma-vm_end)
- return NOPAGE_SIGBUS; /* Disallow mremap */
if (!map)
-
Re: Prospects of DRM TTM making it into 2.6.24?
I also have a few AGP changes I need to line up to support the chipset flushing work I've done to support TTM properly.. Did anything happen with that null-pointer deref I was hitting? I've rebased the patches in my tree along with a chunk I missed which should make your patch unnecessary. Do you pull my agp-mm tree into -mm? ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/agp-2.6 agp-mm if not.. Dave. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 00/12] PAT 64b: PAT support for X86_64
Yes. It is that wonderful time of the year again. No, no. We are not talking about holiday season or new year here. We are talking about one another rehash of why we do not support PAT in x86 question and series of patches that implement some PAT support before going into hibernation again. Only difference is that we hope to take this little further this time and may be really get this support into upstream kernel soon. Woot, PAT support: this time we mean it!! I'll just give one comment after a reading your todo.. * Do we need to allow RAM pages to be mapped as WC? If not, then we don't need to follow the TLB flush mechanism (make pte not present, flush, and set pte with new mapping) mentioned in section 10.12.4 of SDM Vol3a. Yes, the main use for GPUs is to have RAM pages mapped WC, and placed into a GART on the GPU side, currently for Intel IGD we are okay as the CPU can access the GPU GART aperture, but other chips exist where this isn't possible, I think poulsbo and possible some of the AMD IGPs.. Dave. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 00/12] PAT 64b: PAT support for X86_64
On Dec 15, 2007 8:00 AM, Siddha, Suresh B [EMAIL PROTECTED] wrote: On Fri, Dec 14, 2007 at 12:28:25AM +, Dave Airlie wrote: Yes, the main use for GPUs is to have RAM pages mapped WC, and placed into a GART on the GPU side, currently for Intel IGD we are okay as the CPU can access the GPU GART aperture, but other chips exist where this isn't possible, I think poulsbo and possible some of the AMD IGPs.. Ok. So how is it working today on these platforms with no PAT support. Open source drivers use UC or WB on these platforms? As this RAM is not contiguous, one can't use MTRRs to set WC. Right? Well, if WC is needed for RAM, then we have to address it too. It doesn't work really, which is mostly the problem :) We mostly use UC on these pages, or WB within cache coherent domains. mtrrs are totally useless in this situation. Dave. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 00/12] PAT 64b: PAT support for X86_64
It doesn't work really, which is mostly the problem :) We mostly use UC on these pages, or WB within cache coherent domains. mtrrs are totally useless in this situation. In what sense does it not work? oh I was mostly joking hence the smily.. really it just means thing run slower than they need to.. Dave. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] AGP initial support for chipset flushing..
Hi,
We've uncovered a need when using the new memory manager to flush the
chipset global write buffers on certain intel chipset due to a lack of
coherency..
The attached patches add a new AGP interface for this purpose and
implements this in the Intel AGP driver. This stuff is based of some
guesswork in the 915 case from comments in the documentation :).
Unfortuantely the 965 BIOS doesn't set this stuff up properly and it
doesn't use a standard BAR address, so I have to do it by hand, I'd
appreciate any commentary particularly in the setting up of the resource
stuff.
Regards,
Dave.From b9dcf514d0f1f61dc482cac622ffd2d79d500bf8 Mon Sep 17 00:00:00 2001
From: Dave Airlie [EMAIL PROTECTED]
Date: Mon, 29 Oct 2007 15:14:03 +1000
Subject: [PATCH] agp: add chipset flushing support to AGP interface
This bumps the AGP interface to 0.103.
Certain Intel chipsets contains a global write buffer, and this can require
flushing from the drm or X.org to make sure all data has hit RAM before
initiating a GPU transfer, due to a lack of coherency with the integrated
graphics device and this buffer.
This just adds generic support to the AGP interfaces, a follow-on patch
will add support to the Intel driver to use this interface.
Signed-off-by: Dave Airlie [EMAIL PROTECTED]
---
drivers/char/agp/agp.h |3 ++-
drivers/char/agp/backend.c |2 +-
drivers/char/agp/compat_ioctl.c |4
drivers/char/agp/compat_ioctl.h |2 ++
drivers/char/agp/frontend.c | 11 +++
drivers/char/agp/generic.c |7 +++
include/linux/agp_backend.h |1 +
include/linux/agpgart.h |1 +
8 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/drivers/char/agp/agp.h b/drivers/char/agp/agp.h
index b83824c..9ec9374 100644
--- a/drivers/char/agp/agp.h
+++ b/drivers/char/agp/agp.h
@@ -117,7 +117,8 @@ struct agp_bridge_driver {
void (*free_by_type)(struct agp_memory *);
void *(*agp_alloc_page)(struct agp_bridge_data *);
void (*agp_destroy_page)(void *, int flags);
-int (*agp_type_to_mask_type) (struct agp_bridge_data *, int);
+ int (*agp_type_to_mask_type) (struct agp_bridge_data *, int);
+ void (*chipset_flush)(struct agp_bridge_data *);
};
struct agp_bridge_data {
diff --git a/drivers/char/agp/backend.c b/drivers/char/agp/backend.c
index 832ded2..f9c180c 100644
--- a/drivers/char/agp/backend.c
+++ b/drivers/char/agp/backend.c
@@ -43,7 +43,7 @@
* fix some real stupidity. It's only by chance we can bump
* past 0.99 at all due to some boolean logic error. */
#define AGPGART_VERSION_MAJOR 0
-#define AGPGART_VERSION_MINOR 102
+#define AGPGART_VERSION_MINOR 103
static const struct agp_version agp_current_version =
{
.major = AGPGART_VERSION_MAJOR,
diff --git a/drivers/char/agp/compat_ioctl.c b/drivers/char/agp/compat_ioctl.c
index ecd4248..3927579 100644
--- a/drivers/char/agp/compat_ioctl.c
+++ b/drivers/char/agp/compat_ioctl.c
@@ -273,6 +273,10 @@ long compat_agp_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
case AGPIOC_UNBIND32:
ret_val = compat_agpioc_unbind_wrap(curr_priv, (void __user *) arg);
break;
+
+ case AGPIOC_CHIPSET_FLUSH32:
+ ret_val = agpioc_chipset_flush_wrap(curr_priv);
+ break;
}
ioctl_out:
diff --git a/drivers/char/agp/compat_ioctl.h b/drivers/char/agp/compat_ioctl.h
index 71939d6..0c9678a 100644
--- a/drivers/char/agp/compat_ioctl.h
+++ b/drivers/char/agp/compat_ioctl.h
@@ -39,6 +39,7 @@
#define AGPIOC_DEALLOCATE32 _IOW (AGPIOC_BASE, 7, compat_int_t)
#define AGPIOC_BIND32 _IOW (AGPIOC_BASE, 8, compat_uptr_t)
#define AGPIOC_UNBIND32 _IOW (AGPIOC_BASE, 9, compat_uptr_t)
+#define AGPIOC_CHIPSET_FLUSH32 _IO (AGPIOC_BASE, 10)
struct agp_info32 {
struct agp_version version; /* version of the driver*/
@@ -101,5 +102,6 @@ void agp_free_memory_wrap(struct agp_memory *memory);
struct agp_memory *agp_allocate_memory_wrap(size_t pg_count, u32 type);
struct agp_memory *agp_find_mem_by_key(int key);
struct agp_client *agp_find_client_by_pid(pid_t id);
+int agpioc_chipset_flush_wrap(struct agp_file_private *priv);
#endif /* _AGP_COMPAT_H */
diff --git a/drivers/char/agp/frontend.c b/drivers/char/agp/frontend.c
index 7791e98..9bd5a95 100644
--- a/drivers/char/agp/frontend.c
+++ b/drivers/char/agp/frontend.c
@@ -960,6 +960,13 @@ static int agpioc_unbind_wrap(struct agp_file_private *priv, void __user *arg)
return agp_unbind_memory(memory);
}
+int agpioc_chipset_flush_wrap(struct agp_file_private *priv)
+{
+ DBG();
+ agp_flush_chipset(agp_bridge);
+ return 0;
+}
+
static int agp_ioctl(struct inode *inode, struct file *file,
unsigned int cmd, unsigned long arg)
{
@@ -1033,6 +1040,10 @@ static int agp_ioctl(struct inode *inode, struct file *file,
case AGPIOC_UNBIND:
ret_val = agpioc_unbind_wrap(curr_priv, (void __user *) arg);
break;
+
+ case AGPIOC_CHIPSET_FLUSH:
+ ret_val = agpioc_chipset_flush_wrap(curr_priv);
+ break;
}
ioctl_out:
diff
Re: [RFC] AGP initial support for chipset flushing..
In this case, we're performing basically a dma_sync*(...DMA_TO_DEVICE) right? Can we be sure that a single flush is sufficient? Is there any window between when we flush and when we start accessing memory with the device that we could get into more caching trouble? Not that I can think off, but I don't work for the company who screwed up the coherency :-), and I don't have the docs, so please investigate for me ;-) Looks reasonable, I'm not sure we can do much better. The only concern I have is that allocating some more PCI space like that may end up clobbering some *other* hidden BIOS mapping, but there's not a whole lot we can do about that. Again I'm trying to workaround broken BIOS.. nothing I can do. Dave. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Interaction between Xen and XFS: stray RW mappings
On 10/15/07, Andi Kleen [EMAIL PROTECTED] wrote: Hmm, OK. It looks like DRM vmallocs memory (which gives highmem). I meant I'm not sure if it uses that memory uncached. I admit not quite understanding that code. There used to be at least one place where it set UC for an user mapping though. Currently the only DRM memory handed to userspace is vmalloc_32 in drm_scatter.c I notice the VIA driver does its own vmalloc for dmablit, so it may have an issue with this if highmem is involved. This will change with the upcoming memory manager so I'll need to investigate it a bit perhaps... Dave. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: drm i915 hangs on heavy io load
On Tue, Oct 30, 2012 at 10:49 AM, Norbert Preining prein...@logic.at wrote: On Mo, 29 Okt 2012, Tino Keitel wrote: Section Device Option AccelMethod SNA Identifier Card0 Driver intel EndSection Thanks, running now with SNA. Let us see what happens. Please don't, we ain't going to find the bug any quicker changing variables, if the only thing that changed on your system was the kernel then we need to figure out which kernel changes caused it and remove them. Changing userspace is only complicating things and making it less likely we'll ever find the regressions. Once we find the regression, changing userspace optiosn to help understand it is more reasonable. How long does it take you to reproduce, and does it happen when in actual use. On my laptop I've noticed I come back to it sometimes and gnome-shell is dead. This never happened pre 3.7-rc's. But for me its a 3-4 day window so far for it to die, which makes bisecting it a bit of a major problem. and I'm just finished bisecting the last Ironlake regression that took over a month. I would suggest starting a bisect on drivers/gpu/drm/i915 from 3.6 final to 3.7-rc1 or maybe -rc2. 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/
[git pull] drm nouveau fixes
Hi Linus, just a nouveau set, since we have a couple of reports on lkml/dri-devel of regressions that this should fix I sent it along on its own. Dave. The following changes since commit 8f0d8163b50e01f398b14bcd4dc039ac5ab18d64: Linux 3.7-rc3 (2012-10-28 12:24:48 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes Ben Skeggs (6): drm/nouveau: silence modesetting spam on pre-gf8 chipsets drm/nouveau/i2c: fix typo when checking nvio i2c port validity drm/nouveau: allow creation of zero-sized mm drm/nv50/fb: prevent oops on chipsets without compression tags drm/nouveau: resurrect headless mode since rework drm/nouveau: headless mode by default if pci class != vga display Dave Airlie (1): Merge branch 'drm-nouveau-fixes' of git://people.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes drivers/gpu/drm/nouveau/core/core/mm.c |9 -- drivers/gpu/drm/nouveau/core/include/core/mm.h |1 - drivers/gpu/drm/nouveau/core/subdev/fb/nv50.c | 10 ++ drivers/gpu/drm/nouveau/core/subdev/i2c/base.c |2 +- drivers/gpu/drm/nouveau/nouveau_display.c | 36 ++-- drivers/gpu/drm/nouveau/nouveau_drm.c | 36 ++-- drivers/gpu/drm/nouveau/nouveau_drm.h |2 + drivers/gpu/drm/nouveau/nouveau_irq.c | 16 ++ drivers/gpu/drm/nouveau/nv04_dac.c | 16 +- drivers/gpu/drm/nouveau/nv04_dfp.c | 14 drivers/gpu/drm/nouveau/nv04_tv.c |9 ++--- 11 files changed, 83 insertions(+), 68 deletions(-) -- 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/
[git pull] drm fixes
Hi Linus the three nouveau fixes quiten unneeded dmesg spam that people are seeing and pondering, the udl fix stops it from trying to driver monitors that are too big, where we get a black screen. and vmware memory alloc problem. Dave. The following changes since commit 6f0f9b6b3fcfe5e156f20d4f804f0d505c750b3c: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2012-09-25 14:20:29 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to d638163099c86f65984d85aab7ddf2cf78fa3a16: Merge branch 'drm-nouveau-fixes' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes (2012-09-27 17:58:53 +1000) Ben Skeggs (3): drm/nouveau: silence a debug message triggered by newer userspace drm/nvc0/ltcg: mask off intr 0x10 drm/nvc0/fifo: ignore bits in PFIFO_INTR that aren't set in PFIFO_INTR_EN Dan Carpenter (1): vmwgfx: corruption in vmw_event_fence_action_create() Dave Airlie (3): Merge branch 'drm-nouveau-fixes' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes drm/udl: limit modes to the sku pixel limits. Merge branch 'drm-nouveau-fixes' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes drivers/gpu/drm/nouveau/nouveau_abi16.c | 2 +- drivers/gpu/drm/nouveau/nvc0_fb.c | 1 + drivers/gpu/drm/nouveau/nvc0_fifo.c | 3 ++- drivers/gpu/drm/nouveau/nve0_fifo.c | 3 ++- drivers/gpu/drm/udl/udl_connector.c | 7 +++ drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 2 +- 6 files changed, 14 insertions(+), 4 deletions(-) -- 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: 3.5 regression on i915
On Sat, Oct 6, 2012 at 9:42 AM, Willy Tarreau w...@1wt.eu wrote: Chris, Daniel, since version 3.5, my Asus EeePC 1005HA bugs during startx. I didn't have the time to investigate until this evening. I could bisect the commits and found that the following one was merged in 3.5-rc1 and is responsible for these bugs that can reliably be triggered : 1b50247a8ddde4af5aaa0e6bc125615372ce6c16 is the first bad commit commit 1b50247a8ddde4af5aaa0e6bc125615372ce6c16 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Tue Apr 24 15:47:30 2012 +0100 drm/i915: Remove the list of pinned inactive objects Simplify object tracking by removing the inactive but pinned list. The only place where this was used is for counting the available memory, which is just as easy performed by checking all objects on the rare occasions it is required (application startup). For ease of debugging, we keep the reporting of pinned objects through the error-state and debugfs. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch I tried to revert it from 3.5.6-rc1 but it does not revert cleanly at all and I'm totall unfamiliar with this code to attempt anything sane at this time of the night. The crash happens here in i915_gem_entervt_ioctl() : 3659 BUG_ON(!list_empty(dev_priv-mm.active_list)); 3660 BUG_ON(!list_empty(dev_priv-mm.flushing_list)); - 3661 BUG_ON(!list_empty(dev_priv-mm.inactive_list)); 3662 mutex_unlock(dev-struct_mutex); More info in the trace below : [ cut here ] kernel BUG at drivers/gpu/drm/i915/i915_gem.c:3661! invalid opcode: [#1] SMP Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss uvcvideo videobuf2_core videodev videobuf2_vmalloc videobuf2_memops uhci_hcd ath9k mac80211 snd_hda_codec_realtek ath9k_common microcode ath9k_hw psmouse serio_raw sg ath cfg80211 atl1c lpc_ich mfd_core ehci_hcd snd_hda_intel snd_hda_codec snd_hwdep snd_pcm rtc_cmos snd_timer snd evdev eeepc_laptop snd_page_alloc sparse_keymap Pid: 2866, comm: X Not tainted 3.5.6-rc1-eeepc #1 ASUSTeK Computer INC. 1005HA/1005HA EIP: 0060:[c12dc291] EFLAGS: 00013297 CPU: 0 EIP is at i915_gem_entervt_ioctl+0xf1/0x110 EAX: f5941df4 EBX: f594 ECX: EDX: 0002 ESI: f5835400 EDI: EBP: f51d7e38 ESP: f51d7e20 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 CR0: 8005003b CR2: b760e0a0 CR3: 351b6000 CR4: 07d0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process X (pid: 2866, ti=f51d6000 task=f61af8d0 task.ti=f51d6000) Stack: 0001 f5835414 f51d7e84 f5835400 f54f85c0 f51d7f10 c12b530b 0001 c151b139 c14751b6 c152e030 0b32 6459 0059 e200 0001 6459 c159ddd0 c12dc1a0 ffea Call Trace: [c12b530b] drm_ioctl+0x2eb/0x440 [c12dc1a0] ? i915_gem_init+0xe0/0xe0 [c1052b2b] ? enqueue_hrtimer+0x1b/0x50 [c1053321] ? __hrtimer_start_range_ns+0x161/0x330 [c10530b3] ? lock_hrtimer_base+0x23/0x50 [c1053163] ? hrtimer_try_to_cancel+0x33/0x70 [c12b5020] ? drm_version+0x90/0x90 [c10ca171] vfs_ioctl+0x31/0x50 [c10ca2e4] do_vfs_ioctl+0x64/0x510 [c10535de] ? hrtimer_nanosleep+0x8e/0x100 [c1052c20] ? update_rmtp+0x80/0x80 [c10ca7c9] sys_ioctl+0x39/0x60 [c1433949] syscall_call+0x7/0xb Code: 83 c4 0c 5b 5e 5f 5d c3 c7 44 24 04 2c 05 53 c1 c7 04 24 6f ef 47 c1 e8 6e e0 fd ff c7 83 38 1e 00 00 00 00 00 00 e9 3f ff ff ff 0f 0b eb fe 0f 0b eb fe 8d b4 26 00 00 00 00 0f 0b eb fe 8d b6 EIP: [c12dc291] i915_gem_entervt_ioctl+0xf1/0x110 SS:ESP 0068:f51d7e20 ---[ end trace dd332ec083cbd513 ]--- I have the full dmesg if that can help. I do not have KMS and have not tested 3.6-* yet. $ grep I915 .config CONFIG_DRM_I915=y # CONFIG_DRM_I915_KMS is not set Any reason you don't have KMS, you'll keep hitting these non-kms bugs since it has no users anymore really. Granted they'll get fixed, but I suspect its a losing battle over time. 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: 3.5 regression on i915
On Sat, Oct 6, 2012 at 3:27 AM, Willy Tarreau w...@1wt.eu wrote: On Sat, Oct 06, 2012 at 01:58:45AM +0200, Willy Tarreau wrote: On Sat, Oct 06, 2012 at 09:48:57AM +1000, Dave Airlie wrote: Any reason you don't have KMS, you'll keep hitting these non-kms bugs since it has no users anymore really. Granted they'll get fixed, but I suspect its a losing battle over time. Well, back in old times every time I tried to enable it, I only ran into problems so I got used to disable it, which made sense since it didn't bring me any benefit. OK I found why in the end. When I enable KMS, my X server fails to start and segfaults in intel_drv.so. So I think that the comment in Kconfig below is quite appropriate : Okay are you running a really old userspace? just wondering what could cause this. 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: [PATCH] make CONFIG_EXPERIMENTAL invisible and default
Really I would much prefer to add some Don't enable it unless you're doing kernel hacking. If unsure say N text in the Kconfig. I can understand that distros want to cover as much feature as they can for their users. But should it be an excuse for not reading outstanding warnings in Kconfig help text? In my experience, they do not read these warnings carefully. :-( Or perhaps they do read them, but react to them by running the code through some test suite rather than by putting full faith in the warning. I think Kconfig is mostly what distro would like to use the thing is the Kconfig text needs to be there upfront when its merged, not two months later, since then it too late for a distro to notice. I'd bet most distros would read the warnings, but in a lot of cases the warning don't exist until its too late. Dave. Or may be add some specific warning yeah. I wouldn't mind much. We have some weeks to think about it -- I cannot see pushing a warning in as a regression. ;-) Thanx, Paul -- 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/ -- 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/
[git pull] drm for 3.7-rc1 (part 2)
Hi Linus, This is the follow-up pull, 3 pieces a) exynos next stuff, was delayed but looks okay to me, one patch in v4l bits but it was acked by v4l person. b) UAPI disintegration bits c) intel fixes - DP fixes, hang fixes, other misc fixes. Dave. The following changes since commit 0b8e74c6f44094189dbe78baf4101acc7570c6af: Merge branch 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media (2012-10-07 17:49:05 +0900) are available in the git repository at: git://people.freedesktop.org/~airlied/linux.git drm-next for you to fetch changes up to 1f31c69dac71bebc0f00bc8534a6345782045501: Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-next (2012-10-07 21:13:54 +1000) Adam Jackson (6): drm: Export drm_probe_ddc() drm/dp: Update DPCD defines drm/i915/dp: Fetch downstream port info if needed during DPCD fetch drm/i915/dp: Be smarter about connection sense for branch devices drm/dp: Document DP spec versions for various DPCD registers drm/dp: Make sink count DP 1.2 aware Ben Widawsky (2): drm/i915: Fix set_caching locking drm/i915: Fix GT_MODE default value Chris Wilson (3): drm/i915: Actually invalidate the TLB for the SandyBridge HW contexts w/a drm/i915: Flush the pending flips on the CRTC before modification drm/i915: Try harder to complete DP training pattern 1 Daniel Vetter (2): drm/i915: call drm_handle_vblank before finish_page_flip drm/i915: don't frob the vblank ts in finish_page_flip Dave Airlie (3): Merge branch 'disintegrate-drm' of git://git.infradead.org/users/dhowells/linux-headers into drm-next Merge branch 'exynos-drm-next' of git://git.infradead.org/users/kmpark/linux-samsung into drm-next Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-next David Howells (1): UAPI: (Scripted) Disintegrate include/drm Dmitry Rogozhkin (1): drm/i915: EBUSY status handling added to i915_gem_fault(). Inki Dae (16): drm/exynos: added device object to subdrv's remove callback as argument drm/exynos: separated subdrv_probe function into two parts. drm/exynos: separeated fimd_power_on into some parts. drm/exynos: fixed duplicated mode setting. drm/exynos: add wait_for_vblank callback interface. drm/exynos: make sure that hardware overlay for fimd is disabled drm/exynos: make sure that hardware overlay for hdmi is disabled drm/exynos: check NV12M format specific to Exynos properly drm/exynos: update crtc to plane safely drm/exynos: Disable plane when released drm/exynos: add pid to g2d_runqueue_node drm/exynos: fix duplicated mutex lock issue drm/exynos: check crtc's dpms mode at page flip drm/exynos: check crtc's dpms mode at SetCrtc drm/exynos: support drm_wait_vblank feature for VIDI drm/exynos: fix display power call issue. Jani Nikula (1): drm/i915: use adjusted_mode instead of mode for checking the 6bpc force flag Jesse Barnes (1): drm/i915: set swizzling to none on VLV Joonyoung Shim (2): drm/exynos: fix to calculate CRTC shown via screen drm/exynos: fix kcalloc size of g2d cmdlist node Leela Krishna Amudala (1): drm/exynos: add platform_device_id table and driver data for drm fimd Mika Kuoppala (1): drm/i915: print warning if vmi915_gem_fault error is not handled Rahul Sharma (9): drm: exynos: remove drm hdmi platform data struct drm: exynos: hdmi: add support for exynos5 ddc drm: exynos: hdmi: add support for exynos5 hdmiphy drm: exynos: hdmi: add support for platform variants for mixer drm: exynos: hdmi: add support to disable video processor in mixer drm: exynos: hdmi: add support for exynos5 mixer drm: exynos: hdmi: replace is_v13 with version check in hdmi drm: exynos: hdmi: add support for exynos5 hdmi drm: exynos: hdmi: remove drm common hdmi platform data struct Sachin Kamat (1): drm/exynos: Fix potential NULL pointer dereference Tomasz Stanislawski (5): media: s5p-hdmi: add HPD GPIO to platform data drm: exynos: hdmi: support for platform variants drm: exynos: hdmi: fix interrupt handling drm: exynos: hdmi: use s5p-hdmi platform data drm: exynos: hdmi: turn off HPD interrupt in HDMI chip drivers/gpu/drm/drm_edid.c|3 +- drivers/gpu/drm/exynos/exynos_ddc.c | 22 +- drivers/gpu/drm/exynos/exynos_drm_connector.c | 50 +- drivers/gpu/drm/exynos/exynos_drm_connector.h |4 + drivers/gpu/drm/exynos/exynos_drm_core.c | 100 ++- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 20 +- drivers/gpu/drm/exynos/exynos_drm_drv.h | 19 +- drivers/gpu/drm/exynos/exynos_drm_encoder.c | 116 ++- drivers/gpu/drm/exynos
[git pull] drm fixes
Hi Linus, scattered selection of fixes: radeon: load detect fixes from SuSE/AMD intel: misc i830, sdvo regression, vesafb kickoff ums fix exynos: maintainers entry update + fixes udl: fix stride scanout issue its slightly bigger than I'd probably like, but nothing looked dangerous enough to hold off on. Dave. The following changes since commit 4936b172d699434547addbe452c2d600ea6a4baf: Merge branch 'drm-nouveau-fixes' of git://people.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes (2012-10-31 13:46:09 +1000) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes Alex Deucher (1): drm/radeon: add load detection support for ext DAC on R200 (v2) Chris Wilson (1): drm/i915: Only kick out vesafb if we takeover the fbcon with KMS Daniel Vetter (3): drm/i915: fix overlay on i830M drm/i915: VGA needs to be on pipe A on i830M drm/i915: clear the entire sdvo infoframe buffer Dave Airlie (4): Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes Merge branch 'drm-fixes-3.7' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge branch 'exynos-drm-fixes' of git://git.kernel.org/.../daeinki/drm-exynos into drm-fixes drm/udl: fix stride issues scanning out stride != width*bpp Egbert Eich (6): DRM/Radeon: Fix Load Detection on legacy primary DAC. DRM/Radeon: Fix primary DAC Load Detection for RV100 chips. DRM/Radeon: On DVI-I use Load Detection when EDID is bogus. DRM/Radeon: Clean up code in TV DAC load detection. DRM/Radeon: Fix TV DAC Load Detection for single CRTC chips. DRM/radeon: For single CRTC GPUs move handling of CRTC_CRT_ON to crtc_dpms(). Igor Murzov (1): drm/radeon: fix ATPX function documentation Inki Dae (2): drm/exynos: fix display on issue MAINTAINERS: Add git repository for Exynos DRM Jani Nikula (1): drm/i915: be less verbose about inability to provide vendor backlight Peter Senna Tschudin (1): drivers/gpu/drm/radeon/evergreen_cs.c: Remove unnecessary semicolon Rahul Sharma (1): drm: exynos: removed warning due to missing typecast for mixer driver data Rob Clark (1): drm/exynos: add support for ARCH_MULTIPLATFORM MAINTAINERS |1 + drivers/gpu/drm/exynos/Kconfig |2 +- drivers/gpu/drm/exynos/exynos_drm_connector.c |1 + drivers/gpu/drm/exynos/exynos_drm_encoder.c | 33 +++-- drivers/gpu/drm/exynos/exynos_mixer.c |2 +- drivers/gpu/drm/i915/i915_dma.c |3 +- drivers/gpu/drm/i915/intel_crt.c|2 +- drivers/gpu/drm/i915/intel_overlay.c| 14 ++- drivers/gpu/drm/i915/intel_panel.c |2 +- drivers/gpu/drm/i915/intel_sdvo.c | 62 ++--- drivers/gpu/drm/i915/intel_sdvo_regs.h |2 + drivers/gpu/drm/radeon/evergreen_cs.c |2 +- drivers/gpu/drm/radeon/radeon_atpx_handler.c|4 +- drivers/gpu/drm/radeon/radeon_connectors.c | 28 +++- drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 15 ++- drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 175 +++ drivers/gpu/drm/udl/udl_drv.h |2 +- drivers/gpu/drm/udl/udl_fb.c| 12 +- drivers/gpu/drm/udl/udl_transfer.c |5 +- 19 files changed, 275 insertions(+), 92 deletions(-) -- 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: drm i915 hangs on heavy io load
On Sun, Nov 4, 2012 at 10:44 AM, Norbert Preining prein...@logic.at wrote: Hi all, On Di, 30 Okt 2012, Dave Airlie wrote: I would suggest starting a bisect on drivers/gpu/drm/i915 from 3.6 final to 3.7-rc1 or maybe -rc2. Sorry for my ignorance ... I did on master branch $ git checkout v3.7-rc1 ... $ git bisect start drivers/gpu/drm/i915 $ git bisect bad $ git bisect good v3.6 Bisecting: 121 revisions left to test after this (roughly 7 steps) [25c5b2665fe4cc5a93edd29b62e7c05c1526] drm/i915: implement new set_mode code flow $ after that I am back somewhere around 3.6.0-rc2 ??? Am I doing something wrong? I thought I am bisecting between 3.6 and 3.7.-rc2? How can I go back to 3.6.0-rc2? Yeah thats fine, bisecting works by going to where commits were originally committed, so drm-intel-next was 3.6.0-rc2 at some point was only merged into Linus later. 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, linux3.7-rc3: BUG: unable to handle kernel paging request at fffffffffffffff8
On Mon, Nov 5, 2012 at 8:29 AM, Antonio Ospite osp...@studenti.unina.it wrote: On Mon, 29 Oct 2012 23:16:24 +0100 Antonio Ospite osp...@studenti.unina.it wrote: Hi, I am experiencing a bug with nouveau with linux-3.7-rc3 (and since rc1), my video adapter is the one integrated on the MSI M3N78-VM motherboard (hence x86_64): [...] [ 1943.858601] BUG: unable to handle kernel paging request at fff8 [ 1943.858669] IP: [a031a67a] nouveau_mm_head+0x30/0x127 [nouveau] [ 1943.858779] PGD 160d067 PUD 160e067 PMD 0 [ 1943.858803] Oops: [#1] SMP [..] [ 1943.860018] Call Trace: [ 1943.860019] [810fa13d] ? kmem_cache_alloc_trace+0xbf/0xcf [ 1943.860019] [81060f13] ? should_resched+0x5/0x23 [ 1943.860019] [a032a10a] ? nv50_fb_vram_new+0xc5/0x1f2 [nouveau] Ben, I cannot reproduce the crash with 3.7-rc4, I spotted commits a7dbf00 and 5cad16a which seem to be related to the problem I was having; would you mind elaborating a bit about what you think was causing the crash on my side? Maybe the chipset used on this motherboard doesn't support some feature? And how did you figured out from the logs? 5cad16acd25b16681a060d28d10eeacf98d07701 is the actual fix The chipset hasn't got Z compression support, and the oops once decoded pointed out the new code was trying to allocate Z tags from a NULL memory block. The old code use to allocate an empty memory block instead of NULL, and it got lost in the rewrite, Ben just fixed it to allow empty memory blocks again. 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/
[git pull] drm radeon + core fixes
Hi Linus, a single radeon typo fix for a regressions and two fixes for a regression in the open helper addres space stuff. Dave. The following changes since commit 3d70f8c617a436c7146ecb81df2265b4626dfe89: Linux 3.7-rc4 (2012-11-04 11:07:39 -0800) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes Alex Deucher (1): drm/radeon: fix typo in evergreen_mc_resume() Ilija Hadzic (2): drm: restore open_count if drm_setup fails drm: set dev_mapping before calling drm_open_helper drivers/gpu/drm/drm_fops.c | 44 --- drivers/gpu/drm/radeon/evergreen.c |2 +- 2 files changed, 31 insertions(+), 15 deletions(-) -- 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/
[PATCH] pci/runtime-pm: respect devices autosuspend timeout on config access
So I've been adding runtime pm to nouveau/radeon, and on X start it does a lot of pci accesses. Now because the pm on these devices is equivalent to D3cold, we have to resume them which involves a heavy latency due to POSTing the cards. The driver configures the autosuspend timeout to 5s for this reason, and I think the PCI layer config accesses should respect the autosuspend. Cc: Huang Ying ying.hu...@intel.com Cc: Bjorn Helgaas bhelg...@google.com Cc: Rafael J. Wysocki r...@sisk.pl Signed-off-by: Dave Airlie airl...@redhat.com --- drivers/pci/pci-sysfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c index 02d107b..12d3d52 100644 --- a/drivers/pci/pci-sysfs.c +++ b/drivers/pci/pci-sysfs.c @@ -487,7 +487,7 @@ pci_config_pm_runtime_put(struct pci_dev *pdev) struct device *dev = pdev-dev; struct device *parent = dev-parent; - pm_runtime_put(dev); + pm_runtime_put_autosuspend(dev); if (parent) pm_runtime_put_sync(parent); } -- 1.7.12.1 -- 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: scsi target, likely GPL violation
...and then turn around and submit it to Nick since he's the target subsystem maintainer? Nick is probably the one who wrote it! I'm happy to do that, but we should recognize something is seriously skewed when the person nominally in charge of the in-kernel code also has a vested interest in *not* seeing new features added, since it then competes better with his company's offering. RTS is trying to use an open core business model. This works fine for BSD-licensed code or code originally authored entirely by you, but their code (all of it even the new stuff) is a derivative work of the Linux kernel source code, and the GPL says they need to contribute it back. Andy, Accusing us of violating GPL is a serious legal claim. In fact, we are not violating GPL. In short, this is because we wrote the code you are referring to (the SCSI target core in our commercial RTS OS product), we have exclusive copyright ownership of it, and this code contains no GPL code from the community. GPL obligations only apply downstream to licensees, and not to the author of the code. Those who use the code under GPL are subject to its conditions; we are not. Just to clarify since I'm not a major GPL expert. Are you: a) distributing a Linux kernel b) with a module built against it to be linked into it, whether completely written in house or not? Then the module is under the GPL, if you think you are like nvidia or someone then think again, the corner case they live under is that they don't distribute a Linux kernel with their module *ever*, and they have a clear call for non-derived work status since its 90% the same code as in their Windows drivers. But if you distribute a kernel and a module in one place which I assume RTS OS does, then you are in dangerous territory and could be hit with cease and desist notices, which has happened to people shipping kernels and linked nvidia binary drivers before. 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: [GIT PULL] Linux KVM tool for v3.7-rc0
On Sun, Oct 21, 2012 at 4:14 AM, Borislav Petkov b...@alien8.de wrote: On Sat, Oct 20, 2012 at 06:04:36PM +1100, Stephen Rothwell wrote: So are there any compelling arguments from the proponents, or can I remove this from linux-next (and have it removed from the tip auto-latest branch)? FWIW, I gave this a run and I have to say, it works as advertized: I built it and ran it with the latest kernel and the thing simply boots the kernel. Even without a disk image - the simplest command is: $ ./lkvm run --kernel ../../arch/x86/boot/bzImage and it gets me a shell in the vm after a second. So the absolute advantage it gives kernel devs is that they can smoke-test whether their stuff boots in seconds. This is probably not helpful when enabling specific hw features but should be pretty helpful for generic arch stuff. Why couldn't this script just be a wrapper around qemu? I get the kvm developers developing features that isn't ideal, but for the quick boot a kernel tests, I don't see why a well maintained qemu wrapper isn't superior. I hate constructing qemu command lines, but a script in the kernel repo seems like a good idea. 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/
[git pull] drm fixes
Hi Linus, fixes for intel and nouveau mainly. intel: disable HSW by default, sdvo fixes, link train regression fix nouveau: acpi rom loading regression fix, with a few other fixes from the rework core: just other minor fixes and race fixes for ttm. Dave. The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556: Linux 3.7-rc2 (2012-10-20 12:11:32 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes Ben Skeggs (4): drm/nouveau/bios: fetch full 4KiB block to determine ACPI ROM image size drm/nv41/vm: don't init hw pciegart on boards with agp bridge drm/nouveau/fb: fix reporting of memory type on GF8+ IGPs drm/nouveau/clock: fix missing pll type/addr when matching default entry Chris Wilson (2): drm/i915: Add no-lvds quirk for Supermicro X7SPA-H drm/i915: Initialize obj-pages before use by i915_gem_object_do_bit17_swizzle() Daniel Vetter (2): Revert drm/i915: Try harder to complete DP training pattern 1 drm/i915: shut up spurious WARN in the gtt fault handler Dave Airlie (2): Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes Merge branch 'drm-nouveau-fixes' of git://git.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes Egbert Eich (4): DRM/i915: Don't delete DPLL Multiplier during DAC init. DRM/i915: Add QUIRK_INVERT_BRIGHTNESS for NCR machines. DRM/i915: Don't clone SDVO LVDS with analog. DRM/i915: Restore sdvo_flags after dtd-mode-dtd Roundrtrip. Marcin Slusarz (5): drm/nouveau: handle same-fb page flips drm/nouveau: fix nouveau_mm/nouveau_mm_node leak drm/nouveau: warn when trying to free mm which is still in use drm/nouveau: validate vbios size drm/debugfs: remove redundant info from gem_names Martin Peres (1): drm/nouveau/bios: improve error handling when reading the vbios from ACPI Rodrigo Vivi (1): drm/i915: Insert i915_preliminary_hw_support variable. Thierry Reding (3): drm: fb: cma: Fix typo in debug message drm: fb: cma: Fail gracefully on allocation failure drm: platform: Don't initialize driver-private data Thomas Hellstrom (2): drm/ttm: Fix a theoretical race drm/ttm: Fix a theoretical race in ttm_bo_cleanup_refs() drivers/gpu/drm/drm_fb_cma_helper.c |4 +- drivers/gpu/drm/drm_info.c |2 - drivers/gpu/drm/drm_platform.c |1 - drivers/gpu/drm/i915/i915_drv.c | 13 + drivers/gpu/drm/i915/i915_drv.h |1 + drivers/gpu/drm/i915/i915_gem.c |7 +++- drivers/gpu/drm/i915/intel_crt.c| 15 +-- drivers/gpu/drm/i915/intel_display.c| 32 +++ drivers/gpu/drm/i915/intel_dp.c | 15 +++--- drivers/gpu/drm/i915/intel_lvds.c |8 + drivers/gpu/drm/i915/intel_sdvo.c | 14 +++--- drivers/gpu/drm/nouveau/core/core/gpuobj.c |5 +++ drivers/gpu/drm/nouveau/core/core/mm.c |2 +- drivers/gpu/drm/nouveau/core/subdev/bios/base.c | 30 - drivers/gpu/drm/nouveau/core/subdev/bios/pll.c | 10 +++ drivers/gpu/drm/nouveau/core/subdev/fb/nv50.c |1 + drivers/gpu/drm/nouveau/core/subdev/vm/nv41.c |3 +- drivers/gpu/drm/nouveau/core/subdev/vm/nv44.c |3 +- drivers/gpu/drm/nouveau/nouveau_display.c | 14 ++--- drivers/gpu/drm/shmobile/shmob_drm_drv.c| 12 +++- drivers/gpu/drm/ttm/ttm_bo.c| 24 ++--- 21 files changed, 148 insertions(+), 68 deletions(-) -- 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: drm i915 hangs on heavy io load
(please Cc) I am running 3.7-rc2 and got recently hit a few times (under rc1, too) by hanging drm i915 while doing large io operations. Does booting with i915.i915_enable_rc6=0 help? (Daniel, looks like an ironlake). 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/
[git pull] drm nouveau fixes
Hi Linus, just a bunch of nouveau fixes, Ben wants to get some alternate versions into stable. Dave. The following changes since commit 1f31c69dac71bebc0f00bc8534a6345782045501: Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-next (2012-10-07 21:13:54 +1000) are available in the git repository at: git://people.freedesktop.org/~airlied/linux.git drm-fixes for you to fetch changes up to ceb736c395058699dc82e5efdb2a9279a5b29451: Merge branch 'drm-nouveau-fixes' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next (2012-10-09 14:48:46 +1000) Ben Skeggs (1): drm/nouveau/bios: fix shadowing of ACPI ROMs larger than 64KiB Dave Airlie (1): Merge branch 'drm-nouveau-fixes' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next Marcin Slusarz (2): drm/nouveau: remove unused _nouveau_parent_ctor drm/nv50/clk: wire up pll_calc hook Martin Peres (2): drm/nouveau/fan: fix a typo in PWM's input clock calculation drm/nouveau/timer: bump ptimer's alarm delay from u32 to u64 drivers/gpu/drm/nouveau/core/core/parent.c | 17 drivers/gpu/drm/nouveau/core/include/core/parent.h |3 --- .../gpu/drm/nouveau/core/include/subdev/timer.h|2 +- drivers/gpu/drm/nouveau/core/subdev/bios/base.c| 21 ++-- drivers/gpu/drm/nouveau/core/subdev/clock/nv50.c |1 + drivers/gpu/drm/nouveau/core/subdev/therm/nv50.c |2 +- drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c |2 +- 7 files changed, 14 insertions(+), 34 deletions(-) -- 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: [Linaro-mm-sig] [PATCH] dma-buf: Use EXPORT_SYMBOL
Unlikely as most of the code I've written belongs to Intel or Red Hat. I also have better things to do with life than sue Nvidia and start an all out copyright and patent war in Linuxspace. I forgot to ask, but after your petty G+ trolling, if most of the code belings to Intel or Red Hat, why do we need to listen to *your* lawyers advice? It seems like you aren't a major rights holder but a troll. 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/
[git pull] drm radeon fixes.
Hi Linus, Just radeon fixes in this one, some new PCI IDs, ATPX regression fix, async VM regression fixes some module options fixes. Dave. The following changes since commit b8e902f24fdd16c4373ddc37a4e150c4afe9c6db: drm/ttm: Fix a theoretical race in ttm_bo_cleanup_refs() (2012-10-23 10:15:21 +1000) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes Alex Deucher (6): drm/radeon: add some new SI PCI ids drm/radeon: fix sparse warning drm/radeon: give each backlight a unique id drm/radeon: add error output if VM CS fails on cayman drm/radeon: fix ATPX function documentation drm/radeon: fix ATPX regression in acpi rework Christian König (9): drm/radeon: fix PFP sync in vm_flush drm/radeon: fix cayman_vm_set_page v2 drm/radeon: fix si_set_page v2 drm/radeon: remove set_page check from VM code drm/radeon: fix header size estimation in VM code drm/radeon: fix and simplify pot argument checks v3 drm/radeon: use vzalloc for gart pages drm/radeon: move size limits to gem_object_create. drm/radeon: move the retry to gem_object_create Dave Airlie (1): Merge branch 'drm-fixes-3.7' of git://people.freedesktop.org/~agd5f/linux into drm-fixes drivers/gpu/drm/radeon/atombios_encoders.c |5 ++- drivers/gpu/drm/radeon/evergreen_cs.c |1 + drivers/gpu/drm/radeon/ni.c | 45 ++--- drivers/gpu/drm/radeon/nid.h|1 + drivers/gpu/drm/radeon/radeon_atpx_handler.c|6 +- drivers/gpu/drm/radeon/radeon_device.c | 60 +-- drivers/gpu/drm/radeon/radeon_gart.c| 22 - drivers/gpu/drm/radeon/radeon_gem.c | 18 ++- drivers/gpu/drm/radeon/radeon_legacy_encoders.c |5 ++- drivers/gpu/drm/radeon/radeon_object.c | 19 --- drivers/gpu/drm/radeon/si.c | 47 +++--- include/drm/drm_pciids.h|3 + 12 files changed, 122 insertions(+), 110 deletions(-)
[git pull] drm radeon + nouveau fixes
Hi Linus, just radeon and nouveau, mostly regressions fixers, and a couple of radeon register checker fixes. Dave. The following changes since commit 695ddeb457584a602f2ba117d08ce37cf6ec1589: drm/radeon: fix typo in evergreen_mc_resume() (2012-11-07 10:53:49 +1000) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to 4a48ed2334b7ae61dd11bb114fa35bd4ebdc1ca0: Merge branch 'drm-nouveau-fixes' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes (2012-11-09 14:57:02 +1000) Alex Deucher (3): drm/radeon/dce3: switch back to old pll allocation order for discrete drm/radeon/cayman: add some missing regs to the VM reg checker drm/radeon/si: add some missing regs to the VM reg checker Dave Airlie (2): Merge branch 'drm-fixes-3.7' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge branch 'drm-nouveau-fixes' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes Kelly Doran (1): drm/nvc0/disp: fix regression in vblank semaphore release Maarten Lankhorst (1): drm/nouveau: fix acpi edid retrieval Marcin Slusarz (3): drm/nv41/vm: fix typo in type name drm/nv40/graph: fix typo in type names drm/nv40/mpeg: fix context handling drivers/gpu/drm/nouveau/core/engine/disp/nv50.c | 20 + drivers/gpu/drm/nouveau/core/engine/graph/nv40.c | 4 +- drivers/gpu/drm/nouveau/core/engine/mpeg/nv40.c | 2 +- drivers/gpu/drm/nouveau/core/subdev/vm/nv41.c| 2 +- drivers/gpu/drm/nouveau/nouveau_connector.c | 2 +- drivers/gpu/drm/radeon/atombios_crtc.c | 54 ++-- drivers/gpu/drm/radeon/evergreen_cs.c| 3 ++ drivers/gpu/drm/radeon/evergreend.h | 4 ++ drivers/gpu/drm/radeon/si.c | 1 + drivers/gpu/drm/radeon/sid.h | 1 + 10 files changed, 57 insertions(+), 36 deletions(-) -- 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/
[git pull] drm vmwgfx
Hi Linus, dropped the ball on a vmware patch, so two more fixes for vmwgfx are here, one for hibernate issue, one for a BUG trigger. Dave. The following changes since commit 4a48ed2334b7ae61dd11bb114fa35bd4ebdc1ca0: Merge branch 'drm-nouveau-fixes' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes (2012-11-09 14:57:02 +1000) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to afcc87aa6a233e52df73552dc1dc9ae3881b7cc8: drm/vmwgfx: Fix a case where the code would BUG when trying to pin GMR memory (2012-11-09 20:49:06 +1000) Thomas Hellstrom (2): drm/vmwgfx: Fix hibernation device reset drm/vmwgfx: Fix a case where the code would BUG when trying to pin GMR memory drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 5 + 2 files changed, 6 insertions(+), 1 deletion(-) -- 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: scsi target, likely GPL violation
On Mon, Nov 12, 2012 at 8:41 AM, Julian Calaby julian.cal...@gmail.com wrote: Hi Lawrence, On Mon, Nov 12, 2012 at 9:13 AM, Lawrence Rosen lro...@rosenlaw.com wrote: Alan Cox wrote: So either your work is truely not derivative of the kernel (which I find wildly improbable) or you have a problem and since you are aware of the complaints publically I guess probably a triple damages sized problem. But that's one for your lawyers and whatever opinion they have on the subject. Hi Alan and others, I've been advising Rising Tide Systems (RTS) in this matter. Please let me reassure you that RTS is acting on advice of counsel. It's nice to hear from legal counsel on this matter. I don't think that the *usage* of the kernel APIs is the biggest issue here. There are many examples where proprietary code uses these APIs and is not violating the GPL. As I see it, one of the main concerns is because the proprietary and in-kernel target systems are, from what I understand, quite similar, there is the possibility that GPL licensed contributions to the in-kernel target code may have leaked into to the proprietary code. That said, proving this is a very difficult problem, but the question must still be asked: Can Rising Tide Systems assure us that there is no GPL licensed code within their proprietary target code? Its a bit of both actually. The problem is if you design a kernel subsystem specifically for the Linux kernel, even if you use the internal APIs, you are most likely creating a derived work of the Linux kernel. questions that would need to be asked: Can the scsi target code work completely separate from a Linux kernel? Does it work with another operating system? was it designed for that operating system? The whole in-kernel version under the GPL isn't the problem here and has nothing to do with the violation. Its the one they distribute separately with their RTS OS kernel, and if they distribute it in one combined work, then a GPL violation is possibly indicated. The reasons for non-derived work status that have been suggested (but not accepted by all the community): a) AFS, a file system clearly not developed for Linux, where it being a derived work of something that came after it would be a bit crazy, b) binary GPU drivers, built from the same source base on their Windows platform, and the code existed on Windows before Linux, arguing this driver is a derived work is difficult as well. Also nvidia specifically don't distribute this driver linked against the kernel, and distros who have done this in the past have been on the end of cease-and-desist letters. So really this is purely a derived work issue, whether they release a trailing edge version of their code afterwards under the GPL isn't significant, other than a this might keep the community off our back. (Yes the secondary issue of people who contributed code and cleanups back to that code base and if they integrated it back into their internal code base, is a problem, but I don't believe its the primary issue). 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/
[git pull] drm fixes
Hi Linus, fixes for i915, nouveau and radeon i915: haswell stability, modeset rework fallout, ums fix nouveau: misc fixes from code rework radeon: pll rework fixes, more 2 level PTE cleanups. core: warning fixes on 32-bit. Dave. The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37: Linux 3.7-rc1 (2012-10-14 14:41:04 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux.git drm-fixes for you to fetch changes up to 8a00b6af4cc547725f231c8367ddc7cb56b2cf76: nouveau: fix warning on 32-bit build. (2012-10-16 16:40:53 +1000) Alex Deucher (5): drm/radeon: fix compilation with backlight disabled drm/radeon: allocate PPLLs from low to high drm/radeon: update comments to clarify VM setup (v2) drm/radeon/cayman: set VM max pfn at MC init drm/radeon: check if pcie gen 2 is already enabled (v2) Ben Skeggs (1): drm/nouveau/bios: fix typo in error message Chris Wilson (2): drm/i915: Disallow preallocation of requests drm/i915: fixup i915_gem_object_get_page inline helper Christian König (3): drm/radeon: allocate page tables on demand v4 drm/radeon: don't add the IB pool to all VMs v2 drm/radeon: separate pt alloc from lru add Daniel Vetter (5): drm/i915: paper over a pipe-enable vs pageflip race drm/i915: disable wc gtt pte mappings on gen2 drm/i915: rip out the pipe A quirk for i855gm drm/i915: fixup the plane-pipe fixup code drm/i915/dvo-ch7xxx: fix get_hw_state Dave Airlie (5): Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes Merge branch 'drm-fixes-3.7' of git://people.freedesktop.org/~agd5f/linux into drm-fixes drm: fix warning on 32-bit. Merge branch 'drm-nouveau-fixes' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes nouveau: fix warning on 32-bit build. Egbert Eich (1): drm/radeon: Don't destroy I2C Bus Rec in radeon_ext_tmds_enc_destroy(). Jani Nikula (1): drm/i915: fix non-DP-D eDP backlight cleanup and module reload Kenneth Graunke (1): drm/i915: Set guardband clipping workaround bit in the right register. Luca Tettamanti (1): drm/radeon: use %zu for formatting size_t Marcin Slusarz (1): drm/nv50/fb: fix double free of vram mm Martin Peres (3): drm/nouveau/hwmon: fix the initialization condition drm/nouveau/pm: fix a typo related to the move to the therm subdev drm/nouveau/pm: do not stop reclocking if failing to set the fan speed Max Filippov (1): drm/nouveau: only call ttm_agp_tt_create when __OS_HAS_AGP Randy Dunlap (1): drm: radeon: fix printk format warning Rodrigo Vivi (1): drm/i915: HSW CRW stability magic Thomas Friebel (1): drm/radeon: fix spelling typos in debugging output Willy Tarreau (1): drm/i915: remove useless BUG_ON which caused a regression in 3.5. drivers/char/agp/intel-gtt.c|2 +- drivers/gpu/drm/drm_info.c |2 +- drivers/gpu/drm/i915/dvo_ch7xxx.c |6 +- drivers/gpu/drm/i915/i915_drv.h |9 +- drivers/gpu/drm/i915/i915_gem.c | 19 +- drivers/gpu/drm/i915/i915_reg.h |2 +- drivers/gpu/drm/i915/intel_display.c| 47 ++- drivers/gpu/drm/i915/intel_dp.c |3 +- drivers/gpu/drm/i915/intel_overlay.c| 72 + drivers/gpu/drm/i915/intel_pm.c |4 +- drivers/gpu/drm/nouveau/core/subdev/bios/dcb.c |2 +- drivers/gpu/drm/nouveau/core/subdev/fb/nv50.c |1 - drivers/gpu/drm/nouveau/core/subdev/therm/fan.c |2 +- drivers/gpu/drm/nouveau/nouveau_bo.c|2 + drivers/gpu/drm/nouveau/nouveau_pm.c|6 +- drivers/gpu/drm/radeon/atombios_crtc.c |8 +- drivers/gpu/drm/radeon/evergreen.c |7 +- drivers/gpu/drm/radeon/ni.c | 12 +- drivers/gpu/drm/radeon/r600.c |6 + drivers/gpu/drm/radeon/radeon.h | 14 +- drivers/gpu/drm/radeon/radeon_acpi.c|6 +- drivers/gpu/drm/radeon/radeon_atpx_handler.c|2 +- drivers/gpu/drm/radeon/radeon_cs.c |1 + drivers/gpu/drm/radeon/radeon_device.c |4 + drivers/gpu/drm/radeon/radeon_gart.c| 374 --- drivers/gpu/drm/radeon/radeon_kms.c | 22 +- drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 48 ++- drivers/gpu/drm/radeon/radeon_ring.c|2 +- drivers/gpu/drm/radeon/si.c |7 +- 29 files changed, 443 insertions(+), 249 deletions(-)
Re: X-freeze after clflush changes [Was: 2.6.23-rc6-mm1]
But now I'm talking about another issue -- a regression since rc4-mm1, where X server is unable to bind agp memory (those x logs above). The clflush issue has solved andi in http://lkml.org/lkml/2007/9/19/334 recently Tried that, my laptop still bricks the instant X starts up and the NVidia driver tries to initialize. Not even sysrq-foo works. Time to power-cycle. I'd expect the binary to be doing something stupid with it's flushing and relying on the kernel to do something it no longer does.. so this is most likely a case of not fixable.. Dave. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] video gfx: merge kconfig menus
On 9/25/07, Randy Dunlap [EMAIL PROTECTED] wrote: Is there some reason that we don't put all video gfx config in one place? Is the split just historical, based on subdirectory locations, or is there a bigger reason for it? [to apply cleanly, this patch depends on a patch that was sent to linux-fbdev-devel, which is subscribers-only, so I didn't cc: lkml on it: http://marc.info/?l=linux-fbdev-develm=119070044232621w=2] --- From: Randy Dunlap [EMAIL PROTECTED] Move AGP and DRM menus into the video graphics support menu. They use 'menuconfig' so that they can all be disabled with one selection. Make the console menu use 'menuconfig' so that it can all be disabled with one selection. Make the frame buffer menu use 'menuconfig' so that it can all be disabled with one selection. Signed-off-by: Randy Dunlap [EMAIL PROTECTED] Fine by me.. some day we might move the directories but this is a good start.. Acked-by: Dave Airlie [EMAIL PROTECTED] Dave. --- drivers/char/Kconfig |4 drivers/char/agp/Kconfig |2 +- drivers/char/drm/Kconfig |2 +- drivers/video/Kconfig| 11 +++ 4 files changed, 9 insertions(+), 10 deletions(-) --- linux-2.6.23-rc8.orig/drivers/char/Kconfig +++ linux-2.6.23-rc8/drivers/char/Kconfig @@ -896,10 +896,6 @@ config GPIO_TB0219 depends on TANBAC_TB022X select GPIO_VR41XX -source drivers/char/agp/Kconfig - -source drivers/char/drm/Kconfig - source drivers/char/pcmcia/Kconfig config MWAVE --- linux-2.6.23-rc8.orig/drivers/video/Kconfig +++ linux-2.6.23-rc8/drivers/video/Kconfig @@ -5,8 +5,9 @@ menu Graphics support depends on HAS_IOMEM -source drivers/video/backlight/Kconfig -source drivers/video/display/Kconfig +source drivers/char/agp/Kconfig + +source drivers/char/drm/Kconfig config VGASTATE tristate @@ -19,7 +20,7 @@ config VIDEO_OUTPUT_CONTROL This framework adds support for low-level control of the video output switch. -config FB +menuconfig FB tristate Support for frame buffer devices ---help--- The frame buffer device provides an abstraction for the graphics @@ -1860,6 +1861,9 @@ if ARCH_OMAP source drivers/video/omap/Kconfig endif +source drivers/video/backlight/Kconfig +source drivers/video/display/Kconfig + if VT source drivers/video/console/Kconfig endif @@ -1869,4 +1873,3 @@ if FB || SGI_NEWPORT_CONSOLE endif endmenu - --- linux-2.6.23-rc8.orig/drivers/char/agp/Kconfig +++ linux-2.6.23-rc8/drivers/char/agp/Kconfig @@ -1,4 +1,4 @@ -config AGP +menuconfig AGP tristate /dev/agpgart (AGP Support) depends on ALPHA || IA64 || PARISC || PPC || X86 depends on PCI --- linux-2.6.23-rc8.orig/drivers/char/drm/Kconfig +++ linux-2.6.23-rc8/drivers/char/drm/Kconfig @@ -4,7 +4,7 @@ # This driver provides support for the # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher. # -config DRM +menuconfig DRM tristate Direct Rendering Manager (XFree86 4.1.0 and higher DRI support) depends on (AGP || AGP=n) PCI !EMULATED_CMPXCHG help - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] i915: make vbl interrupts work properly on i965g/gm
Hi Linus, The attached patch is to fix a bug reported on 965gm chipsets (lots of new laptops), I think distros will all have to patch this in to fix it, so can we get it into the 2.6.23 final? (Otherwise I'll wait until stable..) Dave.From 14e53712e5e2ccc72dac1131de78e590e9a9d451 Mon Sep 17 00:00:00 2001 From: Dave Airlie [EMAIL PROTECTED] Date: Fri, 28 Sep 2007 11:46:28 +1000 Subject: [PATCH] i915: make vbl interrupts work properly on i965g/gm hw. This code is ported from the DRM git tree and allows the vblank interrupts to function on the i965 hw. It also requires a change in Mesa's 965 driver to actually use them. Signed-off-by: Dave Airlie [EMAIL PROTECTED] --- drivers/char/drm/i915_drv.h |6 ++ drivers/char/drm/i915_irq.c | 12 2 files changed, 18 insertions(+), 0 deletions(-) diff --git a/drivers/char/drm/i915_drv.h b/drivers/char/drm/i915_drv.h index 737088b..28b9873 100644 --- a/drivers/char/drm/i915_drv.h +++ b/drivers/char/drm/i915_drv.h @@ -210,6 +210,12 @@ extern int i915_wait_ring(struct drm_device * dev, int n, const char *caller); #define I915REG_INT_MASK_R 0x020a8 #define I915REG_INT_ENABLE_R 0x020a0 +#define I915REG_PIPEASTAT 0x70024 +#define I915REG_PIPEBSTAT 0x71024 + +#define I915_VBLANK_INTERRUPT_ENABLE (1UL17) +#define I915_VBLANK_CLEAR (1UL1) + #define SRX_INDEX 0x3c4 #define SRX_DATA 0x3c5 #define SR01 1 diff --git a/drivers/char/drm/i915_irq.c b/drivers/char/drm/i915_irq.c index 4b4b2ce..bb8e9e9 100644 --- a/drivers/char/drm/i915_irq.c +++ b/drivers/char/drm/i915_irq.c @@ -214,6 +214,10 @@ irqreturn_t i915_driver_irq_handler(DRM_IRQ_ARGS) struct drm_device *dev = (struct drm_device *) arg; drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev-dev_private; u16 temp; + u32 pipea_stats, pipeb_stats; + + pipea_stats = I915_READ(I915REG_PIPEASTAT); + pipeb_stats = I915_READ(I915REG_PIPEBSTAT); temp = I915_READ16(I915REG_INT_IDENTITY_R); @@ -225,6 +229,8 @@ irqreturn_t i915_driver_irq_handler(DRM_IRQ_ARGS) return IRQ_NONE; I915_WRITE16(I915REG_INT_IDENTITY_R, temp); + (void) I915_READ16(I915REG_INT_IDENTITY_R); + DRM_READMEMORYBARRIER(); dev_priv-sarea_priv-last_dispatch = READ_BREADCRUMB(dev_priv); @@ -252,6 +258,12 @@ irqreturn_t i915_driver_irq_handler(DRM_IRQ_ARGS) if (dev_priv-swaps_pending 0) drm_locked_tasklet(dev, i915_vblank_tasklet); + I915_WRITE(I915REG_PIPEASTAT, + pipea_stats|I915_VBLANK_INTERRUPT_ENABLE| + I915_VBLANK_CLEAR); + I915_WRITE(I915REG_PIPEBSTAT, + pipeb_stats|I915_VBLANK_INTERRUPT_ENABLE| + I915_VBLANK_CLEAR); } return IRQ_HANDLED; -- 1.5.3.1
Re: [PATCH] [AGPGART] intel_agp: fix stolen mem range on G33
Subject: [PATCH] [AGPGART] intel_agp: fix stolen mem range on G33
G33 GTT stolen memory is below graphics data
stolen memory and be seperate, so don't subtract
it in stolen mem counting.
Signed-off-by: Zhenyu Wang [EMAIL PROTECTED]
Andrew I meant to upstream these for 2.6.23 but travelling is still in
progress, so if you could send them to Linus...
Acked-by: Dave Airlie [EMAIL PROTECTED]
---
drivers/char/agp/intel-agp.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/char/agp/intel-agp.c b/drivers/char/agp/intel-agp.c
index 2c9ca2c..581f922 100644
--- a/drivers/char/agp/intel-agp.c
+++ b/drivers/char/agp/intel-agp.c
@@ -506,6 +506,11 @@ static void intel_i830_init_gtt_entries(void)
break;
}
} else {
+ /* G33's GTT stolen memory is separate from gfx data
+* stolen memory.
+*/
+ if (IS_G33)
+ size = 0;
switch (gmch_ctrl I830_GMCH_GMS_MASK) {
case I855_GMCH_GMS_STOLEN_1M:
gtt_entries = MB(1) - KB(size);
When looking at a fix I need to work out whether it might be needed in
2.6.23. But your description of this patch didn't describe the problem
which it fixes in a way which allows me to decide this.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [AGPGART] intel_agp: fix GTT map size on G33
Subject: [PATCH] [AGPGART] intel_agp: fix GTT map size on G33 G33 has 1MB GTT table range. Fix GTT mapping in case like 512MB aperture size. Signed-off-by: Zhenyu Wang [EMAIL PROTECTED] Acked-by: Dave Airlie [EMAIL PROTECTED] Ditto. What happens if this patch isn't in 2.6.23? And is it applicable to and needed in 2.6.22? It's support for new hardware enablement, so maybe stable requires it, but I'm not sure how widespread this hw is yet.. Dave. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: X freezes kernel during exit [Re: 2.6.23-rc3-mm1]
What other info needed? I'm seeing this on my 965gm chipset with Andi's clflush patches on x86 32-bit, it looks like an interaction with the agp code which does a big bunch of change page attr to allocate the AGP aperture backed memory.. I think the code might have worked in a previous iteration on my 64-bit 965G machine at home but I'm on the road and won't be back anytime soon.. I'll see what I can figure out from my laptop... Dave. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem: screen partially garbled in i830m (regression)
I sent this mail to David Airlie two weeks ago but I haven't gotten a reply so far, that's why I'm posting to LKML this time. Short summary: 874808c6dd429f7431b906a32c7f78a68e7636af broke intel_agp.ko for me, I'm getting a garbled screen. I'm travelling, and I'll try and get Zhenyu to take a look at what he changed.. but he is also travelling... We probably need two defines.. Dave. Hello David, with recent kernels, there seems to be a problem with agpgart for my i830m chipset. The upper part of the screen is garbled, e.g. I can make out parts of the image that is to be displayed, but it's chopped and repeated. The box with which I'm having this problem is a not a regular PC, but a x86-based set top box called S100. It's got a fanless Celeron 733 MHz and 128M RAM and it's somewhat popular due to its cheapness. Just makes a nice living-room computer :) I'll attach the output of lspci -vvv. FYI, I'm not using the official X.org driver but its IEGD counterpart. Unfortunately, the S100 comes with a TV-out encoder chip that's only supported by their closed source driver. Since the kernel is not tainted by that, it shouldn't be a problem - similar problems also occur with X.org drivers. With working kernels, I'd get the following messages in dmesg: --snip-- [ 40.188375] agpgart: Detected an Intel 830M Chipset. [ 40.188741] agpgart: Detected 380K stolen memory. [ 40.199908] agpgart: AGP aperture is 128M @ 0xf000 --snap-- A broken kernel will result in the following messages: --snip-- Jul 25 16:29:42 mythbuntu-alpha2 kernel: [ 44.941473] Linux agpgart interface v0.102 (c) Dave Jones Jul 25 16:29:42 mythbuntu-alpha2 kernel: [ 44.957021] agpgart: Detected an Intel 830M Chipset. Jul 25 16:29:42 mythbuntu-alpha2 kernel: [ 44.957605] agpgart: No pre-allocated video memory detected. Jul 25 16:29:42 mythbuntu-alpha2 kernel: [ 44.968696] agpgart: AGP aperture is 128M @ 0xf000 --snap-- I used git-bisect to narrow down change that introduced this problem and came up with this: --snip-- 874808c6dd429f7431b906a32c7f78a68e7636af is first bad commit commit 874808c6dd429f7431b906a32c7f78a68e7636af Author: Wang Zhenyu [EMAIL PROTECTED] Date: Wed Jun 6 11:16:25 2007 +0800 [AGPGART] intel_agp: Add support for G33, Q33 and Q35 chipsets This patch adds pci ids for G33, Q33 and Q35 chips, and update with new GTT size and stolen mem size detect method on these chips. Signed-off-by: Wang Zhenyu [EMAIL PROTECTED] Signed-off-by: Dave Jones [EMAIL PROTECTED] :04 04 39b18b6860f139cb28a80020dc9347314753e16d da24fb8672087cdfe6509cd1d4cb189534f887d6 M drivers --snap-- Particulary, there's a change to agp.h: --snip-- -#define I830_GMCH_GMS_MASK 0x70 +#define I830_GMCH_GMS_MASK 0xF0 --snap-- I reverted this change in my git tree and I'm now running 2.6.23-rc3-gb377fd39-dirty without any distortion at all. Do you think this can be fixed? I'll be glad to provide more Information. Thank you for your time! Regards, Michael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem: screen partially garbled in i830m (regression)
reply so far, that's why I'm posting to LKML this time. Short summary:
874808c6dd429f7431b906a32c7f78a68e7636af broke intel_agp.ko for me, I'm
getting a garbled screen.
Can you try the attached patch?
Dave.From 56e5b226de1406812bbe739caad0d2a93f8c596d Mon Sep 17 00:00:00 2001
From: Dave Airlie [EMAIL PROTECTED]
Date: Thu, 13 Sep 2007 00:08:01 +1000
Subject: [PATCH] intel-agp: Fix i830 mask variable that changed with G33 support
The mask on i830 should be 0x70 always, later chips 0xF0 should be okay.
Signed-off-by: Dave Airlie [EMAIL PROTECTED]
---
drivers/char/agp/agp.h |3 ++-
drivers/char/agp/intel-agp.c |2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/char/agp/agp.h b/drivers/char/agp/agp.h
index 35ab1a9..8955e7f 100644
--- a/drivers/char/agp/agp.h
+++ b/drivers/char/agp/agp.h
@@ -176,7 +176,7 @@ struct agp_bridge_data {
#define I830_GMCH_MEM_MASK 0x1
#define I830_GMCH_MEM_64M 0x1
#define I830_GMCH_MEM_128M 0
-#define I830_GMCH_GMS_MASK 0xF0
+#define I830_GMCH_GMS_MASK 0x70
#define I830_GMCH_GMS_DISABLED 0x00
#define I830_GMCH_GMS_LOCAL 0x10
#define I830_GMCH_GMS_STOLEN_512 0x20
@@ -190,6 +190,7 @@ struct agp_bridge_data {
#define INTEL_I830_ERRSTS 0x92
/* Intel 855GM/852GM registers */
+#define I855_GMCH_GMS_MASK 0xF0
#define I855_GMCH_GMS_STOLEN_0M 0x0
#define I855_GMCH_GMS_STOLEN_1M (0x1 4)
#define I855_GMCH_GMS_STOLEN_4M (0x2 4)
diff --git a/drivers/char/agp/intel-agp.c b/drivers/char/agp/intel-agp.c
index 2c9ca2c..c15f5d2 100644
--- a/drivers/char/agp/intel-agp.c
+++ b/drivers/char/agp/intel-agp.c
@@ -506,7 +506,7 @@ static void intel_i830_init_gtt_entries(void)
break;
}
} else {
- switch (gmch_ctrl I830_GMCH_GMS_MASK) {
+ switch (gmch_ctrl I855_GMCH_GMS_MASK) {
case I855_GMCH_GMS_STOLEN_1M:
gtt_entries = MB(1) - KB(size);
break;
--
1.5.2.5
Re: 2.6.23-rc1 regression: mm: fix fault vs invalidate race for linear mappings
Is this with a binary-only module? We saw an issue with that in SLES9 where the module is returning a locked page from its nopage handler when it isn't really supposed to. It might be fixed in latest drivers, have you tried them? Doesn't sound like it he mentions radeon drm module which is open... Dave. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] agp: don't lock pages
On Thu, Jul 26, 2007 at 07:26:53AM +1000, Benjamin Herrenschmidt wrote: On Wed, 2007-07-25 at 13:19 +0200, Nick Piggin wrote: Hi, Does this patch solve the X problem? Does anyone see anything wrong with it or know why agp was locking the pages? We need to do a little bit of auditing here, but I suspect it will turn out all right. I think the reason it locked them in the first place was to avoid AGP pages mapped into process space from being swapped out. I think that should be taken care of by appropriate vma flags nowadays, but we need to double check. It also might have been a way around dodgy refcounting at one point but I think we got that right nowadays (I remember fixing issues in that area when we removed PageReserved from those pages back then). Yeah I had a bit of a look around, and it seems OK (but would appreciate an ack from someone who knows the code). These pages will never get seen by page reclaim, so we're OK there. There is a get_page before the SetPageLocked and a put_page right before the unlock_page, so refcounting should not be broken if it wasn't already: note that the lock_page doesn't pin a reference on a page in general -- we can use it as such for pagecache (although it isn't very clean), because the lock pins the page in pagecache and the pagecache holds a ref. Anyway, if Dave or David can take a look, that would be appreciated. We'll need this for 2.6.23. I talked with Ben earlier and I can't see anything inherently wrong with removing the lock_page, I assume it was put there to stop things getting swapped but if the get/put does that then I'd be happy to remove it. I'm just a bit confused how this didn't get picked up in -mm at all. Dave. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] AGP fixes for 2.6.23-rc1
On Fri, 27 Jul 2007, Dave Airlie wrote: Hi Linus, Please pull the 'agp-patches' branch from git://master.kernel.org/pub/scm/linux/kernel/git/airlied/agp-2.6.git agp-patches and of course I find the old version of my script.. that should be ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/agp-2.6.git agp-patches Dave. It contains one very important fix from Nick for AGP hangs with the nopage/pfn/flush stuff.. it also contains some minor docs changes and one coverity fix. Dave. Documentation/kernel-parameters.txt |7 +++ drivers/char/agp/Kconfig|2 +- drivers/char/agp/ati-agp.c |9 ++--- drivers/char/agp/generic.c |2 -- drivers/char/agp/intel-agp.c| 19 --- drivers/char/agp/sgi-agp.c |1 - 6 files changed, 22 insertions(+), 18 deletions(-) commit f191f144079b0083c6fa7d01a4acbd7263fb5032 Author: Alan Hourihane [EMAIL PROTECTED] Date: Fri Jul 27 10:56:43 2007 +1000 agp: AMD AGP is used on UP1100 UP1500 alpha boxen Signed-off-by: Dave Airlie [EMAIL PROTECTED] commit dde4787642ee3cb85aef80bdade04b6f8ddc3df8 Author: Zhenyu Wang [EMAIL PROTECTED] Date: Thu Jul 26 09:18:09 2007 +0800 intel_agp: really fix 945/965GME Fix some missing places to check with device id info, which should probe the device gart correctly. Signed-off-by: Wang Zhenyu [EMAIL PROTECTED] Signed-off-by: Dave Airlie [EMAIL PROTECTED] commit a51b34593f691a0837d752a1394dcee19483c607 Author: Nick Piggin [EMAIL PROTECTED] Date: Wed Jul 25 13:19:22 2007 +0200 agp: don't lock pages AGP should not need to lock pages. They are not protecting any race because there is no lock_page calls, only SetPageLocked. This is causing hangs with d00806b183152af6d24f46f0c33f14162ca1262a. Signed-off-by: Nick Piggin [EMAIL PROTECTED] Signed-off-by: Dave Airlie [EMAIL PROTECTED] commit c99c108ac362f5cc37f79fad7e9897bd9d033bcc Author: Chuck Ebbert [EMAIL PROTECTED] Date: Fri Jul 27 10:46:20 2007 +1000 AGP: document boot options Add documentation for AGP boot options. Signed-off-by: Chuck Ebbert [EMAIL PROTECTED] Signed-off-by: Dave Airlie [EMAIL PROTECTED] commit 190644e180794208bc638179f4d5940fe419bf9c Author: Jesper Juhl [EMAIL PROTECTED] Date: Sat Jul 21 17:39:11 2007 +0200 Fix use after free / double free bug in ati_create_gatt_pages / ati_free_gatt_pages Hi, Coverity spotted a use after free bug in drivers/char/agp/ati-agp.c::ati_create_gatt_pages(). The same one that was in drivers/char/agp/amd-k7-agp.c::amd_create_gatt_pages() The problem is this: If entry = kzalloc(sizeof(struct ati_page_map), GFP_KERNEL); fails, then there's a loop in the function to free all entries allocated so far and break out of the allocation loop. That in itself is pretty sane, but then the (now freed) 'tables' is assigned to ati_generic_private.gatt_pages and 'retval' is set to -ENOMEM which causes ati_free_gatt_pages(); to be called at the end of the function. The problem with this is that ati_free_gatt_pages() will then loop 'ati_generic_private.num_tables' times and try to free each entry in tables[] - this is bad since tables has already been freed and furthermore it will call kfree(tables) at the end - a double free. This patch removes the freeing loop in ati_create_gatt_pages() and instead relies entirely on the call to ati_free_gatt_pages() to free everything we allocated in case of an error. It also sets ati_generic_private.num_tables to the actual number of entries allocated instead of just using the value passed in from the caller - this ensures that ati_free_gatt_pages() will only attempt to free stuff that was actually allocated. Note: I'm in no way intimate with this code and I have no way to actually test this patch (besides compile test it), so while I've tried to be careful in reading the code and make sure the patch does the right thing an ACK from someone who actually knows the code in-depth would be very much appreciated. Signed-off-by: Jesper Juhl [EMAIL PROTECTED] Signed-off-by: Dave Airlie [EMAIL PROTECTED] -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git pull] AGP fixes for 2.6.23-rc1
Hi Linus, Please pull the 'agp-patches' branch from git://master.kernel.org/pub/scm/linux/kernel/git/airlied/agp-2.6.git agp-patches It contains one very important fix from Nick for AGP hangs with the nopage/pfn/flush stuff.. it also contains some minor docs changes and one coverity fix. Dave. Documentation/kernel-parameters.txt |7 +++ drivers/char/agp/Kconfig|2 +- drivers/char/agp/ati-agp.c |9 ++--- drivers/char/agp/generic.c |2 -- drivers/char/agp/intel-agp.c| 19 --- drivers/char/agp/sgi-agp.c |1 - 6 files changed, 22 insertions(+), 18 deletions(-) commit f191f144079b0083c6fa7d01a4acbd7263fb5032 Author: Alan Hourihane [EMAIL PROTECTED] Date: Fri Jul 27 10:56:43 2007 +1000 agp: AMD AGP is used on UP1100 UP1500 alpha boxen Signed-off-by: Dave Airlie [EMAIL PROTECTED] commit dde4787642ee3cb85aef80bdade04b6f8ddc3df8 Author: Zhenyu Wang [EMAIL PROTECTED] Date: Thu Jul 26 09:18:09 2007 +0800 intel_agp: really fix 945/965GME Fix some missing places to check with device id info, which should probe the device gart correctly. Signed-off-by: Wang Zhenyu [EMAIL PROTECTED] Signed-off-by: Dave Airlie [EMAIL PROTECTED] commit a51b34593f691a0837d752a1394dcee19483c607 Author: Nick Piggin [EMAIL PROTECTED] Date: Wed Jul 25 13:19:22 2007 +0200 agp: don't lock pages AGP should not need to lock pages. They are not protecting any race because there is no lock_page calls, only SetPageLocked. This is causing hangs with d00806b183152af6d24f46f0c33f14162ca1262a. Signed-off-by: Nick Piggin [EMAIL PROTECTED] Signed-off-by: Dave Airlie [EMAIL PROTECTED] commit c99c108ac362f5cc37f79fad7e9897bd9d033bcc Author: Chuck Ebbert [EMAIL PROTECTED] Date: Fri Jul 27 10:46:20 2007 +1000 AGP: document boot options Add documentation for AGP boot options. Signed-off-by: Chuck Ebbert [EMAIL PROTECTED] Signed-off-by: Dave Airlie [EMAIL PROTECTED] commit 190644e180794208bc638179f4d5940fe419bf9c Author: Jesper Juhl [EMAIL PROTECTED] Date: Sat Jul 21 17:39:11 2007 +0200 Fix use after free / double free bug in ati_create_gatt_pages / ati_free_gatt_pages Hi, Coverity spotted a use after free bug in drivers/char/agp/ati-agp.c::ati_create_gatt_pages(). The same one that was in drivers/char/agp/amd-k7-agp.c::amd_create_gatt_pages() The problem is this: If entry = kzalloc(sizeof(struct ati_page_map), GFP_KERNEL); fails, then there's a loop in the function to free all entries allocated so far and break out of the allocation loop. That in itself is pretty sane, but then the (now freed) 'tables' is assigned to ati_generic_private.gatt_pages and 'retval' is set to -ENOMEM which causes ati_free_gatt_pages(); to be called at the end of the function. The problem with this is that ati_free_gatt_pages() will then loop 'ati_generic_private.num_tables' times and try to free each entry in tables[] - this is bad since tables has already been freed and furthermore it will call kfree(tables) at the end - a double free. This patch removes the freeing loop in ati_create_gatt_pages() and instead relies entirely on the call to ati_free_gatt_pages() to free everything we allocated in case of an error. It also sets ati_generic_private.num_tables to the actual number of entries allocated instead of just using the value passed in from the caller - this ensures that ati_free_gatt_pages() will only attempt to free stuff that was actually allocated. Note: I'm in no way intimate with this code and I have no way to actually test this patch (besides compile test it), so while I've tried to be careful in reading the code and make sure the patch does the right thing an ACK from someone who actually knows the code in-depth would be very much appreciated. Signed-off-by: Jesper Juhl [EMAIL PROTECTED] Signed-off-by: Dave Airlie [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] AGP fixes for 2.6.23-rc1
It would really be nice to actually see the patches that go along with this. Otherwise you are not giving outside reviewers any chance at all to evaluate these fixes. Or were they posted on LKML, and I missed them? In this case I think I picked up all of these patches from LKML by searching for agp in my gmail a/c, maybe one of them didn't go via lkml (intel pci ids) Thanks for the script, Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: What does drm do with signals?
On 8/24/07, Oleg Nesterov [EMAIL PROTECTED] wrote: Could someone please explain why do we need block_all_signals() ? I can't understand what was the intended behaviour, but anyway I suspect it doesn't work as expected. http://dri.sourceforge.net/doc/drm_low_level.html Section 4.1 explains the intent... Dave. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git pull] drm patches for 2.6.23-rc4
Hi Linus, Please pull the 'drm-patches' branch from git://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-patches This just contains a pci id, ioremap balancing and dead code removal patches. Dave. drivers/char/drm/drm_bufs.c| 13 +++-- drivers/char/drm/via_dmablit.c |2 +- 2 files changed, 8 insertions(+), 7 deletions(-) commit 0769d39c993145754852b517ddd9c11586f0a014 Author: Scott Thompson postfail at hushmail.com Date: Sat Aug 25 18:17:49 2007 +1000 drm: ioremap return value checks Signed-off-by: Scott Thompson postfail at hushmail.com Signed-off-by: Dave Airlie [EMAIL PROTECTED] commit 22c806c23fe17f9c744d19edfe650cfd6496bc2a Author: Simon Farnsworth [EMAIL PROTECTED] Date: Mon Jul 23 18:32:01 2007 +1000 drm/via: Fix dmablit when blit queue is full fd.o bug 11542 Acked-by: Thomas Hellstrom Signed-off-by: Dave Airlie [EMAIL PROTECTED] commit 7ea4d4bd5e21380f028c3a6e2500655090a3f932 Author: Adrian Bunk [EMAIL PROTECTED] Date: Mon Jul 23 10:00:51 2007 +0200 drm_rmmap_ioctl(): remove dead code This patch removes some obviously dead code spotted by the Coverity checker. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Signed-off-by: Dave Airlie [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git pull] agp patches for 2.6.23-rc4
Hi Linus, Please pull the 'agp-patches' branch from git://master.kernel.org/pub/scm/linux/kernel/git/airlied/agp-2.6.git agp-patches actually this patch is a pci id, ioremap checks and a coverity fix... the drm patch has no pci id change.. Dave. drivers/char/agp/amd-k7-agp.c |2 ++ drivers/char/agp/ati-agp.c |3 +++ drivers/char/agp/efficeon-agp.c |2 ++ drivers/char/agp/hp-agp.c |1 + drivers/char/agp/i460-agp.c |4 drivers/char/agp/intel-agp.c| 14 +- drivers/char/agp/nvidia-agp.c |3 +++ drivers/char/agp/via-agp.c |5 + include/linux/pci_ids.h |1 + 9 files changed, 30 insertions(+), 5 deletions(-) commit 5bdbc7dc2c07d507b41bffdadc2c8cc13b2d4326 Author: Scott Thompson postfail at hushmail.com Date: Sat Aug 25 18:14:00 2007 +1000 agp: balance ioremap checks patchset against 2.6.23-rc3. corrects missing ioremap return checks and balancing on iounmap calls, integrated changes per list recommendations on the original set of patches.. Signed-off-by: Scott Thompson postfail at hushmail.com Signed-off-by: Dave Airlie [EMAIL PROTECTED] commit 32ddef98f232585f20bc8bdb891029a6a5f633d0 Author: Xavier Bachelot [EMAIL PROTECTED] Date: Sat Aug 25 18:10:52 2007 +1000 agp: Add device id for P4M900 to via-agp module Signed-off-by: Dave Airlie [EMAIL PROTECTED] commit db7f3ded8d42c60b0d0a4f71d621e105790b872b Author: Jesper Juhl [EMAIL PROTECTED] Date: Sat Aug 4 20:30:58 2007 +0200 efficeon-agp leaks 'struct agp_bridge_data' in error paths of agp_efficeon_probe() (This is a resend of a patch originally submitted on 24-Jul-2007 00:14) Ok, this is something the coverity checker found (CID: 1813). I'm not at all intimate with this code, so I'm not sure if this attempt at a fix is correct (but at least it compiles). Please look it over and NACK if bad or merge if good ;-) Signed-off-by: Jesper Juhl [EMAIL PROTECTED] Signed-off-by: Dave Airlie [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
resume failing on ATA controller
Hi, I've got an HP 2510p with a 965 mobile chipset and ICH8, lspci is at http://people.freedesktop.org/~airlied/hp2510p/hp-lspci-vv.txt Resume is failing on the hard disk resume by the looks of it (no video to prove it..) but I've rmmod nearly everything and my network interface comes back and I can ping it but anything that tries to access the disk looks stuck... I also know someone running the same laptop using drivers/ide drivers whose suspend/resume works properly I'm running the latest Fedora rawhide kernel based on -rc3-git7 http://people.freedesktop.org/~airlied/hp2510p/ata_dmesg.txt Dave. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/23] drm: introduce drm_zalloc
On Tue, 28 Aug 2007, Christoph Hellwig wrote: On Mon, Aug 27, 2007 at 10:57:50PM +0200, [EMAIL PROTECTED] wrote: Hello, As there are many places in drm code where drm_alloc + memset is used this patch series introduces drm_zalloc and also makes use of drm_calloc where needed. Most of these patches save some bytes so the benefit is a few kB saved (gcc 4.1.2) with patch applied. Also some small (style, etc.) things are fixed. This patch series does the conversion drm tree-wide. All patches were compile tested. Please just convert it to plain kzalloc/kcalloc and kill these utterly useless wrappers instead. The wrappers aren't useless the drm alloc/free passes in a memory space for debugging purposes so we can track memory abuse when developing, but drm_zalloc shouldjust alias to drm_calloc really.. Dave. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/23] drm: introduce drm_zalloc
Note the slab has a memory tracking feature that accounts memory to callers of the allocator. IF that's not enough for you please help improving the common code instead of inventing your own. Christoph that code was written over 6-7 years ago, feel free to provide a patch for it to use the slab allocator, we only turn this code on though when developing new drivers, I don't think it ever gets used outside of that.. we don't need the overhead of the memory tracking in normal use.. Please stop implying that all the code in the drm is magically new and that we should be reusing kernel infrastructure that wasn't even written when the code first appeared.. or provide patches... Dave. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
uncached page allocator
Hi all, I've started doing some work with using the new DRM memory manager from TG for pixmaps in the X server using Intel 9xx series hardware. The intel hardware pretty much requires pages to be uncached for the GPU to access them. It can use cached memory for some operations but it isn't very useful and my attempts to use it ended in a lot of crashiness.. Now one of the major usage patterns for pixmaps is allocate pixmap copy data into pixmap use pixmap from hardware free pixmap with the current memory manager + updated change_page_attr (to use clflush when we have it) fixes from Andi Kleen, it operates something like this allocate pixmap gets cached memory copy data into the pixmap pre-use from hardware we flush the cache lines and tlb use the pixmap in hardware pre-free we need to set the page back to cached so we flush the tlb free the memory. The other path is if we don't want to use the memory cached ever is just allocate pixmap flush cache lines/tlb use uncached from CPU use uncached from GPU pre-free set the page back to cached, flush the TLB free the page Now the big issue here on SMP is that the cache and/or tlb flushes require IPIs and they are very noticeable on the profiles, So after all that I'd like to have some sort of uncached page list I can allocate pages from, so with frequent pixmap creation/destruction I don't spend a lot of time in the cache flushing routines and avoid the IPI in particular. The options I can sorta see roughly are: 1. the DRM just allocates a bunch of uncached pages and manages a cache of them for interacting with the hardware, this sounds wrong and we run into how do we correctly size the pool issues. 2. (Is this idea crazy??) We modify the VM somehow so we have an uncached list, when we first allocate pages with the GFP_UNCACHED they get migrated to the uncached zone and the pages use a page flag to say they are uncached. Then the DRM just re-uses things from that list. If later we end up with memory pressure, the free pages on the uncached list could be migrated back to the normal page lists by modifying the page attributes and flushing the tlb Any other ideas and suggestions? Dave. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: uncached page allocator
Blame intel ;) Any other ideas and suggestions? Without knowing exactly what you are doing: - Copies to uncached memory are very expensive on an x86 processor (so it might be faster not to write and flush) - Its not clear from your description how intelligent your transfer system is. It is still possible to change the transfer system, but it should be intelligent enough or possible to make it more intelligent.. I also realise I need PAT + write combining but I believe this problem is othogonal... I'd expect for example that the process was something like Parse pending commands until either 1. Queue empties 2. A time target passes For each command we need to shove a pixmap over add it to the buffer to transfer Do a single CLFLUSH and maybe IPI Fire up the command queue Keep the buffers hanging around until there is memory pressure if we may reuse that pixmap Can you clarify that ? So at the moment a pixmap maps directly to a kernel buffer object which is a bunch of pages that get faulted in on the CPU or allocated when the buffer is to be used by the GPU. So when a pixmap is created a buffer object is created, when a pixmap is destroyed a buffer object is destroyed. Perhaps I can cache a bunch of buffer objects in userspace for re-use as pixmaps but I'm not really sure that will scale too well. When X wishes the GPU to access a buffer (pixmap), it calls into the kernel with a single ioctl with a list of all buffers the GPU is going to access along with a buffer containing the command to do the access, now at the moment, when each of those buffers is bound into the GART for the first time the system does a change_page_attr for each page and calls the global flush[1]. Now if a buffer is bound into the GART and gets accessed from the CPU later again (software fallback) we have the choice of taking it back out of the GART and letting the nopfn call fault back in the pages uncached or we can flush the tlb and bring them back in cached. We are hoping to avoid software fallbacks on the hardware platforms we want to work on as much as possible. Finally when a buffer is destroyed, the pages are released back to the system, so of course the pages are set back to cached and we need another tlb/cache flush per pixmap buffer destructor. So you can see why some sort of uncached+writecombined page cache would be useful, I could just allocate a bunch of pages at startup as uncached+writecombined, and allocate pixmaps from them and when I bind/free the pixmap I don't need the flush at all, now I'd really like this to be part of the VM so that under memory pressure it can just take the pages I've got in my cache back and after flushing turn them back into cached pages, the other option is for the DRM to do this on its own and penalise the whole system. [1]. (this is one inefficiency in that if multiple buffers are being bound in for the first time it'll flush for each of them, I'm trying to get rid of this inefficiency but I may need to tweak the order of things as at the moment, it crashes hard if I tried to leave the cache/tlb flush until later.) Dave. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: uncached page allocator
Write-combining access seems the correct thing here, followed by a wmb(). Uncached writing would be horrendously slow. [snip] So after all that I'd like to have some sort of uncached page list I can allocate pages from This is exactly what Intel's PAT mechanism exists for - just mark the desired access type (index) on the pages you've been allocated. It's documented in the Intel Architecture Software Design manuals, but Linux's support is lacking in certain areas [discussions on LKML], which a number of developers have been trying to move forward. Quite a few significant graphics/HPC etc vendors are forced to use it without this complete support, so it would be good to get this additional impetus involved... I'm hoping to pick up the PAT cause at some point soon this stuff is definitely required to get any use out of modern graphics hardware. It is slightly orthogonal to the issue I mentioned in that I still have the problem of allocating uncached memory without the flushing overheads associated with making pages cached/uncached constantly.. Dave. Daniel -- Daniel J Blueman - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
LCA 2008 Kernel Miniconf CFP
Call For Presentations == We are happy to announce that the Call for Presentations for LCA Kernel Miniconf is now open. LCA Kernel Miniconf is part of linux.conf.au, the annual Australian Linux open source developers' conference. When: 29th January 2008 Where: Melbourne University, Linux.conf.au http://miniconf.mel8ourne.org/wiki/index.php?title=Kernel The current schedule gives us 6 slots. One slot is reserved for 5 minute lightning talks - this gives us 6-8 lightning talks, where people working on kernel project and give a quick spiel on their current project. All these slots are currently open, and no slides should be used, just spiel. The other 5 slots are open for suggestion. Last year it all worked out pretty well with the balance of techy vs newbie stuff. I'd like to say have one or two general kernel topics suitable for a range of people and one or two talks aimed more in-depth or technically. I'd definitely like to bring back the Suspend/resume workshop which was fun (as the guy who got his laptop debugged by Linus/akpm personally will atest) and depending on who attends we might try for the kernel maintainers panel again. Please note that in order to give a presentation you must be signed up for the main conference. We also cannot provide any travel assistance for speakers at the kernel mini conference. However I'm sure you might be able to convince your company that going to LCA might be more useful if you do get to speak at it :-) So I'll leave the CFP open for a month or so, please mail [EMAIL PROTECTED] with your suggestions and proposals. About linux.conf.au linux.conf.au (http://linux.conf.au/) is Australia's annual technical conference about Free Software. Fun, informal and seriously technical, linux.conf.au draws together Free and Open Source Software developers from across the world. It will be held from January 28th to February 2nd, 2008 at The University of Melbourne. Dave and Matthew Wilcox (who I haven't ran this by yet :-) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23(.1) Regression? i915 oopses and panics
On 10/14/07, Thomas Bächler [EMAIL PROTECTED] wrote: I first discovered this problem when updating to 2.6.23 final on x86_64. When I launched google earth, the kernel paniced. When I tried to reproduce, it oopsed instead of panicing. dri/drm seems to work generally, as I am running beryl without trouble, so far I could only reproduce the problem with google earth. I have been using 2.6.23-rc6 for a while before, but I cannot tell if the problem already occured there. I am sure though that it wasn't there on 2.6.22(.Y). If anyone can tell me which commit might have caused this, I can revert it and test though. lets start with: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e4a7b1d1d90d202a030688ab5b177c3c0f15ee3e and work from there.. Dave. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23(.1) Regression? i915 oopses and panics
On 10/14/07, Thomas Bächler [EMAIL PROTECTED] wrote:
Dave Airlie schrieb:
lets start with:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e4a7b1d1d90d202a030688ab5b177c3c0f15ee3e
and work from there..
I'm sorry, I forgot to mention that: As I _thought_ it had worked with
rc6, I already found that commit. I reverted it and got a panic again
(no trace, as I was in X), so this one doesn't seem to cause the problem.
Okay I've spotted a potential bug that might lay hidden, try the
attached patch to see if it helps..
Dave.
From 7c63ae4527355d8f52dc285a9163a5947a61572e Mon Sep 17 00:00:00 2001
From: Dave Airlie [EMAIL PROTECTED]
Date: Sun, 14 Oct 2007 21:21:30 +1000
Subject: [PATCH] i915: fix vbl swap allocation size.
Oops...
Signed-off-by: Dave Airlie [EMAIL PROTECTED]
---
drivers/char/drm/i915_irq.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/char/drm/i915_irq.c b/drivers/char/drm/i915_irq.c
index bb8e9e9..94d638e 100644
--- a/drivers/char/drm/i915_irq.c
+++ b/drivers/char/drm/i915_irq.c
@@ -553,7 +553,7 @@ int i915_vblank_swap(DRM_IOCTL_ARGS)
return DRM_ERR(EBUSY);
}
- vbl_swap = drm_calloc(1, sizeof(vbl_swap), DRM_MEM_DRIVER);
+ vbl_swap = drm_calloc(1, sizeof(*vbl_swap), DRM_MEM_DRIVER);
if (!vbl_swap) {
DRM_ERROR(Failed to allocate memory to queue swap\n);
--
1.5.2.4
Re: 2.6.23(.1) Regression? i915 oopses and panics
On 10/14/07, Thomas Bächler [EMAIL PROTECTED] wrote: Dave Airlie schrieb: I'm sorry, I forgot to mention that: As I _thought_ it had worked with rc6, I already found that commit. I reverted it and got a panic again (no trace, as I was in X), so this one doesn't seem to cause the problem. Okay I've spotted a potential bug that might lay hidden, try the attached patch to see if it helps.. I applied the patch, compiled i915.ko, rmmoded the old module, insmoded the new one and started X. The issue seems to be gone, googleearth starts again without any messages to syslog, so no oops and no panic. Will you submit this patch to the stable team? As soon as I get it upstream into Linus's tree I'll forward it on to the stable guys Dave. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]: drm: cleanup DRM_DEBUG() parameters
On 10/14/07, Németh Márton [EMAIL PROTECTED] wrote: From: Márton Németh [EMAIL PROTECTED] As DRM_DEBUG macro already prints out the __FUNCTION__ string (see drivers/char/drm/drmP.h), it is not worth doing this again. At some other places the ending \n was added. Signed-off-by: Márton Németh [EMAIL PROTECTED] Hi Márton, Could you rebase the patch against the drm-mm tree or against -mm kernel? as it conflicts with the stuff I'm about to push to Linus.. Dave. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git pull] drm patches for 2.6.24-rc1
Hi Linus,
This contains a major macro removal and ioctl related usercopy cleanups,
it also fixes a bug in the intel interrupt code with a dodgy calloc size.
Please pull the 'drm-patches' branch from
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-patches
Dave.
drivers/char/drm/drm.h| 20 +-
drivers/char/drm/drmP.h | 237 +++--
drivers/char/drm/drm_agpsupport.c | 130 +++-
drivers/char/drm/drm_auth.c | 48 ++--
drivers/char/drm/drm_bufs.c | 203 ---
drivers/char/drm/drm_context.c| 177 --
drivers/char/drm/drm_dma.c| 11 +-
drivers/char/drm/drm_drawable.c | 67 ++---
drivers/char/drm/drm_drv.c| 186 ++-
drivers/char/drm/drm_fops.c | 34 +-
drivers/char/drm/drm_ioc32.c |2 +-
drivers/char/drm/drm_ioctl.c | 196 +---
drivers/char/drm/drm_irq.c| 98 +++
drivers/char/drm/drm_lock.c | 75 ++---
drivers/char/drm/drm_os_linux.h | 10 -
drivers/char/drm/drm_pciids.h |2 -
drivers/char/drm/drm_scatter.c| 48 +--
drivers/char/drm/drm_vm.c |4 +-
drivers/char/drm/i810_dma.c | 312 ++
drivers/char/drm/i810_drm.h |5 -
drivers/char/drm/i810_drv.h |9 +-
drivers/char/drm/i830_dma.c | 210 +---
drivers/char/drm/i830_drv.h | 15 +-
drivers/char/drm/i830_irq.c | 30 +--
drivers/char/drm/i915_dma.c | 214 ++---
drivers/char/drm/i915_drv.h | 36 ++-
drivers/char/drm/i915_irq.c | 128 +++
drivers/char/drm/i915_mem.c | 125 +++
drivers/char/drm/mga_dma.c| 140 -
drivers/char/drm/mga_drv.h| 21 +-
drivers/char/drm/mga_state.c | 197 +---
drivers/char/drm/mga_warp.c |8 +-
drivers/char/drm/r128_cce.c | 138 -
drivers/char/drm/r128_drm.h | 18 -
drivers/char/drm/r128_drv.h | 23 +-
drivers/char/drm/r128_state.c | 351 +---
drivers/char/drm/r300_cmdbuf.c| 68 ++--
drivers/char/drm/radeon_cp.c | 146 -
drivers/char/drm/radeon_drv.h | 43 ++--
drivers/char/drm/radeon_irq.c | 34 +--
drivers/char/drm/radeon_mem.c | 108 +++
drivers/char/drm/radeon_state.c | 683 +
drivers/char/drm/savage_bci.c | 145 -
drivers/char/drm/savage_drv.h |9 +-
drivers/char/drm/savage_state.c | 200 ++--
drivers/char/drm/sis_drv.c|2 +-
drivers/char/drm/sis_drv.h|5 +-
drivers/char/drm/sis_mm.c | 112 +++
drivers/char/drm/via_dma.c| 144 -
drivers/char/drm/via_dmablit.c| 54 ++--
drivers/char/drm/via_drv.h| 22 +-
drivers/char/drm/via_irq.c| 47 ++--
drivers/char/drm/via_map.c| 14 +-
drivers/char/drm/via_mm.c | 83 ++---
drivers/char/drm/via_verifier.c |8 +-
drivers/char/drm/via_video.c | 20 +-
56 files changed, 2359 insertions(+), 3116 deletions(-)
commit ace3dff5b7f0bf5a647e60dcd0c0a7d46792f5d9
Author: Xavier Bachelot [EMAIL PROTECTED]
Date: Mon Oct 15 11:09:35 2007 +1000
via invalid device ids removal
0x1106, 0x7204 is unknown and thus is not an IGP/GPU.
0x1106, 0x3304 is K8M800 hostbridge, not an IGP/GPU.
None of them are in drm git tree.
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Dave Airlie [EMAIL PROTECTED]
commit eed0f722b3fccb1eb2706b5f484cb511d46f70b8
Author: chaohong guo [EMAIL PROTECTED]
Date: Mon Oct 15 10:45:49 2007 +1000
radeon: Commit the ring after each partial texture upload blit.
This makes sure each blit starts as early as possible, which may improve
texture upload performance in some cases.
Signed-off-by: Dave Airlie [EMAIL PROTECTED]
commit 54583bf4efda79388fc13163e35c016c8bc5de81
Author: Dave Airlie [EMAIL PROTECTED]
Date: Sun Oct 14 21:21:30 2007 +1000
i915: fix vbl swap allocation size.
Oops...
Signed-off-by: Dave Airlie [EMAIL PROTECTED]
commit c153f45f9b7e30289157bba3ff5682291df16caa
Author: Eric Anholt [EMAIL PROTECTED]
Date: Mon Sep 3 12:06:45 2007 +1000
drm: Replace DRM_IOCTL_ARGS with (dev, data, file_priv) and remove
DRM_DEVICE.
The data is now in kernel space, copied in/out as appropriate according to t
This results in DRM_COPY_{TO,FROM}_USER going away, and error paths to deal
with those failures. This also means that XFree86 4.2.0 support for i810 DR
is lost.
Signed-off-by: Dave Airlie [EMAIL PROTECTED]
commit b589ee5943a9610ebaea6e4e3433f2ae4d812b0b
Author: Dave Airlie [EMAIL PROTECTED]
Date: Tue Aug 28 15:16:47 2007 +1000
drm: remove XFREE86_VERSION macros.
These are no longer needed or being used.
Signed-off-by: Dave Airlie [EMAIL PROTECTED]
commit 6c340eac0285f3d62406d2d902d0e96fbf2a5dc0
Author: Eric Anholt [EMAIL
[git pull] agp patches for 2.6.24-rc1
Hi Linus,
Please pull from 'agp-patches' branch of
master.kernel.org:/pub/scm/linux/kernel/git/airlied/agp-2.6.git agp-patches
to receive the following updates:
drivers/char/agp/agp.h|7 +--
drivers/char/agp/ali-agp.c| 27 ---
drivers/char/agp/amd-k7-agp.c |9 ++---
drivers/char/agp/backend.c| 12
drivers/char/agp/generic.c| 19 +--
drivers/char/agp/i460-agp.c |4 ++--
drivers/char/agp/intel-agp.c |6 --
7 files changed, 50 insertions(+), 34 deletions(-)
Dave Airlie (1):
AGP fix race condition between unmapping and freeing pages
Jesper Juhl (1):
fix use after free in amd create gatt pages
diff --git a/drivers/char/agp/agp.h b/drivers/char/agp/agp.h
index 8955e7f..b83824c 100644
--- a/drivers/char/agp/agp.h
+++ b/drivers/char/agp/agp.h
@@ -58,6 +58,9 @@ struct gatt_mask {
* devices this will probably be ignored */
};
+#define AGP_PAGE_DESTROY_UNMAP 1
+#define AGP_PAGE_DESTROY_FREE 2
+
struct aper_size_info_8 {
int size;
int num_entries;
@@ -113,7 +116,7 @@ struct agp_bridge_driver {
struct agp_memory *(*alloc_by_type) (size_t, int);
void (*free_by_type)(struct agp_memory *);
void *(*agp_alloc_page)(struct agp_bridge_data *);
- void (*agp_destroy_page)(void *);
+ void (*agp_destroy_page)(void *, int flags);
int (*agp_type_to_mask_type) (struct agp_bridge_data *, int);
};
@@ -267,7 +270,7 @@ int agp_generic_remove_memory(struct agp_memory *mem, off_t
pg_start, int type);
struct agp_memory *agp_generic_alloc_by_type(size_t page_count, int type);
void agp_generic_free_by_type(struct agp_memory *curr);
void *agp_generic_alloc_page(struct agp_bridge_data *bridge);
-void agp_generic_destroy_page(void *addr);
+void agp_generic_destroy_page(void *addr, int flags);
void agp_free_key(int key);
int agp_num_entries(void);
u32 agp_collect_device_status(struct agp_bridge_data *bridge, u32 mode, u32
command);
diff --git a/drivers/char/agp/ali-agp.c b/drivers/char/agp/ali-agp.c
index 4941ddb..aa5ddb7 100644
--- a/drivers/char/agp/ali-agp.c
+++ b/drivers/char/agp/ali-agp.c
@@ -156,29 +156,34 @@ static void *m1541_alloc_page(struct agp_bridge_data
*bridge)
return addr;
}
-static void ali_destroy_page(void * addr)
+static void ali_destroy_page(void * addr, int flags)
{
if (addr) {
- global_cache_flush(); /* is this really needed? --hch */
- agp_generic_destroy_page(addr);
- global_flush_tlb();
+ if (flags AGP_PAGE_DESTROY_UNMAP) {
+ global_cache_flush(); /* is this really needed?
--hch */
+ agp_generic_destroy_page(addr, flags);
+ global_flush_tlb();
+ } else
+ agp_generic_destroy_page(addr, flags);
}
}
-static void m1541_destroy_page(void * addr)
+static void m1541_destroy_page(void * addr, int flags)
{
u32 temp;
if (addr == NULL)
return;
- global_cache_flush();
+ if (flags AGP_PAGE_DESTROY_UNMAP) {
+ global_cache_flush();
- pci_read_config_dword(agp_bridge-dev, ALI_CACHE_FLUSH_CTRL, temp);
- pci_write_config_dword(agp_bridge-dev, ALI_CACHE_FLUSH_CTRL,
- (((temp ALI_CACHE_FLUSH_ADDR_MASK) |
- virt_to_gart(addr)) | ALI_CACHE_FLUSH_EN));
- agp_generic_destroy_page(addr);
+ pci_read_config_dword(agp_bridge-dev, ALI_CACHE_FLUSH_CTRL,
temp);
+ pci_write_config_dword(agp_bridge-dev, ALI_CACHE_FLUSH_CTRL,
+ (((temp ALI_CACHE_FLUSH_ADDR_MASK) |
+virt_to_gart(addr)) |
ALI_CACHE_FLUSH_EN));
+ }
+ agp_generic_destroy_page(addr, flags);
}
diff --git a/drivers/char/agp/amd-k7-agp.c b/drivers/char/agp/amd-k7-agp.c
index f60bca7..1405a42 100644
--- a/drivers/char/agp/amd-k7-agp.c
+++ b/drivers/char/agp/amd-k7-agp.c
@@ -100,21 +100,16 @@ static int amd_create_gatt_pages(int nr_tables)
for (i = 0; i nr_tables; i++) {
entry = kzalloc(sizeof(struct amd_page_map), GFP_KERNEL);
+ tables[i] = entry;
if (entry == NULL) {
- while (i 0) {
- kfree(tables[i-1]);
- i--;
- }
- kfree(tables);
retval = -ENOMEM;
break;
}
- tables[i] = entry;
retval = amd_create_page_map(entry);
if (retval != 0)
break;
}
- amd_irongate_private.num_tables = nr_tables;
+ amd_irongate_private.num_tables = i;
amd_irongate_private.gatt_pages = tables;
if (retval != 0)
diff --git
Re: [PATCH] Map volume and brightness events on thinkpads
But it *is* a key press! To get somewhat back on track: volume and brightness (and similar - lid close etc) events clearly are keypresses. However, I would also argue that a keypress that is acted on by the firmware automatically is *different* from a keypress that hasn't been acted on: one is a key was pressed *and* hardware did something automatically, and the other is just a key was pressed event. We also have cases where userspace may have told ACPI to stop the firmware acting on the keypress which may or may not be known to the piece of the kernel dealing with keypresses... hence just pass the key up to userspace and let it deal with it. Dave. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] [PATCH] DRM TTM Memory Manager patch
Hi, The patch is too big to fit on the list and I've no idea how we could break it down further, it just happens to be a lot of new code.. http://people.freedesktop.org/~airlied/ttm/0001-drm-Implement-TTM-Memory-manager-core-functionality.txt The patch header and diffstat are below, This isn't for integration yet but we'd like an initial review by anyone with the spare time and inclination, there is a lot stuff relying on getting this code bet into shape and into the kernel but any cleanups people can suggest now especially to the user interfaces would be appreciated as once we set that stuff in stone it'll be a pain to change... also it doesn't have any driver side code, this is just the generic pieces. I'll post the intel 915 side code later but there isn't that much to it.. It applies on top of my drm-2.6 git tree drm-mm branch - This patch brings in the TTM (Translation Table Maps) memory management system from Thomas Hellstrom at Tungsten Graphics. This patch only covers the core functionality and changes to the drm core. The TTM memory manager enables dynamic mapping of memory objects in and out of the graphic card accessible memory (e.g. AGP), this implements the AGP backend for TTM to be used by the i915 driver. drivers/char/drm/Makefile |3 +- drivers/char/drm/drm.h| 238 - drivers/char/drm/drmP.h | 153 +++- drivers/char/drm/drm_agpsupport.c | 160 +++ drivers/char/drm/drm_bo.c | 2329 drivers/char/drm/drm_bo_move.c| 395 +++ drivers/char/drm/drm_bufs.c |2 + drivers/char/drm/drm_drv.c| 46 +- drivers/char/drm/drm_fence.c | 661 +++ drivers/char/drm/drm_fops.c | 75 ++- drivers/char/drm/drm_memory.c | 69 ++ drivers/char/drm/drm_mm.c | 13 +- drivers/char/drm/drm_object.c | 293 + drivers/char/drm/drm_objects.h| 464 drivers/char/drm/drm_proc.c | 90 ++ drivers/char/drm/drm_stub.c | 24 +- drivers/char/drm/drm_ttm.c| 337 ++ drivers/char/drm/drm_vm.c | 193 +++- 18 files changed, 5503 insertions(+), 42 deletions(-) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git pull] DRM patches for 2.6.22-rc1
Hi Linus, Please pull the 'drm-patches' branch of git://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-patches This contains the drm patch for 2.6.22-rc1, and contains a number of fixes in the mmap code and the locking for AIGLX systems along with new hw support for i965GM. Dave. drivers/char/drm/README.drm| 16 +++-- drivers/char/drm/drm.h |4 +- drivers/char/drm/drmP.h| 23 +-- drivers/char/drm/drm_bufs.c| 75 +++ drivers/char/drm/drm_drv.c |9 +-- drivers/char/drm/drm_fops.c| 96 ++-- drivers/char/drm/drm_hashtab.c | 17 +- drivers/char/drm/drm_hashtab.h |1 - drivers/char/drm/drm_irq.c |4 +- drivers/char/drm/drm_lock.c| 134 --- drivers/char/drm/drm_mm.c |2 + drivers/char/drm/drm_pciids.h |3 +- drivers/char/drm/drm_proc.c|2 +- drivers/char/drm/drm_stub.c|1 - drivers/char/drm/drm_vm.c | 102 --- drivers/char/drm/i915_dma.c|3 +- drivers/char/drm/radeon_cp.c |8 +- drivers/char/drm/sis_drv.c |2 +- drivers/char/drm/via_drv.c |3 +- drivers/char/drm/via_mm.h | 40 20 files changed, 196 insertions(+), 349 deletions(-) commit ce7dd06372058f9e3e57ee4c0aeba694a43a80ad Author: Wang Zhenyu [EMAIL PROTECTED] Date: Thu Apr 26 07:42:56 2007 +1000 drm/i915: Add 965GM pci id update Signed-off-by: Dave Airlie [EMAIL PROTECTED] commit 9e9c1326a592c677c94d730fcf4446d0e275aef4 Author: Dave Airlie [EMAIL PROTECTED] Date: Sat Mar 24 17:57:54 2007 +1100 drm: just use io_remap_pfn_range on all archs.. Move the sparc64 ifdef around to clean this up. Signed-off-by: Dave Airlie [EMAIL PROTECTED] commit 38315878a560eede1a2db52e511ad3a2cfbb4206 Author: Hugh Dickins [EMAIL PROTECTED] Date: Sat Mar 24 17:55:16 2007 +1100 drm: fix DRM_CONSISTENT mapping This patch got lost in the DRM git tree for ages, bring it back to life. Signed-off-by: Dave Airlie [EMAIL PROTECTED] commit d7d8aac79dc38cbdef83b774e49bafdae9918137 Author: Thomas Hellstrom thomas-at-tungstengraphics-dot-com Date: Sat Mar 24 17:52:49 2007 +1100 drm: fix up mmap locking in preparation for ttm changes This change is needed to protect againt disappearing maps which aren't common. The map lists are protected using sturct_mutex but drm_mmap never locked it. Signed-off-by: Dave Airlie [EMAIL PROTECTED] commit 040ac32048d5efabd557c1e0a6ab8aec2c710c56 Author: Thomas Hellstrom thomas-at-tungstengraphics-dot-com Date: Fri Mar 23 13:28:33 2007 +1100 drm: fix driver deadlock with AIGLX and reclaim_buffers_locked Bugzilla Bug #9457 Add refcounting of user waiters to the DRM hardware lock, so that we can use DRM_LOCK_CONT flag more conservatively. Also add a kernel waiter refcount that if nonzero transfers the lock for the kernel context when it is released. This is useful when waiting for idle and can be used for very simple fence object driver implementations for the new memory manager Signed-off-by: Dave Airlie [EMAIL PROTECTED] commit 4b560fde06aeb342f3ff0bce924627ab722d251a Author: Andrew Morton [EMAIL PROTECTED] Date: Mon Mar 19 09:08:21 2007 +1100 drm: fix warning in drm_fops.c drivers/char/drm/drm_fops.c: In function 'drm_setup': drivers/char/drm/drm_fops.c:60: warning: comparison of distinct pointer types lacks a cast Unfortunately PAGE_SIZE has different types on different architectures. Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Dave Airlie [EMAIL PROTECTED] commit 99da6d861c659bb1a961b70f50fad268b9ed5a5f Author: Thomas Hellstrom thomas-at-tungstengraphics-dot-com Date: Mon Mar 19 08:52:17 2007 +1100 drm: allow for more generic drm ioctls Signed-off-by: Dave Airlie [EMAIL PROTECTED] commit 6244270ef62203e057191bf85489e2ff91cc0e60 Author: Jay Estabrook [EMAIL PROTECTED] Date: Sun Mar 11 11:46:27 2007 +1100 drm: fix alpha domain handling Signed-off-by: Dave Airlie [EMAIL PROTECTED] commit 74be8e3b3707956f8f232313de9fad896d5489ac Author: Thomas Hellstrom thomas-at-tungstengraphics-dot-com Date: Sun Mar 11 11:45:24 2007 +1100 via: fix CX700 pci id Signed-off-by: Dave Airlie [EMAIL PROTECTED] commit 0bead7cdc94b4897f3d92db6170737a2da527134 Author: Adrian Bunk [EMAIL PROTECTED] Date: Sun Mar 11 11:41:16 2007 +1100 drm: make drm_io_prot static. This patch makes the needlessly global drm_io_prot() static. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Signed-off-by: Dave Airlie [EMAIL PROTECTED] commit 5379397182a7b5fa1c68ceaefe311ce4c1d04b2a Author: Robert P. J. Day [EMAIL PROTECTED] Date: Sun Mar 11 11:39:31 2007 +1100 drm: remove via_mm.h Delete apparently unused header file drivers/char/drm/via_mm.h. Signed-off-by: Robert P. J. Day [EMAIL
[PATCH] r128_state.c: break missing in switch statement (fwd)
Hi Andrew/Linus,
Can you make sure this goes into 2.6.12? until you sort out the bk
thing I'll adopt this approach :-)
Dave.
drm: fix r128_state.c switch statements..
in drivers/char/drm/r128_state.c (linux-2.6.12-rc2), some breaks are
missing in the switch statement. See trivial fix below.
Signed-off-by: Hansjoerg Lipp [EMAIL PROTECTED]
Signed-off-by: Dave Airlie [EMAIL PROTECTED]
diff -urp linux-2.6.12-rc2/drivers/char/drm/r128_state.c
linux-2.6.12-rc2-fix/drivers/char/drm/r128_state.c
--- linux-2.6.12-rc2/drivers/char/drm/r128_state.c 2005-04-06
13:18:05.0 +0200
+++ linux-2.6.12-rc2-fix/drivers/char/drm/r128_state.c 2005-04-06
13:23:50.0 +0200
@@ -1549,12 +1549,16 @@ static int r128_cce_depth( DRM_IOCTL_ARG
switch ( depth.func ) {
case R128_WRITE_SPAN:
ret = r128_cce_dispatch_write_span( dev, depth );
+ break;
case R128_WRITE_PIXELS:
ret = r128_cce_dispatch_write_pixels( dev, depth );
+ break;
case R128_READ_SPAN:
ret = r128_cce_dispatch_read_span( dev, depth );
+ break;
case R128_READ_PIXELS:
ret = r128_cce_dispatch_read_pixels( dev, depth );
+ break;
}
COMMIT_RING();
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [bk tree] DRM add a version check.. for 2.6.12 (distro kernel maintainers + drm users plz read also...)
I tried 2.6.12-rc2 which includes this patch, and I get DRM failures here, which causes application and X to hang. (I got failures with 2.6.11 also.) Does the FC-4 test kernel work? There was a bug in X6.8.2 but I think it would be fixed in FC-4 test.. I run Xorg CVS on a 9200 with the latest kernel and it seems fine... granted I've been able to crash it with running a few wierd apps.. I've just had no chance to debug it yet but it isn't the common case... maybe I should play tuxracer for a while.. the symptoms are typical of a card lockup, spinning in ioctl forever... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [bk tree] DRM add a version check.. for 2.6.12 (distro kernel maintainers + drm users plz read also...)
My lattest runs were with 2 days old FC development (a.k.a. bleeding edge) environment with xorg-11-** of same age. Then I noticed that these DRM patches didn't make it into kernel-smp-2.6.11-1.1226_FC4.i686.rpm, and I made 2.6.12-rc2 -- just in case it had fixed the problem... well these patches shouldn't really affect it.. Could the card-lockups be recovered in a bit nicer way ? (And detected, too!) In theory yes, but there isn't really anything you can do except reboot, as usually the CP (command processor) is hung, and you have to do a full GPU reset, I can't imagine X or Linux consoles surviving it too well... ATI have a VPU Recover in their windows driver which does it.. but they know their cards a bit better than we do.. it might be worth turning Render acceleration off Option RenderAccel No in xorg.conf and see if it gets any stabler... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] radeonfb: (#2) Implement proper workarounds for PLL accesses
There are 1694 calls to radeon_pll_errata_after_data during a switch from X to the console and 393 calls the other way. Wow... Ben that seems a bit extreme... there's not even close to 393 plls :-) Dave. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
Are you happy with processing patches + descriptions, one per mail? Yes. That's going to be my interim, I was just hoping that with 2.6.12-rc2 out the door, and us in a calming down period, I could afford to not even do that for a while. The real problem with the email thing is that it ends up piling up: what BK did in this respect was that anythign that piled up in a BK repository ended up still being there, and a single bk pull got it anyway - so if somebody got ignored because I was busy with something else, it didn't add any overhead. The queue didn't get congested. And that's a big thing. It comes from the Linus pulls model where people just told me that they were ready, instead of the everybody pushes to Linus model, where the destination gets congested at times. Something I think we'll miss is bkbits.net in the long run, being able to just push all patches for Linus to a tree and then forget about that tree until Linus pulled from it was invaluable.. the fact that this tree was online the whole time and you didn't queue up huge mails for Linus's INBOX to be missed, meant a lot to me compared to pre-bk workings.. Maybe now that kernel.org has been 'pimped out' we could set some sort of system up where maintainers can drop a big load of patchsets or even one big patch into some sort of public area and say this is my diffs for Linus for his next pull and let Linus pull it at his lesuire... some kinda rsync'y type thing comes to mind ... so I can mail Linus and say hey Linus please grab rsync://pimpedout.kernel.org/airlied/drm-linus and you grab everything in there and I get notified perhaps or just a log like the bkbits stats page, and Andrew can grab the patchsets the same as he does for bk-drm now ... and I can have airlied/drm-2.6 where I can queue stuff for -mm then just re-generate the patches for drm-linus later on.. Dave. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: EXPORT_SYMBOL_GPL for __symbol_get replacing EXPORT_SYMBOL for deprecated inter_module_get
The case in point for me is ATI's binary openGL accelerated drivers (fglrx) - these used inter_module_get() to communicate with the agp gart module, for obvious reasons - this AGP communication is essential to the functionality of the driver. No, I don't like ATI only having closed-source drivers any more than you, but given the extremely competetive nature of high end video card sales, I can see why they want to do it this way. The point is that now, as of 2.6.11-? or 2.6.12-? (not sure of the exact revision), the inter_module_get() functions has been removed, and the functionality can only be got (as far as I can tell) through use of the symbol_get() function. you might have done some research on what happened before ranting away like a crazy. AGP dropped the drm_agp interface in favour of the DRM modules calling the AGP backend directly, a patch for the ATI drivers has been sailing around for ages I even wrote one myself for someone I think but I've lost it now ... all the AGP symbols needed are exported with EXPORT_SYMBOL. you might have noticed no-one else complaining around here which is usually a good sign that there is nothing worth complaining about :-) Dave. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
