"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.
>> 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.
.....
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
|
