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 requests after rc1.
If Ve
On Thu, Jan 29, 2015 at 3:57 PM, Greg Kroah-Hartman
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 couple of) truly outra
On Wed, Jan 28, 2015 at 8:11 PM, Dave Airlie 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")
- drivers/video/console/*
On Sun, Jan 16, 2011 at 3:44 PM, Ben Skeggs 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. For example, on
On Sun, Jan 16, 2011 at 12:00 PM, Anca Emanuel 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 case, that would be at
On Thu, Jul 8, 2010 at 4:33 PM, Rafael J. Wysocki wrote:
>
> Unresolved regressions
> --
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16353
> Subject : 2.6.35 regression
> Submitter : Zeev Tarantov
> Date : 2010-07-05 13:04 (4 days
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 "f
[ 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 (Re
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
> Date : 2010-
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 descripti
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
> Date : 2010-03-24 15:49 (15 days old)
> First-Bad
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
too? Or was the original patch yours?
Linus
--
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 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, 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 & RADEON_I
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
> Date : 2010-03-09 16:47 (13 days old)
Fixed by commit 3836a03d978e68b
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
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 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
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?
>
>
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
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 VE
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
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 stron
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 rea
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
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
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
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-deve
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 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:
>
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 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 f
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, 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 pr
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 ju
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, 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 t
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 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 - som
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 nouve
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 c
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
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
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 personall
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 interf
On Thu, 4 Mar 2010, Jesse Barnes wrote:
> On Thu, 4 Mar 2010 10:36:55 -0800
> Jesse Barnes 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 what gives. Guidan
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 compa
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
> Date: Fri Feb 12 10:27:35 2010 +1000
>
> drm/nouveau: new gem
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 t
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 thr
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 exp
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 t
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 defau
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 i
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 e
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 m
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 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 ne
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 necess
On Sat, 30 Jan 2010, Johannes Hirte wrote:
>
> This is caused by commit 42590a75019a50012f25a962246498dead42843
>
> Fix is already posted:
>
> http://marc.info/?l=linux-kernel&m=126428141429200&w=2
Goodie. Kevin, can you test the patch from FUJITA Tomonori in that thread
("http://marc.info/?
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)
> 0x811c159
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
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 t
On Sat, 9 Jan 2010, Rafael J. Wysocki wrote:
>
> From: Rafael J. Wysocki
>
> 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,
> which brok
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 firmware!
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, r
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 hav
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 ac
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 pa
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
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 quest
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 wo
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, 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 col
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 gene
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 w
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 redetecti
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 a
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 won
amp;m=124811234302786&w=4
> Handled-By: Alan Stern
> Alan Cox
Commit c56d3000861 should fix this.
> Regressions with patches
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13891
> Subject :
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 in
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 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 useles
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.
>
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
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
> > cras
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 openini
On Wed, 17 Jun 2009, Dave Airlie wrote:
>
> Linus can you pull this tree?
I hate pulling trees when I know there are _known_ bugs.
Even during the merge window. The rest of the -rc series is for fixing up
bugs, yes, but not bugs that were introduced on purpose.
Linus
--
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
On Fri, 5 Jun 2009, Dave Airlie wrote:
> On Fri, Jun 5, 2009 at 3:42 PM, Markus
> Trippelsdorf wrote:
> > On Thu, Jun 04, 2009 at 04:39:50AM +0100, Dave Airlie wrote:
> >>
> >> Hi Linus,
> >>
> >> Please pull the 'drm-fixes' branch from
> >> ssh://master.kernel.org/pub/scm/linux/kernel/git/airli
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
> Date : 2009-05-16 16:28 (1 days old)
> References: http://marc.info/
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 po
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 th
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 me
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 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 ou
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
-
On Mon, 26 Jan 2009, Linus Torvalds wrote:
> >
> > There must be easier ways to do so I think.
>
> Um. Yes. Something like
>
> git am -s -C1
>
> which ends up requiring just a single line of context for the patch to
> apply, exactly like the GNU &#x
1 - 100 of 298 matches
Mail list logo
