Home Home > Tag > 12.2
Sign up | Login

Deprecation notice: openSUSE Lizards user blog platform is deprecated, and will remain read only for the time being. Learn more...

Posts Tagged ‘12.2’

ATI/AMD catalyst fglrx legacy updated to new 13.1 version

January 24th, 2013 by

Proprietary AMD/ATI Catalyst fglrx legacy 13.1 (8.97.100.7-1) rpm released

Notice

This release concern only radeon HD2xxx to HD4xxx owners

The published Catalyst fglrx rpm version support openSUSE version from 11.4 to 12.3 (new repository) and also Tumbleweed (thus also kernel 3.8x series).
For testing with the next openSUSE 12.3 just use the new openSUSE_12.3 repo

The release note

Feedback

Sebastian Siebert will publish an article today, and he’s looking for feedback about the patches included to make it working on 12.3, so don’t hesitate to get in touch with him

Comments:

As I didn’t have a gpu card of this series, I can’t test it before publishing the rpm like for normal fglrx. If someone has a spare hd2xxx or hd4xxx, Could he(she) contact me?

Have fun!

Proprietary AMD/ATI Catalyst fglrx 13.1 (9.012-1) rpm released

January 21st, 2013 by

Proprietary AMD/ATI Catalyst fglrx 13.1 (9.012-1) rpm released

Sorry this article should have been published Saturday, but some trouble (error in a updated module) locked me outside of lizards), Thanks to Matthew to have fix it in the meantime

fglrx 13.1 amd-ccc & fgl_glxgears

fglrx 13.1 amd-ccc & fgl_glxgears

Notice

This release concern only owners of radeon HD5xxx or above.
For older gpu, the fglrx-legacy is still 12.6, and thus didn’t work with Kernel 3.6, 3.7, 3.8
SDB:AMD_fgrlx_legacy
Beware of that fact, and prefer the free open-source radeon driver which came out of the box from your openSUSE distribution.

Release note about 13.1

This Catalyst fglrx version support openSUSE version from 11.4 to 12.3 (new repository) and also Tumbleweed (thus also kernel 3.8x series).
For testing with the next openSUSE 12.3 just use the new openSUSE_12.3 repo

Release Note

A release note is available on AMD website

Fixed issues

    [368958]: Driver release version is added to GL_VERSION
    [367282]: Bblank VGA display after resume from suspend
    [367245]: X crash for AMD PowerXpress™ A+I High-Performance mode on Ubuntu 12.10
    [366820] Performance of Valve Linux games
    [366805]: Segmentation fault when exit QtOpenGL applications such as AMD CodeXL
    [366425]: Xserver getting exit upon resume from suspend on RHEL 5.8
    [364107]: VariBright not working when change AMD PowerPlay™ settings in AMD Catalust Control Center:LE
    [363638]: VariBright doesn’t work after resume from suspend on “Trinity” platform
    [350759]: Flickering cursor when run some full-screen OpenGL games with CrossFire enabled
    [347895]: OpenGL performance on “Southern Islands” ASICs
    [344996]: 16 re-frames doesn’t work for H.264 @Level 5.1
    [337240]: Corruption when resize the Konsole window
    [304016]: One display goes black after changing from multi-display desktop from single independent

Sebastien Siebert making script

Sebastian Siebert post about 13.1

If you have any problems with the driver, don’t be afraid to report to Sebastian (German and English bugreports are gladly accepted).
he will try, as far as I am able to reproduce the bug. Together with the necessary system information, he will go directly to the right place at AMD to have the bug fixed in the next driver release.
Thank you very much, Sebastian.

See below what to do in case of troubles.

Or you can also ping him on irc (freespacer)

fglrx & 3d effects kde 4.9.5 on openSUSE 12.2

fglrx & 3d effects kde 4.9.5 on openSUSE 12.2


(more…)

AMD/ATI fglrx 9.002 Catalyst 12.10 released

October 28th, 2012 by

AMD/ATI Catalyst fglrx 12.10 (9.002) released

Notice

This release concern only owners of radeon HD5xxx or above. For older gpu, the fglrx-legacy is still 12.6
SDB:AMD_fgrlx_legacy

fglrx-12.10-s1

fgl_glxgears & AMD CCLE

Release note about 12.10

This Catalyst version support 11.4 to Tumbleweed (thus also kernel 3.6x series). Unfortunately the latest factory didn’t upgrade successfully and failed to create its initrd. So no fglrx 12.10 for factory actually, but you are debugging free radeon, don’t you? 🙂

I’m translating here a note from Sebastian Siebert last post

