[gentoo-amd64] Laptop freeze

[gentoo-amd64] Laptop freeze

[Tonko Mulder]

Hello list,

I have gentoo installed on my laptop[1] and everything is working fine
except for one thing.
Every time when I emerge something and even when I don't my laptop
first hangs and than the screen goes black.

This only happens when I use X, when I'm working with console only it
doesn't hang.

Does anyone got an idea what's causing this?

Kinds regards, Tonko


[1] http://jtt-tonko.blogspot.com/2008/06/laptop-info.html
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Laptop freeze

[Bob Sanders]

Tonko Mulder, mused, then expounded:
> Hello list,
> 
> I have gentoo installed on my laptop[1] and everything is working fine
> except for one thing.
> Every time when I emerge something and even when I don't my laptop
> first hangs and than the screen goes black.
> 
> This only happens when I use X, when I'm working with console only it
> doesn't hang.
> 
> Does anyone got an idea what's causing this?
>

What version of X?  Given that your running - ACCEPT_KEYWORDS="amd64 ~amd64"
along with baselayout 2, having it be unstable is not surprising.

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.

But, if a screen goes blank, it typically means the Gfx adapter is not running
the correct vertical and hoizontial freqencies that the LCD screen can
handle.  But that assuming that it's only the screen that's locking up.

Have you tried setting it up for remote login and ssh'ing in from another
system when this happens?

Bob
 
> Kinds regards, Tonko
> 
> 
> [1] http://jtt-tonko.blogspot.com/2008/06/laptop-info.html
> -- 
> gentoo-amd64@lists.gentoo.org mailing list
> 

-- 
-  
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Laptop freeze

[Tonko Mulder]

On 6/19/08, Bob Sanders <rsanders@sgi.com> wrote:
> Tonko Mulder, mused, then expounded:
>
> > Hello list,
>  >
>  > I have gentoo installed on my laptop[1] and everything is working fine
>  > except for one thing.
>  > Every time when I emerge something and even when I don't my laptop
>  > first hangs and than the screen goes black.
>  >
>  > This only happens when I use X, when I'm working with console only it
>  > doesn't hang.
>  >
>  > Does anyone got an idea what's causing this?
>  >
>
>
> 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.

>
>  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.
>
>  But, if a screen goes blank, it typically means the Gfx adapter is not running
>  the correct vertical and hoizontial freqencies that the LCD screen can
>  handle.  But that assuming that it's only the screen that's locking up.
>
>  Have you tried setting it up for remote login and ssh'ing in from another
>  system when this happens?
No I haven't, I'll try that next time.

>
>  Bob
>
This or was a new install on new hardware, I bought the laptop in
February and installed gentoo on it, I've had the freezing since.
This freezing is the only part of the laptop which doesn't work like
it should, the rest is fine.
>
>  > Kinds regards, Tonko
>  >
>  >
>  > [1] http://jtt-tonko.blogspot.com/2008/06/laptop-info.html
>
> > --
>  > gentoo-amd64@lists.gentoo.org mailing list
>  >
>
>  --
>  -
>
> --
>  gentoo-amd64@lists.gentoo.org mailing list
>
>
-- 
gentoo-amd64@lists.gentoo.org mailing list

[gentoo-amd64] Re: Laptop freeze

[Duncan]

"Tonko Mulder" <tonko.mulder@gmail.com> posted
43ba12950806190904n9014817td243ef4cc4c8b549@mail.gmail.com, 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@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: Laptop freeze

[Beso]

