Re: [git pull] drm: previous pull req + 1.

2009-06-30 Thread Chris Wilson
Revised patch, unmap_mapping_range() on unbind and clear register. From 8f13b6389ee0c8a39a2073279928a3a228bd27dc Mon Sep 17 00:00:00 2001 From: Chris Wilson ch...@chris-wilson.co.uk Date: Mon, 29 Jun 2009 08:45:31 +0100 Subject: [PATCH] drm/i915: Remove mappings on clearing fence register As the

Re: [git pull] drm: previous pull req + 1.

2009-06-23 Thread Michel Dänzer
On Mon, 2009-06-22 at 18:18 -0700, Jesse Barnes wrote: On Tue, 23 Jun 2009 11:04:39 +1000 Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Mon, 2009-06-22 at 17:24 -0700, Linus Torvalds wrote: On Tue, 23 Jun 2009, Benjamin Herrenschmidt wrote: As far as I can

Re: [git pull] drm: previous pull req + 1.

2009-06-23 Thread Jesse Barnes
On Tue, 23 Jun 2009 09:48:00 +0200 Michel Dänzer mic...@daenzer.net wrote: In fact, nowdays, we do have the infrastructure to be smart and enforce that. IE. Instead of using a boring remap_page_ranges() in fb_mmap() we could use a fault handler. When in KD_TEXT, we fail them, when in

Re: [git pull] drm: previous pull req + 1.

2009-06-23 Thread Jesse Barnes
On Tue, 23 Jun 2009 12:26:15 +1000 Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Mon, 2009-06-22 at 19:07 -0700, Jesse Barnes wrote: Yeah I don't think we should try to change the mode, unless we really have to for whatever reason. fbcon should generally be able to paint to

Re: [git pull] drm: previous pull req + 1.

