Re: [git pull] drm fixes for v4.12-rc1

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

Re: [PATCH] vt_buffer: drop console buffer copying optimisations

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) -

Re: [PATCH] vt_buffer: drop console buffer copying optimisations

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

Re: Please revert nouveau.

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

Re: Please revert nouveau.

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.

Re: 2.6.35-rc4-git3: Reported regressions from 2.6.34

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            

Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34

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

Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34

[ 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: 2.6.34-rc6-git2: Reported regressions from 2.6.33

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

Re: 2.6.34-rc3-git6: Reported regressions from 2.6.33

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

Re: 2.6.34-rc3-git6: Reported regressions from 2.6.33

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

Re: [Regression, post-rc2] Commit a5ee4eb7541 breaks OpenGL on RS780 (was: Re: Linux 2.6.34-rc3)

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

Re: [Regression, post-rc2] Commit a5ee4eb7541 breaks OpenGL on RS780 (was: Re: Linux 2.6.34-rc3)

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

Re: [Regression, post-rc2] Commit a5ee4eb7541 breaks OpenGL on RS780 (was: Re: Linux 2.6.34-rc3)

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

Re: [Regression, post-rc2] Commit a5ee4eb7541 breaks OpenGL on RS780 (was: Re: Linux 2.6.34-rc3)

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

Re: [git pull] drm fixes

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

Re: 2.6.34-rc2: Reported regressions from 2.6.33

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)

Re: [git pull] drm request 3

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?

Re: [git pull] drm request 3

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

Re: [git pull] drm request 3

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

Re: Making Xorg easier to test (was Re: [git pull] drm request 3)

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

Re: [git pull] drm request 3

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.

Re: [git pull] drm request 3

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.

Re: [git pull] drm request 3

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

Re: Making Xorg easier to test (was Re: [git pull] drm request 3)

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.

Re: [git pull] drm request 3

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

Re: [git pull] drm request 3

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

Re: [git pull] drm request 3

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

Re: [git pull] drm request 3

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

Re: [git pull] drm request 3

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

Re: [git pull] drm request 3

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

Re: [git pull] drm request 3

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

Re: [git pull] drm request 3

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

Re: [git pull] drm request 3

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

Re: [git pull] drm request 3

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

Re: [git pull] drm request 3

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

Re: [git pull] drm request 3

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

Re: [git pull] drm request 3

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

Re: [git pull] drm request 3

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

Re: [git pull] drm request 3

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

Re: [git pull] drm request 3

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

Re: [git pull] drm request 3

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

Re: [git pull] drm request 3

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

Re: [git pull] drm request 3

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

Re: [git pull] drm request 3

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

Re: [git pull] drm request 3

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,

Re: [git pull] drm request 3

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

Re: [git pull] drm request 3

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

Re: [git pull] drm request 3

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

Re: [git pull] drm request 3

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

Re: [git pull] drm request 3

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

Re: [git pull] drm request 2

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

Re: [git pull] drm request 2

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

Re: [git pull] drm request 2

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

Re: [git pull] drm request 2

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

Re: [git pull] drm request 2

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

Re: [git pull] drm request 2

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

Re: [PATCH][RFC] time: add wait_interruptible_timeout macro to sleep (w. timeout) until wake_up

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

Re: hung bootup with drm/radeon/kms: move radeon KMS on/off switch out of staging.

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

Re: hung bootup with drm/radeon/kms: move radeon KMS on/off switch out of staging.

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: [

Re: Radeon KMS regression still present in 2.6.33-rc6

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

Re: Radeon KMS regression still present in 2.6.33-rc6

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

Re: Radeon KMS regression still present in 2.6.33-rc6

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

Re: [PATCH] DRM / i915: Fix resume regression on MSI Wind U100 w/o KMS

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,

Re: [PATCH] DRM / i915: Fix resume regression on MSI Wind U100 w/o KMS

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,

Re: [PATCH] DRM / i915: Fix resume regression on MSI Wind U100 w/o KMS

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

Re: [git pull] drm

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,

Re: [git pull] drm nouveau pony for Xmas.

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

Re: [git pull] drm

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?

Re: [git pull] drm

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

Re: [git pull] drm

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

Re: [git pull] drm

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

Re: [git pull] drm

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

Re: [git pull] drm

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

Re: [git pull] drm

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

Re: [git pull] more drm kms code

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

Re: Linux 2.6.31-rc7

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

Re: Linux 2.6.31-rc7

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

Re: Linux 2.6.31-rc7

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

Re: Linux 2.6.31-rc7

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

Re: Linux 2.6.31-rc7

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

Re: 2.6.31-rc5: Reported regressions from 2.6.30

. 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

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

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.

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.

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.

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.

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.

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.

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 - fixes + radeon KMS (part 2)

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

Re: [git pull] drm fixes

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

Re: 2.6.30-rc6: Reported regressions from 2.6.29

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:

Re: 2.6.30-rc6: Reported regressions from 2.6.29

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

Re: [git pull] drm-next

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

Re: [git pull] drm-next

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

Re: [git pull] drm-next

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

Re: your mail

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

Re: [PATCH] drm: Rip out the racy, unused vblank signal code.

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

Re: [git pull] drm-fixes

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

Re: [git pull] drm-fixes

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   2   3   >