> On Fri, May 29, 2015 at 12:13 PM, Sergio Belkin <sebelk at gmail.com
> <https://admin.fedoraproject.org/mailman/listinfo/devel>> wrote:
> >* Hi, *>
> >* Could you tell me if anyone else is having this kind of issues: *>
> >* [vie may 29 07:01:22 2015] [drm] Initialized drm 1.1.0 20060810 *>*
> [vie may 29 07:01:22 2015] [drm] Memory usable by graphics device = 2048M *
> >* [vie may 29 07:01:22 2015] fb: switching to inteldrmfb from EFI VGA *>*
> [vie may 29 07:01:22 2015] [drm] Replacing VGA console driver *>* [vie
> may 29 07:01:22 2015] [drm] Supports vblank timestamp caching Rev 2 *>*
> (21.10.2013). *>* [vie may 29 07:01:22 2015] [drm] Driver supports
> precise vblank timestamp *>* query. *>* [vie may 29 07:01:22 2015] [drm]
> Initialized i915 1.6.0 20150130 for *>* 0000:00:02.0 on minor 0 *>* [vie
> may 29 07:01:22 2015] fbcon: inteldrmfb (fb0) is primary device *>* [vie
> may 29 07:01:22 2015] [drm:intel_set_pch_fifo_underrun_reporting *>*
> [i915]] *ERROR* uncleared pch fifo underrun on pch transcoder A *>* [vie
> may 29 07:01:22 2015] [drm:intel_pch_fifo_underrun_irq_handler [i915]] *>*
> *ERROR* PCH transcoder A FIFO underrun *>* [vie may 29 07:01:23 2015]
> i915 0000:00:02.0: fb0: inteldrmfb frame buffer *>* device * What exactly
> is your problem? What are the symptoms? Also bugzilla is
> a better place for those kind of things.
Interestingly I also see this error and usually it tends to be associated
with GNOME instability and lockups or crashes. There's a thread about
this, specifically in reference to Intel Haswell. I get crashes and
lockups occasionally and when this happens that error message scrolls
>>* Do you think that the average user with a clicking sound card or disk
*>>* corruption when suspending would be able to make the link to this new
> Even better ... the integrated mouse pointer on my external ThinkPad USB
> keyboard stops working if USB suspend is enabled for this device.
I get this same issue with my computer, but TLP doesn't suspend input
devices... or at least it should.
> +1 ... If the kernel isn't perfect, lets make the kernel perfect instead.
> Just my 2 cents.
The one thing I like about TLP would be the ability to tune the
machine based on power state. If the kernel or gnome or whatever can
do this, I applaud it. Something like this should be default and
tweak-able. This includes disk spin down time, bus powersave modes and
variable writeback rates.
It's quite clear that battery life sucks for the stock install... I
think some initiative should be taken regardless of the method. I'm
sure that laptops are the most effected by this.
I've started poking into packaging the mhvtl project for Fedora and
EPEL. This package also contains a kernel module, which normally works
fine - until you hit Secure Boot.
So I was wondering how to handle this the best way. AFAIK, there are
currently no plans to get the mhvtl.ko kernel module into the upstream
Some packages (VirtualBox, IIRC) can compile the kernel module
on-the-fly if it is missing during boot. That's an easy thing to
implement. But for secure boot, things gets complicated as the kernel
module needs to be signed.
I've played with mokutil and the sign-file script which is in
kernel-devel, based on this article . This all works fine. I could
easily install my own key, compile the mhvtl.ko module and sign it. And
then it was possible to load the module.
It's also important to remember that kernels do get updated. So when a
new kernel is installed, it is (to my knowledge) required to recompile
the module. If I'm mistaken, please educate me!
My current idea to solve this is to:
* Have a "preparation" script which the admin is required to run
on a new system. This scripts generates the needed key material and
runs mokutil which installs the key. It will then provide enough
information so that the admin can reboot the system and get the MOK
* Have a unit file which runs a ExecStartPre= script. This script
will check if the key material exists. If it does, it will check
if the mhvtl.ko module for the currently running kernel exists.
If the module is missing, it will compile it, sign it and load it.
Failures along the way will cause the unit file to fail all together.
When the ExecStartPre= script has completed successfully, it will
start the needed processes it normally would do.
Any thoughts or comments to this approach? Anyone got a better idea?
Yes, I do know it is not good to have the keying material for the
signing too easily available. So I'm also keen to hear ideas how to
protect the key better. With that said, I'm planning on only providing
access to the key file to the root user only. And I'll look into if I
can restrict the accesss even further with some SELinux rules (so only
the ExecStartPre= script can access it together with the "preparation"
Another thought ... Are there other packages who could benefit of such a
solution if it was made more generic? I'm willing to investigate into
this too, if there are more users out there ... Or if someone has
already done that - no need to reinvent the wheel!
The recently released libgdata-0.17.1 has bumped its soname. The
highlights are support for version 3 of the YouTube API, and an
initial port to version 2 of the Drive API.
This is only for rawhide. I will be rebuilding affected packages.
I will push Lucene 5.1.0 to rawhide next week. Followed immediately by Eclipse rebuild to make it work with it.
This is early enough in the F23 cycle to give time for people to port to 5.x. If someone is not able to migrate to Lucene 5 - he/she would have to submit a Lucene 4.x compat package based on the current one which I'll take care of reviewing. Version 5 has been out for quite few months and I clearly don't have time to maintain old version so plan accordingly :).
Red Hat Eclipse team
-----BEGIN PGP SIGNED MESSAGE-----
- -------- Forwarded Message --------
Subject: clang++ compiler flags
Date: Thu, 28 May 2015 21:05:55 +0200
From: Antonio Trande <anto.trande(a)gmail.com>
'clang++' compiler is unable to use ARM %optflags used on Fedora
Which flags i can use on ARM architectures with clang++ compiler?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
-----END PGP SIGNATURE-----
I would like to suggest that tlp  be included with Fedora Workstation by
default, starting with Fedora 23.
tlp is already a well-maintained Fedora package , is quite stable, and
achieves dramatic battery life and laptop optimization gains without having
to run a daemon or a background process. It also ships with informative
stat tools. It seems to be the current leader in zero-configuration laptop
performance optimization, and is extremely lightweight.
Since Fedora Workstation ships with NetworkManager, the helper package
tlp-rdw should also be included .
It seems like integrating the existing Fedora package as a default in
Fedora Workstation shipments should be a no-brainer. Why isn't this already
the case? Can we make this happen?