On Thu, May 11, 2017 at 11:00 PM, Dave Airlie wrote:
>
> It also has an amdgpu fixes pull, with lots of ongoing work on Vega10
> which is new in this kernel and is preliminary support so may have a
> fair bit of movement.
Note: I will *not* be taking these kinds of pull
On Wed, Jan 28, 2015 at 8:11 PM, Dave Airlie airl...@redhat.com wrote:
Linus, this came up a while back I finally got some confirmation
that it fixes those servers.
I'm certainly ok with this. which way should it go in? The users are:
- drivers/tty/vt/vt.c (Greg KH, tty layer)
-
On Thu, Jan 29, 2015 at 3:57 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
I can take this through the tty tree, but can I put it in linux-next and
wait for the 3.20 merge window to give people who might notice a
slow-down a chance to object?
Yes. The problem only affects one (or a
On Sun, Jan 16, 2011 at 12:00 PM, Anca Emanuel anca.eman...@gmail.com wrote:
In 2.6.37-git5 with the revert, the boot screen is changing the resolution.
With this version, it don't.
So, can you make a nice report of that - along with 'dmesg' for _both_
cases - to the right people?
In this
On Sun, Jan 16, 2011 at 3:44 PM, Ben Skeggs bske...@redhat.com wrote:
I've tested a bit here, current git with the revert does appear to work
fine for me.
So Anca has a 8800GT - is that what you're testing?
Also, there may be things like FB config issues and/or kernel command
line arguments.
On Thu, Jul 8, 2010 at 4:33 PM, Rafael J. Wysocki r...@sisk.pl wrote:
Unresolved regressions
--
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16353
Subject : 2.6.35 regression
Submitter : Zeev Tarantov zeev.taran...@gmail.com
Date
On Wed, 9 Jun 2010, Rafael J. Wysocki wrote:
That has a reverting the commit fixes it, and a confirmation from Nick
Bowler.
Eric, Carl: should I just revert that commit? Or do you have a fix?
This one is reported to have been fixed already. Closed now.
Heh. That fixed already
[ Added lots of cc's to direct specific people to look at the regressions
that may or may not be theirs... ]
On Wed, 9 Jun 2010, Rafael J. Wysocki wrote:
* Quite a few of the already reported regressions may be related to the bug
fixed by 386f40c86d6c8d5b717ef20620af1a750d0dacb4
On Tue, 4 May 2010, Rafael J. Wysocki wrote:
Unresolved regressions
--
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15880
Subject : Very bad regression from 2.6.33 as of 1600f9def
Submitter : Alex Elsayed eternal...@gmail.com
Date
On Wed, 7 Apr 2010, Rafael J. Wysocki wrote:
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15718
Subject : File corruption regression on NFS related to commit
1f36f774
Submitter : Boaz Harrosh bharr...@panasas.com
Date : 2010-03-24 15:49 (15 days
On Wed, 7 Apr 2010, Al Viro wrote:
No, it's not the same thing; the fix is to have nfs -d_revalidate()
return an error on failing open attempt (in insane codepath that has
-d_revalidate() handling open()). Confirmed to work by reporter...
Ok, can you do the proper changelog description
On Thu, 1 Apr 2010, Rafael J. Wysocki wrote:
OK, I've verified that partial revert (below) is sufficient.
Hmm. Through the DRM merge I just did, this area actually conflicted, and
the resolved version is now
if ((rdev-family = CHIP_RV380)
(!(rdev-flags
On Thu, 1 Apr 2010, Alex Deucher wrote:
Clemems' PCI quirk: RS780/RS880: disable MSI completely patch is the
right approach I think. Note that it's only devices hung off the int
gfx pci to pci bridge that have broken MSI (gfx and audio). MSI works
fine on the PCIE slots. I have a
On Thu, 1 Apr 2010, Alex Deucher wrote:
What I meant to say was MSI works fine on bridges other than the
bridge the internal gfx lives on. quirk_disable_msi() just disables
MSI on the devices on that particular bridge as far as I understand
it, but I'm by no means an expert on the PCI
On Fri, 2 Apr 2010, Rafael J. Wysocki wrote:
Appended, with sign-offs and changelog.
---
Subject: PCI quirk: RS780/RS880: disable MSI completely
Hmm. Isn't this missing a
From: Clemens Ladisch clem...@ladisch.de
too? Or was the original patch yours?
Linus
On Tue, 30 Mar 2010, Dave Airlie wrote:
Actually Linus, don't bother, consider this revoked, I'm going to kill
the GPU reset code and re-send this tomorrow, its just a mess to get it
back out of the tree at this point,
but I realised I was falling back to the old ways, of putting
On Sun, 21 Mar 2010, Rafael J. Wysocki wrote:
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15495
Subject : Flood of SELinux denials on polkitd
Submitter : Alex Villacis Lasso avill...@ceibo.fiec.espol.edu.ec
Date : 2010-03-09 16:47 (13 days old)
On Sat, 6 Mar 2010, Sergio Monteiro Basto wrote:
You shouldn't expect, by now, upgrade drm kernel without update libdrm
or at least recompile libdrm.
Why?
Why shouldn't I expect that? I already outlined exactly _how_ it could be
done.
Why are people saying that technology has to suck?
On Sat, 6 Mar 2010, Sergio Monteiro Basto wrote:
On Sat, 2010-03-06 at 09:40 -0800, Linus Torvalds wrote:
Why are people making excuses for bad programming and bad technology?
Is not bad technology is new technology, the API have to change faster ,
unless you want wait 2 years until get
On Fri, 5 Mar 2010, C. Bergström wrote:
staging != stable
This really is being repeated, over and over. But it's irrelevant.
It's irrelevant because it's just a bad _excuse_.
That driver is used in production environments. That's _reality_. The
whole staging thing is nothing more than a
On Fri, 5 Mar 2010, Carlos R. Mafra wrote:
Whereas everytime I wanted to do that with Xorg it was such a pain that
I want to keep away from that mess.
Actually, take it from me: Xorg is _pleasant_ to test these days.
Ok, so that's partly compared to the mess it _used_ to be, but it's
On Fri, 5 Mar 2010, 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.
Now, I agree that that would have been the optimal setup from a testing an
user standpoint, but I think it's a bit too strong.
On Fri, 5 Mar 2010, Alan Cox wrote:
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. Linus ordered them to merge it.
On Fri, 5 Mar 2010, Alan Cox wrote:
Yeah perhaps Fedora should have pushed an update that was smart enough to
handle the Nouveau old/new ABI before the patch went upstream. Hindsight
is an exact science.
Alan - it seems you're missing the whole point.
The thing I objected to, in the VERY
On Fri, 5 Mar 2010, Daniel Stone wrote:
FWIW, Option ModulePath in xorg.conf lets you more or less do this;
the usual approach is to install your new server + drivers into a
separate prefix.
The thing is, Xorg has - and I think for _very_ good reasons - deprecated
using xorg.conf at all.
On Fri, 5 Mar 2010, Alan Cox wrote:
So the watershed moment was _never_ the Linus merged it. The watershed
moment was always Fedora started shipping it. That's when the problems
with a standard upstream kernel started.
Why is that so hard for people to understand?
So why are you
On Fri, 5 Mar 2010, Daniel Stone wrote:
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?
I think that's what David ended up saying, but I
Hmm. What the hell am I supposed to do about
(II) NOUVEAU(0): [drm] nouveau interface version: 0.0.16
(EE) NOUVEAU(0): [drm] wrong version, expecting 0.0.15
(EE) NOUVEAU(0): 879:
now?
What happened to the whole backwards compatibility thing? I wasn't even
warned that
On Thu, 4 Mar 2010, Linus Torvalds wrote:
I see the commit that does this was very aware of it:
commit a1606a9596e54da90ad6209071b357a4c1b0fa82
Author: Ben Skeggs bske...@redhat.com
Date: Fri Feb 12 10:27:35 2010 +1000
drm/nouveau: new gem pushbuf
On Thu, 4 Mar 2010, Jesse Barnes wrote:
Whoa, so breaking ABI in staging drivers isn't ok? Lots of other
staging drivers are shipped by distros with compatible userspaces, but I
thought the whole point of staging was to fix up ABIs before they
became mainstream and had backwards compat
On Thu, 4 Mar 2010, Jesse Barnes wrote:
On Thu, 4 Mar 2010 10:36:55 -0800
Jesse Barnes jbar...@virtuousgeek.org wrote:
Yes Dave probably should have mentioned it in his pull request, but
that doesn't seem to be a good reason not to pull imo...
And now I see Dave did mention this, so
On Thu, 4 Mar 2010, Matthew Garrett wrote:
When you asked that nouveau was merged, people explicitly told you that
the reason it hadn't been was because the interface was unstable and
userspace would break. You asked that it be merged anyway, and now
you're unhappy because the interface
On Thu, 4 Mar 2010, Linus Torvalds wrote:
But none of that changes my basic objections. I didn't ask for nouveau to
be merged as staging - I asked it to be merged because a major distro uses
it.
Put another way: the issue of whether _I_ happen to see this personally or
not is kind
On Thu, 4 Mar 2010, Jesse Barnes wrote:
If marking the driver as staging doesn't allow them to break ABI when
they need to, then it seems like they'll have no choice but to either
remove the driver from upstream and only submit it when the ABI is
stable, or fork the driver and submit a new
On Thu, 4 Mar 2010, Matthew Garrett wrote:
If you'd made it clear that you wanted the interface to be stable
before it got merged, I suspect that it simply wouldn't have been merged
until the interface was stable.
What kind of excuse is that? It's we did bad things, but if we didn't do
On Thu, 4 Mar 2010, Matthew Garrett wrote:
You're asking volunteers who didn't ask for their driver to be merged to
perform more work in order to support users they didn't ask for.
And _you_ are making excuses for BAD TECHNICAL DECISIONS!
Come on! How hard is it to admit that that the
On Fri, 5 Mar 2010, Dave Airlie wrote:
At the moment in Fedora we deal with this for our users, we have
dependencies between userspace and kernel space and we upgrade the bits
when they upgrade the kernels, its a pain in the ass, but its what we
accepted we needed to do to get nouveau
On Thu, 4 Mar 2010, Matthew Garrett wrote:
IOW, we have a real technical problem here. Are you just going to continue
to make excuses about it?
I'm not questioning the fact that it would be preferable to provide
compatibility. But that compatibility doesn't come for free - someone
On Thu, 4 Mar 2010, Stephane Marchesin wrote:
In short, the don't break user space interfaces principle is making
user space code quality worse for everyone. And it makes our lives as
graphics developers pretty miserable actually
And _my_ point is that if you did a half-way decent job on
On Thu, 4 Mar 2010, Adam Jackson wrote:
On Thu, 2010-03-04 at 11:14 -0800, Linus Torvalds wrote:
On Thu, 4 Mar 2010, Matthew Garrett wrote:
If you'd made it clear that you wanted the interface to be stable
before it got merged, I suspect that it simply wouldn't have been merged
On Fri, 5 Mar 2010, Dave Airlie wrote:
Its nouveau project not X not DRM, stop generalising the situation.
Is it really just nouveau? I've not looked, but I bet the intel driver and
the radeon driver have _exactly_ the same oh, I'm the wrong version, I
will now kill myself behavior.
I
On Thu, 4 Mar 2010, Linus Torvalds wrote:
Is it really just nouveau? I've not looked, but I bet the intel driver and
the radeon driver have _exactly_ the same oh, I'm the wrong version, I
will now kill myself behavior.
Ok, I cloned the drm tree just to see, and it does seem like it's
On Fri, 5 Mar 2010, Dave Airlie wrote:
I'm not saying it doesn't happen in other drivers from time to time, but
when it does its treated as regression, for nouveau and STAGING that
isn't what the Nouveau project (which Stephane mostly speaks for) seems
to want at this stage.
The
On Fri, 5 Mar 2010, Dave Airlie wrote:
Speaking as distro maintainer here,
No because we've got versioned interfaces and we are happy to support them
yes it would be nice sometimes to dream about this, but its a major explosion
in
the testing matrix. You have to realise the more
On Fri, 5 Mar 2010, Ben Skeggs wrote:
The idea of staging was to allow for exactly the second problem, so why
are you surprised? The fact Fedora ships nouveau is irrelevant, we also
expect that for the most part people will be using our packages, which
deal with the ABI issues.
The fact
On Fri, 5 Mar 2010, Luc Verhaegen wrote:
libdrm is composed of the main libdrm, and several driver specific
libdrms today (... and libkms, yes).
It's actually not libdrm that is the primary issue, I'm sorry for saying
that.
It's the nouveau_drv.so thing - the actual X driver.
Anyway,
On Thu, 4 Mar 2010, Linus Torvalds wrote:
Anyway, since I had looked at the libdrm sources, I had most of this on my
machine anyway, so I've compiled it all, and am going to reboot and see if
I can make a few symlinks work.
IOW, right now I have this:
[r...@nehalem ~]# cd /usr
On Fri, 5 Mar 2010, Luc Verhaegen wrote:
In an ideal world, you shouldn't be forced to update anything except
some/all of the driver bits.
But the fact that libdrm is lumped together as it is, and that mesa is a
monolith, forces you to update a more significant portion of your
On Fri, 5 Mar 2010, Dave Airlie wrote:
wget
http://kojipkgs.fedoraproject.org/packages/xorg-x11-drv-nouveau/0.0.16/2.20100218git2964702.fc13/src/xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.src.rpm
rebuild + install.
This one doesn't work on F12.
It wants xorg-x11-server-devel
On Fri, 5 Mar 2010, Dave Airlie wrote:
if not then:
http://people.fedoraproject.org/~airlied/xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.test.src.rpm
That src rpm should be rebuildable on F12, I just removed the requires
on F13 stuff.
Well, that wants the new kernel, but I can
On Thu, 4 Mar 2010, Linus Torvalds wrote:
On Fri, 5 Mar 2010, Dave Airlie wrote:
if not then:
http://people.fedoraproject.org/~airlied/xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.test.src.rpm
That src rpm should be rebuildable on F12, I just removed the requires
on F13
On Tue, 2 Mar 2010, Linus Torvalds wrote:
I disabled it in the merge, since I had to fix up that file anyway. But
please don't make me do these so-called evil merges where I end up
modifying the thing I merge.
Never mind. I've unpulled the whole effin' mess since it doesn't even
compile
On Tue, 2 Mar 2010, Linus Torvalds wrote:
It's still code. And if the user didn't ask for it, it should damn well
not be there.
And I repeat: unless the feature cures cancer, it's not on by default.
Sometimes we split up _old_ features as config options, or do things that
are meant
On Mon, 1 Mar 2010, Dave Airlie wrote:
Same tree as yesterday with a warning + PPC build fix + fix for build on
x86 after PPC (I think I just validated Ingo).
Why is VGA_SWITCHEROO enabled by default?
We don't do things like that. New drivers and new features are _not_
enabled by
On Tue, 2 Mar 2010, Dave Airlie wrote:
because it does nothing on anything except the laptops in question and on
those it does nothing except add a control file in debugfs?
It's still code. And if the user didn't ask for it, it should damn well
not be there.
So how am I supposed to
On Wed, 3 Mar 2010, Dave Airlie wrote:
Did I mention that driver is in STAGING?
Staging is for _improving_ the quality of the drivers, not for making it
worse.
We still very much have quality standards. The staging tree is for things
to get in that don't quite _reach_ the standards we
On Wed, 3 Mar 2010, Dave Airlie wrote:
So can we get linux-next builds to build with *your* Kconfig? This should
cut down the amount of crap you see considerably.
No.
Dave, _think_ about what you're saying.
The absolute last thing we want to do is to make it easier for crap to
flow
On Fri, 26 Feb 2010, Rafał Miłecki wrote:
Following macro is soemthing that seems to work fine for us, but instead
introducing this to radeon KMS only, I'd like to propose adding this to whole
wait.h. Do you this it's something we should place there? Can someone take
this
patch for me? Or
On Thu, 4 Feb 2010, Ingo Molnar wrote:
Well, once i applied the revert i got no more hangs or crashes today, in lots
of bootups. This is fully repeatable - if i re-apply that commit with the
config i sent the hang happens again.
But that's just because when it was in staging, you'd never
On Thu, 4 Feb 2010, Alex Deucher wrote:
And if it crashes, he'll report a bug and we'll fix it.
Ok, you have a bug-report. See earlier in the thread:
btw., i just found another bug activated via this same commit, a boot hang
after DRM init:
[9.858352] [drm] Connector 1:
[
On Sat, 30 Jan 2010, Kevin Winchester wrote:
Thank you - the patch from FUJITA Tomonori corrected the issue.
I also tried out the additional patches from John Kacur. They did not
break anything that I could see, and the logic behind them seems
reasonable to me. They weren't necessary
On Sat, 30 Jan 2010, Kevin Winchester wrote:
I took a picture of the crash details:
http://picasaweb.google.ca/kjwinchester/LinuxKernelPanic#5432580230065271634
In case it helps, here is the gdb listing for the problem address:
(gdb) l *(radeon_agp_init+0x1d)
0x811c1592 is in
On Sat, 30 Jan 2010, Johannes Hirte wrote:
This is caused by commit 42590a75019a50012f25a962246498dead42843
Fix is already posted:
http://marc.info/?l=linux-kernelm=126428141429200w=2
Goodie. Kevin, can you test the patch from FUJITA Tomonori in that thread
On Sat, 9 Jan 2010, Jerome Glisse wrote:
On Fri, Jan 08, 2010 at 06:50:41PM -0800, Jesse Barnes wrote:
Linus, can we ever drop those old paths? Maybe after the new bits have
been around for awhile? Users of really old userspace stacks would
lose 3D support, but they'd still have 2D,
On Sat, 9 Jan 2010, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki r...@sisk.pl
Commit cbda12d77ea590082edb6d30bd342a67ebc459e0 (drm/i915: implement
new pm ops for i915), among other things, removed the .suspend and
.resume pointers from the struct drm_driver object in i915_drv.c,
On Sat, 9 Jan 2010, Rafael J. Wysocki wrote:
Which is functionally equivalent to my patch, because i915_suspend/resume()
won't be called by drm_class_suspend/resume() in the KMS case anyway.
Ahh, right you are - that class suspend function does a check for
DRIVER_MODESET, and only does the
On Fri, 11 Dec 2009, Jeff Garzik wrote:
F11 uses nouveau here. It is actually a pain to get 'nv' going as an
alternate -- bugs have been filed. Makes kernel dev more difficult for me. I
was actually told, by Fedora people, that I should be hacking on the Fedora
(rpm-based) kernel,
On Fri, 11 Dec 2009, Dave Airlie wrote:
Please pull the 'drm-nouveau-pony' branch from
PONIES! Yay! I lurve ponies!
And it works for me too. Needed to get the firmware from the fedora
project, and make sure that it loads as a module rather than built in (so
that it can find the
On Thu, 10 Dec 2009, Dave Airlie wrote:
The biggest missing feature [ ... ]
No, the biggest missing feature is that Fedora is _still_ shipping
Nouveau, and I'm _still_ not seeing Red Hat people actively trying to get
it merged into mainline.
What the _hell_ is going on?
On Thu, 10 Dec 2009, Xavier Bestel wrote:
Last time they were asked that, they wanted to be free of changing their
kernel/userspace interface before upstreaming.
I've heard all the excuses. If it isn't ready, they shouldn't ship it to
millions of people. And if it's ready, they should work
On Thu, 10 Dec 2009, Maarten Maathuis wrote:
You assume that Red Hat has full control over the project, which i
don't think is the case. The reason it isn't in staging yet (as far as
i know) is because of some questions over the copyright of some
(essential) microcode. Either the question
On Thu, 10 Dec 2009, Stephane Marchesin wrote:
I'm not sure why people are arguing so much over this, given that no
nouveau devs were at the kernel summit, and we only heard rumours
afterwards that there were complaints about us not being ready for
merging.
The thing is, my complaint is
On Thu, 10 Dec 2009, Alan Cox wrote:
But not only is Fedora not following the rules,
You changed the rules. You require a Signed-off-by:. Fedora can no more
add a signed off by than you can. It's not their code nor Red Hat's code
any more than they own the kernel because they pay
On Thu, 10 Dec 2009, C. Bergström wrote:
Thanks for the rather lengthly explanation, but in case you missed what people
are trying to say here..
With all due respect Linus..
patches welcome
The problem is that I have never even heard a Red Hat or Fedora person
actually acknoledge
On Fri, 11 Dec 2009, Dave Airlie wrote:
I'm going to see what Ben can do with a firmware loader and the ctxprogs,
we can send a patch that contains all the other bits of the driver, however
since the ctxprogs aren't currently something we can add Signed-off-by to,
someone else will have to
On Thu, 8 Oct 2009, Dave Airlie wrote:
Please pull the 'drm-linus' branch from
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus
Its had a recent merge because it was definitely getting non-trivial to
fixup,
non-radeon-kms: adds proper fb layer colormap
On Wed, 26 Aug 2009, Dave Airlie wrote:
3. Here's the thing, we do detect something has changed, we detect we no
longer have a monitor connected on the mac mini because the routing
for the DDC pins is insane and need special treatment in the driver.
That's the second thing - DDC in general
On Tue, 25 Aug 2009, mailing54 wrote:
Linus Torvalds schrieb:
Are you using the same config? It sounds very much like your -rc7 problems
are due to the Intel KMS (kernel mode setting) driver, which I know has had
problems on at least Mac Mini's. And I wonder if the -rc6 kernel deb used
On Wed, 26 Aug 2009, Zhenyu Wang wrote:
In my experience, the BIOS setup doesn't reflect what outputs should be
used at runtime, and certainly not the correct configuration of the
enabled outputs. For example, if we went to this, the giant monitor
attached to my laptop that I actually
On Wed, 26 Aug 2009, Dave Airlie wrote:
If you actually detected things _right_, none of this would be an issue.
But you don't. And you seem to have a really hard time even admitting
that. You try to re-detect things, and you SCREW UP.
This isn't anything to do with redetection, and
On Wed, 26 Aug 2009, Zhenyu Wang wrote:
We can't depend on any BIOS display config as you noted before our driver.
But you do. You depend on the even _less_ reliable existence of a VBT
table.
And our driver does more flexible config than VBIOS does.
If by flexible you mean doesn't work
. Wysocki r...@sisk.pl
Date : 2009-08-02 13:37 (1 days old)
Handled-By: Linus Torvalds torva...@linux-foundation.org
Patch : http://patchwork.kernel.org/patch/38774/
Ok, this is committed as 79896cf42f6a96d7e14f2dc3473443d68d74031d.
Bug-Entry : http
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.
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
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
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
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
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
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
On Tue, 16 Jun 2009, Ryan Hope wrote:
+#ifdef MODULE
module_init(radeon_init);
+#else
+late_initcall(radeon_init);
+#endif
You should never need something like that.
Just do
late_initcall(radeon_init);
and if it's a module (which doesn't have early vs late etc), it will
On Fri, 5 Jun 2009, Dave Airlie wrote:
On Fri, Jun 5, 2009 at 3:42 PM, Markus
Trippelsdorfmar...@trippelsdorf.de wrote:
On Thu, Jun 04, 2009 at 04:39:50AM +0100, Dave Airlie wrote:
Hi Linus,
Please pull the 'drm-fixes' branch from
On Sat, 16 May 2009, Rafael J. Wysocki wrote:
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13329
Subject : cifs_close: NULL pointer dereference
Submitter : Luca Tettamanti kronos...@gmail.com
Date : 2009-05-16 16:28 (1 days old)
References:
On Mon, 18 May 2009, Ingo Molnar wrote:
Btw., why did the patch (and the revert) make any difference to the
test? Timing differences look improbable.
It's the change from
!signal_group_exit(signal)
to
!sig_kernel_only(signr)
and quite frankly, I still don't see the
On Sun, 29 Mar 2009, Dave Airlie wrote:
This branch has a merge in it, due to conflicts with the Intel drm tree
you already pulled. I've asked Eric to not send you direct pulls, he
mentioned you said he should, but it really screws over my tree. I don't
mind direct pulls outside the
On Sun, 29 Mar 2009, Dave Airlie wrote:
My plans from now on are just to send you non-linear trees, whenever I
merge a patch into my next tree thats when it stays in there, I'll pull
Eric's tree directly into my tree and then I'll send the results, I
thought we cared about a clean merge
On Mon, 30 Mar 2009, Dave Airlie wrote:
- Don't merge upstream code at random points.
You should _never_ pull my tree at random points (this was my biggest
issue with early git users - many developers would just pull my current
random tree-of-the-day into their
On Fri, 27 Mar 2009, Eric Anholt wrote:
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel
drm-intel-next
Grr.
Guys, what the *hell* is wrong with you, when you can't even react to
trivial warnings and fix buggy code pointed out by
On Wed, 28 Jan 2009, Dave Airlie wrote:
I'm quite happy to push this, if nobody objects with a good reason.
Heh, since I was the one asking for this, I already applied it. If it
breaks something, people can blame me.
Linus
Dave,
you have some odd and slightly git usage model, which shows up in various
commits. Lookie here as an example from comit 335041ed:
Author: Jesse Barnes jbar...@virtuousgeek.org 2009-01-22 04:22:06
Committer: Dave Airlie airl...@redhat.com 2009-01-22 04:22:06
On Mon, 26 Jan 2009, Sam Ravnborg wrote:
Well I'm not 100% sure what happened for this patch, I suspect,
jbarnes sent patch a week
or two ago, it misapplied against the tree I had currently when
applied with git-am, it didn't work so I hand
applied the patch with patch and then did
1 - 100 of 263 matches
Mail list logo