From: Alan Cox a...@lxorguk.ukuu.org.uk
Date: Fri, 5 Mar 2010 12:38:34 +
The conclusion is crystal clear, breaking an ABI via a flag day
cleanup/feature/etc is:
Ingo go read the staging Kconfig. It's crystal clear, and lots of vendor
junk that is in there being cleaned up it would be
From: Alan Cox a...@lxorguk.ukuu.org.uk
Date: Fri, 5 Mar 2010 15:09:34 +
I think you miss a bigger picture ?
If Fedora hadn't merged it then it wouldn't have gotten to the state of
usability it had. If Fedora hadn't merged it then several hundred
thousand users wouldn't have had useful
From: Daniel Stone dan...@fooishbar.org
Date: Fri, 5 Mar 2010 17:17:54 +0200
On Fri, Mar 05, 2010 at 06:37:18AM -0800, David Miller wrote:
If it effects such a large number of people, which this noveau thing
does, it's entirely relevant to everyone. And the way it's breaking
and making
From: Daniel Stone dan...@fooishbar.org
Date: Fri, 5 Mar 2010 17:40:09 +0200
On Fri, Mar 05, 2010 at 07:26:12AM -0800, David Miller wrote:
In fact, I argue that the moment nouveau went into Fedora and
was turned on by default, the interfaces needed to be frozen.
That's a matter
From: Daniel Stone dan...@fooishbar.org
Date: Fri, 5 Mar 2010 17:41:43 +0200
I understand that you guys are upset about this, so maybe you'd like to
donate, say, 10% of your developer base to help out? That'd be pretty
ace.
You have to support less than %10 of the amount of hardware we have
From: Alan Cox a...@lxorguk.ukuu.org.uk
Date: Fri, 5 Mar 2010 16:02:17 +
You can't unleash something like this on a userbase of this magnitude
and then throw your hands up in the air and say I'm not willing to
support this in a reasonable way.
Not to belabour the obvious - they didn't.
From: Daniel Stone dan...@fooishbar.org
Date: Fri, 5 Mar 2010 18:04:34 +0200
So you're saying that there's no way to develop any reasonable body of
code for the Linux kernel without committing to keeping your ABI
absolutely rock-solid stable for eternity, no exceptions, ever? Cool,
that
From: Xavier Bestel xavier.bes...@free.fr
Date: Fri, 05 Mar 2010 18:50:24 +0100
On Fri, 2010-03-05 at 07:49 -0800, David Miller wrote:
From: Daniel Stone dan...@fooishbar.org
Date: Fri, 5 Mar 2010 17:41:43 +0200
I understand that you guys are upset about this, so maybe you'd like
From: Jesse Barnes jbar...@virtuousgeek.org
Date: Fri, 5 Mar 2010 10:02:44 -0800
So from that perspective, the graphics stack is the most complex one in
Linux by a long shot. It's even worse than if we had STREAMS
networking with a ton of different modules up in userspace messing with
From: Alan Cox a...@lxorguk.ukuu.org.uk
Date: Fri, 11 Dec 2009 09:18:43 +
However the fundamental point stands. The only people who can sign it off
are the people who wrote it. Those are the rules. Red Hat didn't write the
code, Red Hat cannot sign it off however much you rant at them. You
...@lst.de
Cc: Al Viro v...@zeniv.linux.org.uk
Cc: Arnd Bergmann arndbergm...@googlemail.com
Reported-by: David Miller da...@davemloft.net
Signed-off-by: Heiko Carstens heiko.carst...@de.ibm.com
Acked-by: David S. Miller da...@davemloft.net
From: Dave Airlie airl...@linux.ie
Date: Wed, 28 Oct 2009 05:42:27 + (GMT)
I'll add this to my TODO for before the next merge window as its
definitely more than I can manage now.
I'll do it.
--
Come build with us!
From: David Miller da...@davemloft.net
Date: Tue, 27 Oct 2009 23:04:50 -0700 (PDT)
From: Dave Airlie airl...@linux.ie
Date: Wed, 28 Oct 2009 05:42:27 + (GMT)
I'll add this to my TODO for before the next merge window as its
definitely more than I can manage now.
I'll do it.
Ok
From: Andi Kleen a...@firstfloor.org
Date: Wed, 28 Oct 2009 08:59:08 +0100
}
-chunk_array_ptr = (uint64_t *)(unsigned long)(cs-chunks);
+#ifdef CONFIG_COMPAT
+if (is_compat_task())
Are the COMPAT ifdefs really needed? The compiler should optimize that
away anyways on non
From: Andi Kleen a...@firstfloor.org
Date: Wed, 28 Oct 2009 09:19:09 +0100
On Wed, Oct 28, 2009 at 01:11:41AM -0700, David Miller wrote:
From: Andi Kleen a...@firstfloor.org
Date: Wed, 28 Oct 2009 08:59:08 +0100
}
- chunk_array_ptr = (uint64_t *)(unsigned long)(cs-chunks);
+#ifdef
From: Arnd Bergmann arndbergm...@googlemail.com
Date: Wed, 28 Oct 2009 13:13:32 +0100
IMHO a better way to handle the radeon specific ioctls would be to
avoid the compat_alloc_user_space and just define the common
function taking a kernel pointer, with two implementations of the
copy
From: Arnd Bergmann arndbergm...@googlemail.com
Date: Wed, 28 Oct 2009 13:13:32 +0100
The ioctl argument actually needs a compat_ptr() conversion as well.
For the s390 case, we can't do that in common code, because some
ioctl methods put a 32 bit integer into the argument. Not sure if we
want
From: Arnd Bergmann arndbergm...@googlemail.com
Date: Wed, 28 Oct 2009 16:40:18 +0100
I'm pretty sure it was ok when we started adding the compat_ioctl
handlers years ago. I think most people just ignored these for
the majority of drivers that can't possibly run on s390. Even
on s390, gcc
From: Dave Airlie airl...@gmail.com
Date: Wed, 28 Oct 2009 11:22:18 +1000
Is there really no way to avoid compat ioctls? was I delusional in
thinking there was?
If you use pointers in your interfaces in any way, no.
And for this drm_radeon_info thing the pointer is pointless,
you're just
From: Andi Kleen a...@firstfloor.org
Date: Wed, 28 Oct 2009 03:53:17 +0100
Dave Airlie airl...@gmail.com writes:
Now I thought cool I don't need to worry about compat ioctl hackery I can
run 32 on 64 bit apps fine and it'll all just work.
Now Dave Miller points out that I'm obivously
From: Dave Airlie airl...@gmail.com
Date: Wed, 28 Oct 2009 13:05:08 +1000
DrNick on irc suggested just doing:
if (is_compat_task()) ptr = 0x;
Is there a one liner I can just do in the actual ioctls instead of
adding 20 compat
ones?
Just do the right thing and pass all
From: Dave Airlie airl...@gmail.com
Date: Wed, 28 Oct 2009 13:28:10 +1000
On Wed, Oct 28, 2009 at 1:19 PM, Andi Kleen a...@firstfloor.org wrote:
On Wed, Oct 28, 2009 at 01:05:08PM +1000, Dave Airlie wrote:
We've designed that into a/c also, we pad all 64-bit values to 64-bit
alignment on all
From: Andi Kleen a...@firstfloor.org
Date: Wed, 28 Oct 2009 04:34:55 +0100
On Wed, Oct 28, 2009 at 01:28:10PM +1000, Dave Airlie wrote:
Well this was what I was trying to gather, so maybe I just need to write
something up to state that compat_ioctl is always required for new ioctls
that pass
From: Dave Airlie airl...@linux.ie
Date: Wed, 28 Oct 2009 03:43:07 + (GMT)
we already opencoded this (probably before it was macroisied or we just
pasted it), so the radeon one is buggy, I should just go and compat_* all
of these then and we should be all happy?
It should be, it's only
From: Dave Airlie airl...@linux.ie
Date: Wed, 28 Oct 2009 03:54:34 + (GMT)
we already opencoded this (probably before it was macroisied or we just
pasted it), so the radeon one is buggy, I should just go and compat_* all
of these then and we should be all happy?
It should be,
From: Andi Kleen a...@firstfloor.org
Date: Wed, 28 Oct 2009 05:36:11 +0100
On Tue, Oct 27, 2009 at 08:37:09PM -0700, David Miller wrote:
On sparc64, in order to make debugging easier, we trap any time
the kernel does a userspace access to a compat task and any
of the upper 32-bits are non
From: Arnd Bergmann a...@arndb.de
Date: Thu, 19 Feb 2009 15:19:01 +0100
On Wednesday 18 February 2009, David Miller wrote:
drm: Only use DRM_IOCTL_UPDATE_DRAW compat wrapper for compat X86.
Only X86 32-bit uses a different alignment for unsigned long long
than it's 64-bit counterpart
From: Andrew Morton a...@linux-foundation.org
Date: Thu, 19 Feb 2009 15:27:26 -0800
eg:
arch/xtensa/include/asm/shmparam.h
#define SHMLBA ((PAGE_SIZE DCACHE_WAY_SIZE)? PAGE_SIZE : DCACHE_WAY_SIZE)
But including linux/shm.h here seems a bit silly. We'll see..
If DRM even builds on
drm: radeon: Fix unaligned access in r300_scratch().
In compat mode, the cmdbuf-buf 64-bit address cookie can
potentially be only 32-bit aligned. Dereferencing this as
64-bit causes expensive unaligned traps on platforms like
sparc64.
Use get_unaligned() to fix.
Signed-off-by: David S. Miller
Ben, I'm pretty sure you're hitting this too on powerpc. Every time a
32-bit process tries to upload cliprects it's going to fail with
-EFAULT or similar.
Nothing in userspace checks the return value for errors, etc. :-/
The only reason I caught this is because I have a debugging check on
From: Benjamin Herrenschmidt b...@kernel.crashing.org
Date: Thu, 19 Feb 2009 08:59:50 +1100
Could that be related to the kernel spewing a bunch of
[drm:drm_update_drawable_info] *ERROR* Failed to copy cliprects from userspace
Yep, that is exactly caused by this bug.
Ok, this is the last DRM bug I am aware of with Radeon on sparc64.
What kills me is that I fixed this bug 6 or 7 years ago :)
drm: Preserve SHMLBA bits in hash key for _DRM_SHM mappings.
Platforms such as sparc64 have D-cache aliasing issues. We
cannot allow virtual
From: Sedat Dilek sedat.di...@googlemail.com
Date: Sun, 15 Feb 2009 10:28:29 +0100
unfortunately, your latest DRM patch [1] is broken while building
against Linux-2.6.25-rc5.
This is my patch-series:
Did you read my patch postings? I said my work was relative
to dri-next, as sparc64 also
From: Dave Airlie airl...@gmail.com
Date: Sat, 14 Feb 2009 17:42:02 +1000
On Sat, Feb 14, 2009 at 4:09 PM, David Miller da...@davemloft.net wrote:
1) Mis-sizes the GART table save buffer, it uses PAGE_SIZE instead
of the constant 4096 to determine how many GART entries
From: Benjamin Herrenschmidt b...@kernel.crashing.org
Date: Sat, 14 Feb 2009 20:07:54 +1100
I did some research, and it does appear that the GART does read the
PTEs from the VRAM using the Host Data Path. This means the surface
control byte swapping settings are applied.
So for depths
This allocates a physical surface for the PCI GART table, this way no
matter what other surface configurations exist the GART table will
always be seen by the hardware properly.
We encode the file pointer of the virtual surface allocate using a
special cookie value, called PCIGART_FILE_PRIV. On
From: David Miller da...@davemloft.net
Date: Sat, 14 Feb 2009 01:11:45 -0800 (PST)
From: Benjamin Herrenschmidt b...@kernel.crashing.org
Date: Sat, 14 Feb 2009 20:07:54 +1100
We can do that by registering a surface from the kernel to cover the
GART I suppose, and clean things a bit so
From: Michel Dänzer mic...@daenzer.net
Date: Sat, 14 Feb 2009 10:59:59 +0100
On Sat, 2009-02-14 at 01:51 -0800, David Miller wrote:
This allocates a physical surface for the PCI GART table, this way no
matter what other surface configurations exist the GART table will
always be seen
From: Benjamin Herrenschmidt b...@kernel.crashing.org
Date: Thu, 12 Feb 2009 21:35:59 +1100
Oh BTW something else to be careful with, though I suppose it's working
some what by accident right now... when the GART is in the frame buffer
it gets applied the current fb swapper setting... ouch !
drm: ati_pcigart: Fix limit check in drm_ati_pcigart_init().
The variable 'max_pages' is ambiguous. There are two concepts
of pages being used in this function.
First, we have ATI GART pages which are always 4096 bytes.
Then, we have system pages which are of size PAGE_SIZE.
Eliminate the
The PCI GART table initialization code treats the GART table mapping
unconditionally as a kernel virtual address.
But it could be in the framebuffer, for example, and thus we're
dealing with a PCI MEM space ioremap() cookie. Treating that as a
virtual address is illegal and will crash some
The buffers mapped by the PCI GART can be written to by the device,
not just read.
For example, this happens via the RB_RPTR writeback on Radeon.
So we can't use PCI_DMA_TODEVICE else we'll get protection faults
on IOMMU platforms.
Signed-off-by: David S. Miller da...@davemloft.net
---
The memory behind ring_rptr can either be in ioremapped memory
or a vmalloc() normal kernel memory buffer.
However, the code unconditionally uses DRM_{READ,WRITE}32() (and thus
readl() and writel()) to access it.
Basically, if RADEON_IS_AGP then it's ioremap()'d memory else it's
vmalloc'd
The address needs to be a GART relative address, rather than a PCI
DMA address.
Signed-off-by: David S. Miller da...@davemloft.net
---
drivers/gpu/drm/radeon/radeon_cp.c | 15 ---
1 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cp.c
These are not supposed to be booleans, they are
supposed to be bit masks.
Signed-off-by: David S. Miller da...@davemloft.net
---
drivers/gpu/drm/radeon/radeon_drv.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_drv.h
From: Benjamin Herrenschmidt b...@kernel.crashing.org
Date: Thu, 12 Feb 2009 21:35:59 +1100
Oh BTW something else to be careful with, though I suppose it's working
some what by accident right now... when the GART is in the frame buffer
it gets applied the current fb swapper setting... ouch !
From: Dave Airlie airl...@gmail.com
Date: Thu, 12 Feb 2009 21:23:13 +1000
are you on a PCI or PCIE card, I've no idea what buses you have on sparc64.
On the PCI cards the GART table will always be in main memory.
PCIE always in VRAM.
PCI-E
From: Dave Airlie airl...@gmail.com
Date: Thu, 12 Feb 2009 21:26:51 +1000
On Thu, Feb 12, 2009 at 8:15 PM, David Miller da...@davemloft.net wrote:
David, this work is against your drm-next branch.
Here are a collection of bug fixes for the Radeon DRM support. Most
of them have to do
From: Dave Airlie [EMAIL PROTECTED]
Date: Mon, 2 Apr 2007 09:44:41 +1000
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(),
From: Dave Airlie [EMAIL PROTECTED]
Date: Mon, 2 Apr 2007 14:08:13 +1000
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
From: Dave Airlie [EMAIL PROTECTED]
Date: Mon, 2 Apr 2007 15:15:48 +1000
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
51 matches
Mail list logo
