Fwd: KDE login broken in rawhide
Hi, Since about last week I can't login into KDE anymore using KDM. The KDE splash screen appears, but after this xmessage pops up saying ~"can't start kded4" or something like that. I've quite a number of KDE4 updates installed, but it still happens. Has somebody else experienced this problem too? Does it need manual solving? Thank you in advance, Clemens PS: Sorry for the double-post, i sent this to fedora-list by accident. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Time for 2.6.30 in F-11?
Hi, > The fact is that F11 shipped with broken Xv support for old Intel > chips such as the i855 among other deficiencies. The problem can > mainly be attributed to the outdated xorg-drv-x11-intel-2.7.0 that > came with F11. The version in F11 isn't really 2.7, its heavily patched as is the kernel part. In fact the RedHat guys fixed tons of bugs themself, because intel seemed unable to e.g. provide mouse-pointer support for i865 when UXA is used, or to find the cause of sporadic pixmap corruptions. All this was done by RedHat. > A newer version (2.8.0) for that driver exists but also > depends on an updated user-space libdrm and kernel DRM for Intel h/w > hence the request. xorg-drv-x11-intel should be really updated ASAP. As far as I know 2.8.0 hasn't been officially released. I could imaginge they hestitate to replace the patched 2.6.29, until 2.8.0 is released and declared as stable. - Clemens -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Missing libxklavier.so.12 dependency
Hi, For a few days now updating rawhide doesn't work, because it misses a dependency: kdebase-workspace-4.2.95-3.fc12.i586 from rawhide has depsolving problems --> Missing Dependency: libxklavier.so.12 is needed by package kdebase-workspace-4.2.95-3.fc12.i586 (rawhide) Error: Missing Dependency: libxklavier.so.12 is needed by package kdebase-workspace-4.2.95-3.fc12.i586 (rawhide) You could try using --skip-broken to work around the problem You could try running: package-cleanup --problems package-cleanup --dupes rpm -Va --nofiles --nodigest Is this anything to worry about my system, or will that be fixed anyway? Thanks, Clemens -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: more debugging enabled in rawhide kernels.
It has a horrible impact at least on Intel's driver performance. I've run some benchmarks, which show half the performance. This could be due to the update to 2.8.0 or due to debugging enabled. - Clemens 2009/6/25 Dave Jones : > On Thu, Jun 25, 2009 at 04:53:27PM +0100, Richard W.M. Jones wrote: > > On Wed, Jun 24, 2009 at 08:08:40PM -0400, Dave Jones wrote: > > > In tomorrows rawhide kernel, I've enabled a debugging option > > > called kmemleak. As the name suggests, this tracks memory allocations, > > > and prints backtraces in cases where the memory is believed to be lost. > > > > As a general comment, I see many backtraces when I run the libguestfs > > testsuite. Most are harmless, in that they don't appear to affect the > > running of programs, so I don't report them. But is it helpful to > > report these? If so how - open BZs for each variation that I see? > > Everything I've seen so far looks like a false positive. > The next build should reduce the number of these (hopefully dramatically). > > So for now, just hold off on filing anything. > > Dave > > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
> There were actually some P4 laptops. They tended to be very large (to > contain the required power and cooling) and have a battery life measured > in minutes. They probably should also have come with heavy-duty lap heat > protectors... I had a HP xe4500, with a P4M-1.6ghz, and its battery lasted 3 hours. (was 4000mA/h, 14,8V) Thats longer than my Core2Duo based thosiba laptop, which is a "buissness-class" machine. Even found a review: http://reviews.cnet.com/laptops/hp-omnibook-xe4500-pentium/4505-3121_7-20001966.html So yes the P4 was a horrible CPU, however when it came to heat/battery I didn't miss a thing with this laptop. - Clemens -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Plase switch to intel-2.8 prerelease
Hi, It would be great to see rawhide switching from intel-2.7.0 to 2.8pre soon. After the switch to xorg-server-1.6.99 the old intel-driver only works with EXA, UXA+KMS is broken, and I miss a bunch of fixes in 2.7 that are in 2.8. Thanks, Clemens -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: X11 on intel (rawhide)
Rawhide deployed a xorg-update, while various drivers haven't been updated so there's a version mismatch. I use the vesa driver for now (also quite unstable, due to what seem to be pixman bugs), however an updated intel-driver should be out soon (hopefully). - Clemens 2009/6/23 Paul : > Hi, > > Following the last official rawhide update (21st was it?), my desktop > has been hosed. > > I've updated to the latest xorg-server and intel drivers (plus a few > others) as well as gdm and anything else I can think off. All updates > have been pulled from koji between 4pm and 10.30pm (UK, GMT) > > All I'm now getting is gdm failing to start (it shows a box where the > usernames are normally, but it's blank, then restarts X). > > When I look at the logs, I'm seeing the following at the bottom > (xorg.0.log) > > Backtrace > 0: /usr/bin/Xorg(xorg_backtrace+0x3b) [0x80a3afb] > 1: /usr/bin/Xorg [0x80a71b5] > 2: [0xd09410] > 3: /usr/lib/libdrm_intel.so.1 [0xe44750] > 4: /usr/lib/libdrm_intol.so.1.(drm_intel_bufmgr_destroy+0xf)[0xe412bf] > 5: /usr/lib/xorg/modules/drivers/intel_drv.so [0xf80132] > 6: /usr/bin/Xorg [0x80fbdfe] > 7: /usr/bin/Xorg [0x80c4cc5] > 8: /usr/bin/Xorg [0x80b200c] > 9: /usr/lib/xorg/modules/extensions/libextmod.so [0x1753a1] > 10:/usr/bin/Xorg [0x816f1a2] > 11:/usr/bin/Xorg [0x80e4bc0] > 12:/usr/bin/Xorg [0x81a9459] > 13:/usr/bin/Xorg [0x80e1fc2] > 14:/usr/lib/xorg/modules/extensions/libglx.so [0x2792ba] > 15:/usr/bin/Xorg [0x8063238] > 16:/lib/libc.so.6 (__libc_start_main+0xe6) [0x8c0a66] > 17:/usr/bin/Xorg [0x8062d91] > > Segmentation fault at address 0xfa4 > > Chipset 965GM > > Any ideas on what can be causing gdm/x to behave like this and more > over, how do I fix it? > > TTFN > > Paul > > -- > Sie können mich aufreizen und wirklich heiß machen! > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
> 1) Optimizing for P4 is ... messy > 2) If you're using C2D, etc., you can already use the 64-bit distro. So why not stay with generic, where most users would benefit. Sure I could use 64-bit, as could all the others using 32-bit on 64-bit capable CPUs (I guess 50% of all fedora-x86 users). - Clemens -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
> - Optimize for Atom I also don't get this one. Why not optimize for the cpu architectur in use by most fedora-x86 users, like p4 or c2d? It seems crazy to optimize for a cpu with maybe 5% market share, just because its the "only" x86 cpu left. (by the way, the via C7 is still sold too). - Clemens -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12 (#2)
Why can't you just leave it as-is? I mean is 1% improvement (for cpu intensive workload) really worth changing anything? Instead of messing arround with stuff like that, I guess a lot of code would benefit of beeing build with profile driven optimizations, which often yields a 5-15% improvement without sacrifycing anything. On amd64 it would even enable the auto-vectorizer (if enabled) to vectorize only parts which count, without bloating code unescessary. However that would be _real_ work, instead of just changing switches and discussing it forth and back ;) - Clemens -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Changing the default 32-bit x86 arch for Fedora 12
>> The slower x86 is, the more motivation there is to move to x86-64. > > +1 I for myself run a i586 as server, and have a few Athlon-TB machines arround. Yes, I still use the x86-version on my Core2Duo machine, but only because I am lazy ;) Leave x86 where it belongs, and move on with amd64. - Clemens -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
