I'm in the middle of a emerge -e world, since the new portage requested this.
A lot of things fail to compile, among these are x11-libs/libX11-9999
/ libXext-9999 and libXi-9999
I don't know if they will compile later on or should I remove every
driver for X?
I believe that was in Beso's post.
On Fri, Jun 20, 2008 at 10:07 PM, Beso <givemesugarr@...> wrote:
>
>
> 2008/6/20 Duncan <1i5t5.duncan@...>:
>>
>> "Tonko Mulder" <tonko.mulder@...> posted
>> 43ba12950806190904n9014817td243ef4cc4c8b549@..., excerpted
>> below, on Thu, 19 Jun 2008 18:04:11 +0200:
>>
>> >> What version of X? Given that your running - ACCEPT_KEYWORDS="amd64
>> >> ~amd64"
>> >> along with baselayout 2, having it be unstable is not surprising.
>> > That's kinda weird, since my make.conf only has ~amd64. About
>> > baselayout, I had this before I migrated to baselayout-2.
>>
>> FWIW I run ~amd64 as well and wouldn't consider it particularly
>> unstable. I believe much of the instability may be when people try to
>> run mostly stable but some ~arch, and choose packages that simply aren't
>> stable on the older dependencies they are running. A full ~arch install,
>> ~arch meaning it's generally stable upstream, but the Gentoo package
>> might not be (with the occasional exception of packages like portage,
>> where Gentoo /is/ upstream, and the rule is sometimes bent a bit), should
>> be reasonably stable as well, except that because not all the Gentoo
>> specific issues have been worked out, there may be a few problems, mainly
>> at emerge or config time, not so much once running.
>>
>> As for ~arch and arch both, that's how the PMs interpret ~arch, because
>> many packages are fully stable, without a ~arch version. So those
>> packages are merged at stable arch. ~arch just means merge it where
>> there's such a version to merge.
>
> well, i agree with duncan on ~amd64. it's quite stable and baselayout2 is
> only unstable if you compile it on a amd64 branch without doing the emerge
> -e world after going with ~amd64 branch. but if you compile it when you
> install your system is quite reliable. just be aware that the sabayon one
> (if you have sabayon repo) will get installed instead of the gentoo one and
> would lockup quite frequently.
>
>>
>> >> And from my rather limited experience with the ATI 690 chipset, I'm
>> >> rather impressed that it's only X that's losing sync and not the whole
>> >> laptop that freezing up.
>> > When it's freezing, my only option is to hold the power switch >3 sec.
>> > The laptop is then turned of and usually I wait a few seconds before I
>> > turn it on.
>> > It doesn't seem like a heat issue cause then I shouldn't be able to turn
>> > it on that quick.
>> >
>> > Virtual consoles won't work when the freeze occurs and neither will the
>> > num/caps/scroll-lock buttons.
>>
>> If you have the proper kernel option (magic sys-req keys) enabled, then
>> you may well at least be able to do alt-srq-s (sync), alt-srq-u (unmount
>> what can be, remount read-only what can't be unmounted), alt-srq-b
>> (reBoot).
>>
>> The s/u/b sequence above should help prevent filesystem damage and
>> possible loss of data. Test it without the lockup to ensure its
>> working. Once you know it is, then it forms a good test of how locked up
>> the system actually is as well. If the kernel itself is scrambled, that
>> won't respond either (even where the kernel can still see the keys, if it
>> thinks it's scrambled enough that its no longer safe to write to disk
>> because it doesn't know where it might be writing, it won't write at
>> all), thus if it works, the kernel was still in a reasonably coherent
>> state even if the machine was otherwise not responding.
>>
>> If it responds to the magic srq-s/u/b sequence, it's likely an X
>> segfault, not directly a kernel problem. Similarly with the ssh in
>> idea. If it won't respond at all to either of those, it's a kernel
>> problem.
>
> i'm afraid that here i have to disagree with you. the rs690 and rs480
> chipsets have a great power over the pc, to the extent of disabling magic
> keys. until i've been able to setup in the proper way xorg, mesa dri and
> kernel modules (after 2-3 days of work) i was able to get rid of the hard
> lockups. ui think that this is due to the boards not having any memory and
> to trying to lockup system memory assigned to other structures. this happens
> to a big extent if you use gcc-4.3.1 that doesn't have anymore the fix for
> memory write and read. for example when you compile the kernel with
> gcc-4.3.x you risk to compile a kernel function that allocates ram in the
> wrong way (the memory allocation is both to the right and to the left) and
> overwrite ram spaces that shouldn't be overwritten. this is a very
> superfluos explanation of the compiling structures removed in the lastest
> gcc code to conform to ABI, that lead to kernel problems, done deliberately
> in this way to have people understand the real problem. this is one of the
> reasons why i'm still not using gcc-4.3.1 as default compiler. i'm still
> afraid of this ABI conformation that with great probability has been ignored
> by the various devels.
> returning to the ati problems, i was talking about how the igp chipsets have
> a great big of control over the system because of the direct system memory
> access and because xorg still runs as root for ati. this is a very annoying
> problem that has been partially cleared in the git drm and xf86-video-ati
> code. i don't know if they already reached the stable releases, but i don't
> remember seeing xf85-video-ati bumps in the last period (they uisually get
> annouced quickly in the xorg-mailing list). fglrx also is quite annoying
> with these igp boards for what i know but maybe the 8.6 that has been bumped
> out some days ago has cleared this (but it's still not compatible with
> xorg-1.4.2).
>>
>> .....
>>
>> FWIW, I'm on a desktop/workstation (pretty much the latter except the
>> weak video card) with a Radeon 9200 series card, running ~amd64, and was
>> seeing similar problems (X segfaults, according to the system log, as
>> recovered after the alt-srq-s/u/b thing, NOT kernel lockups, so if you
>> find it's kernel lockups, it's different) for a short period. They seem
>> to have disappeared with the latest updates, however, altho I'm not
>> positive as the freezes would take awhile and weren't easily
>> reproducible, here. But I've seen none since the upgrade and it has
>> quite passed the time I might otherwise see it.
>>
>> That included an update to xorg-server-1.4.2 among other things, but only
>> started happening relatively recently, I believe after updating something
>> else xorg related before xorg-server itself was available for update.
>>
>> I should also mention, however, that I'm still on xf86-video-ati-6.6.3,
>> since I've so far not found the magic config incantation to get the newer
>> ~arch version running dual monitors at 1600x1200 each, stacked for
>> 1600x2400 using (on 6.6.3) merged framebuffer (the newer version kills
>> that in favor of xinerama, which maybe is the problem), running on this
>> old Radeon 9200 series. I thought it might be an incompatibility between
>> the newer components and the older ati/radeon driver until xorg-
>> server-1.4.2 seemed to have fixed it.
>>
>> So, differences between laptop and workstation hardware, and between the
>> mobile video you have and my older desktop video, aside, if you haven't
>> yet, try upgrading to xorg-server-1.4.2 (now ~amd64), and see if that
>> cures your X freeze problems, assuming that's what it is and the kernel
>> is still going fine.
>>
>> --
>> Duncan - List replies preferred. No HTML msgs.
>> "Every nonfree program has a lord, a master --
>> and if you use the program, he is your master." Richard Stallman
>>
>> --
>> gentoo-amd64@g.o mailing list
>>
>
>
>
> --
> dott. ing. beso
--
gentoo-amd64@g.o mailing list
|