[-- Attachment #1: Type: text/plain, Size: 7395 bytes --]

2008/6/20 Duncan <1i5t5.duncan@cox.net>:

> "Tonko Mulder" <tonko.mulder@gmail.com> posted
> 43ba12950806190904n9014817td243ef4cc4c8b549@mail.gmail.com, 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@lists.gentoo.org mailing list
>
>


-- 
dott. ing. beso

[-- Attachment #2: Type: text/html, Size: 8984 bytes --]

Re: [gentoo-amd64] Re: Laptop freeze

[Tonko Mulder]

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@gmail.com> wrote:
>
>
> 2008/6/20 Duncan <1i5t5.duncan@cox.net>:
>>
>> "Tonko Mulder" <tonko.mulder@gmail.com> posted
>> 43ba12950806190904n9014817td243ef4cc4c8b549@mail.gmail.com, 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@lists.gentoo.org mailing list
>>
>
>
>
> --
> dott. ing. beso
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: Laptop freeze

[Beso]

[-- Attachment #1: Type: text/plain, Size: 1399 bytes --]

2008/6/21 Tonko Mulder <tonko.mulder@gmail.com>:

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


probably they failed because of the new libxcb api which has removed 2
useless libtool archive files that shouldn't be used from the start. the
other thing that might cause problems is portage deps resolver which
sometime is bad and would emerge some packages after the ones requiring
them. this usually happens often in an emerge -e world.
if you try to rebuild them after the world rebuild and you cannot build them
again, remove the installed versions (with emerge --unmerge libX11 linXext
libXi ) and reemerge them with emerge --oneshot libX11 libXext libXi. at
that point they should emerge.  if they don't emerge emerge the portage ones
with xorg-server from portage and post the emerge logs so we can help you
out. you'll get also xorg-server error surely since libX11 isn't the one
required as dep and, as i've told you, probably also libXtst and xdpyinfo.
today i have a little spare time and i'll search out for the synaptics
ebuild (with patches) to post in the case you own a synaptics or alps
touchpad.


-- 
dott. ing. beso

[-- Attachment #2: Type: text/html, Size: 1722 bytes --]

Re: [gentoo-amd64] Re: Laptop freeze

[Tonko Mulder]

After trying a few things a lot of thing refused to compile, so I got
my external hard drive and started a new installation with the 2008
profile and the x11 overlay. And so far it is going well, if
everything goes well I will move that installation to my current one.

Just to keep you posted :)

On 6/21/08, Beso <givemesugarr@gmail.com> wrote:
> 2008/6/21 Tonko Mulder <tonko.mulder@gmail.com>:
>
>> 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.
>
>
> probably they failed because of the new libxcb api which has removed 2
> useless libtool archive files that shouldn't be used from the start. the
> other thing that might cause problems is portage deps resolver which
> sometime is bad and would emerge some packages after the ones requiring
> them. this usually happens often in an emerge -e world.
> if you try to rebuild them after the world rebuild and you cannot build them
> again, remove the installed versions (with emerge --unmerge libX11 linXext
> libXi ) and reemerge them with emerge --oneshot libX11 libXext libXi. at
> that point they should emerge.  if they don't emerge emerge the portage ones
> with xorg-server from portage and post the emerge logs so we can help you
> out. you'll get also xorg-server error surely since libX11 isn't the one
> required as dep and, as i've told you, probably also libXtst and xdpyinfo.
> today i have a little spare time and i'll search out for the synaptics
> ebuild (with patches) to post in the case you own a synaptics or alps
> touchpad.
>
>
> --
> dott. ing. beso
>
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: Laptop freeze

[Tonko Mulder]

I now have X on git ebuilds and everything is working fine. So far I
haven't seen any black screens or freezes. The only 2 ebuilds that
fail are x11-libs/cairo-9999 which fails due to autoconf and
eselect-opengl-1.0.6-r2 due to the mirrors which don't have
glext.h-40.bz2

As I said everything is working fine except for those 2 ebuilds, so if
anyone has some hints how I can solve that I'd be happy.

On 6/30/08, Tonko Mulder <tonko.mulder@gmail.com> wrote:
> After trying a few things a lot of thing refused to compile, so I got
>  my external hard drive and started a new installation with the 2008
>  profile and the x11 overlay. And so far it is going well, if
>  everything goes well I will move that installation to my current one.
>
>  Just to keep you posted :)
>
>
>  On 6/21/08, Beso <givemesugarr@gmail.com> wrote:
>  > 2008/6/21 Tonko Mulder <tonko.mulder@gmail.com>:
>  >
>  >> 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.
>  >
>  >
>  > probably they failed because of the new libxcb api which has removed 2
>  > useless libtool archive files that shouldn't be used from the start. the
>  > other thing that might cause problems is portage deps resolver which
>  > sometime is bad and would emerge some packages after the ones requiring
>  > them. this usually happens often in an emerge -e world.
>  > if you try to rebuild them after the world rebuild and you cannot build them
>  > again, remove the installed versions (with emerge --unmerge libX11 linXext
>  > libXi ) and reemerge them with emerge --oneshot libX11 libXext libXi. at
>  > that point they should emerge.  if they don't emerge emerge the portage ones
>  > with xorg-server from portage and post the emerge logs so we can help you
>  > out. you'll get also xorg-server error surely since libX11 isn't the one
>  > required as dep and, as i've told you, probably also libXtst and xdpyinfo.
>  > today i have a little spare time and i'll search out for the synaptics
>  > ebuild (with patches) to post in the case you own a synaptics or alps
>  > touchpad.
>  >
>  >
>  > --
>  > dott. ing. beso
>  >
>
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: Laptop freeze

[Beso]

[-- Attachment #1.1: Type: text/plain, Size: 3138 bytes --]

2008/7/5 Tonko Mulder <tonko.mulder@gmail.com>:

> I now have X on git ebuilds and everything is working fine. So far I
> haven't seen any black screens or freezes. The only 2 ebuilds that
> fail are x11-libs/cairo-9999 which fails due to autoconf and
> eselect-opengl-1.0.6-r2 due to the mirrors which don't have
> glext.h-40.bz2
>
> As I said everything is working fine except for those 2 ebuilds, so if
> anyone has some hints how I can solve that I'd be happy.
>

as i've told you the x11 ebuilds are really good and the overall quality of
the git xorg is quite impressive. the cairo and glitz ebuilds always have
some problems with autoconf, but once in a while they compile. i think that
this is due to some autoconf-wrapper issues, but i'm not sure. use the
portage ones instead of the 9999 versions for them.
as for eselect-opengl i have 1.0.6-r2 installed well and without issues.
i've posted my bz2 for opengl. try putting it in your distfiles directory
and retry installing.


>
> On 6/30/08, Tonko Mulder <tonko.mulder@gmail.com> wrote:
> > After trying a few things a lot of thing refused to compile, so I got
> >  my external hard drive and started a new installation with the 2008
> >  profile and the x11 overlay. And so far it is going well, if
> >  everything goes well I will move that installation to my current one.
> >
> >  Just to keep you posted :)
> >
> >
> >  On 6/21/08, Beso <givemesugarr@gmail.com> wrote:
> >  > 2008/6/21 Tonko Mulder <tonko.mulder@gmail.com>:
> >  >
> >  >> 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.
> >  >
> >  >
> >  > probably they failed because of the new libxcb api which has removed 2
> >  > useless libtool archive files that shouldn't be used from the start.
> the
> >  > other thing that might cause problems is portage deps resolver which
> >  > sometime is bad and would emerge some packages after the ones
> requiring
> >  > them. this usually happens often in an emerge -e world.
> >  > if you try to rebuild them after the world rebuild and you cannot
> build them
> >  > again, remove the installed versions (with emerge --unmerge libX11
> linXext
> >  > libXi ) and reemerge them with emerge --oneshot libX11 libXext libXi.
> at
> >  > that point they should emerge.  if they don't emerge emerge the
> portage ones
> >  > with xorg-server from portage and post the emerge logs so we can help
> you
> >  > out. you'll get also xorg-server error surely since libX11 isn't the
> one
> >  > required as dep and, as i've told you, probably also libXtst and
> xdpyinfo.
> >  > today i have a little spare time and i'll search out for the synaptics
> >  > ebuild (with patches) to post in the case you own a synaptics or alps
> >  > touchpad.
> >  >
> >  >
> >  > --
> >  > dott. ing. beso
> >  >
> >
> --
> gentoo-amd64@lists.gentoo.org mailing list
>
>


-- 
dott. ing. beso

[-- Attachment #1.2: Type: text/html, Size: 4476 bytes --]

[-- Attachment #2: opengl.eselect-1.0.6.bz2 --]
[-- Type: application/x-bzip2, Size: 3295 bytes --]

Re: [gentoo-amd64] Re: Laptop freeze

[Tonko Mulder]

On 7/6/08, Beso <givemesugarr@gmail.com> wrote:
>
> as i've told you the x11 ebuilds are really good and the overall quality of
> the git xorg is quite impressive. the cairo and glitz ebuilds always have
> some problems with autoconf, but once in a while they compile. i think that
> this is due to some autoconf-wrapper issues, but i'm not sure. use the
> portage ones instead of the 9999 versions for them.
Already running the portage one :)

>  as for eselect-opengl i have 1.0.6-r2 installed well and without issues.
> i've posted my bz2 for opengl. try putting it in your distfiles directory
> and retry installing.
Thanks for the bz2, after putting it in my distfiles all I had to do
was adjust the ebuild to accept my keyword (~amd64) and it didn't have
any trouble installing.

I'll see when the git cairo wants to install.
Now I have another weird problem, I use my wireless network card (an
Atheros AR5006EG or and AR5007EG, lspci isn't that accurate I heard)
with ndiswrapper and sometimes it works and connects right away and
sometimes it can't detect any networks. And at times it detects the
networks but it can't connect for some reason.

Does anyone has an hint on that? Or anything else that helps, since
this is quite annoying
>
> >
> >
> >
> >
> > On 6/30/08, Tonko Mulder <tonko.mulder@gmail.com> wrote:
> > > After trying a few things a lot of thing refused to compile, so I got
> > >  my external hard drive and started a new installation with the 2008
> > >  profile and the x11 overlay. And so far it is going well, if
> > >  everything goes well I will move that installation to my current one.
> > >
> > >  Just to keep you posted :)
> > >
> > >
> > >  On 6/21/08, Beso <givemesugarr@gmail.com> wrote:
> > >  > 2008/6/21 Tonko Mulder <tonko.mulder@gmail.com>:
> > >  >
> > >  >> 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.
> > >  >
> > >  >
> > >  > probably they failed because of the new libxcb api which has removed
> 2
> > >  > useless libtool archive files that shouldn't be used from the start.
> the
> > >  > other thing that might cause problems is portage deps resolver which
> > >  > sometime is bad and would emerge some packages after the ones
> requiring
> > >  > them. this usually happens often in an emerge -e world.
> > >  > if you try to rebuild them after the world rebuild and you cannot
> build them
> > >  > again, remove the installed versions (with emerge --unmerge libX11
> linXext
> > >  > libXi ) and reemerge them with emerge --oneshot libX11 libXext libXi.
> at
> > >  > that point they should emerge.  if they don't emerge emerge the
> portage ones
> > >  > with xorg-server from portage and post the emerge logs so we can help
> you
> > >  > out. you'll get also xorg-server error surely since libX11 isn't the
> one
> > >  > required as dep and, as i've told you, probably also libXtst and
> xdpyinfo.
> > >  > today i have a little spare time and i'll search out for the
> synaptics
> > >  > ebuild (with patches) to post in the case you own a synaptics or alps
> > >  > touchpad.
> > >  >
> > >  >
> > >  > --
> > >  > dott. ing. beso
> > >  >
> > >
> > --
> > gentoo-amd64@lists.gentoo.org mailing list
> >
> >
>
>
>
> --
> dott. ing. beso
>
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: Laptop freeze

[Beso]

[-- Attachment #1: Type: text/plain, Size: 4777 bytes --]

2008/7/6 Tonko Mulder <tonko.mulder@gmail.com>:

> On 7/6/08, Beso <givemesugarr@gmail.com> wrote:
> >
> > as i've told you the x11 ebuilds are really good and the overall quality
> of
> > the git xorg is quite impressive. the cairo and glitz ebuilds always have
> > some problems with autoconf, but once in a while they compile. i think
> that
> > this is due to some autoconf-wrapper issues, but i'm not sure. use the
> > portage ones instead of the 9999 versions for them.
> Already running the portage one :)
>
> >  as for eselect-opengl i have 1.0.6-r2 installed well and without issues.
> > i've posted my bz2 for opengl. try putting it in your distfiles directory
> > and retry installing.
> Thanks for the bz2, after putting it in my distfiles all I had to do
> was adjust the ebuild to accept my keyword (~amd64) and it didn't have
> any trouble installing.
>

i thought that you already were on ~amd64 since you asked for 1.0.6 ebuild
that should be coded as unstable for amd64 branch... well, it doesn't really
matter much...


>
> I'll see when the git cairo wants to install.
> Now I have another weird problem, I use my wireless network card (an
> Atheros AR5006EG or and AR5007EG, lspci isn't that accurate I heard)
> with ndiswrapper and sometimes it works and connects right away and
> sometimes it can't detect any networks. And at times it detects the
> networks but it can't connect for some reason.
>

this is one of the things i've failed with.... there's a post in the forum
if you search ar5006eg that points to an ebuild they say it works (a
modified madwifi-ng driver) but i wasn't able to have it working (i think
that it's limited to x86 architecture). as for ndiswrapper i know that the
latest kernels are removing some ndiswrapper needed calls. also the
ndiswrapper is known to be quite buggy: it either works well or doesn't
really work.... i've had some terific experiences with it some time ago with
the bcm wifi boards and stopped using it at all. i preffer not having a
functionality than using that stuff installed. for what it worths, do you
have the wpa_supplicant and the linux wireless utils (iwconfig and other
utils) installed?!


>
> Does anyone has an hint on that? Or anything else that helps, since
> this is quite annoying
> >
> > >
> > >
> > >
> > >
> > > On 6/30/08, Tonko Mulder <tonko.mulder@gmail.com> wrote:
> > > > After trying a few things a lot of thing refused to compile, so I got
> > > >  my external hard drive and started a new installation with the 2008
> > > >  profile and the x11 overlay. And so far it is going well, if
> > > >  everything goes well I will move that installation to my current
> one.
> > > >
> > > >  Just to keep you posted :)
> > > >
> > > >
> > > >  On 6/21/08, Beso <givemesugarr@gmail.com> wrote:
> > > >  > 2008/6/21 Tonko Mulder <tonko.mulder@gmail.com>:
> > > >  >
> > > >  >> 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.
> > > >  >
> > > >  >
> > > >  > probably they failed because of the new libxcb api which has
> removed
> > 2
> > > >  > useless libtool archive files that shouldn't be used from the
> start.
> > the
> > > >  > other thing that might cause problems is portage deps resolver
> which
> > > >  > sometime is bad and would emerge some packages after the ones
> > requiring
> > > >  > them. this usually happens often in an emerge -e world.
> > > >  > if you try to rebuild them after the world rebuild and you cannot
> > build them
> > > >  > again, remove the installed versions (with emerge --unmerge libX11
> > linXext
> > > >  > libXi ) and reemerge them with emerge --oneshot libX11 libXext
> libXi.
> > at
> > > >  > that point they should emerge.  if they don't emerge emerge the
> > portage ones
> > > >  > with xorg-server from portage and post the emerge logs so we can
> help
> > you
> > > >  > out. you'll get also xorg-server error surely since libX11 isn't
> the
> > one
> > > >  > required as dep and, as i've told you, probably also libXtst and
> > xdpyinfo.
> > > >  > today i have a little spare time and i'll search out for the
> > synaptics
> > > >  > ebuild (with patches) to post in the case you own a synaptics or
> alps
> > > >  > touchpad.
> > > >  >
> > > >  >
> > > >  > --
> > > >  > dott. ing. beso
> > > >  >
> > > >
> > > --
> > > gentoo-amd64@lists.gentoo.org mailing list
> > >
> > >
> >
> >
> >
> > --
> > dott. ing. beso
> >
> --
> gentoo-amd64@lists.gentoo.org mailing list
>
>


-- 
dott. ing. beso

[-- Attachment #2: Type: text/html, Size: 6893 bytes --]

Re: [gentoo-amd64] Re: Laptop freeze

[Tonko Mulder]

On 7/7/08, Beso <givemesugarr@gmail.com> wrote:
> 2008/7/6 Tonko Mulder <tonko.mulder@gmail.com>:
>
> >
> > On 7/6/08, Beso <givemesugarr@gmail.com> wrote:
> > >
> > > as i've told you the x11 ebuilds are really good and the overall quality
> of
> > > the git xorg is quite impressive. the cairo and glitz ebuilds always
> have
> > > some problems with autoconf, but once in a while they compile. i think
> that
> > > this is due to some autoconf-wrapper issues, but i'm not sure.GL development package gentoo use the
> > > portage ones instead of the 9999 versions for them.
> > Already running the portage one :)
> >
> >
> > >  as for eselect-opengl i have 1.0.6-r2 installed well and without
> issues.
> > > i've posted my bz2 for opengl. try putting it in your distfiles
> directory
> > > and retry installing.
> > Thanks for the bz2, after putting it in my distfiles all I had to do
> > was adjust the ebuild to accept my keyword (~amd64) and it didn't have
> > any trouble installing.
> >
>
> i thought that you already were on ~amd64 since you asked for 1.0.6 ebuild
> that should be coded as unstable for amd64 branch... well, it doesn't really
> matter much...
I am on ~amd64 as far as I know, although amd64 appears in my emerge
--info for some reason.
>
> >
> > I'll see when the git cairo wants to install.
> > Now I have another weird problem, I use my wireless network card (an
> > Atheros AR5006EG or and AR5007EG, lspci isn't that accurate I heard)
> > with ndiswrapper and sometimes it works and connects right away and
> > sometimes it can't detect any networks. And at times it detects the
> > networks but it can't connect for some reason.
> >
>
> this is one of the things i've failed with.... there's a post in the forum
> if you search ar5006eg that points to an ebuild they say it works (a
> modified madwifi-ng driver) but i wasn't able to have it working (i think
> that it's limited to x86 architecture). as for ndiswrapper i know that the
> latest kernels are removing some ndiswrapper needed calls. also the
> ndiswrapper is known to be quite buggy: it either works well or doesn't
> really work.... i've had some terific experiences with it some time ago with
> the bcm wifi boards and stopped using it at all. i preffer not having a
> functionality than using that stuff installed. for what it worths, do you
> have the wpa_supplicant and the linux wireless utils (iwconfig and other
> utils) installed?!
I do have wpa_supplicant and the wireless utils installed.
>
>
> >
> > Does anyone has an hint on that? Or anything else that helps, since
> > this is quite annoying
> >
> >
> >
> > >
> > > >
> > > >
> > > >
> > > >
> > > > On 6/30/08, Tonko Mulder <tonko.mulder@gmail.com> wrote:
> > > > > After trying a few things a lot of thing refused to compile, so I
> got
> > > > >  my external hard drive and started a new installation with the 2008
> > > > >  profile and the x11 overlay. And so far it is going well, if
> > > > >  everything goes well I will move that installation to my current
> one.
> > > > >
> > > > >  Just to keep you posted :)
> > > > >
> > > > >
> > > > >  On 6/21/08, Beso <givemesugarr@gmail.com> wrote:
> > > > >  > 2008/6/21 Tonko Mulder <tonko.mulder@gmail.com>:
> > > > >  >
> > > > >  >> 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.
> > > > >  >
> > > > >  >
> > > > >  > probably they failed because of the new libxcb api which has
> removed
> > > 2
> > > > >  > useless libtool archive files that shouldn't be used from the
> start.
> > > the
> > > > >  > other thing that might cause problems is portage deps resolver
> which
> > > > >  > sometime is bad and would emerge some packages after the ones
> > > requiring
> > > > >  > them. this usually happens often in an emerge -e world.
> > > > >  > if you try to rebuild them after the world rebuild and you cannot
> > > build them
> > > > >  > again, remove the installed versions (with emerge --unmerge
> libX11
> > > linXext
> > > > >  > libXi ) and reemerge them with emerge --oneshot libX11 libXext
> libXi.
> > > at
> > > > >  > that point they should emerge.  if they don't emerge emerge the
> > > portage ones
> > > > >  > with xorg-server from portage and post the emerge logs so we can
> help
> > > you
> > > > >  > out. you'll get also xorg-server error surely since libX11 isn't
> the
> > > one
> > > > >  > required as dep and, as i've told you, probably also libXtst and
> > > xdpyinfo.
> > > > >  > today i have a little spare time and i'll search out for the
> > > synaptics
> > > > >  > ebuild (with patches) to post in the case you own a synaptics or
> alps
> > > > >  > touchpad.
> > > > >  >
> > > > >  >
> > > > >  > --
> > > > >  > dott. ing. beso
> > > > >  >
> > > > >
> > > > --
> > > > gentoo-amd64@lists.gentoo.org mailing list
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > dott. ing. beso
> > >
> > --
> >
> >
> >
> > gentoo-amd64@lists.gentoo.org mailing list
> >
> >
>
>
>
> --
> dott. ing. beso
-- 
gentoo-amd64@lists.gentoo.org mailing list

[gentoo-amd64] Re: Laptop freeze

[Duncan]

"Tonko Mulder" <tonko.mulder@gmail.com> posted
43ba12950807062352t893e37bte2310abfa8fd900d@mail.gmail.com, excerpted
below, on  Mon, 07 Jul 2008 08:52:15 +0200:

> I am on ~amd64 as far as I know, although amd64 appears in my emerge
> --info for some reason.

Yes, it makes perfect sense if you think about it a bit.

~arch must include stable also.  The keyword simply sets the minimum 
stability the sysadmin wants to allow.  ~arch simply tells the PM 
(package manager) it's OK to install somewhat "less stable" packages than 
it would if it only took arch.

Consider the scenario of a mature package that doesn't have many 
updates.  It will often have its latest version keyworded stable, with no 
further ~arch version.  If ~arch meant only ~arch, the PM couldn't 
install that package, so the keyword must be interpreted as the minimum 
stability desired -- it's always OK to install packages more stable than 
that.  

The way that's expressed in emerge --info is that both ~arch and arch are 
listed.

As I said, it makes perfect sense once you think about it a bit.  Gentoo 
isn't supposed to be a black box.  There's logic behind the way it works, 
and understanding that logic makes things /much/ less confusing!  =8^)

-- 
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@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: Laptop freeze

[Tonko Mulder]

I was just thinking about a reply that Beso made.
He said that I need compiz.
Now everything works, so I was wondering what I would gain by
installing compiz(-fusion)

--
Tonko
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: Laptop freeze

[Beso]

[-- Attachment #1: Type: text/plain, Size: 852 bytes --]

2008/7/12 Tonko Mulder <tonko.mulder@gmail.com>:

> I was just thinking about a reply that Beso made.
> He said that I need compiz.
> Now everything works, so I was wondering what I would gain by
> installing compiz(-fusion)
>

compiz gives some usability boost with various effects and 3d eye candy to
the desktop. installing it doesn't mean you'll need to use it, but just that
you could use it. myself  i've got it installed and use it sometimes since
it's not bad at all and since some stuff like the exposes, the cube and some
other effects improve usability of the overall system. before using out
compiz for some time i thought that it was just some use candy and nothing
more, but after using it for some time i found it to be quite productive.
i personally use the desktop-effects compiz ebuilds and find them quite
good.

-- 
dott. ing. beso

[-- Attachment #2: Type: text/html, Size: 1142 bytes --]

Re: [gentoo-amd64] Laptop freeze

[Brett Johnson]

On Thu, Jun 19, 2008 at 05:28:50PM +0200, Tonko Mulder wrote:
> Hello list,
> 
> I have gentoo installed on my laptop[1] and everything is working fine
> except for one thing.
> Every time when I emerge something and even when I don't my laptop
> first hangs and than the screen goes black.
> 
> This only happens when I use X, when I'm working with console only it
> doesn't hang.
> 
> Does anyone got an idea what's causing this?
> 
You don't provide a lot of details. The first thing you should confirm
is whether or not the laptop is actually locking up or just some process
(like X) is using 100% cpu. To check this you can try a couple of
things:

1) try to access the laptop from a remote computer. Of course, make sure
you can access the machine remotely before the machine locks up. I
normally have ssh running on my machines, but you could use telnet, rsh
or possibly ftp or http. Just make sure you have the appropriate service
running on the laptop.

2) Use <CTRL>+<ALT>+<F1> to try and switch from X to a virtual console
window.

3) If you have ACPI properly setup and responding to the power button,
you could try pressing the power button < 3 seconds. This should shut
down the laptop.

If any of these above work when the screen is blank, than the system is
not locked up. It's likely X or some application is causing X to stop
responding. If this is the case, you need to figure out what is causing
the problem. The first thing would be to log in (either through VC or
ssh) and run the "top" command. This will show what the system is doing
and how much CPU time each process is using. What to do from here
depends on whether or not something is using 100% CPU.

If you can not log in or shutdown, then it's possible the machine
did lock up. Then next steps would be to look in the logs (/var/log) for
any clues to what may be happening before the system crashes.


Is this a new install on new hardware, or was it working fine and just
started locking up?

It may also be a heat problem. You may want to look in to getting
lm_sensors or some other tool installed to monitor the system
temperatures. If could be the CPU or GPU is over heating and either
stops responding or shuts the system down.

-- 
Brett Johnson
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Laptop freeze

[Beso]

[-- Attachment #1: Type: text/plain, Size: 2276 bytes --]

2008/6/19 Tonko Mulder <tonko.mulder@gmail.com>:

> Hello list,
>
> I have gentoo installed on my laptop[1] and everything is working fine
> except for one thing.
> Every time when I emerge something and even when I don't my laptop
> first hangs and than the screen goes black.
>
> This only happens when I use X, when I'm working with console only it
> doesn't hang.
>
> Does anyone got an idea what's causing this?
>
> Kinds regards, Tonko
>
>
> [1] http://jtt-tonko.blogspot.com/2008/06/laptop-info.html
> --
> gentoo-amd64@lists.gentoo.org mailing list
>
>
the problem is due to the videocard. what you need to do is the following:
1. add the x11 overlay
2. unmask and unkeyword all the packages in the x11 overlay
3. remove the contents of /var/cache/ldconfig/ if present
4. emerge -uDNv world and install the git x11 libs, protos and server,
including the mesa, x11-drm and libdrm after removing synaptics, vesa,
xprint use flags (some are inputs and other videocards).
5. revdep-rebuild (you'll have quite some stuff in there because of the
libxcb update). if some packages fail during update or rebuild skip them for
the moment.
6. restart system and now you should fully working have a compiz enabled
desktop (of course you need compiz).

ps. don't loose time with other xorg-servers and stuff. this is the only
fully working configuration for rs680. i have the same chipsets and have
tried fglrx and radeon and the only stuff that made my laptop work fine was
x11 overlay and the packages from git. this is due to some problems with
released versions that don't contain yet the new code. the important stuff,
if you don't want to install everything are: the protos, libX11, mesa,
libdrm, x11-drm and xorg-server with the updates pushed in by them. but if
you just install these you might risk having an inconsistent x11 system that
might crash from time to time. the packages that might fail during
compilation are libXtst (xmlto error, that i haven't been able to fix yet),
and xdpyinfo (dependent on libXtst). if ou see other packages failing then
you could first remove the installed package and then push the new 9999
version of it. i'd also advice the use of ffmpeg-20089999 live ebuild from
berkano overlay that has live code for ffmpeg.


-- 
dott. ing. beso

[-- Attachment #2: Type: text/html, Size: 2833 bytes --]