I have a small request: If you have any problems with the driver, don’t be afraid to report to me (I take German and English bugreports are also gladly accepted). I will try, as far as I am able to reproduce the bug. Together with the necessary system information, I will go directly to the right place at AMD to have the bug fixed in the next driver release.
Thank you very much, Sebastian.

See below what to do in case of troubles.

Or you can also ping him on irc (freespacer)

(more…)

AMD/ATI Catalyst fglrx & fglrx legacy news

July 31st, 2012 by

AMD/ATI Catalyst fglrx & fglrx legacy news

Explanations of Hell

During June, with the version 12.6 (8.980) AMD decide to drop support for legacy radeon chipset from its main fglrx package and drop the time based release cycle.
So now if you are the owner of radeon hd2xxx to hd4xxx chipset family you will have to use the -legacy- version of fglrx, and
consequently if you have a radeon hd5xxx or above, you have to use the standard fglrx driver.
Then start the hell. After getting the new developed script from Sebastian Siebert, I will be able to offer the two versions. Unfortunately the two drivers can’t coexist in the same repository, the legacy drivers wants to install in place of normal one. This imply another limitation, you can’t have two graphics cards with differents generation at the same time.
So I decide to clarify (is that possible? :-)) the mess, and split the drivers in two distinct repositories. I use that excuse to also change the ati (deprecated brand name) and use new names: amd-fglx and amd-fglrx-legacy.
Don’t worry about your exiting installation, I will provide a symlink during the next 6 months at least for the old repositories. But read carefully the rest of the story, and apply any changes needed to your installation to be sure to continue to safely use the right driver.
I also decided to remove any version below 12.4 (8.961) in all repositories, except for openSUSE 11.2.

I need your help to spread those informations around the internet, and be sure that every user that need this driver know where and how to use it right. Tweet FbLike G+ forums, mailing list, private blogs Go now!

Release note about 12.6 and legacy 8.97.100

Both version can handle kernel 3.4 and 3.5

Sebastian Siebert warn us about the state of legacy

AMD catalyst control center and fgl_glxgears

These cards with the unofficial support of openSUSE 12.2 can run in the ideal case, just under 2 more years. However, one must keep in mind that the legacy driver is looked after, while AMD continues and eliminates errors found, but will not add new features. This can mean, among other things, that the next version of GNOME or KDE will not run with its 3D effects, especially when used with a desktop or Tumbleweed extra repository.

Sebastian’s post

If you have any comments, be do on his blog. Don’t be shy, you can leave there the result of test in english too 😀
or ask in forums, irc and ping freespacer.
See below what to do in case of troubles.

12.2 Factory rpms are presently available, use at your own risk, and report bugs in forums and Sebastian blogs.
Anyways, factory and 12.2 should keep their effort on debuging and testing widely the free radeon driver.

(more…)

Optimizing a boot time, aka 2 second boot

July 26th, 2012 by

During the hackweek, I have decided to take a look onto a boot process to realize, how fast can be boot of the system. This metric is considered as a not important, especially in a geek community. But I am sure that this is an important part of user experience. Following text is mean to share my investigations with you – but you should be aware what you are doing, since I have been focused on reducing the boot time as much as possible.

A bit of theory

Basically you have three possibilities how to make your boot fast.

  1. Start things in a parallel.
  2. Start things on demand.
  3. Start less things.

… root of all evil …

“Premature optimization is the root of all evil.”

And I will modestly extend Donald Knuth’s sentence, that the blind optimization as well. So if we have to optimize something, we have to know what to do. Fortunately systemd comes with an excellent tool called systemd-analyze, which show us our boot in several ways.

The simple run of command prints the time we spent in a boot and in which phase.

# systemd-analyze
Startup finished in 8480ms (kernel) + 30873ms (userspace) = 39353ms

That was the default (minimal X system) 12.2 installation on my EEE 701 netbook, which is probably not suitable to work as nowadays cellsmarphone, because is pathetically slow. On the other hand is it a perfect playground, so let’s continue with an investigating.

The overall time is nice, but won’t help to know what’s going on. There are two more subcommands, blame and plot shows us more information about the boot. The first shows the services sorted by the start time. The ones boots so long are those we should kicked off as a first ones.

Let see what slow the boot down a most

$ systemd-analyze blame | head
 11385ms network.service
  5664ms SuSEfirewall2_init.service
  5575ms systemd-vconsole-setup.service
  3032ms ntp.service
  2840ms remount-rootfs.service
  2230ms postfix.service
  2021ms network-remotefs.service
  1925ms cpufreq.service
  1661ms SuSEfirewall2_setup.service
  1506ms xdm.service

