Hi, Mesa 17.0.2 backports can now be installed from the updates ppa. Have fun testing, and feel free to file any bugs you find using ‘apport-bug mesa’.
Hi, I’ve prepared X server 1.19.2 along with the driver rebuilds for zesty on the staging ppa here:
It also comes with mesa 17.0.1 while it’s still stuck in zesty-proposed… Anyway, give it a shot and report success/failure stories on the FFe bug. The plan is to migrate this to zesty next week.
That said, 13.0.4 is now available on ppa:ubuntu-x-swat/updates for both 16.04 and 16.10. The PPA carries latest LLVM 3.9.1 package as well which fixes some bugs for Radeon users. There were some games released recently that benefit from these, which is one more reason why these backports were (finally) made available.
Update: Ubuntu 17.04 will ship with Mesa 17, so that’s the version which will be backported to 16.04 next.
Previous LTS point-releases came with a renamed Mesa backported from the latest release (as in mesa-lts-wily for instance) . Among other issues this prevented providing newer Mesa backports for point-release users without getting a mess of different versions.
That’s why from 16.04.2 onwards Mesa will be backported unrenamed, and this time it is the last version of the 12.0.x series which was also used in 16.10. It’s available now in xenial-proposed, and of course in yakkety-proposed too (16.10 released with 12.0.3). Get it while hot!
I’ve uploaded Mesa 12.0.4 for xenial and yakkety to my testing PPA for you to try out. 16.04 shipped with 11.2.0 so it’s a slightly bigger update there, while yakkety is already on 12.0.3 but the new version should give radeon users a 15% performance boost in certain games with complex shaders.
Please give it a spin and report to the (yakkety) SRU bug if it works or not, and mention the GPU you tested with. At least Intel Skylake seems to still work fine here.
The ppa now has 12.0.5 for both xenial & yakkety. There have been no comments to the SRU bug about success/failure, so feel free to add a comment here instead.
Earlier this week Debian unstable and Ubuntu Yakkety switched to load the ‘modesetting’ X video driver by default on Intel graphics gen4 and newer. This roughly maps to GPU’s made since 2007 (965GM->). The main reason for this was to get rid of chasing after upstream git, because there hasn’t been a stable release in nearly three years and even the latest devel snapshot is over a year and a half old. It also means sharing the glamor 2D acceleration backend with radeon/amdgpu, which is a nice change knowing that the intel SNA backend was constantly slightly broken for some GPU generation(s).
Xserver 1.18.4 was released this week with a number of backported fixes to glamor and modesetting driver from master, so the time was right to make the switch now while both Stretch and Yakkety are still on the development phase. So I wrote a small patch for the xserver to load intel driver only on gen2 & gen3 which can’t do glamor efficiently. Newer Intel GPU’s will fall back to modesetting. This approach is good since it can be easily overridden by dropping a conffile to /etc/X11 that uses something else.
I’ve seen only one bug filed that was caused by this change so far, and it turned out to be a kernel bug fixed in 4.6 (Yak will ship with 4.8). If you see something strange like corrupt widgets or whatnot after upgrading to current Yakkety, verify it doesn’t happen with intel (‘cp /usr/share/doc/xserver-xorg-video-intel/xorg.conf /etc/X11’ followed by login manager restart or reboot) and file a bug against xserver-xorg-core (verify xdiagnose is installed, then run ‘ubuntu-bug xserver-xorg-core)’. We’ll take it from there.
Xserver 1.18.2 was released yesterday, and it’s now available for xenial on the staging PPA. It has a fair number of fixes for glamor, DRI2/DRI3/Present and others. Plan is to move it to the main repository next week. The PPA also has a minor update to xserver-xorg-video-intel, and the latest release candidate for Mesa 11.2.0 which has a feature-freeze exception bug filed. Feel free to add comments about success/failure there, and for xserver/intel file a bug against the source package (xorg-server, x-x-v-intel). Happy testing!
In case someone hasn’t noticed yet, fglrx has been removed from Xenial. There are a couple of reasons for this. First of all, the driver did not support XServer 1.18 which we wanted to get in for 16.04. But more importantly, AMD asked us earlier this year to migrate to the open driver stack since fglrx would not be supported in 16.04. With this move we will have the shared core of AMD’s new driver stack in place and ready for adding the proprietary pieces of their hybrid stack, once they have been released later this year.
What does this mean in practice?
- machines currently running fglrx will be automatically migrated to the open source driver stack (kernel, mesa, X) after an upgrade to 16.04 – fglrx package will be removed and xorg configuration moved aside so that the OSS driver can run
- users relying on pro/workstation class features (latest OpenGL, OpenCL, ..) probably should stay on a supported release until the hybrid stack is available
We’re trying to make the transition as painless as possible. Alberto Milone has already backported basically every amdgpu kernel driver commit from 4.5 to the xenial kernel. So even the latest AMD GPU’s should be working fine with modesetting, power management etc. We’re also tracking changes to the Xserver to make sure any fixes applied to master also get in the 1.18.x branch for next point release, especially changes to the glamor acceleration library which newer radeons use for speeding up 2D graphics on Xorg. And there’s also a feature-freeze exception filed for Mesa 11.2… So I’d say we’re as well prepared as we humanly can!
One thing that needs some more thought is what happens when users on 14.04.[2,3,4] get migrated to 14.04.5 with supported HWE stack from 16.04. We’ll discuss this with AMD and hopefully come up with something so that in August when 14.04.5 is released things work as good as or even better than before 🙂
Long time no blog.. sheesh, didn’t realize it has been nearly four years since the previous post.
Anyway, I’ve pushed updated SSSD packages to ppa:sssd/updates. This includes 1.8.5 LTM (“Long Term Maintenance”) bugfix release for precise, which I inted to SRU sometime soon. I’ve also pushed 1.9.2 for quantal, which is basically the version that got in raring on Monday. Feel free to test and report bugs on launchpad, as usual.
The University I work for has offered a UNIX (secure-) shell service for its students and staff for over 15 years now. The servers have so far been AIX (Power/PPC), OSF1/Digital Unix/Tru64 UNIX (alpha) and Solaris (sparc64).They’ve also been mostly top-of-the-line (=expensive) boxes so they can handle hundreds of simultaneous users without problems. The exotic hardware and OS also makes it more secure, since script-kiddies tend to use more common hardware and OS’s.
Now we are in the process of phasing out the last remaining publicly available Tru64 server (ES40/4x667MHz, 5GB RAM), and possibly with a x86-64 server running Linux (Ubuntu 8.04). The reason why Linux has not been an option before is that some people claim it still can’t handle the load of ~1000 users reading their email (pine/alpine/mutt) while chatting with irssi or whatnot. Also the security problems have been brought up. It’s possibly a lot easier to break into Linux than Solaris, because Linux is more common and easy to get (although there is Opensolaris now..).
What I’d like to know is that are there people already running Linux on similar purpose, and how does it perform? What measures can be taken against the security threats (preferably something that doesn’t involve building a custom kernel)? What else should be taken into account to make it scale better?
The x86 hardware is at least a lot cheaper. Eight-core blade with 64GB of RAM is less than 8kEUR.. but could it handle 700 users like the ES40 does with ease?