Hi Linus,
3 fixes, one for an ongoing Intel VT-d/Ironlake GPU that I've been testing, and one kexec fix from Jerome for an issue reported on the list where the gpu writeback engines need to be switched off, along with a trivial fix from Alex.
Due to the size of the kexec fix I've decided to keep this pull small. (I have some kzalloc->kcalloc fixes to check on).
Dave.
The following changes since commit 45e713efe2fa574b6662e7fb63fae9497c5e03d4:
Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (2011-12-05 16:54:15 -0800)
are available in the git repository at:
git://people.freedesktop.org/~airlied/linux drm-fixes
Alex Deucher (1): drm/radeon/kms: fix return type for radeon_encoder_get_dp_bridge_encoder_id
Daniel Vetter (1): drm/i915: fix infinite recursion on unbind due to ilk vt-d w/a
Jerome Glisse (1): drm/radeon: disable possible GPU writeback early v3
drivers/gpu/drm/i915/i915_gem.c | 7 ++++++- drivers/gpu/drm/radeon/evergreen.c | 2 ++ drivers/gpu/drm/radeon/ni.c | 18 ++++++++++++++++++ drivers/gpu/drm/radeon/nid.h | 19 +++++++++++++++++++ drivers/gpu/drm/radeon/r100.c | 20 ++++++-------------- drivers/gpu/drm/radeon/r520.c | 2 +- drivers/gpu/drm/radeon/r600.c | 16 ++++++++++++++++ drivers/gpu/drm/radeon/radeon_asic.h | 2 ++ drivers/gpu/drm/radeon/radeon_encoders.c | 7 +++---- drivers/gpu/drm/radeon/rs600.c | 20 +++++++++++++++++++- drivers/gpu/drm/radeon/rs600d.h | 21 +++++++++++++++++++++ drivers/gpu/drm/radeon/rs690.c | 2 +- drivers/gpu/drm/radeon/rv515.c | 2 +- drivers/gpu/drm/radeon/rv770.c | 16 ++++++++++++++++ drivers/gpu/drm/radeon/rv770d.h | 20 ++++++++++++++++++++ 15 files changed, 151 insertions(+), 23 deletions(-)
On Tue, Dec 6, 2011 at 8:21 AM, Dave Airlie airlied@linux.ie wrote:
3 fixes, one for an ongoing Intel VT-d/Ironlake GPU that I've been testing, and one kexec fix from Jerome for an issue reported on the list where the gpu writeback engines need to be switched off, along with a trivial fix from Alex.
Quite frankly, I think it's too late for something like a kexec bugfix. Nobody cares. So kexec doesn't work - that's not something new. This doesn't smell like a regression to me. And the kcalloc things you mention *sound* like some kind of cleanup crap.
The DRM layer has been fairly good for a few releases, but I'm getting the feeling that I need to start pushing back, because I'm getting stuff that I don't think matters, and shouldn't be sent to me after -rc4.
So I'm not pulling this.
What the heck is up?
By now, I want fixes that either fix real regressions that people *care* about, or that help new unreleased hardware that people *will* care about and that cannot possibly mess up old users.
kexec? Who the f*ck cares? Really?
Linus
What the heck is up?
Well I do care about kexec but only due to being forced into caring about it for a certain enterprise distro that uses it a lot, so maybe I was a bit biased in this case, and I dislike random memory corruptions due to my subsystem even in the kexec case. Writing a random 0 dword somewhere in memory isn't that pretty and no fun to track down, when the kexec looks like it succeeds.
But I've no problem leaving it sitting around until -next.
The kzalloc->kcalloc ones are partly better integer overflow defence where userspace passes in a number of objects but I just need to make sure they are that and not cleanups, but I haven't gotten around to it yet.
Cool I'll resend just the Intel and obvious radeon one and stick the others into -next.
Dave.
On Tue, Dec 6, 2011 at 8:36 AM, Dave Airlie airlied@gmail.com wrote:
Well I do care about kexec but only due to being forced into caring about it for a certain enterprise distro that uses it a lot, so maybe I was a bit biased in this case, and I dislike random memory corruptions due to my subsystem even in the kexec case. Writing a random 0 dword somewhere in memory isn't that pretty and no fun to track down, when the kexec looks like it succeeds.
So having looked at the patch itself, I don't dislike the notion of making sure certain fields are nicely initialized. So I don't hate the patch itself, but quite frankly, to me it doesn't smell even *remotely* like "regression fix". I don't think this is something that has ever worked.
And I do realize that some enterprise distros want to use kexec, but at the same time I say "that's *their* problem". We know kexec hasn't been horribly reliable, anybody who uses it should have be taking that into account.
I hope kexec gets more reliable, but I *also* really hope that our RC series will calm down, and on the whole, weighing the two concerns, when we're talking about something that has never worked before either, I think the thing is pretty clear.
That said, if there is some other real use-case ("this fixes problems with the BIOS from Xyz initializing things to random crap"), I'd have no real objections to the patch itself.
So my complaint is really a "I want to be more anal about the later -rc patches, I feel we're slipping", not a "I hate the patch per se".
Linus
So having looked at the patch itself, I don't dislike the notion of making sure certain fields are nicely initialized. So I don't hate the patch itself, but quite frankly, to me it doesn't smell even *remotely* like "regression fix". I don't think this is something that has ever worked.
Well just for completeness I tracked it down to 724c80e1d630296d1324859e964d80d35007d83c which git describe shows as v2.6.36-rc5-456-g724c80e, so while it is a technical regression, it took a long time for anyone to notice.
I think we probably need a more invasive patch in any case, as there is still a race between when the drm midlayer calls pci_set_master and the sanity enforcement, which we should close by moving pci_set_master into the drivers (midlayer design yet again for the win).
so I'll leave it for -next.
Dave.
dri-devel@lists.freedesktop.org
-
Dave Airlie -
Dave Airlie -
Linus Torvalds