And take look at the output of systemd-analyze plot command

openSUSE 12.2 boot diagram

You can see, that there is a long chain of SuSEfirewall2_init -> network -> network-remotefs -> SuSEfirewall2_setup tooks several dozen seconds to be finished. And nothing is wrong with that, but that is the server solution, not what I want to have on my tiny laptop.

Making a laptop boot twice more faster

So having the complex dependencies of several services in mind, I decided to mask some of them. Masking in systemd world means the service cannot be started using systemd, so it becomes invisible for it. I masked those

  • network.service – will be replaced by NetworkManager, which is more suitable for laptops usage
  • SuSEfirewall2_init and SuSEfirewall2_setup – even if it’s a security feature, a risc for laptop, which is mostly offline and running only sshd is pretty small.
  • ntp.service, network-remotefs.service – those does not makes a sense on my laptop
  • postfix.service – I do not want to send emails via /usr/bin/sendmail
  • cpufreq.service – it is even not supported by my CPU (grep rc.cpufreq /var/log/messages)

Do not forget to install NetworkManager and the applet and change the /etc/sysconfig/network/config and reboot.

Now we have

$ systemd-analyze
Startup finished in 8528ms (kernel) + 11123ms (userspace) = 19652ms

Using an strace with systemd

Now we have a list of worse services

$ systemd-analyze blame | head -n 10
  5476ms xdm.service
  4172ms systemd-vconsole-setup.service
  3950ms systemd-modules-load.service
  2781ms remount-rootfs.service
  1848ms NetworkManager.service
  1439ms media.mount
  1426ms systemd-remount-api-vfs.service
  1419ms dev-hugepages.mount
  1411ms dev-mqueue.mount
  1371ms sys-kernel-debug.mount

and a proper boot chart

bootchart w/o network.service

It shows us an another botleneck, which is the systemd-vconsole-setup.service, because it delay the sysinit.target, which is very early boot stage. In case like this, we can only use strace to know, what is taking too long. And debugging is pretty straightforward in systemd world. All we have to do is copy service file to /etc/systemd/system and change the ExecStart

ExecStart=/usr/bin/strace -f -tt -o /run/%N.strace /lib/systemd/systemd-vconsole-setup

and reboot. Then you will find the output in /run/systemd-vconsole-setup.strace with a timestamps. Looking there it’s obvious calling hwinfo --bios is extremely expensive in this stage. You can speedup the unit by setting the KBD_NUMLOCK to yes or no in /etc/sysconfig/keyboard, or you can try to mask it completely I did.

The next service needs to closer look was system-modules-load – then strace says that it spent 2(!) in init_module() for module microcode. I disabled it as well, even for CPUs needs it can’t be recommended.

Native systemd units

There is one tiny init script called purge-kernels, which starts for 300ms according blame. And in this particular case systemd alternative will be way more effective

$ cat /etc/systemd/system/purge-kernels.service
[Unit]
Description=Purge old kernels
After=local_fs.target
ConditionPathExists=/boot/do_pure_kernels

[Service]
Type=oneshot
ExecStart=/sbin/purge-kernels

because systemd only do one stat on the file and do not run it at all, so this service disappears from the blame at all.

The kernel time

There is one interesting thing about kernel time – 8 seconds spent there seems to be a lot to me. Simple ls on /boot gave me a pointer

$ ls -lh /boot/vmlinuz-* /boot/initrd-*
-rw-r--r-- 1 root root  14M Jul 24 11:03 /boot/initrd-3.4.4-1.1-desktop
-rw-r--r-- 1 root root 4.7M Jul 10 15:48 /boot/vmlinuz-3.4.4-1.1-desktop

The initrd is huge, around three times bigger than kernel? So let’s try to find what caused that. Every package can add it’s own setup script into /lib/mkinitrd/scripts/ thus let ask rpm whose did that

$ rpm -qf /lib/mkinitrd/scripts/setup-* | sort -u
cifs-utils-5.5-2.2.2.i586
cryptsetup-1.4.2-3.2.1.i586
device-mapper-1.02.63-26.1.1.i586
dmraid-1.0.0.rc16-18.2.1.i586
kpartx-0.4.9-3.1.1.i586
lvm2-2.02.84-26.1.1.i586
mdadm-3.2.5-3.3.2.i586
mkinitrd-2.7.0-62.2.1.i586
multipath-tools-0.4.9-3.1.1.i586
plymouth-scripts-0.8.5.1-1.3.1.noarch
splashy-0.3.13-35.1.1.i586

