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

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

<    1   2   3