2009-06-23 Thread Jesse Barnes
On Tue, 23 Jun 2009 08:39:44 -0700 Jesse Barnes jbar...@virtuousgeek.org wrote: On Tue, 23 Jun 2009 09:48:00 +0200 Michel Dänzer mic...@daenzer.net wrote: On a side note, I did precisely that about ten years ago on my Amiga. :) Granted, that was using two separate framebuffer devices (X

Re: [git pull] drm: previous pull req + 1.

2009-06-22 Thread Andrew Lutomirski
On Sun, Jun 21, 2009 at 3:47 PM, Linus Torvaldstorva...@linux-foundation.org wrote: What *has* changed is that we have a newradeon driver, and it looks like that new radeon driver is crap, and does this:        info-fix.smem_start = (unsigned long)fbptr; which is totally screwed up. It

Re: [git pull] drm: previous pull req + 1.

2009-06-22 Thread Andrew Lutomirski
On Sun, Jun 21, 2009 at 1:16 AM, Dave Airlieairl...@linux.ie wrote: I tried this tree (specifically, a merge of Linus' fb20871 this tree) on Fedora 11 with modesetting enabled on an integrated Radeon 2100, and plymouthd crashes immediately with a corrupt page table.  Photo attached.  After

Re: [git pull] drm: previous pull req + 1.

2009-06-22 Thread Andrew Lutomirski
On Sun, Jun 21, 2009 at 5:14 PM, Andrew Lutomirskil...@mit.edu wrote: On Sun, Jun 21, 2009 at 3:47 PM, Linus Torvaldstorva...@linux-foundation.org wrote: What *has* changed is that we have a newradeon driver, and it looks like that new radeon driver is crap, and does this:        

Re: [git pull] drm: previous pull req + 1.

2009-06-22 Thread Dave Airlie
There is a ttm_fbdev_mmap() function in TTM that may help in this situation. As with the standard ttm mmap it's using fault() which means it's possible to move out the backing buffer object if you first reserve it and then call unmap_mapping_range() on the relevant fbdev address space to

Re: [git pull] drm: previous pull req + 1.

2009-06-22 Thread Maxim Levitsky
On Sun, 2009-06-21 at 22:24 +0100, Chris Wilson wrote: On Sun, 2009-06-21 at 17:47 +0300, Maxim Levitsky wrote: 52dc7d32b88156248167864f77a9026abe27b432 is first bad commit commit 52dc7d32b88156248167864f77a9026abe27b432 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Sat Jun 6

Re: [git pull] drm: previous pull req + 1.

2009-06-22 Thread Linus Torvalds
On Mon, 22 Jun 2009, Thomas Hellström wrote: It would be very helpful if we could introduce an fbdev mutex that protects fbdev accesses to the kernel map and to the fbdev acceleration functions. Not going to happen. Why? 'printk'. If you can't handle printk, then you're basically useless.

Re: [git pull] drm: previous pull req + 1.

2009-06-22 Thread Linus Torvalds
On Mon, 22 Jun 2009, Andrew Lutomirski wrote: What if we only guaranteed that the framebuffer is mapped when it's showing on the screen? I think that works ok. We only care about printk being immediate in that case, and if it gets buffered I don't think we care. printk doesn't need to

Re: [git pull] drm: previous pull req + 1.

2009-06-22 Thread Linus Torvalds
On Tue, 23 Jun 2009, Benjamin Herrenschmidt wrote: As far as I can remember, all fbdev operations are done under the console semaphore. Yeah, and some of them are horribly broken (ie copying data from user space while doing it - causing horrible things like VC switching latencies and

Re: [git pull] drm: previous pull req + 1.

2009-06-22 Thread Benjamin Herrenschmidt
On Mon, 2009-06-22 at 17:24 -0700, Linus Torvalds wrote: On Tue, 23 Jun 2009, Benjamin Herrenschmidt wrote: As far as I can remember, all fbdev operations are done under the console semaphore. Yeah, and some of them are horribly broken (ie copying data from user space while doing it

Re: [git pull] drm: previous pull req + 1.

2009-06-22 Thread Benjamin Herrenschmidt
On Mon, 2009-06-22 at 11:22 -0700, Linus Torvalds wrote: Not going to happen. Why? 'printk'. If you can't handle printk, then you're basically useless. And printk absolutely -has- to work in bad situations (the most important messages could happen in any context). Well... yes and no. If

Re: [git pull] drm: previous pull req + 1.

2009-06-22 Thread Benjamin Herrenschmidt
On Mon, 2009-06-22 at 18:18 -0700, Jesse Barnes wrote: I think it could work, but ideally we'd keep the kernel fbcon object pinned, and keep printing into it even while some other gfx app is running. That way we don't have to dump the whole queue into it when a panic occurs, we can just

Re: [git pull] drm: previous pull req + 1.

2009-06-22 Thread Benjamin Herrenschmidt
On Mon, 2009-06-22 at 19:07 -0700, Jesse Barnes wrote: Yeah I don't think we should try to change the mode, unless we really have to for whatever reason. fbcon should generally be able to paint to whatever we have up as long as we set it up properly. Well... it may not. IE. The text consoles

Re: [git pull] drm: previous pull req + 1.

2009-06-22 Thread Jesse Barnes
On Tue, 23 Jun 2009 11:58:44 +1000 Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Mon, 2009-06-22 at 18:18 -0700, Jesse Barnes wrote: I think it could work, but ideally we'd keep the kernel fbcon object pinned, and keep printing into it even while some other gfx app is running.

Re: [git pull] drm: previous pull req + 1.

2009-06-22 Thread Jesse Barnes
On Tue, 23 Jun 2009 11:04:39 +1000 Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Mon, 2009-06-22 at 17:24 -0700, Linus Torvalds wrote: On Tue, 23 Jun 2009, Benjamin Herrenschmidt wrote: As far as I can remember, all fbdev operations are done under the console

Re: [git pull] drm: previous pull req + 1.

2009-06-22 Thread Arnaldo Carvalho de Melo
Em Sun, Jun 21, 2009 at 08:05:36PM -0400, Andrew Lutomirski escreveu: David -- there are still plenty of bugs. The kernel gets my monitor's resolution wrong (X reads it off DDC correctly but I have to use xrandr to force the resolution). No crashes here, but I was able to use an external

Re: [git pull] drm: previous pull req + 1.

2009-06-21 Thread Maxim Levitsky
On Sat, 2009-06-20 at 17:42 -0700, Linus Torvalds wrote: On Sun, 21 Jun 2009, Maxim Levitsky wrote: Something from this tree breaks my i965. Using -git just before this was pulled, a552f0af753eb4b5bbbe9eff205fe874b04c4583 works, but using latest git makes google earth stall,

Re: [git pull] drm: previous pull req + 1.

2009-06-21 Thread Linus Torvalds
On Sun, 21 Jun 2009, Dave Airlie wrote: I tried this tree (specifically, a merge of Linus' fb20871 this tree) on Fedora 11 with modesetting enabled on an integrated Radeon 2100, and plymouthd crashes immediately with a corrupt page table. Photo attached. After the crash, bootup

Re: [git pull] drm: previous pull req + 1.

2009-06-21 Thread Linus Torvalds
On Sun, 21 Jun 2009, Linus Torvalds wrote: Dave - no amount of userspace differences make a corrupted page table acceptable. This needs to be fixed. No excuses. Kernel crashes are never an issue of you used the wrong user space. So corrupted page table means that one of the reserved

Re: [git pull] drm: previous pull req + 1.

2009-06-21 Thread Linus Torvalds
On Sun, 21 Jun 2009, Andrew Lutomirski wrote: Anyway, here's a totally UNTESTED patch that hopefully gives a warning on where exactly we set the invalid bits. Andy, mind trying it out? You should get the warnign much earlier, and it should have a much more useful back-trace. Your

Re: [git pull] drm: previous pull req + 1.

2009-06-21 Thread Chris Wilson
On Sun, 2009-06-21 at 17:47 +0300, Maxim Levitsky wrote: 52dc7d32b88156248167864f77a9026abe27b432 is first bad commit commit 52dc7d32b88156248167864f77a9026abe27b432 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Sat Jun 6 09:46:01 2009 +0100 The error here seems to be my

Re: [git pull] drm: previous pull req + 1.

2009-06-21 Thread Dave Airlie
On Sun, 21 Jun 2009, Andrew Lutomirski wrote: Anyway, here's a totally UNTESTED patch that hopefully gives a warning on where exactly we set the invalid bits. Andy, mind trying it out? You should get the warnign much earlier, and it should have a much more useful back-trace.

Re: [git pull] drm: previous pull req + 1.

2009-06-21 Thread Dave Airlie
On Sun, 21 Jun 2009, Dave Airlie wrote: I tried this tree (specifically, a merge of Linus' fb20871 this tree) on Fedora 11 with modesetting enabled on an integrated Radeon 2100, and plymouthd crashes immediately with a corrupt page table. Photo attached. After the crash,

Re: [git pull] drm: previous pull req + 1.

2009-06-20 Thread Maxim Levitsky
On Sat, 2009-06-20 at 06:23 +0100, Dave Airlie wrote: Hi Linus, Please pull the 'drm-linus' branch from ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus This is the same tree from the previous pull request + the fix from Pierre that actually makes the

Re: [git pull] drm: previous pull req + 1.

2009-06-20 Thread Linus Torvalds
On Sun, 21 Jun 2009, Maxim Levitsky wrote: Something from this tree breaks my i965. Using -git just before this was pulled, a552f0af753eb4b5bbbe9eff205fe874b04c4583 works, but using latest git makes google earth stall, it doesn't update its main window. It appears that openining and

Re: [git pull] drm: previous pull req + 1.

2009-06-20 Thread Dave Airlie
Please pull the 'drm-linus' branch from ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus This is the same tree from the previous pull request + the fix from Pierre that actually makes the PAE/GEM combination on i965 work. \o/ Something from this

Re: [git pull] drm: previous pull req + 1.

2009-06-20 Thread Dave Airlie
I tried this tree (specifically, a merge of Linus' fb20871 this tree) on Fedora 11 with modesetting enabled on an integrated Radeon 2100, and plymouthd crashes immediately with a corrupt page table. Photo attached. After the crash, bootup stops, although ctrl-alt-del works. You need a

[git pull] drm: previous pull req + 1.

2009-06-19 Thread Dave Airlie
Hi Linus, Please pull the 'drm-linus' branch from ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus This is the same tree from the previous pull request + the fix from Pierre that actually makes the PAE/GEM combination on i965 work. \o/ Dave.