So I went through a list and try to uninstall things I do not need

  • cifs-utils – if you do not have any windows disc to mount, you can remove, but no impact on initrd size
  • cryptsetup – this is a popular service for laptops, but I do not have any luks device, so let skip that. It removes a half of Yast as well, so I saved 18M of space, but a little in initrd.
  • device-mapper, dmraid, kpartx and lvm2 – cannot be easily removed as too much low-level stuff depends on it
  • mdadm – no linux md devides, skip that
  • mkinitrd – removal can reduce initrd to zero, but we would need own kernel
  • multipath-tools – no multipath device, let skip that

  • plymouth-scripts – who would need the “fancy” boot when booting so fast? – reducing initrd to 8.9M
  • splashy – the same – and reducing initrd to 6.6M

So the things intended to provide fancy boot actually bloats the system. Let’s measure the impact of those changes

$ systemd-analyze
2781ms (kernel) + 4999ms (userspace) = 7780ms

bootchart w/o network.service

And that’s all folks …?

There are a lot of factors slowing our boot – reducing it to 8 seconds is not that bad. One have to go carefully through blame and plot output to see what delays his computer in start. I would say making NetworkManager default one at least when installing laptop pattern would be nice and simple change as well as continue on “systemdifization” of openSUSE.

There are few other tricks, which get us closer to the target time, but I’ll post them next day.

AMD/ATI fglrx 8.961 Catalyst 12.4 (build 5) rpms available for openSUSE 12.2, 12.1, 11.4, 11.3 & Tumbleweed

May 31st, 2012 by

Those informations are obsolete now : please consult //lizards.opensuse.org/?p=8888

AMD/ATI Catalyst 12.4 / fglrx 8.961 (build 5 revised) rpms are available

Quick Résumé about 12.4

The first version available in repository from April 30th has trouble with any kernel never than 3.3

Sebastian Siebert has create a patch for kernel 3.4+, I google translate quickly his blog article here.

AMD catalyst control center and fgl_glxgears

May 30th 2012
WARNING! Who use AMD Catalyst 12.4 driver from the AMD installer will inevitably have problems with kernel 3.4.0 and higher (eg from the Tumbleweed repo).
Because the driver is designed, at least up to kernel 3.3.x on openSUSE only.
Here are some examples of errors when compiling a kernel module fglrx:

error: 'cpu_possible_map' undeclared (first use in this function) ... 
error: implicit declaration of function '__save_init_fpu'

Or when you load the fglrx kernel module:

 A FATAL: Error inserting fglrx (/ lib/modules/3.4.0-25-desktop/extra/fglrx.ko): Unknown symbol in module, or unknown parameter (see dmesg)
 The output of dmesg: fglrx: Unknown symbol old_rsp (err 0) 

I now have an updated makerpm-amd script and replaced the older packaging from script to a newer.
At this point, I say thank you for the helpful feedback and also to the AMD community that their minds have assembled to investigate the problem and make it to the world.
The packaging script I maintain, need no extra time. The kernel patches for the compiler error I’ve already entered for this month in the AMD installer. In the next AMD Catalyst we will not need this patch anymore. Since the patch will be included in the source fglrx from AMD for the next version.

Small warning for stormy times: AMD plans to graphics chips R6xx/R7xx not lead to the main branch.
The graphics card series Radeon HD 2000, 3000 and 4000 are affected (Phoronix has reported). The last supported version is expected to be AMD Catalyst 12.7. However, AMD has turned in and stored in a separate branch of this, it weiterzupflegen there. It means that no new feature added, but only fix bugs. openSUSE 11.4 and 12.1 is still supported and maintained. The chances are good that the driver to get there will also run on an X-Server 1.12.
The next openSUSE version 12.2 in July, will should use the X-server 1.10, so that the driver theoretically run on this version of openSUSE. For this I’ll create a separate makerpm-amd script, that this legacy continues as usual drivers to install on openSUSE 11.4 and 12.1 (possibly 12.2) and will also provide the necessary kernel patches. AMD believes that these chipsets will already extensive support from the free Radeon driver. So it is time to order a new graphics card in order to continue the beta drivers from AMD Catalyst testing on openSUSE. A new graphics card was already planned last October. So I will finally keep your hardware donation for the new graphics card.

See more at Sebastian’s blog.
Don’t be shy, you can leave there the result of test in english too 😀
or ask in forums, irc and ping freespacer.
See below what to do in case of troubles.

The rpms version 8.961 are available from Thursday May 31

(more…)