[arch-general] regression in nouveau ?
Hello all, over the past few months I have installed Arch on a number of systems, all of them used for quite intensive audio work (think of systems with > 1000 jack ports). All of them have worked flawlessly, no latency problems even with the standard kernel. Today I installed one more, on exactly the same HW as the previous one which was something like 6 weeks ago. Main difference is probably kernel 2.6.33 instead of 32. This system is completely unusable: almost anything 'graphical' - opening or closing windows, changing workspaces, etc. will generate showers of xruns. Using nouveau's 'no_accel' option solves the xruns, audio is as stable as it has ever been. But the system is again useless - just scrolling an xterm up one line takes a second or so. Nor has using this option been necessary before (all of the previous installs use nouveau). So has anything changed in nouveau that can explain this ? Any solutions ? TIA, -- FA O tu, che porte, correndo si ? E guerra e morte !
On Mon, May 24, 2010 at 11:00 PM, <fons@kokkinizita.net> wrote:
Hello all,
over the past few months I have installed Arch on a number of systems, all of them used for quite intensive audio work (think of systems with > 1000 jack ports). All of them have worked flawlessly, no latency problems even with the standard kernel.
Today I installed one more, on exactly the same HW as the previous one which was something like 6 weeks ago. Main difference is probably kernel 2.6.33 instead of 32.
This system is completely unusable: almost anything 'graphical' - opening or closing windows, changing workspaces, etc. will generate showers of xruns.
Using nouveau's 'no_accel' option solves the xruns, audio is as stable as it has ever been. But the system is again useless - just scrolling an xterm up one line takes a second or so. Nor has using this option been necessary before (all of the previous installs use nouveau).
So has anything changed in nouveau that can explain this ? Any solutions ?
Never heard of similar regression before. Can you try using http://aur.archlinux.org/packages.php?K=kernel26-nouveau-git and http://aur.archlinux.org/packages.php?K=xf86-video-nouveau-git ? If you still have the same problems with git, you should ask upstream (irc freenode #nouveau or ML http://lists.freedesktop.org/mailman/listinfo/nouveau) http://nouveau.freedesktop.org/wiki/FrontPage But it would help to have as much precision as possible about what is the latest version of each nouveau component that worked, and what is the first that is bad, i.e. minimizing the regression window. Also note the first item about latency on this page : http://nouveau.freedesktop.org/wiki/ToDo
On Mon, May 24, 2010 at 11:42:54PM +0200, Xavier Chantry wrote:
Never heard of similar regression before. Can you try using http://aur.archlinux.org/packages.php?K=kernel26-nouveau-git and http://aur.archlinux.org/packages.php?K=xf86-video-nouveau-git ?
Would that be possible at all, given 24.3.2010 posted by xavier Merge of 2.6.34-rc2. On Monday, nouveau git tree went straight from 2.6.32 to 2.6.34-rc2. One backlight API change in 2.6.34-rc2 breaks compatibility with older kernels (< 2.6.34-rc2), so people doing out-of-tree builds will have to update their kernel to rc2. Alternatively, you could try to revert the backlight commit. The last thing I want is to get entangled in a recursive 'update to the latest' game. I tried the inverse today - downgrading nouveau to the version used on the machines that do work. Same problem, the older version wants a kernel < 2.6.33, and gods knows where things will end if I go that route. This is not about hacking and having fun with bleeding edge versions. Apart from the machine that doesn't work (and I don't expect anything more than what all distros since a year or two have been able to provide OOTB), there's 9000 Euro of audio hardware sitting idle. I don't mind having to tweak things, do a lot of configuration manually, etc. etc., but I do expect things to work when they go into core/extra, or at least have a fallback available. There is none, AFAICS. Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !
On Wed, May 26, 2010 at 12:32 AM, <fons@kokkinizita.net> wrote:
I don't mind having to tweak things, do a lot of configuration manually, etc. etc., but I do expect things to work when they go into core/extra, or at least have a fallback available. There is none, AFAICS.
I don't know what you are saying. Just use nvidia. or nv or vesafb. Or if none of the drivers suits you, just use a different brand. Or if none of linux graphic drivers suits you, then use a different os.
On Wed, May 26, 2010 at 01:32:39AM +0200, Xavier Chantry wrote:
On Wed, May 26, 2010 at 12:32 AM, <fons@kokkinizita.net> wrote:
I don't mind having to tweak things, do a lot of configuration manually, etc. etc., but I do expect things to work when they go into core/extra, or at least have a fallback available. There is none, AFAICS.
I don't know what you are saying. Just use nvidia. or nv or vesafb.
If you can tell me how to install nv on current Arch I'd be most obliged. I installed the package, and modprobe (and all others) just tell me there's no such module. Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !
On 25 May 2010 16:32, <fons@kokkinizita.net> wrote:
On Mon, May 24, 2010 at 11:42:54PM +0200, Xavier Chantry wrote:
Never heard of similar regression before. Can you try using http://aur.archlinux.org/packages.php?K=kernel26-nouveau-git and http://aur.archlinux.org/packages.php?K=xf86-video-nouveau-git ?
Would that be possible at all, given
24.3.2010 posted by xavier Merge of 2.6.34-rc2. On Monday, nouveau git tree went straight from 2.6.32 to 2.6.34-rc2. One backlight API change in 2.6.34-rc2 breaks compatibility with older kernels (< 2.6.34-rc2), so people doing out-of-tree builds will have to update their kernel to rc2. Alternatively, you could try to revert the backlight commit.
The last thing I want is to get entangled in a recursive 'update to the latest' game.
Um, one of the packages he suggested you build is a GIT kernel with nouveau merged in, which will work fine.
I tried the inverse today - downgrading nouveau to the version used on the machines that do work. Same problem, the older version wants a kernel < 2.6.33, and gods knows where things will end if I go that route.
This is not about hacking and having fun with bleeding edge versions. Apart from the machine that doesn't work (and I don't expect anything more than what all distros since a year or two have been able to provide OOTB), there's 9000 Euro of audio hardware sitting idle.
I don't mind having to tweak things, do a lot of configuration manually, etc. etc., but I do expect things to work when they go into core/extra, or at least have a fallback available. There is none, AFAICS.
The binary nvidia driver? Also, I seriously doubt that the devs would have let this go to extra if they personally experienced this problem. And, nouveau is still in development, so you get what you sign up for, to some extent.
Ciao,
--
FA
O tu, che porte, correndo si ? E guerra e morte !
-- Tavian Barnes
On Tue, May 25, 2010 at 05:33:36PM -0600, Tavian Barnes wrote:
The binary nvidia driver?
Has latency problems as well, which is why people doing serious audio are using nv. If someone can tell me how to get it installed on current Arch I'd be most happy to use nv.
Also, I seriously doubt that the devs would have let this go to extra if they personally experienced this problem. And, nouveau is still in development, so you get what you sign up for, to some extent.
True, and that it not a real problem. But as long as nouveau is still in this state, it would be wise to provide an alternative. AFAICS, you just can't use nv anymore with current Arch. Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !
On 26 May 2010 08:56, <fons@kokkinizita.net> wrote:
On Tue, May 25, 2010 at 05:33:36PM -0600, Tavian Barnes wrote:
The binary nvidia driver?
Has latency problems as well, which is why people doing serious audio are using nv.
If someone can tell me how to get it installed on current Arch I'd be most happy to use nv.
Also, I seriously doubt that the devs would have let this go to extra if they personally experienced this problem. And, nouveau is still in development, so you get what you sign up for, to some extent.
True, and that it not a real problem. But as long as nouveau is still in this state, it would be wise to provide an alternative. AFAICS, you just can't use nv anymore with current Arch.
Yeah you can. nv isn't a kernel module though, it's just an Xorg driver, still using UMS. To use it, 1) Blacklist nouveau and nvidia 2) Install xf86-video-nv 3) Set Driver to "nv" in xorg.conf And, even if nv doesn't work for you, there's always xf86-video-vesa and xf86-video-fbdev.
Ciao,
-- FA
O tu, che porte, correndo si ? E guerra e morte !
-- Tavian Barnes
On Wed, May 26, 2010 at 09:22:15AM -0600, Tavian Barnes wrote:
Yeah you can. nv isn't a kernel module though, it's just an Xorg driver, still using UMS. To use it,
1) Blacklist nouveau and nvidia 2) Install xf86-video-nv 3) Set Driver to "nv" in xorg.conf
And, even if nv doesn't work for you, there's always xf86-video-vesa and xf86-video-fbdev.
Many thanks ! I did as you suggested. Booting the default image failed with what looked like a very long backtrace and froze the machine. But booting fallback worked, and after an mkinitcpio also the default worked. Result: rock-stable audio, and the display is a fast as it needs to be. Again many thanks, finally I can start using this system. BTW, what is the official advantage of KMS ? Having RL 3 and ttys that do not depend on a video driver seems like a good thing (TM) to me. Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !
Excerpts from fons's message of 2010-05-26 22:50:43 +0200:
On Wed, May 26, 2010 at 09:22:15AM -0600, Tavian Barnes wrote:
Yeah you can. nv isn't a kernel module though, it's just an Xorg driver, still using UMS. To use it,
1) Blacklist nouveau and nvidia 2) Install xf86-video-nv 3) Set Driver to "nv" in xorg.conf
And, even if nv doesn't work for you, there's always xf86-video-vesa and xf86-video-fbdev.
Many thanks !
I did as you suggested. Booting the default image failed with what looked like a very long backtrace and froze the machine.
But booting fallback worked, and after an mkinitcpio also the default worked.
Result: rock-stable audio, and the display is a fast as it needs to be.
Again many thanks, finally I can start using this system.
BTW, what is the official advantage of KMS ? Having RL 3 and ttys that do not depend on a video driver seems like a good thing (TM) to me.
Ciao,
Glad it works for you now. KMS was advertised mainly with he following features: - TTY in native resolution and hence nicer to look at - shorter delay when switching from X to TTY -- Regards, Philipp ----- "Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan
On 05/26/10 17:01, Philipp Überbacher wrote:
KMS was advertised mainly with he following features: - TTY in native resolution and hence nicer to look at - shorter delay when switching from X to TTY
- can implement power-saving features - ability to run X as non-root - ...probably some more things that google would tell us quickly
Excerpts from fons's message of 2010-05-26 00:32:22 +0200:
On Mon, May 24, 2010 at 11:42:54PM +0200, Xavier Chantry wrote:
Never heard of similar regression before. Can you try using http://aur.archlinux.org/packages.php?K=kernel26-nouveau-git and http://aur.archlinux.org/packages.php?K=xf86-video-nouveau-git ?
Would that be possible at all, given
24.3.2010 posted by xavier Merge of 2.6.34-rc2. On Monday, nouveau git tree went straight from 2.6.32 to 2.6.34-rc2. One backlight API change in 2.6.34-rc2 breaks compatibility with older kernels (< 2.6.34-rc2), so people doing out-of-tree builds will have to update their kernel to rc2. Alternatively, you could try to revert the backlight commit.
The last thing I want is to get entangled in a recursive 'update to the latest' game.
I tried the inverse today - downgrading nouveau to the version used on the machines that do work. Same problem, the older version wants a kernel < 2.6.33, and gods knows where things will end if I go that route.
This is not about hacking and having fun with bleeding edge versions. Apart from the machine that doesn't work (and I don't expect anything more than what all distros since a year or two have been able to provide OOTB), there's 9000 Euro of audio hardware sitting idle.
I don't mind having to tweak things, do a lot of configuration manually, etc. etc., but I do expect things to work when they go into core/extra, or at least have a fallback available. There is none, AFAICS.
Ciao,
As someone else suggested, I'd try the nv driver. It's generally worse than nouveau in its graphics performance, but it's usable. It's what has been used for years by those who didn't want to use the proprietary nvidia driver. It used to work o.k. for me with regards to audio, but I never used very low frame settings (never under 128). The proprietary driver is also an option but it used to perform worse with regards to audio than nv. Mileage seems to vary with every version. The other option I see is trying to duplicate the setup you have on your other machines. The packages should be in pacmans cache. There may be an automatic or semi-automatic way to do this. Then I'd test new kernel/nouveau versions and see whether the situation improves. Sadly audio performance / locks /latency seems to be not on graphics driver developers minds at all. -- Regards, Philipp ----- "Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan
On Wed, May 26, 2010 at 2:08 AM, Philipp Überbacher <hollunder@lavabit.com> wrote:
Sadly audio performance / locks /latency seems to be not on graphics driver developers minds at all.
It's definitely not their primary focus. But if you open a bug report saying "that commit greatly increased latency" and you can prove it, you can be sure they will do something about it. The work to provide good, detailed, and useful bug reports is in user's hands, not developers'. When the users don't do their homework, regressions remain.
On Wed, May 26, 2010 at 09:54:26AM +0200, Xavier Chantry wrote:
On Wed, May 26, 2010 at 2:08 AM, Philipp Überbacher <hollunder@lavabit.com> wrote:
Sadly audio performance / locks /latency seems to be not on graphics driver developers minds at all.
It's definitely not their primary focus. But if you open a bug report saying "that commit greatly increased latency" and you can prove it, you can be sure they will do something about it.
I will. But my first concern ATM is to get this system in a usable state - that's what the customer pays me for. On of the many things I tried before even posting was to use the nv driver. Modified the xorg.conf, but for some reason, the system goes on using nouveau regardless. ** Is it still possible to use nv on today's Arch ? ** I've used nv for years without any problem. The reason to prefer it over nvidia was not ideological - nvidia has latency problems as well, and I never needed 3D acceleration. Looking at the xrun statistics in function of audio period size, it looks like current nouveau is blocking audio (either by dis- abling interrupts, or by locking a shared HW resource) for about 3-4 ms. *No* driver today should ever do that - it's really late 1990's performance.
The work to provide good, detailed, and useful bug reports is in user's hands, not developers'. When the users don't do their homework, regressions remain.
Agreed. Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !
On Wed, May 26, 2010 at 10:46 AM, <fons@kokkinizita.net> wrote:
Looking at the xrun statistics in function of audio period size, it looks like current nouveau is blocking audio (either by dis- abling interrupts, or by locking a shared HW resource) for about 3-4 ms. *No* driver today should ever do that - it's really late 1990's performance.
As I said, there are some people who are willing to help in that area. But without people like you reporting and testing, it's never going to happen. We need audio guys and graphics/drivers guys allocating some times to work together and resolve the issues. There was at least one nouveau developer trying to help out : http://lists.freedesktop.org/archives/nouveau/2010-February/004981.html But the reporter just disappeared. I just talked to him on IRC #nouveau, here are some extracts : 23:01 < stillunknown> you need someone with the time and the itch to pursue this 23:02 < stillunknown> because the magic solution isn't going to drop from the sky 23:02 < stillunknown> we can help, but that goes for anyone 23:07 < stillunknown> shining: my first guess is that we disable irq's in a few code paths 23:14 < stillunknown> my guess is the irq disabling around fences, since that is the only thing that i suspect will trigger frequently when rendering 23:16 < stillunknown> makes me wonder why we disable irq's there 23:16 < stillunknown> mailinglist time :-) 23:18 < stillunknown> ah for nv04 i can understand, but for the rest not so much If there is no one to test / experiment, I am afraid the situation won't improve anytime soon. And just a reminder that these people help/work for free in their limited spare time :)
On Wed, May 26, 2010 at 11:26:58PM +0200, Xavier Chantry wrote:
As I said, there are some people who are willing to help in that area. But without people like you reporting and testing, it's never going to happen. We need audio guys and graphics/drivers guys allocating some times to work together and resolve the issues.
There was at least one nouveau developer trying to help out : http://lists.freedesktop.org/archives/nouveau/2010-February/004981.html But the reporter just disappeared.
The name (Adrian Knoth) rings a bell, he's probably on one of Linux Audio lists. And if he's using firewire audio he must be one of the 'brave ones' - it's not obvious at all ATM. So Maarten Maathuis looks like the one to get in contact with.
And just a reminder that these people help/work for free in their limited spare time :)
Most of us who write and contribute things are in that situation... Isn't there any contact/overlap between the nv and nouveau teams ? The nv devs got this right (it also took them some time IIRC), but that shows it's possible. As you have probably been reading, meanwhile I've been able to get nv in place instead of nouveau, and things just work. The 'blacklist' trick should be documented somewhere - it's obvious once you know it but it surely didn't pop up by itself. Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !
On Mon, May 24, 2010 at 11:42 PM, Xavier Chantry <chantry.xavier@gmail.com> wrote:
Also note the first item about latency on this page : http://nouveau.freedesktop.org/wiki/ToDo
Ah now I remember where this latency TODO came from, there actually was one report about bad latency earlier that month (february) : You could read the following thread : http://lists.freedesktop.org/archives/nouveau/2010-February/004960.html There were several tips about modifying xorg driver to improve things and get more debug information. Did you also switch from UMS -> KMS between 2.6.32 and 2.6.33 ? It's easy to tell, it brings you native (high) resolution in tty / consoles. Maybe the problem always existed in the KMS path, and it's the only way now.
participants (5)
-
fons＠kokkinizita.net
-
Isaac Dupree
-
Philipp Überbacher
-
Tavian Barnes
-
Xavier Chantry