[gentoo-amd64] madwifi-ng not compile in amd64

[gentoo-amd64] madwifi-ng not compile in amd64

[agtdino]

Hi,

When compile madwifi-ng I get error: 

 Preparing ath_hal module
../scripts/get_arch.mk:44: *** ARCH mismatch: supplied "x86", determined
"x86_64".  Alto.
 * 
 * ERROR: net-wireless/madwifi-ng-0.9.3.3 failed.

perhaps is in inestable?
I'would tri to maskit.

Thank's and regards


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

Re: [gentoo-amd64] madwifi-ng not compile in amd64

[Beso]

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

for me madwifi-ng compiles very fine.... maybe you've got some problems on
your system....
an output of emerge --info and of make.conf and of the portage log when it
fails compiling might help identifying the problem....

2008/1/28, agtdino <agtdino@teleline.es>:
>
> Hi,
>
> When compile madwifi-ng I get error:
>
> Preparing ath_hal module
> ../scripts/get_arch.mk:44: *** ARCH mismatch: supplied "x86", determined
> "x86_64".  Alto.
> *
> * ERROR: net-wireless/madwifi-ng-0.9.3.3 failed.
>
> perhaps is in inestable?
> I'would tri to maskit.
>
> Thank's and regards
>
>
> --
> gentoo-amd64@lists.gentoo.org mailing list
>
>


-- 
dott. ing. beso

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

Re: [gentoo-amd64] madwifi-ng not compile in amd64

[Volker Armin Hemmann]

On Montag, 28. Januar 2008, agtdino wrote:

kernel version?
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] madwifi-ng not compile in amd64

[Beso]

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

it does gets indicated in emerge --info if i don't remember wrong.
anyway, based on my experience it works fine from 2.6.20 to 2.6.24, so i
think that there's some misconfiguration issues on the host system on which
is trying to install it.

2008/1/28, Volker Armin Hemmann <volker.armin.hemmann@tu-clausthal.de>:
>
> On Montag, 28. Januar 2008, agtdino wrote:
>
> kernel version?
> --
> gentoo-amd64@lists.gentoo.org mailing list
>
>


-- 
dott. ing. beso

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

Re: [gentoo-amd64] madwifi-ng not compile in amd64

[agtdino]

Hi, 


This is emerge --info output 

Portage 2.1.4 (default-linux/amd64/2006.1, gcc-4.2.2, glibc-2.7-r1,
2.6.24-gentoo x86_64)
=================================================================
System uname: 2.6.24-gentoo x86_64 AMD Athlon(tm) 64 Processor 3000+
Timestamp of tree: Mon, 28 Jan 2008 15:29:01 +0000
ccache version 2.4 [enabled]
app-shells/bash:     3.2_p33
dev-java/java-config: 1.3.7, 2.1.3
dev-lang/python:     2.3.6-r3, 2.4.4-r6, 2.5.1-r5
dev-python/pycrypto: 2.0.1-r6
dev-util/ccache:     2.4-r7
sys-apps/baselayout: 1.12.11.1
sys-apps/sandbox:    1.2.18.1-r2
sys-devel/autoconf:  2.13, 2.61-r1
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2,
1.10.1
sys-devel/binutils:  2.18-r1
sys-devel/gcc-config: 1.4.0-r4
sys-devel/libtool:   1.5.24
virtual/os-headers:  2.6.24
ACCEPT_KEYWORDS="amd64 ~amd64"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=k8 -pipe -O2"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /var/service"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d"
CXXFLAGS="-march=k8 -pipe -O2"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig ccache distlocks metadata-transfer parallel-fetch
sandbox sfperms strict unmerge-orphans userfetch"
GENTOO_MIRRORS="http://distfiles.gentoo.org
http://distro.ibiblio.org/pub/linux/distributions/gentoo
ftp://mirrors.blueyonder.co.uk/sites/gentoo
ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo
ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo
http://mirror.switch.ch/mirror/gentoo/
ftp://mirror.switch.ch/mirror/gentoo/ ftp://ftp.solnet.ch/mirror/Gentoo
http://www.mirror.ac.uk/mirror/www.ibiblio.org/"
LANG="es_ES.utf8"
LC_ALL="es_ES.utf8"
LINGUAS="es"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times
--compress --force --whole-file --delete --stats --timeout=180
--exclude=/distfiles --exclude=/local --exclude=/packages
--filter=H_**/files/digest-*"
PORTAGE_TMPDIR="/var/tmp/portage"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="X a52 aac alsa amd64 apache2 arts automount avi berkdb bidi
bitmap-fonts cdda cdio cdr cli cpdflib cracklib crypt ctype cups curl
dba dlloader dri dts dvd dvdread encode ffmpeg firefox fortran freetype
gd gdbm gdexternal glade glitz gnome gnutls gpm gtk gtk2 httpd iconv
ipv6 irmc isdnlog jpeg kde lame live mad matroska midi mikmod mjpeg mmx2
mp3 mpeg mplayer mudflap musepack mysql ncurses network new-login nls
nptl nptlonly nvidia ogg oggvorbis opengl openmp pam pcre pdf
pdo-external pear perl photo-viewer php php5 png ppds pppd python
quicktime readline reflection samba scanner sdl session simplexml soap
soup spell spl sqlite ssl stream svg symlink syslog tcpd theora tk
transcode truetype truetype-fonts type1-fonts unicode usb useflag utf8
v4l2 vcd vlc vlm vorbis wxwindows xinerama xml xorg xsl xv xvid zlib"
ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci
emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0
intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci"
ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug
file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null
plug rate route share shm softvol" APACHE2_MODULES="actions alias
auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default
authn_file authz_dbm authz_default authz_groupfile authz_host
authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate
dir disk_cache env expires ext_filter file_cache filter headers ident
imagemap include info log_config logio mem_cache mime mime_magic
negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http
rewrite setenvif so speling status unique_id userdir usertrack
vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux"
LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb
ncurses text" LINGUAS="es" USERLAND="GNU" VIDEO_CARDS="nvidia"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS,
PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS,
PORTDIR_OVERLAY


This is my make.conf


# These settings were set by the catalyst build script that
automatically built this stage
# Please consult /etc/make.conf.example for a more detailed example
CFLAGS="-march=k8 -pipe -O2"
CHOST="x86_64-pc-linux-gnu"
CXXFLAGS="${CFLAGS}"
MAKEOPTS="-j2"
USE="curl soup glitz svg pdf irmc arts useflag lame scanner encode vlc
kde usb vorbis quicktime mjpeg network X glade dvd dvdread ffmpeg mpeg
mad wxwindows aac dts a52 theora oggvorbis freetype bidi xv svga gnutls
stream vlm httpd cdda vcd cdio live mysql python photo-viewer mpeg
mplayer musepack ogg aac nvidia utf8 dri mmx2 opengl cups ssl gtk samba
cli apache2 ctype gd jpeg mysql pcre pdo-external pear png simplexml
soap sqlite truetype xml xsl zlib nls spell gtk2 gnome dvd alsa cdr php
session gdexternal cpdflib berkdb dba php5 unicode mikmod sdl mp3 nptl
nptlonly new-login dlloader symlink mmx sse sse2 3dnowext 3dnow xvid
v4l2 avi transcode xinerama nvidia matroska syslog automount firefox
iconv jpeg tk"  
#GENTOO_MIRRORS="http://linuv.uv.es/mirror/gentoo"
GENTOO_MIRRORS="http://distfiles.gentoo.org
http://distro.ibiblio.org/pub/linux/distributions/gentoo
ftp://mirrors.blueyonder.co.uk/sites/gentoo
ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo
ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo
http://mirror.switch.ch/mirror/gentoo/
ftp://mirror.switch.ch/mirror/gentoo/ ftp://ftp.solnet.ch/mirror/Gentoo
http://www.mirror.ac.uk/mirror/www.ibiblio.org/"
FEATURES="ccache autoconfig distlocks metadata-transfer parallel-fetch
sandbox
sfperms strict"
CCACHE_SIZE="2G"
CCACHE_DIR="/var/tmp/ccache"
LINGUAS="es"
PKGDIR=/usr/portage/packages
PORTAGE_TMPDIR=/var/tmp/portage
#RESUMECOMMAND="/usr/bin/axel -v -a -o /\${DISTDIR}/\${FILE} \${URI}"
#FETCHCOMMAND="/usr/bin/axel -v -a -o /\${DISTDIR}/\${FILE} \${URI}"
#RESUMECOMMAND_HTTP="/usr/bin/axel -v -a -o /\${DISTDIR}/\${FILE} \
${URI}"
#FETCHCOMMAND_HTTP="/usr/bin/axel -v -a -o /\${DISTDIR}/\${FILE} \
${URI}"
#SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
#ACCEPT_KEYWORDS="~amd64"
FETCHCOMMAND="/usr/bin/axel -a -o \${DISTDIR}/\${FILE} \${URI}"
RESUMECOMMAND="${FETCHCOMMAND}"
FETCHCOMMAND_HTTP="/usr/bin/axel -a -o \${DISTDIR}/\${FILE} \${URI}"
RESUMECOMMAND_HTTP="${FETCHCOMMAND}"
ACCEPT_KEYWORDS="amd64 ~amd64"
AUTOCLEAN="yes"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
VIDEO_CARDS="nvidia"
INPUT_DEVICES="keyboard mouse"
SANE_BACKENDS="snapscan"
APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon
authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default
authz_groupfile authz_host authz_owner authz_user autoindex cache dav
dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter
file_cache filter headers ident imagemap include info log_config logio
mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer
proxy_connect proxy_http rewrite setenvif so speling status unique_id
userdir usertrack vhost_alias"


Thank's and regards I have recente update kernel.2.6.24

revdep-rebuild non resolve the problem and maskit the package don't.

Than'ks and regards





El mar, 29-01-2008 a las 07:51 +0000, Beso escribió:
> it does gets indicated in emerge --info if i don't remember wrong.
> anyway, based on my experience it works fine from 2.6.20 to 2.6.24, so
> i think that there's some misconfiguration issues on the host system
> on which is trying to install it.
> 
> 2008/1/28, Volker Armin Hemmann
> <volker.armin.hemmann@tu-clausthal.de>:
>         On Montag, 28. Januar 2008, agtdino wrote:
>         
>         kernel version?
>         --
>         gentoo-amd64@lists.gentoo.org mailing list
>         
> 
> 
> 
> -- 
> dott. ing. beso

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

Re: [gentoo-amd64] madwifi-ng not compile in amd64

[Steev Klimaszewski]

On Tue, 2008-01-29 at 09:17 +0100, agtdino wrote:
> Hi, 
Hi!

I am the maintainer of madwifi-ng - it is currently incompatible (well
there is a patch in bugzilla however it is not the proper fix) with
2.6.24 - if you absolutely must have 2.6.24, then you will need to
compile the madwifi modules from svn, until they put out a release
(which *should* be soon, they are only waiting on two patches) that is
compatible with 2.6.24. 

Sorry for your troubles, for now, unless it is absolutely necessary, I
would suggest continuing using 2.6.23-r6

-- Steev

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

Re: [gentoo-amd64] madwifi-ng not compile in amd64

[agtdino]

Hello, Thank's for the response I will change kernel to 2.6.23-r6.

Regard's

El mar, 29-01-2008 a las 02:31 -0600, Steev Klimaszewski escribió:
> On Tue, 2008-01-29 at 09:17 +0100, agtdino wrote:
> > Hi, 
> Hi!
> 
> I am the maintainer of madwifi-ng - it is currently incompatible (well
> there is a patch in bugzilla however it is not the proper fix) with
> 2.6.24 - if you absolutely must have 2.6.24, then you will need to
> compile the madwifi modules from svn, until they put out a release
> (which *should* be soon, they are only waiting on two patches) that is
> compatible with 2.6.24. 
> 
> Sorry for your troubles, for now, unless it is absolutely necessary, I
> would suggest continuing using 2.6.23-r6
> 
> -- Steev
> 

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

Re: [gentoo-amd64] madwifi-ng not compile in amd64

[Beso]

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

i think that if you're using the flags you're using you're a real gentoo
poweruser. but the fact that the profile is still set to 2006.1 makes me
wonder if you really know what you're doing...
someone who usually uses the flags you're using also uses the latest
profile.
i really think that you should update your profile (use eselect profile to
do it, i think that 2006.1 would disappear in some months) and then compile
at least the base system from the amd64 branch. then you could use
gcc-4.2.2and other things the way you want. i personally use a lot of
unstable stuff,
but the base system is amd64 and not ~amd64.

2008/1/29, agtdino <agtdino@teleline.es>:
>
> Hello, Thank's for the response I will change kernel to 2.6.23-r6.
>
> Regard's
>
> El mar, 29-01-2008 a las 02:31 -0600, Steev Klimaszewski escribió:
> > On Tue, 2008-01-29 at 09:17 +0100, agtdino wrote:
> > > Hi,
> > Hi!
> >
> > I am the maintainer of madwifi-ng - it is currently incompatible (well
> > there is a patch in bugzilla however it is not the proper fix) with
> > 2.6.24 - if you absolutely must have 2.6.24, then you will need to
> > compile the madwifi modules from svn, until they put out a release
> > (which *should* be soon, they are only waiting on two patches) that is
> > compatible with 2.6.24.
> >
> > Sorry for your troubles, for now, unless it is absolutely necessary, I
> > would suggest continuing using 2.6.23-r6
> >
> > -- Steev
> >
>
> --
> gentoo-amd64@lists.gentoo.org mailing list
>
>


-- 
dott. ing. beso

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

Re: [gentoo-amd64] madwifi-ng not compile in amd64

[agtdino]

Well, my system is uptime since for a long time and has many updates
more than I belive!,, :D 
For the moments is running well, I dont be a freek of gentoo but when I
buy the amd64 system I had to make something hard step's to startit,
perhaps it's not something clean and it's has profiles to the pass.
I go to think in change this profile, or it reinstall from scratch ( is
more fastest but the less interesting :( )
 
Thank's and regards

El mar, 29-01-2008 a las 09:56 +0000, Beso escribió:
> i think that if you're using the flags you're using you're a real
> gentoo poweruser. but the fact that the profile is still set to 2006.1
> makes me wonder if you really know what you're doing...
> someone who usually uses the flags you're using also uses the latest
> profile.
> i really think that you should update your profile (use eselect
> profile to do it, i think that 2006.1 would disappear in some months)
> and then compile at least the base system from the amd64 branch. then
> you could use gcc-4.2.2 and other things the way you want. i
> personally use a lot of unstable stuff, but the base system is amd64
> and not ~amd64. 
> 
> 2008/1/29, agtdino <agtdino@teleline.es>:
>         Hello, Thank's for the response I will change kernel to
>         2.6.23-r6.
>         
>         Regard's
>         
>         El mar, 29-01-2008 a las 02:31 -0600, Steev Klimaszewski
>         escribió:
>         > On Tue, 2008-01-29 at 09:17 +0100, agtdino wrote:
>         > > Hi,
>         > Hi!
>         >
>         > I am the maintainer of madwifi-ng - it is currently
>         incompatible (well
>         > there is a patch in bugzilla however it is not the proper
>         fix) with
>         > 2.6.24 - if you absolutely must have 2.6.24, then you will
>         need to
>         > compile the madwifi modules from svn, until they put out a
>         release
>         > (which *should* be soon, they are only waiting on two
>         patches) that is
>         > compatible with 2.6.24.
>         >
>         > Sorry for your troubles, for now, unless it is absolutely
>         necessary, I
>         > would suggest continuing using 2.6.23-r6
>         >
>         > -- Steev
>         >
>         
>         --
>         gentoo-amd64@lists.gentoo.org mailing list
>         
> 
> 
> 
> -- 
> dott. ing. beso

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

Re: [gentoo-amd64] madwifi-ng not compile in amd64

[Beso]

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

well, just removing ~amd64 from your make.conf and eselect profile set
default-linux/amd64/2007.0 and then emerge -uDNvp will let you see what
would compile.
if you instead want to rebuild from scratch then funtoo has recent compiled
stages that would let you not compile a lot of updated stuff.

2008/1/29, agtdino <agtdino@teleline.es>:
>
> Well, my system is uptime since for a long time and has many updates
> more than I belive!,, :D
> For the moments is running well, I dont be a freek of gentoo but when I
> buy the amd64 system I had to make something hard step's to startit,
> perhaps it's not something clean and it's has profiles to the pass.
> I go to think in change this profile, or it reinstall from scratch ( is
> more fastest but the less interesting :( )
>
> Thank's and regards
>
> El mar, 29-01-2008 a las 09:56 +0000, Beso escribió:
> > i think that if you're using the flags you're using you're a real
> > gentoo poweruser. but the fact that the profile is still set to 2006.1
> > makes me wonder if you really know what you're doing...
> > someone who usually uses the flags you're using also uses the latest
> > profile.
> > i really think that you should update your profile (use eselect
> > profile to do it, i think that 2006.1 would disappear in some months)
> > and then compile at least the base system from the amd64 branch. then
> > you could use gcc-4.2.2 and other things the way you want. i
> > personally use a lot of unstable stuff, but the base system is amd64
> > and not ~amd64.
> >
> > 2008/1/29, agtdino <agtdino@teleline.es>:
> >         Hello, Thank's for the response I will change kernel to
> >         2.6.23-r6.
> >
> >         Regard's
> >
> >         El mar, 29-01-2008 a las 02:31 -0600, Steev Klimaszewski
> >         escribió:
> >         > On Tue, 2008-01-29 at 09:17 +0100, agtdino wrote:
> >         > > Hi,
> >         > Hi!
> >         >
> >         > I am the maintainer of madwifi-ng - it is currently
> >         incompatible (well
> >         > there is a patch in bugzilla however it is not the proper
> >         fix) with
> >         > 2.6.24 - if you absolutely must have 2.6.24, then you will
> >         need to
> >         > compile the madwifi modules from svn, until they put out a
> >         release
> >         > (which *should* be soon, they are only waiting on two
> >         patches) that is
> >         > compatible with 2.6.24.
> >         >
> >         > Sorry for your troubles, for now, unless it is absolutely
> >         necessary, I
> >         > would suggest continuing using 2.6.23-r6
> >         >
> >         > -- Steev
> >         >
> >
> >         --
> >         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: 4738 bytes --]

Re: [gentoo-amd64] madwifi-ng not compile in amd64

[agtdino]

Hi, 


# eselect profile list
Available profile symlink targets:
  [1]   default-linux/amd64/2006.1 *
  [2]   default-linux/amd64/2006.1/desktop
  [3]   default-linux/amd64/2006.0/no-symlinks
  [4]   default-linux/amd64/2006.1/no-multilib
  [5]   default-linux/amd64/2007.0
  [6]   default-linux/amd64/2007.0/desktop
  [7]   default-linux/amd64/2007.0/no-multilib
  [8]   default-linux/amd64/2007.0/server
  [9]   hardened/amd64
  [10]  hardened/amd64/multilib
  [11]  selinux/2007.0/amd64
  [12]  selinux/2007.0/amd64/hardened

#eselect profile set 6

And then - sos -

# emerge --update --deep --newuse --pretend --verbose world


Total: 478 packages (1 upgrade, 396 downgrades, 14 new, 1 in new slot,
66 reinstalls, 5 blocks), Size of downloads: 480,074 kB

so bad! :----(

perhaps with the 2Gb of ccache that I have saved could take this process
only one or 2 days. 

Thank's for the tip  


El mar, 29-01-2008 a las 11:22 +0000, Beso escribió:
> well, just removing ~amd64 from your make.conf and eselect profile set
> default-linux/amd64/2007.0 and then emerge -uDNvp will let you see
> what would compile.
> if you instead want to rebuild from scratch then funtoo has recent
> compiled stages that would let you not compile a lot of updated stuff.
> 
> 2008/1/29, agtdino <agtdino@teleline.es>:
>         Well, my system is uptime since for a long time and has many
>         updates
>         more than I belive!,, :D
>         For the moments is running well, I dont be a freek of gentoo
>         but when I
>         buy the amd64 system I had to make something hard step's to
>         startit,
>         perhaps it's not something clean and it's has profiles to the
>         pass.
>         I go to think in change this profile, or it reinstall from
>         scratch ( is
>         more fastest but the less interesting :( )
>         
>         Thank's and regards
>         
>         El mar, 29-01-2008 a las 09:56 +0000, Beso escribió:
>         > i think that if you're using the flags you're using you're a
>         real
>         > gentoo poweruser. but the fact that the profile is still set
>         to 2006.1
>         > makes me wonder if you really know what you're doing...
>         > someone who usually uses the flags you're using also uses
>         the latest
>         > profile.
>         > i really think that you should update your profile (use
>         eselect
>         > profile to do it, i think that 2006.1 would disappear in
>         some months)
>         > and then compile at least the base system from the amd64
>         branch. then
>         > you could use gcc-4.2.2 and other things the way you want. i
>         > personally use a lot of unstable stuff, but the base system
>         is amd64
>         > and not ~amd64.
>         >
>         > 2008/1/29, agtdino <agtdino@teleline.es>:
>         >         Hello, Thank's for the response I will change kernel
>         to
>         >         2.6.23-r6.
>         >
>         >         Regard's
>         >
>         >         El mar, 29-01-2008 a las 02:31 -0600, Steev
>         Klimaszewski
>         >         escribió:
>         >         > On Tue, 2008-01-29 at 09:17 +0100, agtdino wrote:
>         >         > > Hi,
>         >         > Hi!
>         >         >
>         >         > I am the maintainer of madwifi-ng - it is
>         currently
>         >         incompatible (well
>         >         > there is a patch in bugzilla however it is not the
>         proper
>         >         fix) with
>         >         > 2.6.24 - if you absolutely must have 2.6.24, then
>         you will
>         >         need to
>         >         > compile the madwifi modules from svn, until they
>         put out a
>         >         release
>         >         > (which *should* be soon, they are only waiting on
>         two
>         >         patches) that is
>         >         > compatible with 2.6.24.
>         >         >
>         >         > Sorry for your troubles, for now, unless it is
>         absolutely
>         >         necessary, I
>         >         > would suggest continuing using 2.6.23-r6
>         >         >
>         >         > -- Steev
>         >         >
>         >
>         >         --
>         >         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

Re: [gentoo-amd64] madwifi-ng not compile in amd64

[Beso]

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

the real problem stands in the keyword.... the amd64 would downgrade a lot
of stuff.... before doing it it's better to identify the normal programs,
like kde, gnome, and similar and let them be for the moment as ~amd64....
but at least stuff like, gcc, glibc, baselayout, kernel and some other base
stuff should stay on the amd64 branch.... you won't be able to downgrade
glibc so that one for the moment would stay on the unstable branch.... but
if you don't feel in the mood to downgrade cause the  ~amd64 being to amd64,
then just update the profile and you should see something like 100
packages....
also adding --as-needed as LDFLAGS should help you save some time in
recompiling stuff....
the 2gb of ccache would help, but not a lot.... 400+ packages would mean
about 3-4 days on a amd64 2ghz single core, so prepare for a looong time of
compile time.... also the 5 blockers are not good and should be fixed in
some way before proceeding to the recompile....
if you decide to modify the use flags when changing profile it's the best
time....
so my advice is the following:
1. take some time to look at the use flags (emerge ufed and see a
description of them and also add/remove them from the ufed gui in make.conf)
2. add LDFLAGS="--as-needed" into make.conf
3. take some time to see what packages are needed on ~amd64 (normally kde,
gnome, and other normal use packages like firefox, ktorrent or similar or
even xorg are good also on ~amd64 and don't need a downgrade), but others as
gcc, baselayout, libstdc++, dhcpclient, dhcpcd, network related packages and
kernel modules are normally best on amd64. i'm not saying that using them on
~amd64 won't work, but on this branch you might experience various problems.
after deciding what you want to mantain as ~amd64 you add them to
package.keywords in /et/portage/ with ~amd64 flag and then remove the flag
in make.conf. after that retry the update and see that the number of
packages has decreased dramatically. take another look at the downgraded
stuff and after being sure you could start the update of your system.
this step is a little boring, but after some time spent on configuration,
unmask and mask you'll find yourself with a system with the following
characteristics:
- base system = stable
- cutting edge apps, which sometimes could bring out some problems, but that
wouldn't be caused by system packages faults.

if you want to see some more stuff i reccomend the following overlays:
- sunrise: has a lot of extra interesting stuff of various kind, from
developer stuff to user apps as miro, the free web tv player that challenges
joost.
- sabayon: has some interesting things like the kde4 style kicker for
3.5.8branch
- flameeyes-overlay: has some memory improved stuff like patched codecs and
the oxy-cursors that are really great. from this overlay be sure not to
compile the xine-lib because it's not meant to work with versions of amarok
before the 2.0 and since it has some issues caused by the developing process
(this xine-lib is meant for integration with kde4 and phonon). i recommend
the other codecs like giflib and theora since they have a patch for shared
memory improvements. i also reccomend the ffmpeg with hardcoded-tables flag
from this overlay.
- berkano: has some media related packages like x264-svn, new k3b and some
other media packages
- x11: if you want svn versions of xorg and its components add this overlay.
i've seen some great improvements with the new xf86-video-ati after it has
ggod support for x200m and rs690 and the new mesa and glitz from svn have
some font antialiasing stuff that is really interesting.
to add them emerge layman and use it to update and mantain the new
repositories. on gentoo wiki there are wikis on how to install and use
layman.
if you need some help with the packages or use flags feel free to ask. i'll
try explaining what are my experiences with them.
remember to run revdep-rebuild after updating since it's very likely to have
broken linkage after an update of 400 packages.

ps. consider the profile update as a gentoo full update. if you think about
distro that use versioning then it's similar to updating to ubuntu 7 from
ubuntu 6. so it's normal to have a lot of packages pushed in considering use
flags changes and keywords ones.



2008/1/29, agtdino <agtdino@teleline.es>:
>
> Hi,
>
>
> # eselect profile list
> Available profile symlink targets:
>   [1]   default-linux/amd64/2006.1 *
>   [2]   default-linux/amd64/2006.1/desktop
>   [3]   default-linux/amd64/2006.0/no-symlinks
>   [4]   default-linux/amd64/2006.1/no-multilib
>   [5]   default-linux/amd64/2007.0
>   [6]   default-linux/amd64/2007.0/desktop
>   [7]   default-linux/amd64/2007.0/no-multilib
>   [8]   default-linux/amd64/2007.0/server
>   [9]   hardened/amd64
>   [10]  hardened/amd64/multilib
>   [11]  selinux/2007.0/amd64
>   [12]  selinux/2007.0/amd64/hardened
>
> #eselect profile set 6
>
> And then - sos -
>
> # emerge --update --deep --newuse --pretend --verbose world
>
>
> Total: 478 packages (1 upgrade, 396 downgrades, 14 new, 1 in new slot,
> 66 reinstalls, 5 blocks), Size of downloads: 480,074 kB
>
> so bad! :----(
>
> perhaps with the 2Gb of ccache that I have saved could take this process
> only one or 2 days.
>
> Thank's for the tip
>
>
> El mar, 29-01-2008 a las 11:22 +0000, Beso escribió:
> > well, just removing ~amd64 from your make.conf and eselect profile set
> > default-linux/amd64/2007.0 and then emerge -uDNvp will let you see
> > what would compile.
> > if you instead want to rebuild from scratch then funtoo has recent
> > compiled stages that would let you not compile a lot of updated stuff.
> >
> > 2008/1/29, agtdino <agtdino@teleline.es>:
> >         Well, my system is uptime since for a long time and has many
> >         updates
> >         more than I belive!,, :D
> >         For the moments is running well, I dont be a freek of gentoo
> >         but when I
> >         buy the amd64 system I had to make something hard step's to
> >         startit,
> >         perhaps it's not something clean and it's has profiles to the
> >         pass.
> >         I go to think in change this profile, or it reinstall from
> >         scratch ( is
> >         more fastest but the less interesting :( )
> >
> >         Thank's and regards
> >
> >         El mar, 29-01-2008 a las 09:56 +0000, Beso escribió:
> >         > i think that if you're using the flags you're using you're a
> >         real
> >         > gentoo poweruser. but the fact that the profile is still set
> >         to 2006.1
> >         > makes me wonder if you really know what you're doing...
> >         > someone who usually uses the flags you're using also uses
> >         the latest
> >         > profile.
> >         > i really think that you should update your profile (use
> >         eselect
> >         > profile to do it, i think that 2006.1 would disappear in
> >         some months)
> >         > and then compile at least the base system from the amd64
> >         branch. then
> >         > you could use gcc-4.2.2 and other things the way you want. i
> >         > personally use a lot of unstable stuff, but the base system
> >         is amd64
> >         > and not ~amd64.
> >         >
> >         > 2008/1/29, agtdino <agtdino@teleline.es>:
> >         >         Hello, Thank's for the response I will change kernel
> >         to
> >         >         2.6.23-r6.
> >         >
> >         >         Regard's
> >         >
> >         >         El mar, 29-01-2008 a las 02:31 -0600, Steev
> >         Klimaszewski
> >         >         escribió:
> >         >         > On Tue, 2008-01-29 at 09:17 +0100, agtdino wrote:
> >         >         > > Hi,
> >         >         > Hi!
> >         >         >
> >         >         > I am the maintainer of madwifi-ng - it is
> >         currently
> >         >         incompatible (well
> >         >         > there is a patch in bugzilla however it is not the
> >         proper
> >         >         fix) with
> >         >         > 2.6.24 - if you absolutely must have 2.6.24, then
> >         you will
> >         >         need to
> >         >         > compile the madwifi modules from svn, until they
> >         put out a
> >         >         release
> >         >         > (which *should* be soon, they are only waiting on
> >         two
> >         >         patches) that is
> >         >         > compatible with 2.6.24.
> >         >         >
> >         >         > Sorry for your troubles, for now, unless it is
> >         absolutely
> >         >         necessary, I
> >         >         > would suggest continuing using 2.6.23-r6
> >         >         >
> >         >         > -- Steev
> >         >         >
> >         >
> >         >         --
> >         >         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
>
>


-- 
dott. ing. beso

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

Re: [gentoo-amd64] madwifi-ng not compile in amd64

[Volker Armin Hemmann]

On Mittwoch, 30. Januar 2008, Beso wrote:
> the real problem stands in the keyword.... the amd64 would downgrade a lot
> of stuff.... before doing it it's better to identify the normal programs,
> like kde, gnome, and similar and let them be for the moment as ~amd64....
> but at least stuff like, gcc, glibc, baselayout, kernel and some other base
> stuff should stay on the amd64 branch.... you won't be able to downgrade
> glibc so that one for the moment would stay on the unstable branch.... but
> if you don't feel in the mood to downgrade cause the  ~amd64 being to
> amd64, then just update the profile and you should see something like 100
> packages....
> also adding --as-needed as LDFLAGS should help you save some time in
> recompiling stuff....

yeah - no. Don't do it. It breaks stuff.

> the 2gb of ccache would help, but not a lot.... 400+ packages would mean
> about 3-4 days on a amd64 2ghz single core, so prepare for a looong time of
> compile time.... also the 5 blockers are not good and should be fixed in
> some way before proceeding to the recompile....

no, it would mean something around 12h. Depending on the packages.


> if you decide to modify the use flags when changing profile it's the best
> time....

yeah, check which flags changed, and which ones you really need. That way you 
might be able to cut down the amount of packages.

> so my advice is the following:
> 1. take some time to look at the use flags (emerge ufed and see a
> description of them and also add/remove them from the ufed gui in
> make.conf) 
> 2. add LDFLAGS="--as-needed" into make.conf 

really, don't do it.

> > Total: 478 packages (1 upgrade, 396 downgrades, 14 new, 1 in new slot,
> > 66 reinstalls, 5 blocks), Size of downloads: 480,074 kB

check your keywords - and blockers are easily solved. Usually you need to 
unmerge something. And the blocking ebuild tells you what.


And agtdino and Beso:

DO NOT TOP POST.

This is not a Windows mailing list.
-- 
gentoo-amd64@lists.gentoo.org mailing list

[gentoo-amd64] Re: madwifi-ng not compile in amd64

[Duncan]

Volker Armin Hemmann <volker.armin.hemmann@tu-clausthal.de> posted
200801300220.21430.volker.armin.hemmann@tu-clausthal.de, excerpted below,
on  Wed, 30 Jan 2008 02:20:21 +0100:

>> also adding --as-needed as LDFLAGS should help you save some time in
>> recompiling stuff....
> 
> yeah - no. Don't do it. It breaks stuff.

I think the breakage in most of the common stuff Gentoo devs anyway use 
has been fixed by now.  I know I've had surprisingly few problems (read, 
ZERO problems) with it here.  Surprising, as I expected at least a few, 
but I've seen exactly ZERO.

That said, especially for those who just want things to work, without 
having to futz with LDFLAGS and remerge something occasionally, I'd still 
not recommend it.  For those that enjoy the challenge of such things, 
however, I'd say great!  Go for it!  And for those in the middle, well, 
YMMV, as the saying goes.  You probably lean one way or the other, so 
take your pick.

As for amd64 vs. ~amd64, I'm 100% ~amd64 here, and have been from when I 
started on Gentoo.  In fact, I've read suggestions that Gentoo tends to 
work better at ~arch than at stable, because ~ is where most developers 
are, and it's not uncommon for certain incompatibilities with "old" 
software, that is, the crufty stable stuff from months or years ago 
that's common in stable, to be overlooked until some poor stable keyword 
user files a bug.  Yes, before stabilizing, the arch-devs and arch-
testers normally test a package against a full-stable system, but it's 
simply not possible to test against every permutation of USE flags and 
mix of merged apps.  While it's certainly true that ~arch packages have 
the same issue, at least there there's a decently active community of 
testers actively reporting bugs and devs fixing them.

Were it conveniently possible, I'd say the most trouble-free scenario 
would be to take only ~arch packages that had been ~arch for say a week, 
minimum, after verifying that nobody had run into and filed any serious 
bugs on them.  That'd be after the initial test wave had done its 
installation and testing, but before the cruft that often attaches to 
stable had set in.  

<brainstorming> What would be great would be a keyword system that would 
allow just this, say ~ for initial testing, automatically upgraded to / 
after the week UNLESS they've been marked ~~, with the extra ~ 
automatically added to ~ packages by a script if a bug has been filed, 
blocking the automatic upgrade to /, and a bugzilla keyword that a dev 
could add to put the package back on automated / track if they've decided 
the bug isn't worth derailing the automated / upgrade over.  Then people 
could go full testing ~ mode if they wanted, / mode if they wanted almost 
~ but wanted to be spared the pain of the most obvious bugs as found in 
the initial testing wave, and full stable arch if they wanted crufty old 
packages, say for a server only upgraded for security issues or the like, 
somewhere. </brainstorming>

Of course, YMMV, but ~ for the entire system, with appropriate site based 
masking as Gentoo already makes possible with /etc/portage/package.mask 
and the like, isn't as terrible or system breaking as some folks like to 
make it out to be.  By policy, ~ is only for stable track packages in the 
first place.  Obviously broken packages and those not considered stable 
candidates normally never get even the ~ keyword, as they are kept in 
development overlays or in the tree but without keywords or fully hard 
masked, so ~ packages aren't the broken things a lot of people make them 
out to be.

-- 
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: madwifi-ng not compile in amd64

[Volker Armin Hemmann]

On Mittwoch, 30. Januar 2008, Duncan wrote:
> Volker Armin Hemmann <volker.armin.hemmann@tu-clausthal.de> posted
> 200801300220.21430.volker.armin.hemmann@tu-clausthal.de, excerpted below,
>
> on  Wed, 30 Jan 2008 02:20:21 +0100:
> >> also adding --as-needed as LDFLAGS should help you save some time in
> >> recompiling stuff....
> >
> > yeah - no. Don't do it. It breaks stuff.
>
> I think the breakage in most of the common stuff Gentoo devs anyway use
> has been fixed by now.  I know I've had surprisingly few problems (read,
> ZERO problems) with it here.  Surprising, as I expected at least a few,
> but I've seen exactly ZERO.
>
> That said, especially for those who just want things to work, without
> having to futz with LDFLAGS and remerge something occasionally, I'd still
> not recommend it.  For those that enjoy the challenge of such things,
> however, I'd say great!  Go for it!  And for those in the middle, well,
> YMMV, as the saying goes.  You probably lean one way or the other, so
> take your pick.

aren't bug reports with --as-needed closed as invalid per default?

>
> As for amd64 vs. ~amd64, I'm 100% ~amd64 here, and have been from when I
> started on Gentoo. 

when I started with gentoo, there was no 'stable' or 'unstable'.

And IMHO that was a lot better. But some day some people tried to turn gentoo 
into a 'debian from source'. 

> In fact, I've read suggestions that Gentoo tends to 
> work better at ~arch than at stable, because ~ is where most developers
> are, and it's not uncommon for certain incompatibilities with "old"
> software, that is, the crufty stable stuff from months or years ago
> that's common in stable, to be overlooked until some poor stable keyword
> user files a bug.  Yes, before stabilizing, the arch-devs and arch-
> testers normally test a package against a full-stable system, but it's
> simply not possible to test against every permutation of USE flags and
> mix of merged apps.  While it's certainly true that ~arch packages have
> the same issue, at least there there's a decently active community of
> testers actively reporting bugs and devs fixing them.

from my experience, go stable or unstable. But don't mix. And a better name 
for stable would be 'stale'.

That said, a lot of problems who hit me as an unstable user hit my 'stable' 
friends too. So why use 'stable' at all?

>
>
> <brainstorming> What would be great would be a keyword system that would
> allow just this, say ~ for initial testing, automatically upgraded to /
> after the week UNLESS they've been marked ~~, with the extra ~
> automatically added to ~ packages by a script if a bug has been filed,
> blocking the automatic upgrade to /, and a bugzilla keyword that a dev
> could add to put the package back on automated / track if they've decided
> the bug isn't worth derailing the automated / upgrade over.  Then people
> could go full testing ~ mode if they wanted, / mode if they wanted almost
> ~ but wanted to be spared the pain of the most obvious bugs as found in
> the initial testing wave, and full stable arch if they wanted crufty old
> packages, say for a server only upgraded for security issues or the like,
> somewhere. </brainstorming>

what would be great would be recognizing that 'stable' does not work.

>
> Of course, YMMV, but ~ for the entire system, with appropriate site based
> masking as Gentoo already makes possible with /etc/portage/package.mask
> and the like, isn't as terrible or system breaking as some folks like to
> make it out to be.  By policy, ~ is only for stable track packages in the
> first place.  Obviously broken packages and those not considered stable
> candidates normally never get even the ~ keyword, as they are kept in
> development overlays or in the tree but without keywords or fully hard
> masked, so ~ packages aren't the broken things a lot of people make them
> out to be.

exactly.

~arch is not for broken packages, brocken or highly experimental stuff is in 
package.mask.


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

Re: [gentoo-amd64] Re: madwifi-ng not compile in amd64

[Beso]

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

2008/1/30, Volker Armin Hemmann <volker.armin.hemmann@tu-clausthal.de>:
>
> On Mittwoch, 30. Januar 2008, Duncan wrote:
> > Volker Armin Hemmann <volker.armin.hemmann@tu-clausthal.de> posted
> > 200801300220.21430.volker.armin.hemmann@tu-clausthal.de, excerpted
> below,
> >
> > on  Wed, 30 Jan 2008 02:20:21 +0100:
> > >> also adding --as-needed as LDFLAGS should help you save some time in
> > >> recompiling stuff....
> > >
> > > yeah - no. Don't do it. It breaks stuff.
> >
> > I think the breakage in most of the common stuff Gentoo devs anyway use
> > has been fixed by now.  I know I've had surprisingly few problems (read,
> > ZERO problems) with it here.  Surprising, as I expected at least a few,
> > but I've seen exactly ZERO.
> >
> > That said, especially for those who just want things to work, without
> > having to futz with LDFLAGS and remerge something occasionally, I'd
> still
> > not recommend it.  For those that enjoy the challenge of such things,
> > however, I'd say great!  Go for it!  And for those in the middle, well,
> > YMMV, as the saying goes.  You probably lean one way or the other, so
> > take your pick.
>
> aren't bug reports with --as-needed closed as invalid per default?


they might be, but the fact is that the flag is good and working well.

>
> > As for amd64 vs. ~amd64, I'm 100% ~amd64 here, and have been from when I
> > started on Gentoo.
>
> when I started with gentoo, there was no 'stable' or 'unstable'.
>
> And IMHO that was a lot better. But some day some people tried to turn
> gentoo
> into a 'debian from source'.


hmmm.... from what i remember gento always had stable/unstable branches.
i've started using it about 4 or 5 years ago and for what i remember the 2
branches were there already....

> In fact, I've read suggestions that Gentoo tends to
> > work better at ~arch than at stable, because ~ is where most developers
> > are, and it's not uncommon for certain incompatibilities with "old"
> > software, that is, the crufty stable stuff from months or years ago
> > that's common in stable, to be overlooked until some poor stable keyword
> > user files a bug.  Yes, before stabilizing, the arch-devs and arch-
> > testers normally test a package against a full-stable system, but it's
> > simply not possible to test against every permutation of USE flags and
> > mix of merged apps.  While it's certainly true that ~arch packages have
> > the same issue, at least there there's a decently active community of
> > testers actively reporting bugs and devs fixing them.
>
> from my experience, go stable or unstable. But don't mix. And a better
> name
> for stable would be 'stale'.
>
> That said, a lot of problems who hit me as an unstable user hit my
> 'stable'
> friends too. So why use 'stable' at all?


well, i had more problems with  whole unstable system. the whole unstable
could mix up your system, since a daily update, as i do, especially on
system packages is bad. it could push in some bad stuff inside.

>
> >
> > <brainstorming> What would be great would be a keyword system that would
> > allow just this, say ~ for initial testing, automatically upgraded to /
> > after the week UNLESS they've been marked ~~, with the extra ~
> > automatically added to ~ packages by a script if a bug has been filed,
> > blocking the automatic upgrade to /, and a bugzilla keyword that a dev
> > could add to put the package back on automated / track if they've
> decided
> > the bug isn't worth derailing the automated / upgrade over.  Then people
> > could go full testing ~ mode if they wanted, / mode if they wanted
> almost
> > ~ but wanted to be spared the pain of the most obvious bugs as found in
> > the initial testing wave, and full stable arch if they wanted crufty old
> > packages, say for a server only upgraded for security issues or the
> like,
> > somewhere. </brainstorming>
>
> what would be great would be recognizing that 'stable' does not work.


the problem is that stable needs a lot of testing. and the devs don't have
the time to test is anymore. kde3.5.8 went stable yesterday, but i've been
using it from when it got into portage without problems. also, there are a
lot of unstable packages that the people need so what i'd suggest is the
removal of stable for non-system packages.

>
> > Of course, YMMV, but ~ for the entire system, with appropriate site
> based
> > masking as Gentoo already makes possible with /etc/portage/package.mask
> > and the like, isn't as terrible or system breaking as some folks like to
> > make it out to be.  By policy, ~ is only for stable track packages in
> the
> > first place.  Obviously broken packages and those not considered stable
> > candidates normally never get even the ~ keyword, as they are kept in
> > development overlays or in the tree but without keywords or fully hard
> > masked, so ~ packages aren't the broken things a lot of people make them
> > out to be.
>
> exactly.
>
> ~arch is not for broken packages, brocken or highly experimental stuff is
> in
> package.mask.


or doesn't get into portage at all.... usually a package that is broken
isn't in portage, unless it has already gotten into, but was found broken.

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


-- 
dott. ing. beso

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

Re: [gentoo-amd64] Re: madwifi-ng not compile in amd64

[Volker Armin Hemmann]

On Mittwoch, 30. Januar 2008, Beso wrote:
> 2008/1/30, Volker Armin Hemmann <volker.armin.hemmann@tu-clausthal.de>:

> > aren't bug reports with --as-needed closed as invalid per default?
>
> they might be, but the fact is that the flag is good and working well.

if you can't report bugs, a flag is not good.


> > when I started with gentoo, there was no 'stable' or 'unstable'.
> >
> > And IMHO that was a lot better. But some day some people tried to turn
> > gentoo
> > into a 'debian from source'.
>
> hmmm.... from what i remember gento always had stable/unstable branches.

no ;)
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: madwifi-ng not compile in amd64

[Beso]

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

2008/1/30, Volker Armin Hemmann <volker.armin.hemmann@tu-clausthal.de>:
>
> On Mittwoch, 30. Januar 2008, Beso wrote:
> > 2008/1/30, Volker Armin Hemmann <volker.armin.hemmann@tu-clausthal.de>:
>
> > > aren't bug reports with --as-needed closed as invalid per default?
> >
> > they might be, but the fact is that the flag is good and working well.
>
> if you can't report bugs, a flag is not good.


for what i know a bug is a bug when you have tested that it doesn't present
on an all-stable system. to report a bug just remove the flag and see what
hapens. if it's still there then the bug is present. i don't see the
difficulty.


-- 
dott. ing. beso

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

Re: [gentoo-amd64] Re: madwifi-ng not compile in amd64

[Volker Armin Hemmann]

On Mittwoch, 30. Januar 2008, Beso wrote:
> 2008/1/30, Volker Armin Hemmann <volker.armin.hemmann@tu-clausthal.de>:
> > On Mittwoch, 30. Januar 2008, Beso wrote:
> > > 2008/1/30, Volker Armin Hemmann <volker.armin.hemmann@tu-clausthal.de>:
> > > > aren't bug reports with --as-needed closed as invalid per default?
> > >
> > > they might be, but the fact is that the flag is good and working well.
> >
> > if you can't report bugs, a flag is not good.
>
> for what i know a bug is a bug when you have tested that it doesn't present
> on an all-stable system. to report a bug just remove the flag and see what
> hapens. if it's still there then the bug is present. i don't see the
> difficulty.

you not only have to remove the flag but to rebuild the complete system.
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: madwifi-ng not compile in amd64

[Beso]

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

2008/1/30, Volker Armin Hemmann <volker.armin.hemmann@tu-clausthal.de>:
>
> On Mittwoch, 30. Januar 2008, Beso wrote:
> > 2008/1/30, Volker Armin Hemmann <volker.armin.hemmann@tu-clausthal.de>:
> > > On Mittwoch, 30. Januar 2008, Beso wrote:
> > > > 2008/1/30, Volker Armin Hemmann <
> volker.armin.hemmann@tu-clausthal.de>:
> > > > > aren't bug reports with --as-needed closed as invalid per default?
> > > >
> > > > they might be, but the fact is that the flag is good and working
> well.
> > >
> > > if you can't report bugs, a flag is not good.
> >
> > for what i know a bug is a bug when you have tested that it doesn't
> present
> > on an all-stable system. to report a bug just remove the flag and see
> what
> > hapens. if it's still there then the bug is present. i don't see the
> > difficulty.
>
> you not only have to remove the flag but to rebuild the complete system.


this thing doesn't results to me. but this is not a problem since till now i
haven't got any problem with it, but only satisfactions. i'm not here to
force anyone on having it, but since it is just widely accepted as not
problematic and since i haven't got any problems with it, then there's no
harm in advising people to use it.

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


-- 
dott. ing. beso

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

Re: [gentoo-amd64] Re: madwifi-ng not compile in amd64

[Beso]

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

2008/1/30, Duncan <1i5t5.duncan@cox.net>:
>
> Volker Armin Hemmann <volker.armin.hemmann@tu-clausthal.de> posted
> 200801300220.21430.volker.armin.hemmann@tu-clausthal.de, excerpted below,
> on  Wed, 30 Jan 2008 02:20:21 +0100:
>
> >> also adding --as-needed as LDFLAGS should help you save some time in
> >> recompiling stuff....
> >
> > yeah - no. Don't do it. It breaks stuff.
>
> I think the breakage in most of the common stuff Gentoo devs anyway use
> has been fixed by now.  I know I've had surprisingly few problems (read,
> ZERO problems) with it here.  Surprising, as I expected at least a few,
> but I've seen exactly ZERO.
>
> That said, especially for those who just want things to work, without
> having to futz with LDFLAGS and remerge something occasionally, I'd still
> not recommend it.  For those that enjoy the challenge of such things,
> however, I'd say great!  Go for it!  And for those in the middle, well,
> YMMV, as the saying goes.  You probably lean one way or the other, so
> take your pick.


for me it has worked as a charm and as i've said: the ebuilds that are
broken by it usually have ldflags removed so there's no need to worry
anymore for it. i found it something awesome after the libexpat-2 update.
without it i would have to emerge abour 300 packages (kde stuff, gcc,
mime-shared, firefox ecc) but with it i only needed something like 10-15
packages of which 7 were updates and 2 or 3 had use flags changed. the doc
about that flag is about 2 and a half years old and wasn't updated since
then. i bet that every single dev would advise to us the flag if you happen
to do have some packages that need to recompile broken stuff (x264-svn,
ffmpeg and xine-lib would push some package recompile).
i'd also advise to use the the --buildpkg feature for some high compiling
time packages like kdebase, gcc, openoffice or mplayer. since these packages
are likely to be the same for quite some time and they might be pushed into
recompilation by some other updates having them packaged on disk (they'd
require disk space when packaged) would mean to skip all the compilation
part and jump directly to the install one (of course if they would need to
be recompiled portage would do it).

As for amd64 vs. ~amd64, I'm 100% ~amd64 here, and have been from when I
> started on Gentoo.  In fact, I've read suggestions that Gentoo tends to
> work better at ~arch than at stable, because ~ is where most developers
> are, and it's not uncommon for certain incompatibilities with "old"
> software, that is, the crufty stable stuff from months or years ago
> that's common in stable, to be overlooked until some poor stable keyword
> user files a bug.  Yes, before stabilizing, the arch-devs and arch-
> testers normally test a package against a full-stable system, but it's
> simply not possible to test against every permutation of USE flags and
> mix of merged apps.  While it's certainly true that ~arch packages have
> the same issue, at least there there's a decently active community of
> testers actively reporting bugs and devs fixing them.


well, i'm more pleased by live ebuilds. i personally use a good ammount of
live packages, especially multimedia, xorg and some network stuff like
networkmanager and knm.

Were it conveniently possible, I'd say the most trouble-free scenario
> would be to take only ~arch packages that had been ~arch for say a week,
> minimum, after verifying that nobody had run into and filed any serious
> bugs on them.  That'd be after the initial test wave had done its
> installation and testing, but before the cruft that often attaches to
> stable had set in.
>
> <brainstorming> What would be great would be a keyword system that would
> allow just this, say ~ for initial testing, automatically upgraded to /
> after the week UNLESS they've been marked ~~, with the extra ~
> automatically added to ~ packages by a script if a bug has been filed,
> blocking the automatic upgrade to /, and a bugzilla keyword that a dev
> could add to put the package back on automated / track if they've decided
> the bug isn't worth derailing the automated / upgrade over.  Then people
> could go full testing ~ mode if they wanted, / mode if they wanted almost
> ~ but wanted to be spared the pain of the most obvious bugs as found in
> the initial testing wave, and full stable arch if they wanted crufty old
> packages, say for a server only upgraded for security issues or the like,
> somewhere. </brainstorming>


usually that's the point of hard masking. when a package doesn't work then
it goes hardmasked.

Of course, YMMV, but ~ for the entire system, with appropriate site based
> masking as Gentoo already makes possible with /etc/portage/package.mask
> and the like, isn't as terrible or system breaking as some folks like to
> make it out to be.  By policy, ~ is only for stable track packages in the
> first place.  Obviously broken packages and those not considered stable
> candidates normally never get even the ~ keyword, as they are kept in
> development overlays or in the tree but without keywords or fully hard
> masked, so ~ packages aren't the broken things a lot of people make them
> out to be.


i still think that having the base system on the unstable arch isn't a very
good idea. i've used the same stuff for quite some time, but i found out
that it isn't a very good stuff. or at least 6 months ago wasn't a good
idea.

--
> 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: 7210 bytes --]

[gentoo-amd64] Re: madwifi-ng not compile in amd64

[Duncan]

Beso <givemesugarr@gmail.com> posted
d257c3560801300032m6f6c51adwc9f4bd75da066609@mail.gmail.com, excerpted
below, on  Wed, 30 Jan 2008 09:32:57 +0100:

> i'd also advise to use the the --buildpkg feature for some high
> compiling time packages like kdebase, gcc, openoffice or mplayer. since
> these packages are likely to be the same for quite some time and they
> might be pushed into recompilation by some other updates having them
> packaged on disk (they'd require disk space when packaged) would mean to
> skip all the compilation part and jump directly to the install one (of
> course if they would need to be recompiled portage would do it).

IMO --buildpkg (or better yet, FEATURES=buildpkg, if you've got 2-4 gigs 
of room for the packages) is one of the most under-advertised power-user 
tools Gentoo has.  The binaries are just so handy to have around, giving 
one all the advantages of a binary distribution if you need to remerge or 
need to fetch a "pristine" config file for some reason, without losing 
all the benefits and extra control allowed by from-source, since you 
compile everything initially anyway.

Of course, if something big dependency-wise changes, one often ends up 
rebuilding from-source anyway, so the linking gets updated to the new 
dependencies, so buildpkg is not a cure-all, but it certainly has its 
uses, and I'd be hard pressed to try to do without it!

> i still think that having the base system on the unstable arch isn't a
> very good idea. i've used the same stuff for quite some time, but i
> found out that it isn't a very good stuff. or at least 6 months ago
> wasn't a good idea.

I've never had serious issues in that regard.  I'd suggest it's because 
I /always/ use --update --deep --newuse on my emerge world updates, so 
stuff tends to be pretty up to date anyway, and due to regular use of 
revdep-rebuild and emerge --depclean to keep the system hygiene level 
high.

The one hassle there is, is that ~arch may have multiple version updates 
in the time there's only a single stable version update.  It's not 
uncommon for USE flags to change, thus triggering a --newuse rebuild, and/
or for various bugs and their fixes discovered during the ~ phase to be 
judged -rX worthy, and stable folks and those that don't routinely use
--deep get to skip a lot of that.

The cure, of course, is a faster machine! =8^)  Gentoo was reasonable 
with my old dual Opteron 242, but merges for things such as gcc, glibc, 
and DEFINITELY whole desktop updates like KDE, tended to be a chore.  The 
upgrade to dual dual-core Opteron 290s, combined with 8 gigs memory (tho 
4 gig would do) and putting PORTAGE_TMPDIR on tmpfs, made a HUGE 
difference.  Where KDE 3.5 updates, for example, would take ~12 hours 
back when I had a gig of memory and no tmpfs, and ~8 hours after 
upgrading the memory, I was running the KDE4-svn ebuilds from the 
overlay, and could compile all of KDE4 (well, most, I didn't have kdeedu 
or kdedevel merged) in ~4 hours with the dual dual-cores and 
PORTAGE_TMPDIR on tmpfs with 8 gigs memory, generally < 2 hours with 
everything ccached if I did it daily, and often closer to a single hour!

Really.  Those who've not yet had a chance to try quad cores (however you 
get them) and a good 4 gigs memory minimum, it really /does/ make running 
Gentoo pretty trivial.  A couple years from now when that's a lower end 
new system, it's likely Gentoo and other from-source distributions will 
see a fresh rise in popularity, because the time differences between 
grabbing a binary update and grabbing a from-source update begin to be 
pretty trivial, while all the advantages of from source, in particular, 
greater control of dependencies without bloat, remain.  At that level, 
the admin time, just figuring out what you are going to install, and 
dealing with the config updates, etc, is as much a factor as the compile 
time.  By the time we reach 8 cores and a full 8 to 16 gig RAM, that 
admin time will be the MAJOR factor, with the actual compile time almost 
entirely a non-factor, so the advantages of running binary pretty much 
disappear while the advantages of running from-source remain as big as 
they ever were!

-- 
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: madwifi-ng not compile in amd64

[Beso]

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

2008/1/30, Duncan <1i5t5.duncan@cox.net>:
>
> Beso <givemesugarr@gmail.com> posted
> d257c3560801300032m6f6c51adwc9f4bd75da066609@mail.gmail.com, excerpted
> below, on  Wed, 30 Jan 2008 09:32:57 +0100:
>
> > i'd also advise to use the the --buildpkg feature for some high
> > compiling time packages like kdebase, gcc, openoffice or mplayer. since
> > these packages are likely to be the same for quite some time and they
> > might be pushed into recompilation by some other updates having them
> > packaged on disk (they'd require disk space when packaged) would mean to
> > skip all the compilation part and jump directly to the install one (of
> > course if they would need to be recompiled portage would do it).
>
> IMO --buildpkg (or better yet, FEATURES=buildpkg, if you've got 2-4 gigs
> of room for the packages) is one of the most under-advertised power-user
> tools Gentoo has.  The binaries are just so handy to have around, giving
> one all the advantages of a binary distribution if you need to remerge or
> need to fetch a "pristine" config file for some reason, without losing
> all the benefits and extra control allowed by from-source, since you
> compile everything initially anyway.


i only use it on system packages like gcc that are mandatory for compiling
something (just in case something breaks) and on some big packages that
don't update frequently (kdebase, kdelibs). this requires less space than
buildpkg for all world packages. of course having this option enabled needs
frequent distcleans after updates since there's the risk of having there
different versions of the same package that aren't used.

Of course, if something big dependency-wise changes, one often ends up
> rebuilding from-source anyway, so the linking gets updated to the new
> dependencies, so buildpkg is not a cure-all, but it certainly has its
> uses, and I'd be hard pressed to try to do without it!


it sure helps when a rebuild is triggered after a lib soname update or
relinking issues. in that case there's no need to recompile but only to
relink and having binary builds helps a lot.

> i still think that having the base system on the unstable arch isn't a
> > very good idea. i've used the same stuff for quite some time, but i
> > found out that it isn't a very good stuff. or at least 6 months ago
> > wasn't a good idea.
>
> I've never had serious issues in that regard.  I'd suggest it's because
> I /always/ use --update --deep --newuse on my emerge world updates, so
> stuff tends to be pretty up to date anyway, and due to regular use of
> revdep-rebuild and emerge --depclean to keep the system hygiene level
> high.


the problem is always there: major or blocking bugs getting into the
unstable branch after the update  of the package (has happened with dhcpcd
for example) that makes gentoo devs mask the package the next day or so. so
for people like me that update daily this could be troublesome if it happens
on the system packages.

The cure, of course, is a faster machine! =8^)  Gentoo was reasonable
> with my old dual Opteron 242, but merges for things such as gcc, glibc,
> and DEFINITELY whole desktop updates like KDE, tended to be a chore.  The
> upgrade to dual dual-core Opteron 290s, combined with 8 gigs memory (tho
> 4 gig would do) and putting PORTAGE_TMPDIR on tmpfs, made a HUGE
> difference.  Where KDE 3.5 updates, for example, would take ~12 hours
> back when I had a gig of memory and no tmpfs, and ~8 hours after
> upgrading the memory, I was running the KDE4-svn ebuilds from the
> overlay, and could compile all of KDE4 (well, most, I didn't have kdeedu
> or kdedevel merged) in ~4 hours with the dual dual-cores and
> PORTAGE_TMPDIR on tmpfs with 8 gigs memory, generally < 2 hours with
> everything ccached if I did it daily, and often closer to a single hour!


this is a high end machine. opteron is better than a normal athlon x2 in
terms of compilation and having 8gb on a server mobo, that differs from
normal mobos, is not affordable for every user. my system is about the
average one (2ghz processor, 1gb ram, 80gb hdd) for notebooks and quite
average one for desktops. remember that nuveau devs still work on athlons or
pentium 3 hw, and that hw is not dead yet. your system nowadays is a
middle-high end one.

Really.  Those who've not yet had a chance to try quad cores (however you
> get them) and a good 4 gigs memory minimum, it really /does/ make running
> Gentoo pretty trivial.  A couple years from now when that's a lower end
> new system, it's likely Gentoo and other from-source distributions will
> see a fresh rise in popularity, because the time differences between
> grabbing a binary update and grabbing a from-source update begin to be
> pretty trivial, while all the advantages of from source, in particular,
> greater control of dependencies without bloat, remain.  At that level,
> the admin time, just figuring out what you are going to install, and
> dealing with the config updates, etc, is as much a factor as the compile
> time.  By the time we reach 8 cores and a full 8 to 16 gig RAM, that
> admin time will be the MAJOR factor, with the actual compile time almost
> entirely a non-factor, so the advantages of running binary pretty much
> disappear while the advantages of running from-source remain as big as
> they ever were!


well, this is true for  minor packages, but kdelibs or kdebase for example
are still quite big and if you're not a developer you won't go around
compiling it everyday or so.

--
> 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: 7358 bytes --]

[gentoo-amd64] Re: madwifi-ng not compile in amd64

[Duncan]

Beso <givemesugarr@gmail.com> posted
d257c3560801301106o7d8c3b15mf6e0a4a075bcfbde@mail.gmail.com, excerpted
below, on  Wed, 30 Jan 2008 19:06:47 +0000:

> 2008/1/30, Duncan <1i5t5.duncan@cox.net>:
>>
>> Beso <givemesugarr@gmail.com> posted
>> d257c3560801300032m6f6c51adwc9f4bd75da066609@mail.gmail.com, excerpted
>> below, on  Wed, 30 Jan 2008 09:32:57 +0100:
>>
>> IMO --buildpkg (or better yet, FEATURES=buildpkg, if you've got 2-4
>> gigs of room for the packages) is one of the most under-advertised
>> power-user tools Gentoo has.  The binaries are just so handy to have
>> around, giving one all the advantages of a binary distribution if you
>> need to remerge or need to fetch a "pristine" config file for some
>> reason, without losing all the benefits and extra control allowed by
>> from-source, since you compile everything initially anyway.
> 
> 
> i only use it on system packages like gcc that are mandatory for
> compiling something (just in case something breaks) and on some big
> packages that don't update frequently (kdebase, kdelibs). this requires
> less space than buildpkg for all world packages. of course having this
> option enabled needs frequent distcleans after updates since there's the
> risk of having there different versions of the same package that aren't
> used.

Disk space is cheap! =8^)  As I said, I do FEATURES=buildpkg so have 
packages for the entire system.  I keep them in a dedicated RAID-6 LVM 
volume, along with a backup volume of the same size.  Since my last disk 
upgrade when I increased the sizes of the volumes, I've not yet run out 
of space and only eclean-pkg once in awhile when I decide I've not done 
it recently, so maybe twice a year and it might be 9 months between 
runs.  My system runs ~1 gig for a full set of packages, but I'd say 
closer to 2 gigs is the minimum one should consider viable for such an 
endeavor, given that ideally you keep both the present version and the 
last known working version at least until you've verified that a new 
version of a package works.  AFAIK, I ran 2 gig package partitions 
before, but that didn't really leave me as much room as I'd have liked.  
I'm running 4 gig volumes now, as I said, two of them, the working copy 
and a backup I take every so often.  Right now, df says I'm using 1.9 
gigs out of 4 gigs on my working package volume, and that's with both KDE 
3.5.x and 4.0.x-SVNs merged (but no GNOME tho I do have GTK, so figure 
about the same if you just run KDE and GNOME normally, one copy of each).

The only problem with that system is that for live builds, like my kde-
svn builds, the new copy replaces the old one if I don't specifically 
save the old ones off, and if that new copy doesn't end up working, as is 
quite possible with live-svn...

I could script a solution that automatically saves off the old copy, 
keeping several versions of it much like logrotate does, but I haven't as 
I really haven't had the time I've wanted to get kde-4.x customized to my 
liking, so I've kept kde-3.5.x as my (very customized) main desktop for 
the time being, and it's therefore no big deal if the kde4-svn live 
ebuilds go tits-up on me for awhile.

In fact, I was saying how easy it is to keep kde-svn compiled now that I 
upgraded to dual dual-core Opterons... and it's true.  Once I got past 
the initial compile (that was back in November, so things were quite 
rough still and it took a bit of effort to get the USE flags and etc 
right so it would compile the first time), it has been much easier to 
keep up with routinely updating the compiled builds, than it has to 
actually run them, and go in and get things customized to my liking in 
the environment.  I've played around with it some, but I've actually been 
disappointed as I've simply not had the time I had expected to have to 
get it running to my liking, so mostly, it just sits, and gets updated, 
and seldom gets run as I continue to run kde-3.5.x for my daily work.  It 
has been quite frustrating, actually, because I've /not/ had that time -- 
putting in 10 hours a week more at work really takes the time away from 
other things!  But things are getting rather back to normal, now, so I'm 
hoping I get to it in the next couple weeks...


> it sure helps when a rebuild is triggered after a lib soname update or
> relinking issues. in that case there's no need to recompile but only to
> relink and having binary builds helps a lot.

??  I can see how ccache would help, and maybe keeping the sources around 
with the previous compile job in place so you can simply run make && make 
install and it'll use existing work where it can, but the binary packages 
are already dynamic stub-linked, so you'd still have to rebuild them.  I 
don't quite get what you are saying here, unless you're talking about 
ccache, or under the misimpression that the binary packages aren't 
rebuilt when they need to relink against a new *.so -- they are, from all 
I know.

> the problem is always there: major or blocking bugs getting into the
> unstable branch after the update  of the package (has happened with
> dhcpcd for example) that makes gentoo devs mask the package the next day
> or so. so for people like me that update daily this could be troublesome
> if it happens on the system packages.

Well, that's why I was wishing there was a convenient way to run ~arch, 
but only emerge packages that had been ~arch keyworded for a week or so, 
thus getting past the initial testing wave and any serious bugs that 
might have prompted a new -rX release or a remasking.

However, there again, the binpkg repository is nice, as one can simply 
roll back to whatever they had previously installed, if necessary.

> The cure, of course, is a faster machine! =8^)  Gentoo was reasonable
>> with my old dual Opteron 242, but merges for things such as gcc, glibc,
>> and DEFINITELY whole desktop updates like KDE, tended to be a chore. 
>> The upgrade to dual dual-core Opteron 290s, combined with 8 gigs memory
>> (tho 4 gig would do) and putting PORTAGE_TMPDIR on tmpfs, made a HUGE
>> difference.

> this is a high end machine. opteron is better than a normal athlon x2 in
> terms of compilation and having 8gb on a server mobo, that differs from
> normal mobos, is not affordable for every user. my system is about the
> average one (2ghz processor, 1gb ram, 80gb hdd) for notebooks and quite
> average one for desktops. remember that nuveau devs still work on
> athlons or pentium 3 hw, and that hw is not dead yet. your system
> nowadays is a middle-high end one.

Well, dual-cores are standard now for new gear anyway, and 1-2 gig 
memory, but I get your point.  My machine is certainly a low to middling 
high-end machine today tho really only for the memory and dual dual-
cores.  However, it's not /that/ great (except the 8 gig memory), as it's 
the older socket-940 Opterons, none of the new virtualization stuff, etc, 
and I have the top of the end of the line 2.8 GHz, while as I said, most 
desktops come with dual-core now, and often run 3.2 GHz or higher.

Still, the next paragraph (which I'm snipping) /did/ talk about it being 
common "a couple years from now", and I think that's a reasonable 
prediction, except perhaps 4 gig memory instead of the 8 gig I have, but 
4 gig is still within the comfort range for what I'm talking -- the 8 gig 
is really a bit over the top currently, and it CERTAINLY was before I 
upgraded to the dual-cores so was running only dual CPUs, roughly the 
equivalent of a single dual-core today.

As I said, those who've not yet had a change to try quad cores (whether 
single-core quad socket, dual-core dual socket as I have, or the new quad-
core)... it makes a MUCH bigger difference than I had expected it to.  
Once they and 4 gigs memory become common, I really DO think from source 
could take-off, because it really /does/ become trivial to do the 
compiling -- as I found with kde-4 as I discussed above, the actual 
compiling starts to become much less of an issue than the standard 
sysadmin overhead, and people have to deal with that regardless of what 
distribution they choose, binary or from-source.

> well, this is true for  minor packages, but kdelibs or kdebase for
> example are still quite big and if you're not a developer you won't go
> around compiling it everyday or so.

See, that was exactly my reaction back with the dual single-cores (so 
equivalent to today's single dual-cores).  Minor packages were trivial, 
but the big stuff, gcc, glibc, kdelibs, kdebase, etc, were "practically 
managable", but still decidedly NOT trivial.

I feel like I'm repeating myself (and I am =8^), but I really /was/ 
shocked at how much of a difference the 4 cores (and a decent amount of 
memory, but I had that first, so the bottleneck here was eliminated with 
the 2 to 4 cores upgrade -- tho I did increase CPU speed substantially as 
well, 1.6 to 2.8 GHz) made!  It's really almost embarrassing how 
trivially easy and fast it is to compile even the "big" packages.  When 
all of KDE can be upgraded in 4 hours from scratch, an hour if upgraded 
daily from svn with ccache active, even formerly big individual 
packages... just aren't much of a sweat any more.

It's kinda like how compiling the kernel used to be a big thing on 386s 
and even Pentiums, but on even half-decent modern hardware, the lowest 
end x86_64 around (well, with perhaps the exception of Via's Isaiah or 
whatever it is, I honestly don't know how it does), and even with a 
couple generations old Athlon 1.X GHz (pre-Athlon XP), it might be five 
minutes or so, or even 10, but it's little more than a coffee or two at 
most, certainly not the half-day affair it used to be!  Well, with quad-
cores (again, however you get them, so dual-dual-cores or quad-single-
cores included) and say 4 gig of memory to work with, pretty much any 
single package, even the ones like gcc/glibc/kdelibs that used to be a 
big deal, is that trivial.  (I just checked.  Merging kdelibs-9999.4, the 
kde4 svn version, took all of 5 minutes, 37 seconds, based on the random 
entry in emerge.log I checked.  Of course, that's with ccache enabled and 
only a bit of update since the previous day, but it still has a bit of 
compiling and all that linking to do.  That's about right since as I 
said, all of KDE often takes only an hour, if done daily.)

As for the kernel, it has really ceased even to be a decent measure of 
performance, it's done so fast.  Maybe a minute.  I've honestly not timed 
it since I got the new CPUs in.  I can just see a future boot solution 
containing an initial book kernel in BIOS, using it to load /boot with 
the kernel sources, and compiling them dynamically from source based on 
detected hardware at every boot, then using kexec to switch to the new, 
freshly compiled kernel! =8^)  If the previous work were kept, so only 
newly detected hardware and any admin's config changes had to be built, 
it'd literally only add a few seconds to the boot process, maybe 10 
seconds if no config changes, 30 seconds to a minute if you move the disk 
to a new machine and it has to rebuild almost the entire kernel.

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

[gentoo-amd64] new laptop

[ionut cucu]

Hi List,
I've just bought a new laptop Acer 5715Z and I've have the following
issue the processor overheats until the laptop closes(100 degrees
Celsius). This happened when I had two parallel emerges. So I went to
the shop and changed it with another one, same model. This one can hold
up to 3 parallel emerges but it overheats when I'm watching a movie,
again it reaches the 100 degrees limit. I'm I doing something wrong
here? I'm I missing something (this is the first laptop I have) ?. Or
just by coincidence this one is broken too. I've looked on the Internet
but I hadn't found any similar issues. Thanks!
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] new laptop

[Beso]

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

2008/2/3, ionut cucu <cuciferus@gmail.com>:
>
> Hi List,
> I've just bought a new laptop Acer 5715Z and I've have the following
> issue the processor overheats until the laptop closes(100 degrees
> Celsius). This happened when I had two parallel emerges. So I went to
> the shop and changed it with another one, same model. This one can hold
> up to 3 parallel emerges but it overheats when I'm watching a movie,
> again it reaches the 100 degrees limit. I'm I doing something wrong
> here? I'm I missing something (this is the first laptop I have) ?. Or
> just by coincidence this one is broken too. I've looked on the Internet
> but I hadn't found any similar issues. Thanks!
> --
> gentoo-amd64@lists.gentoo.org mailing list
>
> first: maybe the thermal isn't set right.
what does cat /proc/acpi/thermal_zone/THRM/trip_points says?! mine is
something like this:

critical (S5):           105 C
passive:                 76 C: tc1=3 tc2=1 tsp=150 devices=CPU0
active[0]:               67 C: devices= FN1
active[1]:               57 C: devices= FN2

you might have different values but at least you should have one active and
one passive.
second: don't do parallel emerge if you're not sure that the packages from
one emerge don't collide with the ones from the other. for example,
knetworkmanager needs networkmanager which needs dhcdb which needs dhclient.
if you emerge something that would emerge dhclient then you'd emerge 2 times
dhclient or you might risk one of the 2 emerges to fail because a dep hasn't
yet been installed. you could push up the number of processes to be build
together by increasing the makeopts for example to -j6 or more. increase the
number and see your processors loads. the best number is the one that puts
your processors to about 80% of cpu so that you'd still have 20% of cpu
power to do other things. also add the niceness option so that you don't see
slowdowns when you compile and use some other program.
third: have you installed acpi and acer-acpi?! i presume that you've done it
and you're starting both acpi and acer-acpi at boot.
anyway, the important thing is are the trip_points. if you don't have them
then you might need to make a script to get the thermal temperature and to
slowdown manually the processor when it pushes too much up the temperature.

-- 
dott. ing. beso

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

Re: [gentoo-amd64] new laptop

[ionut cucu]

On Sun, 3 Feb 2008 13:55:56 +0000
Beso <givemesugarr@gmail.com> wrote:

> 2008/2/3, ionut cucu <cuciferus@gmail.com>:
> >
> > Hi List,
> > I've just bought a new laptop Acer 5715Z and I've have the following
> > issue the processor overheats until the laptop closes(100 degrees
> > Celsius). This happened when I had two parallel emerges. So I went
> > to the shop and changed it with another one, same model. This one
> > can hold up to 3 parallel emerges but it overheats when I'm
> > watching a movie, again it reaches the 100 degrees limit. I'm I
> > doing something wrong here? I'm I missing something (this is the
> > first laptop I have) ?. Or just by coincidence this one is broken
> > too. I've looked on the Internet but I hadn't found any similar
> > issues. Thanks! --
> > gentoo-amd64@lists.gentoo.org mailing list
> >
> > first: maybe the thermal isn't set right.
> what does cat /proc/acpi/thermal_zone/THRM/trip_points says?! mine is
> something like this:
> 
> critical (S5):           105 C
> passive:                 76 C: tc1=3 tc2=1 tsp=150 devices=CPU0
> active[0]:               67 C: devices= FN1
> active[1]:               57 C: devices= FN2
> 
> you might have different values but at least you should have one
> active and one passive.
I have only the critical level set
> second: don't do parallel emerge if you're not sure that the packages
> from one emerge don't collide with the ones from the other. for
> example, knetworkmanager needs networkmanager which needs dhcdb which
> needs dhclient. if you emerge something that would emerge dhclient
> then you'd emerge 2 times dhclient or you might risk one of the 2
> emerges to fail because a dep hasn't yet been installed. you could
> push up the number of processes to be build together by increasing
> the makeopts for example to -j6 or more. increase the number and see
> your processors loads. the best number is the one that puts your
> processors to about 80% of cpu so that you'd still have 20% of cpu
> power to do other things. also add the niceness option so that you
> don't see slowdowns when you compile and use some other program.
Well the parallel emerges are done just to load the cpu, after the main
installation process, but thanks for the j6 idea
> third: have you installed acpi and acer-acpi?! i presume that you've
> done it and you're starting both acpi and acer-acpi at boot. anyway,
> the important thing is are the trip_points. if you don't have them
> then you might need to make a script to get the thermal temperature
> and to slowdown manually the processor when it pushes too much up the
> temperature.
 acer_acpi refuses to compile with some file missing error...will
search the bugs later, but is it really necessary? if so could you
please elaborate a little because I was under the impression that the
fans were hardware controlled by default
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] new laptop

[Beso]

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

2008/2/3, ionut cucu <cuciferus@gmail.com>:
>
> On Sun, 3 Feb 2008 13:55:56 +0000
> Beso <givemesugarr@gmail.com> wrote:
>
> > 2008/2/3, ionut cucu <cuciferus@gmail.com>:
> > >
> > > Hi List,
> > > I've just bought a new laptop Acer 5715Z and I've have the following
> > > issue the processor overheats until the laptop closes(100 degrees
> > > Celsius). This happened when I had two parallel emerges. So I went
> > > to the shop and changed it with another one, same model. This one
> > > can hold up to 3 parallel emerges but it overheats when I'm
> > > watching a movie, again it reaches the 100 degrees limit. I'm I
> > > doing something wrong here? I'm I missing something (this is the
> > > first laptop I have) ?. Or just by coincidence this one is broken
> > > too. I've looked on the Internet but I hadn't found any similar
> > > issues. Thanks! --
> > > gentoo-amd64@lists.gentoo.org mailing list
> > >
> > > first: maybe the thermal isn't set right.
> > what does cat /proc/acpi/thermal_zone/THRM/trip_points says?! mine is
> > something like this:
> >
> > critical (S5):           105 C
> > passive:                 76 C: tc1=3 tc2=1 tsp=150 devices=CPU0
> > active[0]:               67 C: devices= FN1
> > active[1]:               57 C: devices= FN2
> >
> > you might have different values but at least you should have one
> > active and one passive.
> I have only the critical level set
> > second: don't do parallel emerge if you're not sure that the packages
> > from one emerge don't collide with the ones from the other. for
> > example, knetworkmanager needs networkmanager which needs dhcdb which
> > needs dhclient. if you emerge something that would emerge dhclient
> > then you'd emerge 2 times dhclient or you might risk one of the 2
> > emerges to fail because a dep hasn't yet been installed. you could
> > push up the number of processes to be build together by increasing
> > the makeopts for example to -j6 or more. increase the number and see
> > your processors loads. the best number is the one that puts your
> > processors to about 80% of cpu so that you'd still have 20% of cpu
> > power to do other things. also add the niceness option so that you
> > don't see slowdowns when you compile and use some other program.
> Well the parallel emerges are done just to load the cpu, after the main
> installation process, but thanks for the j6 idea
> > third: have you installed acpi and acer-acpi?! i presume that you've
> > done it and you're starting both acpi and acer-acpi at boot. anyway,
> > the important thing is are the trip_points. if you don't have them
> > then you might need to make a script to get the thermal temperature
> > and to slowdown manually the processor when it pushes too much up the
> > temperature.
> acer_acpi refuses to compile with some file missing error...will
> search the bugs later, but is it really necessary? if so could you
> please elaborate a little because I was under the impression that the
> fans were hardware controlled by default
> --
> gentoo-amd64@lists.gentoo.org mailing list


acer-acpi is usually necessary for acer notebooks to work well. it is
mandatory for hotkeys and other stuff and is necessary to correct some
acer's modifications in the acpi. so for what i know acer-acpi is manadatory
for acer notebooks as it is asus-acpi on asus notebooks. try to see if
everything fixes after you install it (try unmasking newer versions if you
cannot install stable ones).
the fans are ususally board controlled as it is the passive mode that
reduces the cpu speed, but they can be forced via scripts.




-- 
dott. ing. beso

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

Re: [gentoo-amd64] new laptop

[ionut cucu]

On Sun, 3 Feb 2008 15:49:47 +0000
Beso <givemesugarr@gmail.com> wrote:

> 2008/2/3, ionut cucu <cuciferus@gmail.com>:
> >
> > On Sun, 3 Feb 2008 13:55:56 +0000
> > Beso <givemesugarr@gmail.com> wrote:
> >
> > > 2008/2/3, ionut cucu <cuciferus@gmail.com>:
> > > >
> > > > Hi List,
> > > > I've just bought a new laptop Acer 5715Z and I've have the
> > > > following issue the processor overheats until the laptop
> > > > closes(100 degrees Celsius). This happened when I had two
> > > > parallel emerges. So I went to the shop and changed it with
> > > > another one, same model. This one can hold up to 3 parallel
> > > > emerges but it overheats when I'm watching a movie, again it
> > > > reaches the 100 degrees limit. I'm I doing something wrong
> > > > here? I'm I missing something (this is the first laptop I
> > > > have) ?. Or just by coincidence this one is broken too. I've
> > > > looked on the Internet but I hadn't found any similar issues.
> > > > Thanks! -- gentoo-amd64@lists.gentoo.org mailing list
> > > >
> > > > first: maybe the thermal isn't set right.
> > > what does cat /proc/acpi/thermal_zone/THRM/trip_points says?!
> > > mine is something like this:
> > >
> > > critical (S5):           105 C
> > > passive:                 76 C: tc1=3 tc2=1 tsp=150 devices=CPU0
> > > active[0]:               67 C: devices= FN1
> > > active[1]:               57 C: devices= FN2
> > >
> > > you might have different values but at least you should have one
> > > active and one passive.
> > I have only the critical level set
> > > second: don't do parallel emerge if you're not sure that the
> > > packages from one emerge don't collide with the ones from the
> > > other. for example, knetworkmanager needs networkmanager which
> > > needs dhcdb which needs dhclient. if you emerge something that
> > > would emerge dhclient then you'd emerge 2 times dhclient or you
> > > might risk one of the 2 emerges to fail because a dep hasn't yet
> > > been installed. you could push up the number of processes to be
> > > build together by increasing the makeopts for example to -j6 or
> > > more. increase the number and see your processors loads. the best
> > > number is the one that puts your processors to about 80% of cpu
> > > so that you'd still have 20% of cpu power to do other things.
> > > also add the niceness option so that you don't see slowdowns when
> > > you compile and use some other program.
> > Well the parallel emerges are done just to load the cpu, after the
> > main installation process, but thanks for the j6 idea
> > > third: have you installed acpi and acer-acpi?! i presume that
> > > you've done it and you're starting both acpi and acer-acpi at
> > > boot. anyway, the important thing is are the trip_points. if you
> > > don't have them then you might need to make a script to get the
> > > thermal temperature and to slowdown manually the processor when
> > > it pushes too much up the temperature.
> > acer_acpi refuses to compile with some file missing error...will
> > search the bugs later, but is it really necessary? if so could you
> > please elaborate a little because I was under the impression that
> > the fans were hardware controlled by default
> > --
> > gentoo-amd64@lists.gentoo.org mailing list
> 
> 
> acer-acpi is usually necessary for acer notebooks to work well. it is
> mandatory for hotkeys and other stuff and is necessary to correct some
> acer's modifications in the acpi. so for what i know acer-acpi is
> manadatory for acer notebooks as it is asus-acpi on asus notebooks.
> try to see if everything fixes after you install it (try unmasking
> newer versions if you cannot install stable ones).
> the fans are ususally board controlled as it is the passive mode that
> reduces the cpu speed, but they can be forced via scripts.
> 
> 
> 
> 
Unfortunately asus_acpi doesn't compile
(http://bugs.gentoo.org/show_bug.cgi?id=208577). So I'm just asking for
the cooling process is it mandatory. The issue here is not some hotkeys
but the temperature...I wish to know weather this one is broken to or
not. From what I've read on the http://code.google.com/p/aceracpi/ this
program/driver is mostly for the lcd, battery lifetime  etc. But being
the second laptop with the same issue makes me wonder...I wish i could
compile this....
-- 
gentoo-amd64@lists.gentoo.org mailing list

[gentoo-amd64] Re: new laptop

[Duncan]

ionut cucu <cuciferus@gmail.com> posted 20080204093928.052665b5@cuci,
excerpted below, on  Mon, 04 Feb 2008 09:39:28 +0200:

> Unfortunately asus_acpi doesn't compile
> (http://bugs.gentoo.org/show_bug.cgi?id=208577).

I don't know anything about the laptop driver, but from my experience, 
missing stuff is often due to parallel make.  Try setting MAKEOPTS=-j1 
and see if it makes a difference.  It may be worth adding the result of 
trying that to the bug, as well, regardless of whether it works or not. 

(FWIW, I'm running dual-dual-core Opterons, 8 gigs RAM, and have 
MAKEOPTS="-j20 -l12", and once in awhile when I'm doing nothing else, 
I'll run simply -j, unlimited jobs, just for kicks, as it's fun watching 
the load average go to several-hundred! =8^)  The more jobs, of course 
the more likely one is to run into parallel-make problems, so I probably 
run into them more frequently then most, and am therefore learning the 
hard way what sorts of errors they produce. =8^)

One other possibility, not so likely but possible since it's kernel 
sources you are dealing with and they of course come from another 
package, double-check permissions, particularly if you use 
FEATURES=userpriv.  Make sure the portage user has write permissions in 
the kernel dir and subdirs.

-- 
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: new laptop

[ionut cucu]

On Mon, 4 Feb 2008 08:11:12 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> ionut cucu <cuciferus@gmail.com> posted 20080204093928.052665b5@cuci,
> excerpted below, on  Mon, 04 Feb 2008 09:39:28 +0200:
> 
> > Unfortunately asus_acpi doesn't compile
> > (http://bugs.gentoo.org/show_bug.cgi?id=208577).
> 
> I don't know anything about the laptop driver, but from my
> experience, missing stuff is often due to parallel make.  Try setting
> MAKEOPTS=-j1 and see if it makes a difference.  It may be worth
> adding the result of trying that to the bug, as well, regardless of
> whether it works or not. 
> 
> (FWIW, I'm running dual-dual-core Opterons, 8 gigs RAM, and have 
> MAKEOPTS="-j20 -l12", and once in awhile when I'm doing nothing else, 
> I'll run simply -j, unlimited jobs, just for kicks, as it's fun
> watching the load average go to several-hundred! =8^)  The more jobs,
> of course the more likely one is to run into parallel-make problems,
> so I probably run into them more frequently then most, and am
> therefore learning the hard way what sorts of errors they produce.
> =8^)
> 
> One other possibility, not so likely but possible since it's kernel 
> sources you are dealing with and they of course come from another 
> package, double-check permissions, particularly if you use 
> FEATURES=userpriv.  Make sure the portage user has write permissions
> in the kernel dir and subdirs.
> 
Wow! You're a genius man! With -j1 it worked
-- 
gentoo-amd64@lists.gentoo.org mailing list

[gentoo-amd64] Re: new laptop

[Duncan]

ionut cucu <cuciferus@gmail.com> posted 20080204132343.1b6c190c@cuci,
excerpted below, on  Mon, 04 Feb 2008 13:23:43 +0200:

> Wow! You're a genius man! With -j1 it worked

Perhaps you've heard the popular FLOSS community observation/saying: 
"With enough eyes, all bugs are shallow."

I'm glad to help prove that once again on this one!  =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] new laptop

[Beso]

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

2008/2/4, ionut cucu <cuciferus@gmail.com>:
>
> On Sun, 3 Feb 2008 15:49:47 +0000
> Beso <givemesugarr@gmail.com> wrote:
>
> > 2008/2/3, ionut cucu <cuciferus@gmail.com>:
> > >
> > > On Sun, 3 Feb 2008 13:55:56 +0000
> > > Beso <givemesugarr@gmail.com> wrote:
> > >
> > > > 2008/2/3, ionut cucu <cuciferus@gmail.com>:
> > > > >
> > > > > Hi List,
> > > > > I've just bought a new laptop Acer 5715Z and I've have the
> > > > > following issue the processor overheats until the laptop
> > > > > closes(100 degrees Celsius). This happened when I had two
> > > > > parallel emerges. So I went to the shop and changed it with
> > > > > another one, same model. This one can hold up to 3 parallel
> > > > > emerges but it overheats when I'm watching a movie, again it
> > > > > reaches the 100 degrees limit. I'm I doing something wrong
> > > > > here? I'm I missing something (this is the first laptop I
> > > > > have) ?. Or just by coincidence this one is broken too. I've
> > > > > looked on the Internet but I hadn't found any similar issues.
> > > > > Thanks! -- gentoo-amd64@lists.gentoo.org mailing list
> > > > >
> > > > > first: maybe the thermal isn't set right.
> > > > what does cat /proc/acpi/thermal_zone/THRM/trip_points says?!
> > > > mine is something like this:
> > > >
> > > > critical (S5):           105 C
> > > > passive:                 76 C: tc1=3 tc2=1 tsp=150 devices=CPU0
> > > > active[0]:               67 C: devices= FN1
> > > > active[1]:               57 C: devices= FN2
> > > >
> > > > you might have different values but at least you should have one
> > > > active and one passive.
> > > I have only the critical level set
> > > > second: don't do parallel emerge if you're not sure that the
> > > > packages from one emerge don't collide with the ones from the
> > > > other. for example, knetworkmanager needs networkmanager which
> > > > needs dhcdb which needs dhclient. if you emerge something that
> > > > would emerge dhclient then you'd emerge 2 times dhclient or you
> > > > might risk one of the 2 emerges to fail because a dep hasn't yet
> > > > been installed. you could push up the number of processes to be
> > > > build together by increasing the makeopts for example to -j6 or
> > > > more. increase the number and see your processors loads. the best
> > > > number is the one that puts your processors to about 80% of cpu
> > > > so that you'd still have 20% of cpu power to do other things.
> > > > also add the niceness option so that you don't see slowdowns when
> > > > you compile and use some other program.
> > > Well the parallel emerges are done just to load the cpu, after the
> > > main installation process, but thanks for the j6 idea
> > > > third: have you installed acpi and acer-acpi?! i presume that
> > > > you've done it and you're starting both acpi and acer-acpi at
> > > > boot. anyway, the important thing is are the trip_points. if you
> > > > don't have them then you might need to make a script to get the
> > > > thermal temperature and to slowdown manually the processor when
> > > > it pushes too much up the temperature.
> > > acer_acpi refuses to compile with some file missing error...will
> > > search the bugs later, but is it really necessary? if so could you
> > > please elaborate a little because I was under the impression that
> > > the fans were hardware controlled by default
> > > --
> > > gentoo-amd64@lists.gentoo.org mailing list
> >
> >
> > acer-acpi is usually necessary for acer notebooks to work well. it is
> > mandatory for hotkeys and other stuff and is necessary to correct some
> > acer's modifications in the acpi. so for what i know acer-acpi is
> > manadatory for acer notebooks as it is asus-acpi on asus notebooks.
> > try to see if everything fixes after you install it (try unmasking
> > newer versions if you cannot install stable ones).
> > the fans are ususally board controlled as it is the passive mode that
> > reduces the cpu speed, but they can be forced via scripts.
> >
> >
> >
> >
> Unfortunately asus_acpi doesn't compile
> (http://bugs.gentoo.org/show_bug.cgi?id=208577). So I'm just asking for
> the cooling process is it mandatory. The issue here is not some hotkeys
> but the temperature...I wish to know weather this one is broken to or
> not. From what I've read on the http://code.google.com/p/aceracpi/ this
> program/driver is mostly for the lcd, battery lifetime  etc. But being
> the second laptop with the same issue makes me wonder...I wish i could
> compile this....
> --
> gentoo-amd64@lists.gentoo.org mailing list
>
> well, we have a little problem about trip points, since the only indicated
there is the critical one and you don't have passive ones.
well, we'll need to do a little work on the manual scripts to have the fan
work and to be sure that the thermal won't reach critical trip point where
it would shutdown.
i'll take a look and post some scripts that should help. you'll have to be
sure that you have installed lm_sensors and cpufrequtils and that you have
compiled the cpufreq modules into the kernel or as modules and you'll have
them loaded at boot. we'll have to make the processor slow down when the
thermal goes too high. also i'd like to know what are the capabilities of
your processors:
a cat on the /proc/cpuinfo and then on cat /proc/acpi/processor/CPU(x)/info
where (x) is the number of the core to know what sort of management it can
support. you should have cpu0 and cpu1 if you have a dualcore.


-- 
dott. ing. beso

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

Re: [gentoo-amd64] new laptop

[Beso]

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

2008/2/4, Beso <givemesugarr@gmail.com>:
>
>
>
> 2008/2/4, ionut cucu <cuciferus@gmail.com>:
> >
> > On Sun, 3 Feb 2008 15:49:47 +0000
> > Beso <givemesugarr@gmail.com> wrote:
> >
> > > 2008/2/3, ionut cucu <cuciferus@gmail.com>:
> > > >
> > > > On Sun, 3 Feb 2008 13:55:56 +0000
> > > > Beso <givemesugarr@gmail.com> wrote:
> > > >
> > > > > 2008/2/3, ionut cucu <cuciferus@gmail.com>:
> > > > > >
> > > > > > Hi List,
> > > > > > I've just bought a new laptop Acer 5715Z and I've have the
> > > > > > following issue the processor overheats until the laptop
> > > > > > closes(100 degrees Celsius). This happened when I had two
> > > > > > parallel emerges. So I went to the shop and changed it with
> > > > > > another one, same model. This one can hold up to 3 parallel
> > > > > > emerges but it overheats when I'm watching a movie, again it
> > > > > > reaches the 100 degrees limit. I'm I doing something wrong
> > > > > > here? I'm I missing something (this is the first laptop I
> > > > > > have) ?. Or just by coincidence this one is broken too. I've
> > > > > > looked on the Internet but I hadn't found any similar issues.
> > > > > > Thanks! -- gentoo-amd64@lists.gentoo.org mailing list
> > > > > >
> > > > > > first: maybe the thermal isn't set right.
> > > > > what does cat /proc/acpi/thermal_zone/THRM/trip_points says?!
> > > > > mine is something like this:
> > > > >
> > > > > critical (S5):           105 C
> > > > > passive:                 76 C: tc1=3 tc2=1 tsp=150 devices=CPU0
> > > > > active[0]:               67 C: devices= FN1
> > > > > active[1]:               57 C: devices= FN2
> > > > >
> > > > > you might have different values but at least you should have one
> > > > > active and one passive.
> > > > I have only the critical level set
> > > > > second: don't do parallel emerge if you're not sure that the
> > > > > packages from one emerge don't collide with the ones from the
> > > > > other. for example, knetworkmanager needs networkmanager which
> > > > > needs dhcdb which needs dhclient. if you emerge something that
> > > > > would emerge dhclient then you'd emerge 2 times dhclient or you
> > > > > might risk one of the 2 emerges to fail because a dep hasn't yet
> > > > > been installed. you could push up the number of processes to be
> > > > > build together by increasing the makeopts for example to -j6 or
> > > > > more. increase the number and see your processors loads. the best
> > > > > number is the one that puts your processors to about 80% of cpu
> > > > > so that you'd still have 20% of cpu power to do other things.
> > > > > also add the niceness option so that you don't see slowdowns when
> > > > > you compile and use some other program.
> > > > Well the parallel emerges are done just to load the cpu, after the
> > > > main installation process, but thanks for the j6 idea
> > > > > third: have you installed acpi and acer-acpi?! i presume that
> > > > > you've done it and you're starting both acpi and acer-acpi at
> > > > > boot. anyway, the important thing is are the trip_points. if you
> > > > > don't have them then you might need to make a script to get the
> > > > > thermal temperature and to slowdown manually the processor when
> > > > > it pushes too much up the temperature.
> > > > acer_acpi refuses to compile with some file missing error...will
> > > > search the bugs later, but is it really necessary? if so could you
> > > > please elaborate a little because I was under the impression that
> > > > the fans were hardware controlled by default
> > > > --
> > > > gentoo-amd64@lists.gentoo.org mailing list
> > >
> > >
> > > acer-acpi is usually necessary for acer notebooks to work well. it is
> > > mandatory for hotkeys and other stuff and is necessary to correct some
> > > acer's modifications in the acpi. so for what i know acer-acpi is
> > > manadatory for acer notebooks as it is asus-acpi on asus notebooks.
> > > try to see if everything fixes after you install it (try unmasking
> > > newer versions if you cannot install stable ones).
> > > the fans are ususally board controlled as it is the passive mode that
> > > reduces the cpu speed, but they can be forced via scripts.
> > >
> > >
> > >
> > >
> > Unfortunately asus_acpi doesn't compile
> > (http://bugs.gentoo.org/show_bug.cgi?id=208577). So I'm just asking for
> > the cooling process is it mandatory. The issue here is not some hotkeys
> > but the temperature...I wish to know weather this one is broken to or
> > not. From what I've read on the http://code.google.com/p/aceracpi/ this
> > program/driver is mostly for the lcd, battery lifetime  etc. But being
> > the second laptop with the same issue makes me wonder...I wish i could
> > compile this....
> > --
> > gentoo-amd64@lists.gentoo.org mailing list
> >
> > well, we have a little problem about trip points, since the only
> indicated there is the critical one and you don't have passive ones.
> well, we'll need to do a little work on the manual scripts to have the fan
> work and to be sure that the thermal won't reach critical trip point where
> it would shutdown.
> i'll take a look and post some scripts that should help. you'll have to be
> sure that you have installed lm_sensors and cpufrequtils and that you have
> compiled the cpufreq modules into the kernel or as modules and you'll have
> them loaded at boot. we'll have to make the processor slow down when the
> thermal goes too high. also i'd like to know what are the capabilities of
> your processors:
> a cat on the /proc/cpuinfo and then on cat
> /proc/acpi/processor/CPU(x)/info where (x) is the number of the core to know
> what sort of management it can support. you should have cpu0 and cpu1 if you
> have a dualcore.
>
>
> --
> dott. ing. beso

i forgot to mention the other files in the cpu and thermal directory. they
would help setting up the scripts. also you'll need /dev/cpu/microcode,
/dev/cpu/cpuid, /dev/cpu/msr, Intel MCE features, Intel core2/ newer xeon
compiled directly into the kernel and not as modules. they're in the
processor types and features of the kernel. also you'll need the following
from the power management options:
- acpi support
---> everything compiled into the kernel and not as modules with the
exception of dock, asus extras, toshiba extras, acpi container, smart
battery system which are not mandatory.
- cpu frequency scaling
  │ │                                     [*] CPU Frequency
scaling
│ │
  │ │                                     [*]   Enable CPUfreq
debugging
│ │
  │ │                                     <*>   CPU frequency translation
statistics
│ │
  │ │                                     [*]     CPU frequency translation
statistics details                                                        │
│
  │ │                                           Default CPUFreq governor
(userspace)  --->
│ │
  │ │                                     <M>   'performance'
governor
│ │
  │ │                                     <M>   'powersave'
governor
│ │
  │ │                                     ---   'userspace' governor for
userspace frequency scaling
│ │
  │ │                                     <M>   'ondemand' cpufreq policy
governor
│ │
  │ │                                     <M>   'conservative' cpufreq
governor
│ │
  │ │                                     ---   CPUFreq processor
drivers
│ │
  │ │                                     < >   AMD Opteron/Athlon64
PowerNow!
│ │
  │ │                                     <*>   Intel Enhanced SpeedStep
(deprecated)
│ │
  │ │                                     <*>   ACPI Processor P-States
driver
│ │
  │ │                                     ---   shared
options
│ │
  │ │                                     [*]
/proc/acpi/processor/../performance interface (deprecated)

after controlling this and recompiling if necessary reboot (if you've
recompiled) and do another cat on the thermal trip points to see if it shows
also other states. if it doesn't we will really have to impose the
throttling manually when the temperature goes too high. we'll use the
cpufreq governor to impose the speed when needed and then we'll impose
throttling (processor suspension) when the thermal temp goes too high with
it. if your pc supports limits and other speq steps we could have it lower
the current state to a lower one to cool off a bit. but for this there's the
need to know what your processor can do.
-- 
dott. ing. beso

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

Re: [gentoo-amd64] new laptop

[ionut cucu]

On Mon, 4 Feb 2008 09:26:57 +0000
Beso <givemesugarr@gmail.com> wrote:

> 2008/2/4, Beso <givemesugarr@gmail.com>:
> >
> >
> >
> > 2008/2/4, ionut cucu <cuciferus@gmail.com>:
> > >
> > > On Sun, 3 Feb 2008 15:49:47 +0000
> > > Beso <givemesugarr@gmail.com> wrote:
> > >
> > > > 2008/2/3, ionut cucu <cuciferus@gmail.com>:
> > > > >
> > > > > On Sun, 3 Feb 2008 13:55:56 +0000
> > > > > Beso <givemesugarr@gmail.com> wrote:
> > > > >
> > > > > > 2008/2/3, ionut cucu <cuciferus@gmail.com>:
> > > > > > >
> > > > > > > Hi List,
> > > > > > > I've just bought a new laptop Acer 5715Z and I've have the
> > > > > > > following issue the processor overheats until the laptop
> > > > > > > closes(100 degrees Celsius). This happened when I had two
> > > > > > > parallel emerges. So I went to the shop and changed it
> > > > > > > with another one, same model. This one can hold up to 3
> > > > > > > parallel emerges but it overheats when I'm watching a
> > > > > > > movie, again it reaches the 100 degrees limit. I'm I
> > > > > > > doing something wrong here? I'm I missing something (this
> > > > > > > is the first laptop I have) ?. Or just by coincidence
> > > > > > > this one is broken too. I've looked on the Internet but I
> > > > > > > hadn't found any similar issues. Thanks! --
> > > > > > > gentoo-amd64@lists.gentoo.org mailing list
> > > > > > >
> > > > > > > first: maybe the thermal isn't set right.
> > > > > > what does cat /proc/acpi/thermal_zone/THRM/trip_points
> > > > > > says?! mine is something like this:
> > > > > >
> > > > > > critical (S5):           105 C
> > > > > > passive:                 76 C: tc1=3 tc2=1 tsp=150
> > > > > > devices=CPU0 active[0]:               67 C: devices= FN1
> > > > > > active[1]:               57 C: devices= FN2
> > > > > >
> > > > > > you might have different values but at least you should
> > > > > > have one active and one passive.
> > > > > I have only the critical level set
> > > > > > second: don't do parallel emerge if you're not sure that the
> > > > > > packages from one emerge don't collide with the ones from
> > > > > > the other. for example, knetworkmanager needs
> > > > > > networkmanager which needs dhcdb which needs dhclient. if
> > > > > > you emerge something that would emerge dhclient then you'd
> > > > > > emerge 2 times dhclient or you might risk one of the 2
> > > > > > emerges to fail because a dep hasn't yet been installed.
> > > > > > you could push up the number of processes to be build
> > > > > > together by increasing the makeopts for example to -j6 or
> > > > > > more. increase the number and see your processors loads.
> > > > > > the best number is the one that puts your processors to
> > > > > > about 80% of cpu so that you'd still have 20% of cpu power
> > > > > > to do other things. also add the niceness option so that
> > > > > > you don't see slowdowns when you compile and use some other
> > > > > > program.
> > > > > Well the parallel emerges are done just to load the cpu,
> > > > > after the main installation process, but thanks for the j6
> > > > > idea
> > > > > > third: have you installed acpi and acer-acpi?! i presume
> > > > > > that you've done it and you're starting both acpi and
> > > > > > acer-acpi at boot. anyway, the important thing is are the
> > > > > > trip_points. if you don't have them then you might need to
> > > > > > make a script to get the thermal temperature and to
> > > > > > slowdown manually the processor when it pushes too much up
> > > > > > the temperature.
> > > > > acer_acpi refuses to compile with some file missing
> > > > > error...will search the bugs later, but is it really
> > > > > necessary? if so could you please elaborate a little because
> > > > > I was under the impression that the fans were hardware
> > > > > controlled by default --
> > > > > gentoo-amd64@lists.gentoo.org mailing list
> > > >
> > > >
> > > > acer-acpi is usually necessary for acer notebooks to work well.
> > > > it is mandatory for hotkeys and other stuff and is necessary to
> > > > correct some acer's modifications in the acpi. so for what i
> > > > know acer-acpi is manadatory for acer notebooks as it is
> > > > asus-acpi on asus notebooks. try to see if everything fixes
> > > > after you install it (try unmasking newer versions if you
> > > > cannot install stable ones). the fans are ususally board
> > > > controlled as it is the passive mode that reduces the cpu
> > > > speed, but they can be forced via scripts.
> > > >
> > > >
> > > >
> > > >
> > > Unfortunately asus_acpi doesn't compile
> > > (http://bugs.gentoo.org/show_bug.cgi?id=208577). So I'm just
> > > asking for the cooling process is it mandatory. The issue here is
> > > not some hotkeys but the temperature...I wish to know weather
> > > this one is broken to or not. From what I've read on the
> > > http://code.google.com/p/aceracpi/ this program/driver is mostly
> > > for the lcd, battery lifetime  etc. But being the second laptop
> > > with the same issue makes me wonder...I wish i could compile
> > > this.... --
> > > gentoo-amd64@lists.gentoo.org mailing list
> > >
> > > well, we have a little problem about trip points, since the only
> > indicated there is the critical one and you don't have passive ones.
> > well, we'll need to do a little work on the manual scripts to have
> > the fan work and to be sure that the thermal won't reach critical
> > trip point where it would shutdown.
> > i'll take a look and post some scripts that should help. you'll
> > have to be sure that you have installed lm_sensors and cpufrequtils
> > and that you have compiled the cpufreq modules into the kernel or
> > as modules and you'll have them loaded at boot. we'll have to make
> > the processor slow down when the thermal goes too high. also i'd
> > like to know what are the capabilities of your processors:
> > a cat on the /proc/cpuinfo and then on cat
> > /proc/acpi/processor/CPU(x)/info where (x) is the number of the
> > core to know what sort of management it can support. you should
> > have cpu0 and cpu1 if you have a dualcore.
> >
> >
> > --
> > dott. ing. beso
> 
> i forgot to mention the other files in the cpu and thermal directory.
> they would help setting up the scripts. also you'll
> need /dev/cpu/microcode, /dev/cpu/cpuid, /dev/cpu/msr, Intel MCE
> features, Intel core2/ newer xeon compiled directly into the kernel
> and not as modules. they're in the processor types and features of
> the kernel. also you'll need the following from the power management
> options:
> - acpi support
> ---> everything compiled into the kernel and not as modules with the
> exception of dock, asus extras, toshiba extras, acpi container, smart
> battery system which are not mandatory.
> - cpu frequency scaling
>   │ │                                     [*] CPU Frequency
> scaling
> │ │
>   │ │                                     [*]   Enable CPUfreq
> debugging
> │ │
>   │ │                                     <*>   CPU frequency
> translation statistics
> │ │
>   │ │                                     [*]     CPU frequency
> translation statistics
> details                                                        │ │
>   │ │                                           Default CPUFreq
> governor (userspace)  --->
> │ │
>   │ │                                     <M>   'performance'
> governor
> │ │
>   │ │                                     <M>   'powersave'
> governor
> │ │
>   │ │                                     ---   'userspace' governor
> for userspace frequency scaling
> │ │
>   │ │                                     <M>   'ondemand' cpufreq
> policy governor
> │ │
>   │ │                                     <M>   'conservative' cpufreq
> governor
> │ │
>   │ │                                     ---   CPUFreq processor
> drivers
> │ │
>   │ │                                     < >   AMD Opteron/Athlon64
> PowerNow!
> │ │
>   │ │                                     <*>   Intel Enhanced
> SpeedStep (deprecated)
> │ │
>   │ │                                     <*>   ACPI Processor
> P-States driver
> │ │
>   │ │                                     ---   shared
> options
> │ │
>   │ │                                     [*]
> /proc/acpi/processor/../performance interface (deprecated)
> 
> after controlling this and recompiling if necessary reboot (if you've
> recompiled) and do another cat on the thermal trip points to see if
> it shows also other states. if it doesn't we will really have to
> impose the throttling manually when the temperature goes too high.
> we'll use the cpufreq governor to impose the speed when needed and
> then we'll impose throttling (processor suspension) when the thermal
> temp goes too high with it. if your pc supports limits and other speq
> steps we could have it lower the current state to a lower one to cool
> off a bit. but for this there's the need to know what your processor
> can do.
I've just done what you've advised me and ...already my CPU is cooling
down...but I've noticed the following: sensors only detects my CPU
sensor(souldn't there be others?, and yes I've ran sensors-detect), I
can;t seem to be able to to start fancontrol because pwmconfig can't
gind any pwm sensors. Also on you config I seem not to be able to
change my Cpu's freq with kLaptop.Thanks for the help so far!
--
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] new laptop

[Beso]

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

2008/2/4, ionut cucu <cuciferus@gmail.com>:
>
> On Mon, 4 Feb 2008 09:26:57 +0000
> Beso <givemesugarr@gmail.com> wrote:
>
> > 2008/2/4, Beso <givemesugarr@gmail.com>:
> > >
> > >
> > >
> > > 2008/2/4, ionut cucu <cuciferus@gmail.com>:
> > > >
> > > > On Sun, 3 Feb 2008 15:49:47 +0000
> > > > Beso <givemesugarr@gmail.com> wrote:
> > > >
> > > > > 2008/2/3, ionut cucu <cuciferus@gmail.com>:
> > > > > >
> > > > > > On Sun, 3 Feb 2008 13:55:56 +0000
> > > > > > Beso <givemesugarr@gmail.com> wrote:
> > > > > >
> > > > > > > 2008/2/3, ionut cucu <cuciferus@gmail.com>:
> > > > > > > >
> > > > > > > > Hi List,
> > > > > > > > I've just bought a new laptop Acer 5715Z and I've have the
> > > > > > > > following issue the processor overheats until the laptop
> > > > > > > > closes(100 degrees Celsius). This happened when I had two
> > > > > > > > parallel emerges. So I went to the shop and changed it
> > > > > > > > with another one, same model. This one can hold up to 3
> > > > > > > > parallel emerges but it overheats when I'm watching a
> > > > > > > > movie, again it reaches the 100 degrees limit. I'm I
> > > > > > > > doing something wrong here? I'm I missing something (this
> > > > > > > > is the first laptop I have) ?. Or just by coincidence
> > > > > > > > this one is broken too. I've looked on the Internet but I
> > > > > > > > hadn't found any similar issues. Thanks! --
> > > > > > > > gentoo-amd64@lists.gentoo.org mailing list
> > > > > > > >
> > > > > > > > first: maybe the thermal isn't set right.
> > > > > > > what does cat /proc/acpi/thermal_zone/THRM/trip_points
> > > > > > > says?! mine is something like this:
> > > > > > >
> > > > > > > critical (S5):           105 C
> > > > > > > passive:                 76 C: tc1=3 tc2=1 tsp=150
> > > > > > > devices=CPU0 active[0]:               67 C: devices= FN1
> > > > > > > active[1]:               57 C: devices= FN2
> > > > > > >
> > > > > > > you might have different values but at least you should
> > > > > > > have one active and one passive.
> > > > > > I have only the critical level set
> > > > > > > second: don't do parallel emerge if you're not sure that the
> > > > > > > packages from one emerge don't collide with the ones from
> > > > > > > the other. for example, knetworkmanager needs
> > > > > > > networkmanager which needs dhcdb which needs dhclient. if
> > > > > > > you emerge something that would emerge dhclient then you'd
> > > > > > > emerge 2 times dhclient or you might risk one of the 2
> > > > > > > emerges to fail because a dep hasn't yet been installed.
> > > > > > > you could push up the number of processes to be build
> > > > > > > together by increasing the makeopts for example to -j6 or
> > > > > > > more. increase the number and see your processors loads.
> > > > > > > the best number is the one that puts your processors to
> > > > > > > about 80% of cpu so that you'd still have 20% of cpu power
> > > > > > > to do other things. also add the niceness option so that
> > > > > > > you don't see slowdowns when you compile and use some other
> > > > > > > program.
> > > > > > Well the parallel emerges are done just to load the cpu,
> > > > > > after the main installation process, but thanks for the j6
> > > > > > idea
> > > > > > > third: have you installed acpi and acer-acpi?! i presume
> > > > > > > that you've done it and you're starting both acpi and
> > > > > > > acer-acpi at boot. anyway, the important thing is are the
> > > > > > > trip_points. if you don't have them then you might need to
> > > > > > > make a script to get the thermal temperature and to
> > > > > > > slowdown manually the processor when it pushes too much up
> > > > > > > the temperature.
> > > > > > acer_acpi refuses to compile with some file missing
> > > > > > error...will search the bugs later, but is it really
> > > > > > necessary? if so could you please elaborate a little because
> > > > > > I was under the impression that the fans were hardware
> > > > > > controlled by default --
> > > > > > gentoo-amd64@lists.gentoo.org mailing list
> > > > >
> > > > >
> > > > > acer-acpi is usually necessary for acer notebooks to work well.
> > > > > it is mandatory for hotkeys and other stuff and is necessary to
> > > > > correct some acer's modifications in the acpi. so for what i
> > > > > know acer-acpi is manadatory for acer notebooks as it is
> > > > > asus-acpi on asus notebooks. try to see if everything fixes
> > > > > after you install it (try unmasking newer versions if you
> > > > > cannot install stable ones). the fans are ususally board
> > > > > controlled as it is the passive mode that reduces the cpu
> > > > > speed, but they can be forced via scripts.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > Unfortunately asus_acpi doesn't compile
> > > > (http://bugs.gentoo.org/show_bug.cgi?id=208577). So I'm just
> > > > asking for the cooling process is it mandatory. The issue here is
> > > > not some hotkeys but the temperature...I wish to know weather
> > > > this one is broken to or not. From what I've read on the
> > > > http://code.google.com/p/aceracpi/ this program/driver is mostly
> > > > for the lcd, battery lifetime  etc. But being the second laptop
> > > > with the same issue makes me wonder...I wish i could compile
> > > > this.... --
> > > > gentoo-amd64@lists.gentoo.org mailing list
> > > >
> > > > well, we have a little problem about trip points, since the only
> > > indicated there is the critical one and you don't have passive ones.
> > > well, we'll need to do a little work on the manual scripts to have
> > > the fan work and to be sure that the thermal won't reach critical
> > > trip point where it would shutdown.
> > > i'll take a look and post some scripts that should help. you'll
> > > have to be sure that you have installed lm_sensors and cpufrequtils
> > > and that you have compiled the cpufreq modules into the kernel or
> > > as modules and you'll have them loaded at boot. we'll have to make
> > > the processor slow down when the thermal goes too high. also i'd
> > > like to know what are the capabilities of your processors:
> > > a cat on the /proc/cpuinfo and then on cat
> > > /proc/acpi/processor/CPU(x)/info where (x) is the number of the
> > > core to know what sort of management it can support. you should
> > > have cpu0 and cpu1 if you have a dualcore.
> > >
> > >
> > > --
> > > dott. ing. beso
> >
> > i forgot to mention the other files in the cpu and thermal directory.
> > they would help setting up the scripts. also you'll
> > need /dev/cpu/microcode, /dev/cpu/cpuid, /dev/cpu/msr, Intel MCE
> > features, Intel core2/ newer xeon compiled directly into the kernel
> > and not as modules. they're in the processor types and features of
> > the kernel. also you'll need the following from the power management
> > options:
> > - acpi support
> > ---> everything compiled into the kernel and not as modules with the
> > exception of dock, asus extras, toshiba extras, acpi container, smart
> > battery system which are not mandatory.
> > - cpu frequency scaling
> >   │ │                                     [*] CPU Frequency
> > scaling
> > │ │
> >   │ │                                     [*]   Enable CPUfreq
> > debugging
> > │ │
> >   │ │                                     <*>   CPU frequency
> > translation statistics
> > │ │
> >   │ │                                     [*]     CPU frequency
> > translation statistics
> > details                                                        │ │
> >   │ │                                           Default CPUFreq
> > governor (userspace)  --->
> > │ │
> >   │ │                                     <M>   'performance'
> > governor
> > │ │
> >   │ │                                     <M>   'powersave'
> > governor
> > │ │
> >   │ │                                     ---   'userspace' governor
> > for userspace frequency scaling
> > │ │
> >   │ │                                     <M>   'ondemand' cpufreq
> > policy governor
> > │ │
> >   │ │                                     <M>   'conservative' cpufreq
> > governor
> > │ │
> >   │ │                                     ---   CPUFreq processor
> > drivers
> > │ │
> >   │ │                                     < >   AMD Opteron/Athlon64
> > PowerNow!
> > │ │
> >   │ │                                     <*>   Intel Enhanced
> > SpeedStep (deprecated)
> > │ │
> >   │ │                                     <*>   ACPI Processor
> > P-States driver
> > │ │
> >   │ │                                     ---   shared
> > options
> > │ │
> >   │ │                                     [*]
> > /proc/acpi/processor/../performance interface (deprecated)
> >
> > after controlling this and recompiling if necessary reboot (if you've
> > recompiled) and do another cat on the thermal trip points to see if
> > it shows also other states. if it doesn't we will really have to
> > impose the throttling manually when the temperature goes too high.
> > we'll use the cpufreq governor to impose the speed when needed and
> > then we'll impose throttling (processor suspension) when the thermal
> > temp goes too high with it. if your pc supports limits and other speq
> > steps we could have it lower the current state to a lower one to cool
> > off a bit. but for this there's the need to know what your processor
> > can do.
> I've just done what you've advised me and ...already my CPU is cooling
> down...but I've noticed the following: sensors only detects my CPU
> sensor(souldn't there be others?, and yes I've ran sensors-detect), I
> can;t seem to be able to to start fancontrol because pwmconfig can't
> gind any pwm sensors. Also on you config I seem not to be able to
> change my Cpu's freq with kLaptop.Thanks for the help so far!
> --
> gentoo-amd64@lists.gentoo.org mailing list
>
> what do the files inside /proc/acpi/thermal_zone/ and
/proc/acpi/processor/ contain?!
for klaptop, you have to first configure it. set everything to conservative,
it should raise your processor speed based on your needs. be sure also to
add cpufrequtils as a service at boot and to load the eventual modules at
boot time by adding them to the /etc/modules.autoload/kernel-2.6 so that
they load at boot. without cufrequtils and the modules (if you've build the
stuff as modules and you've done it if you've used my config) you won't be
able to switch. without rebooting you could open konsole and start
cpufrequtils with /etc/init.d/cpufrequtils start and then add it with
rc-update add cpufrequtils default and then modprobe cpufreq_powersave &&
modprobe cpufreq_conservative && modprobe cpufreq_performance. now you
should be able to switch them with klaptop. don't use kpowersaved since it
doesn't work anymore or at least on my pc it cannot find acpid started.
if you'd like a monitor for kde there are different solutions:
- one is superkaramba with some theme like aero-aio
- kima which is directly included into the kicker as an applet and can
monitor thermal, processor temp, processor load, uptime, battery and
processor and /proc speed. i prefer this solution since it's faster to see
and never gets covered by apps letting me see always the state of the
system.
for lm_sensors instead, is quite ok to not have fan control since the fan on
a notebook is not usually connected to some control sensor but is controlled
directly by acpi. on notebooks usually you might find some monitor for cpu
core, for some removable media like pccards and nand devices like mmd. the
only thing that is useful is the core processor monitor which gives you the
temp of the core(s) and it lets you have an idea of how your processor works
. remember that thermal temp might be different and usually is higher than
core temp.
also some helpful utils for kde are: klipper (fabulous klipboard); kompose
(osx kompose changer), ksynaptic (if you have synaptic or alps touchpads
that usually get installed in notebooks), knetworkmanager + networkmanager
and the new kde4 like kicker that includes a built-in search module that
improves usability of kde. other useful kicker applets are the shutdown and
block applets, the kmixer applet (this lets you remove from start kmix), the
show desktop applet and the trash can applet.
also for full kde experience i suggest kaffeine + xine (not 1.1.10 since it
has some problems with external linkage) and amarok + xine. install xft and
cairo with svg and pdf flags and search for the font antialiasing wiki that
was on xeffects if i remember right.
also ksplash-engine-moodin is wonderful for personalizing the ksplash and
oxy-cursors from flameeyes-overlay are wonderful cursor themes.
if you like osx be sure to search for a baghira how to and on how to make
kde identical to osx (don't use kxdocker, though). and before using compiz
be aware that ati drivers don't work well with it. for tuning ati drivers
visit phoronix forums and you'll have a lot of info about them.


-- 
dott. ing. beso

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

Re: [gentoo-amd64] new laptop

[ionut cucu]

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

On Mon, 4 Feb 2008 14:21:29 +0000
Beso <givemesugarr@gmail.com> wrote:

> 2008/2/4, ionut cucu <cuciferus@gmail.com>:
> >
> > On Mon, 4 Feb 2008 09:26:57 +0000
> > Beso <givemesugarr@gmail.com> wrote:
>
> > what do the files inside /proc/acpi/thermal_zone/ and
> /proc/acpi/processor/ contain?!
cat /proc/acpi/thermal_zone/TZ01/
cooling_mode       polling_frequency  state              temperature
trip_points
cat /proc/acpi/thermal_zone/TZ01/*
<setting not supported>
<polling disabled>
state:                   ok
temperature:             0 C
critical (S5):           100 C
 cat /proc/acpi/processor/CPU0/
info         limit        performance  power        throttling

the content of the /proc/acpi/processor/CPUx files it attached since is
rather large for an email
> for klaptop, you have to first configure it. set everything to
> conservative, it should raise your processor speed based on your
> needs. be sure also to add cpufrequtils as a service at boot and to
> load the eventual modules at boot time by adding them to
> the /etc/modules.autoload/kernel-2.6 so that they load at boot.
> without cufrequtils and the modules (if you've build the stuff as
> modules and you've done it if you've used my config) you won't be
> able to switch. without rebooting you could open konsole and start
> cpufrequtils with /etc/init.d/cpufrequtils start and then add it with
> rc-update add cpufrequtils default and then modprobe
> cpufreq_powersave && modprobe cpufreq_conservative && modprobe
> cpufreq_performance. now you should be able to switch them with
> klaptop. 
Not yet I'm not....also the profiles in klaptop(which just overheated
again and it's at 90 degrees and rising in 800Mhz) are named as the
P0,1,2 states(x Mhz, y mW,z uS) and not as they were(conservatve.....)

don't use kpowersaved since it doesn't work anymore or at
> least on my pc it cannot find acpid started. if you'd like a monitor
> for kde there are different solutions:
> - one is superkaramba with some theme like aero-aio
> - kima which is directly included into the kicker as an applet and can
> monitor thermal, processor temp, processor load, uptime, battery and
> processor and /proc speed. i prefer this solution since it's faster
> to see and never gets covered by apps letting me see always the state
> of the system.
> for lm_sensors instead, is quite ok to not have fan control since the
> fan on a notebook is not usually connected to some control sensor but
> is controlled directly by acpi. on notebooks usually you might find
> some monitor for cpu core, for some removable media like pccards and
> nand devices like mmd. the only thing that is useful is the core
> processor monitor which gives you the temp of the core(s) and it lets
> you have an idea of how your processor works . remember that thermal
> temp might be different and usually is higher than core temp.
Thanks, that I did not knew, I'm new to laptops and their fan
"drivers"/sensors and such. I never did had an temp issue on my
machine, although it has to speed states.
> also some helpful utils for kde are: klipper (fabulous klipboard);
> kompose (osx kompose changer), ksynaptic (if you have synaptic or
> alps touchpads that usually get installed in notebooks),
> knetworkmanager + networkmanager and the new kde4 like kicker that
> includes a built-in search module that improves usability of kde.
> other useful kicker applets are the shutdown and block applets, the
> kmixer applet (this lets you remove from start kmix), the show
> desktop applet and the trash can applet. also for full kde experience
> i suggest kaffeine + xine (not 1.1.10 since it has some problems with
> external linkage) and amarok + xine. install xft and cairo with svg
> and pdf flags and search for the font antialiasing wiki that was on
> xeffects if i remember right. also ksplash-engine-moodin is wonderful
> for personalizing the ksplash and oxy-cursors from flameeyes-overlay
> are wonderful cursor themes. if you like osx be sure to search for a
> baghira how to and on how to make kde identical to osx (don't use
> kxdocker, though). and before using compiz be aware that ati drivers
> don't work well with it. for tuning ati drivers visit phoronix forums
> and you'll have a lot of info about 
I'm a fluxbox fan, my brother nags me about kde though he knows these,
but I'm so worried about the temp(now for some reason it's dropping to
70 celsius).
So I don't need no fancontrols but what do I need to keep these temps
stable and below 60?Because now I'm sure it heats up for no reason and
then when it feels like it it cools down. 

[-- Attachment #2: mdea --]
[-- Type: application/octet-stream, Size: 1296 bytes --]

processor id:            0
acpi id:                 1
bus mastering control:   yes
power management:        yes
throttling control:      yes
limit interface:         yes
active limit:            P0:T0
user limit:              P0:T0
thermal limit:           P0:T0
state count:             3
active state:            P2
states:
    P0:                  1467 MHz, 35000 mW, 10 uS
    P1:                  1067 MHz, 23600 mW, 10 uS
   *P2:                  800 MHz, 16000 mW, 10 uS
active state:            C3
max_cstate:              C8
bus master activity:     00000000
maximum allowed latency: 6666 usec
states:
    C1:                  type[C1] promotion[C2] demotion[--] latency[001] usage[00003700] duration[00000000000000000000]
    C2:                  type[C2] promotion[C3] demotion[C1] latency[001] usage[00277478] duration[00000000002011424878]
   *C3:                  type[C3] promotion[--] demotion[C2] latency[017] usage[01264857] duration[00000000008391353640]
state count:             8
active state:            T8
state available: T0 to T7
states:
    T0:                  100%
    T1:                  88%
    T2:                  75%
    T3:                  63%
    T4:                  50%
    T5:                  38%
    T6:                  25%
    T7:                  13%

Re: [gentoo-amd64] new laptop

[Beso]

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

2008/2/4, ionut cucu <cuciferus@gmail.com>:
>
> On Mon, 4 Feb 2008 14:21:29 +0000
> Beso <givemesugarr@gmail.com> wrote:
>
> > 2008/2/4, ionut cucu <cuciferus@gmail.com>:
> > >
> > > On Mon, 4 Feb 2008 09:26:57 +0000
> > > Beso <givemesugarr@gmail.com> wrote:
> >
> > > what do the files inside /proc/acpi/thermal_zone/ and
> > /proc/acpi/processor/ contain?!
> cat /proc/acpi/thermal_zone/TZ01/
> cooling_mode       polling_frequency  state              temperature
> trip_points
> cat /proc/acpi/thermal_zone/TZ01/*
> <setting not supported>
> <polling disabled>
> state:                   ok
> temperature:             0 C
> critical (S5):           100 C
> cat /proc/acpi/processor/CPU0/
> info         limit        performance  power        throttling
>
> the content of the /proc/acpi/processor/CPUx files it attached since is
> rather large for an email
> > for klaptop, you have to first configure it. set everything to
> > conservative, it should raise your processor speed based on your
> > needs. be sure also to add cpufrequtils as a service at boot and to
> > load the eventual modules at boot time by adding them to
> > the /etc/modules.autoload/kernel-2.6 so that they load at boot.
> > without cufrequtils and the modules (if you've build the stuff as
> > modules and you've done it if you've used my config) you won't be
> > able to switch. without rebooting you could open konsole and start
> > cpufrequtils with /etc/init.d/cpufrequtils start and then add it with
> > rc-update add cpufrequtils default and then modprobe
> > cpufreq_powersave && modprobe cpufreq_conservative && modprobe
> > cpufreq_performance. now you should be able to switch them with
> > klaptop.
> Not yet I'm not....also the profiles in klaptop(which just overheated
> again and it's at 90 degrees and rising in 800Mhz) are named as the
> P0,1,2 states(x Mhz, y mW,z uS) and not as they were(conservatve.....)
>
> don't use kpowersaved since it doesn't work anymore or at
> > least on my pc it cannot find acpid started. if you'd like a monitor
> > for kde there are different solutions:
> > - one is superkaramba with some theme like aero-aio
> > - kima which is directly included into the kicker as an applet and can
> > monitor thermal, processor temp, processor load, uptime, battery and
> > processor and /proc speed. i prefer this solution since it's faster
> > to see and never gets covered by apps letting me see always the state
> > of the system.
> > for lm_sensors instead, is quite ok to not have fan control since the
> > fan on a notebook is not usually connected to some control sensor but
> > is controlled directly by acpi. on notebooks usually you might find
> > some monitor for cpu core, for some removable media like pccards and
> > nand devices like mmd. the only thing that is useful is the core
> > processor monitor which gives you the temp of the core(s) and it lets
> > you have an idea of how your processor works . remember that thermal
> > temp might be different and usually is higher than core temp.
> Thanks, that I did not knew, I'm new to laptops and their fan
> "drivers"/sensors and such. I never did had an temp issue on my
> machine, although it has to speed states.
> > also some helpful utils for kde are: klipper (fabulous klipboard);
> > kompose (osx kompose changer), ksynaptic (if you have synaptic or
> > alps touchpads that usually get installed in notebooks),
> > knetworkmanager + networkmanager and the new kde4 like kicker that
> > includes a built-in search module that improves usability of kde.
> > other useful kicker applets are the shutdown and block applets, the
> > kmixer applet (this lets you remove from start kmix), the show
> > desktop applet and the trash can applet. also for full kde experience
> > i suggest kaffeine + xine (not 1.1.10 since it has some problems with
> > external linkage) and amarok + xine. install xft and cairo with svg
> > and pdf flags and search for the font antialiasing wiki that was on
> > xeffects if i remember right. also ksplash-engine-moodin is wonderful
> > for personalizing the ksplash and oxy-cursors from flameeyes-overlay
> > are wonderful cursor themes. if you like osx be sure to search for a
> > baghira how to and on how to make kde identical to osx (don't use
> > kxdocker, though). and before using compiz be aware that ati drivers
> > don't work well with it. for tuning ati drivers visit phoronix forums
> > and you'll have a lot of info about
> I'm a fluxbox fan, my brother nags me about kde though he knows these,
> but I'm so worried about the temp(now for some reason it's dropping to
> 70 celsius).
> So I don't need no fancontrols but what do I need to keep these temps
> stable and below 60?Because now I'm sure it heats up for no reason and
> then when it feels like it it cools down.
>
>
right now i'm studying some scripts to adapt them to your hw. i'll let you
know when i finish them and i'll post them for you to test.

-- 
dott. ing. beso

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

Re: [gentoo-amd64] new laptop

[ionut cucu]

On Mon, 4 Feb 2008 15:52:18 +0000
Beso <givemesugarr@gmail.com> wrote:

> right now i'm studying some scripts to adapt them to your hw. i'll
> let you know when i finish them and i'll post them for you to test.
 
Wouldn't you rather give me a few hints first on how to get my
trip_points set first? Afterwards I can also test the scripts. You can
understand my impacience here.
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] new laptop

[Beso]

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

2008/2/6, ionut cucu <cuciferus@gmail.com>:
>
> On Mon, 4 Feb 2008 15:52:18 +0000
> Beso <givemesugarr@gmail.com> wrote:
>
> > right now i'm studying some scripts to adapt them to your hw. i'll
> > let you know when i finish them and i'll post them for you to test.
>
> Wouldn't you rather give me a few hints first on how to get my
> trip_points set first? Afterwards I can also test the scripts. You can
> understand my impacience here.



the trip_points cannot be set manually, since the trip_points file is
readonly
for the moment my problem is that i cannot make the script to read the acpi
temperature.
for now i'd suggest for you to add some sensor monitor, like kima for kde,
or some others and use them to identify the acpi temperature. when your
thermal reaches 80° you'd have to set the cpufreq to powersave so that the
processor goes to the lowest freq and the thermal
temperature goes down. the console command to do this is:
cpufreq-set -g powersave
when the temperature goes around 60°-62° you can reset the conservative
governor so that you will have the processor go faster when you need it.
cpufreq-set -g conservative.

as soon as i finish the scripts to automatically adjust the processor based
on thermal readings i'll post them to you.

-- 
dott. ing. beso

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

Re: [gentoo-amd64] new laptop

[Brett Johnson]

On Wed, 2008-02-06 at 13:44 +0000, Beso wrote:

> 
> the trip_points cannot be set manually, since the trip_points file is
> readonly
> for the moment my problem is that i cannot make the script to read the
> acpi temperature. 
> for now i'd suggest for you to add some sensor monitor, like kima for
> kde, or some others and use them to identify the acpi temperature.
> when your thermal reaches 80° you'd have to set the cpufreq to
> powersave so that the processor goes to the lowest freq and the
> thermal
> 
> temperature goes down. the console command to do this is:
> cpufreq-set -g powersave 
> when the temperature goes around 60°-62° you can reset the
> conservative governor so that you will have the processor go faster
> when you need it.
> cpufreq-set -g conservative.
> 
> as soon as i finish the scripts to automatically adjust the processor
> based on thermal readings i'll post them to you.
> 
I have not been following this thread to closely so I apologize if this
has already been mentioned. Have you considered ncpufreqd? According to
the Gentoo power management guide:

"Toggles the used governor between performance and powersave depending
on system temperature. Very useful on laptops with notorious heat
problems."

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

Re: [gentoo-amd64] new laptop

[Beso]

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

2008/2/6, Brett Johnson <brett@blzj.com>:
>
>
> On Wed, 2008-02-06 at 13:44 +0000, Beso wrote:
>
> >
> > the trip_points cannot be set manually, since the trip_points file is
> > readonly
> > for the moment my problem is that i cannot make the script to read the
> > acpi temperature.
> > for now i'd suggest for you to add some sensor monitor, like kima for
> > kde, or some others and use them to identify the acpi temperature.
> > when your thermal reaches 80° you'd have to set the cpufreq to
> > powersave so that the processor goes to the lowest freq and the
> > thermal
> >
> > temperature goes down. the console command to do this is:
> > cpufreq-set -g powersave
> > when the temperature goes around 60°-62° you can reset the
> > conservative governor so that you will have the processor go faster
> > when you need it.
> > cpufreq-set -g conservative.
> >
> > as soon as i finish the scripts to automatically adjust the processor
> > based on thermal readings i'll post them to you.
> >
> I have not been following this thread to closely so I apologize if this
> has already been mentioned. Have you considered ncpufreqd? According to
> the Gentoo power management guide:
>
> "Toggles the used governor between performance and powersave depending
> on system temperature. Very useful on laptops with notorious heat
> problems."


this could be a workaround for the issue. try emerging and testing it. if
this still doesn't work let me know so that i can continue to work on the
scripts. for the moment i'll stop working on them and wait for a positive or
negative answer from you.

-- 
dott. ing. beso

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

Re: [gentoo-amd64] new laptop

[ionut cristian cucu]

ncpufreqd will not start but it doesn't print any errors either. But
strange issue: I did a test: MAKEOPTS="-j" emerge amarok and guess
what the temp did not budge a degree over 50, but this morning as I'm
writing this my cpu is on 62% usage but the temp is 95 degrees. This
puzzles me. Stopping any emerge process did help, but last night it
went for hours with full 100% CPU load and now it overheats with
"-j1". It is clear, to me, that something somewhere is wicked.
LATER: I've just noticed that TZ01 in kima was 0 rebooting set it to
50 and now with emerge keeping the cpu at max speed and load gives me
only 55 degrees. So how I will do a kernel update maybe will fix my
problem, because it looks to me like it's comming from there. Isn't
it?
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] new laptop

[Beso]

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

2008/2/7, ionut cristian cucu <cuciferus@gmail.com>:
>
> ncpufreqd will not start but it doesn't print any errors either.


have you set the /etc/ncpufreqd.conf? also, have you started cpufrequtils as
a daemon and loaded the various cpufreq modules?!
without them ncpufreqd won't work. to see if it starts try looking at the
system log.

But
> strange issue: I did a test: MAKEOPTS="-j" emerge amarok and guess
> what the temp did not budge a degree over 50, but this morning as I'm
> writing this my cpu is on 62% usage but the temp is 95 degrees.


it's impossible for the thermal to be at only 50 when compiling unlimited
jobs. maybe the temp you're seeing is the core and not the thermal one. it
makes sense that core is at 50° and thermal at 95°.

This
> puzzles me. Stopping any emerge process did help, but last night it
> went for hours with full 100% CPU load and now it overheats with
> "-j1". It is clear, to me, that something somewhere is wicked.
> LATER: I've just noticed that TZ01 in kima was 0 rebooting set it to
> 50 and now with emerge keeping the cpu at max speed and load gives me
> only 55 degrees. So how I will do a kernel update maybe will fix my
> problem, because it looks to me like it's comming from there. Isn't
> it?


then the tz01 is the processor core thermal and not the thermal itself. then
you should have another thermal zone other than TZ01. try looking in the
/proc/acpi. or better do a ls -lR /proc/acpi > proc-contents.txt and append
it here. it might be useful to see what your proc contains.


-- 
dott. ing. beso

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

Re: [gentoo-amd64] new laptop

[ionut cristian cucu]

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

2008/2/7, Beso <givemesugarr@gmail.com>:
> 2008/2/7, ionut cristian cucu <cuciferus@gmail.com>:
> > ncpufreqd will not start but it doesn't print any errors either.
>
> have you set the /etc/ncpufreqd.conf?
I've looked there and apart from an /proc/acpi/CPU witch had to be
corrected to CPU0 everything else was oki

 also, have you started cpufrequtils as
> a daemon and loaded the various cpufreq modules?!
Yup
>  without them ncpufreqd won't work. to see if it starts try looking at the
> system log.
I have not yet setup the system log yet, and gentoo-wiki is not up
>
> > But
> > strange issue: I did a test: MAKEOPTS="-j" emerge amarok and guess
> > what the temp did not budge a degree over 50, but this morning as I'm
> > writing this my cpu is on 62% usage but the temp is 95 degrees.
>
>
> it's impossible for the thermal to be at only 50 when compiling unlimited
> jobs. maybe the temp you're seeing is the core and not the thermal one. it
> makes sense that core is at 50° and thermal at 95°.
Hmm I might have a little bit exagerated but hwmon1/2 were constant
and certainly in sane values
>
> > This
> > puzzles me. Stopping any emerge process did help, but last night it
> > went for hours with full 100% CPU load and now it overheats with
> > "-j1". It is clear, to me, that something somewhere is wicked.
> > LATER: I've just noticed that TZ01 in kima was 0 rebooting set it to
> > 50 and now with emerge keeping the cpu at max speed and load gives me
> > only 55 degrees. So how I will do a kernel update maybe will fix my
> > problem, because it looks to me like it's comming from there. Isn't
> > it?
>
> then the tz01 is the processor core thermal and not the thermal itself. then
> you should have another thermal zone other than TZ01. try looking in the
> /proc/acpi. or better do a ls -lR /proc/acpi > proc-contents.txt and append
> it here. it might be useful to see what your proc contains.
>
>
> --
> dott. ing. beso

[-- Attachment #2: proc-content.txt --]
[-- Type: text/plain, Size: 3181 bytes --]

/proc/acpi/:
total 0
dr-xr-xr-x 3 root root      0 Feb  7 16:15 ac_adapter
-rw-r--r-- 1 root root      0 Feb  7 16:15 alarm
dr-xr-xr-x 3 root root      0 Feb  7 16:15 battery
dr-xr-xr-x 5 root root      0 Feb  7 16:15 button
-r-------- 1 root root      0 Feb  7 16:15 dsdt
dr-xr-xr-x 3 root root      0 Feb  7 16:15 embedded_controller
-r--r----- 1 root haldaemon 0 Feb  7 09:43 event
-r-------- 1 root root      0 Feb  7 16:15 fadt
dr-xr-xr-x 2 root root      0 Feb  7 16:15 fan
-r--r--r-- 1 root root      0 Feb  7 16:15 info
dr-xr-xr-x 2 root root      0 Feb  7 16:15 power_resource
dr-xr-xr-x 4 root root      0 Feb  7 16:15 processor
-rw-r--r-- 1 root root      0 Feb  7 16:15 sleep
dr-xr-xr-x 3 root root      0 Feb  7 16:15 thermal_zone
-rw-r--r-- 1 root root      0 Feb  7 16:15 wakeup

/proc/acpi/ac_adapter:
total 0
dr-xr-xr-x 2 root root 0 Feb  7 16:15 AC

/proc/acpi/ac_adapter/AC:
total 0
-r--r--r-- 1 root root 0 Feb  7 16:15 state

/proc/acpi/battery:
total 0
dr-xr-xr-x 2 root root 0 Feb  7 16:15 BAT0

/proc/acpi/battery/BAT0:
total 0
-rw-r--r-- 1 root root 0 Feb  7 16:15 alarm
-r--r--r-- 1 root root 0 Feb  7 16:15 info
-r--r--r-- 1 root root 0 Feb  7 16:15 state

/proc/acpi/button:
total 0
dr-xr-xr-x 3 root root 0 Feb  7 16:15 lid
dr-xr-xr-x 4 root root 0 Feb  7 16:15 power
dr-xr-xr-x 3 root root 0 Feb  7 16:15 sleep

/proc/acpi/button/lid:
total 0
dr-xr-xr-x 2 root root 0 Feb  7 16:15 LID0

/proc/acpi/button/lid/LID0:
total 0
-r--r--r-- 1 root root 0 Feb  7 16:15 info
-r--r--r-- 1 root root 0 Feb  7 16:15 state

/proc/acpi/button/power:
total 0
dr-xr-xr-x 2 root root 0 Feb  7 16:15 PWRB
dr-xr-xr-x 2 root root 0 Feb  7 16:15 PWRF

/proc/acpi/button/power/PWRB:
total 0
-r--r--r-- 1 root root 0 Feb  7 16:15 info

/proc/acpi/button/power/PWRF:
total 0
-r--r--r-- 1 root root 0 Feb  7 16:15 info

/proc/acpi/button/sleep:
total 0
dr-xr-xr-x 2 root root 0 Feb  7 16:15 SLPB

/proc/acpi/button/sleep/SLPB:
total 0
-r--r--r-- 1 root root 0 Feb  7 16:15 info

/proc/acpi/embedded_controller:
total 0
dr-xr-xr-x 2 root root 0 Feb  7 16:15 EC0

/proc/acpi/embedded_controller/EC0:
total 0
-r--r--r-- 1 root root 0 Feb  7 16:15 info

/proc/acpi/fan:
total 0

/proc/acpi/power_resource:
total 0

/proc/acpi/processor:
total 0
dr-xr-xr-x 2 root root 0 Feb  7 16:15 CPU0
dr-xr-xr-x 2 root root 0 Feb  7 16:15 CPU1

/proc/acpi/processor/CPU0:
total 0
-r--r--r-- 1 root root 0 Feb  7 16:15 info
-rw-r--r-- 1 root root 0 Feb  7 16:15 limit
-r--r--r-- 1 root root 0 Feb  7 16:15 performance
-r--r--r-- 1 root root 0 Feb  7 16:15 power
-rw-r--r-- 1 root root 0 Feb  7 16:15 throttling

/proc/acpi/processor/CPU1:
total 0
-r--r--r-- 1 root root 0 Feb  7 16:15 info
-rw-r--r-- 1 root root 0 Feb  7 16:15 limit
-r--r--r-- 1 root root 0 Feb  7 16:15 power
-rw-r--r-- 1 root root 0 Feb  7 16:15 throttling

/proc/acpi/thermal_zone:
total 0
dr-xr-xr-x 2 root root 0 Feb  7 16:15 TZ01

/proc/acpi/thermal_zone/TZ01:
total 0
-rw-r--r-- 1 root root 0 Feb  7 16:15 cooling_mode
-rw-r--r-- 1 root root 0 Feb  7 16:15 polling_frequency
-r--r--r-- 1 root root 0 Feb  7 16:15 state
-r--r--r-- 1 root root 0 Feb  7 16:15 temperature
-r--r--r-- 1 root root 0 Feb  7 16:15 trip_points

Re: [gentoo-amd64] new laptop

[ionut cucu]

On Mon, 4 Feb 2008 09:01:41 +0000
Beso <givemesugarr@gmail.com> wrote:

> > well, we have a little problem about trip points, since the only
> > indicated
> there is the critical one and you don't have passive ones.
> well, we'll need to do a little work on the manual scripts to have
> the fan work and to be sure that the thermal won't reach critical
> trip point where it would shutdown.
> i'll take a look and post some scripts that should help. you'll have
> to be sure that you have installed lm_sensors and cpufrequtils and
> that you have compiled the cpufreq modules into the kernel or as
> modules and you'll have them loaded at boot. we'll have to make the
> processor slow down when the thermal goes too high. also i'd like to
> know what are the capabilities of your processors:
> a cat on the /proc/cpuinfo and then on
> cat /proc/acpi/processor/CPU(x)/info where (x) is the number of the
> core to know what sort of management it can support. you should have
> cpu0 and cpu1 if you have a dualcore.


cat /proc/acpi/processor/CPU1/info
processor id:            1
acpi id:                 2
bus mastering control:   yes
power management:        yes
throttling control:      yes
limit interface:         yes
cat /proc/cpuinfo 
<snip as the first is the same as the second> 
processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Pentium(R) Dual  CPU  T2310  @ 1.46GHz
stepping        : 13
cpu MHz         : 1467.000
cache size      : 1024 KB
physical id     : 0
siblings        : 2
core id         : 1
cpu cores       : 2
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall lm constant_tsc arch_perfmon pebs bts rep_good pni monitor
ds_cpl est tm2 ssse3 cx16 xtpr lahf_lm
bogomips        : 2927.97
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

I'm soooo curious to get to the bottom of this as I've seen a post
saying that on windows a guy had the same issue and resolved it with
some "empowering (TM) Acer" drivers. But I've only seen one post
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] madwifi-ng not compile in amd64

[Beso]

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

2008/1/30, Volker Armin Hemmann <volker.armin.hemmann@tu-clausthal.de>:
>
> On Mittwoch, 30. Januar 2008, Beso wrote:
> > the real problem stands in the keyword.... the amd64 would downgrade a
> lot
> > of stuff.... before doing it it's better to identify the normal
> programs,
> > like kde, gnome, and similar and let them be for the moment as
> ~amd64....
> > but at least stuff like, gcc, glibc, baselayout, kernel and some other
> base
> > stuff should stay on the amd64 branch.... you won't be able to downgrade
> > glibc so that one for the moment would stay on the unstable branch....
> but
> > if you don't feel in the mood to downgrade cause the  ~amd64 being to
> > amd64, then just update the profile and you should see something like
> 100
> > packages....
> > also adding --as-needed as LDFLAGS should help you save some time in
> > recompiling stuff....
>
> yeah - no. Don't do it. It breaks stuff.


it doesn't anymore. it works very well.


> the 2gb of ccache would help, but not a lot.... 400+ packages would mean
> > about 3-4 days on a amd64 2ghz single core, so prepare for a looong time
> of
> > compile time.... also the 5 blockers are not good and should be fixed in
> > some way before proceeding to the recompile....
>
> no, it would mean something around 12h. Depending on the packages.


400 packages of which gcc and gnome ones is more than 12h....

> if you decide to modify the use flags when changing profile it's the best
> > time....
>
> yeah, check which flags changed, and which ones you really need. That way
> you
> might be able to cut down the amount of packages.
>
> > so my advice is the following:
> > 1. take some time to look at the use flags (emerge ufed and see a
> > description of them and also add/remove them from the ufed gui in
> > make.conf)
> > 2. add LDFLAGS="--as-needed" into make.conf
>
> really, don't do it.


really do it!!!! the flag works very well and doesn't give any breakage
anymore....  the packages that are broken by this flags have all ldflags
removed in the ebuild so there's no reason to not use it.

> > Total: 478 packages (1 upgrade, 396 downgrades, 14 new, 1 in new slot,
> > > 66 reinstalls, 5 blocks), Size of downloads: 480,074 kB
>
> check your keywords - and blockers are easily solved. Usually you need to
> unmerge something. And the blocking ebuild tells you what.
>
>
> And agtdino and Beso:
>
> DO NOT TOP POST.
>
> This is not a Windows mailing list.


this is how  web gmail works when replying.

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


-- 
dott. ing. beso

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

Re: [gentoo-amd64] madwifi-ng not compile in amd64

[agtdino]

After a few days I have now the system in a stable branch, and my
profile is now apoint to the correct 2007.0 :-) 

Now I'm more stable (xD) than when I decide to deinstall debian-amd64
and install gentoo-amd64. In two, I probe testing or unnestable
packages, because there was the only ( in there moment  ) way to probe
this architecture. 

Thank's for the tip, regard's 


El mié, 30-01-2008 a las 09:18 +0100, Beso escribió:
> 
> 
> 2008/1/30, Volker Armin Hemmann
> <volker.armin.hemmann@tu-clausthal.de>:
>         On Mittwoch, 30. Januar 2008, Beso wrote:
>         > the real problem stands in the keyword.... the amd64 would
>         downgrade a lot
>         > of stuff.... before doing it it's better to identify the
>         normal programs,
>         > like kde, gnome, and similar and let them be for the moment
>         as ~amd64....
>         > but at least stuff like, gcc, glibc, baselayout, kernel and
>         some other base
>         > stuff should stay on the amd64 branch.... you won't be able
>         to downgrade
>         > glibc so that one for the moment would stay on the unstable
>         branch.... but
>         > if you don't feel in the mood to downgrade cause the  ~amd64
>         being to
>         > amd64, then just update the profile and you should see
>         something like 100
>         > packages....
>         > also adding --as-needed as LDFLAGS should help you save some
>         time in
>         > recompiling stuff....
>         
>         yeah - no. Don't do it. It breaks stuff.
> 
> it doesn't anymore. it works very well.
>  
> 
>         > the 2gb of ccache would help, but not a lot.... 400+
>         packages would mean
>         > about 3-4 days on a amd64 2ghz single core, so prepare for a
>         looong time of
>         > compile time.... also the 5 blockers are not good and should
>         be fixed in
>         > some way before proceeding to the recompile....
>         
>         no, it would mean something around 12h. Depending on the
>         packages.
> 
> 400 packages of which gcc and gnome ones is more than 12h....
> 
> 
>         > if you decide to modify the use flags when changing profile
>         it's the best
>         > time....
>         
>         yeah, check which flags changed, and which ones you really
>         need. That way you
>         might be able to cut down the amount of packages.
>         
>         > so my advice is the following:
>         > 1. take some time to look at the use flags (emerge ufed and
>         see a
>         > description of them and also add/remove them from the ufed
>         gui in
>         > make.conf)
>         > 2. add LDFLAGS="--as-needed" into make.conf
>         
>         really, don't do it.
> 
> really do it!!!! the flag works very well and doesn't give any
> breakage anymore....  the packages that are broken by this flags have
> all ldflags removed in the ebuild so there's no reason to not use it. 
> 
> 
>         > > Total: 478 packages (1 upgrade, 396 downgrades, 14 new, 1
>         in new slot,
>         > > 66 reinstalls, 5 blocks), Size of downloads: 480,074 kB
>         
>         check your keywords - and blockers are easily solved. Usually
>         you need to
>         unmerge something. And the blocking ebuild tells you what.
>         
>         
>         And agtdino and Beso:
>         
>         DO NOT TOP POST.
>         
>         This is not a Windows mailing list.
> 
> this is how  web gmail works when replying.
> 
> 
>         --
>         gentoo-amd64@lists.gentoo.org mailing list
>         
> 
> 
> 
> -- 
> dott. ing. beso

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

Re: [gentoo-amd64] madwifi-ng not compile in amd64

[Beso]

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

no problem. if you need other help ask on the forums or here. glad we could
help you.

2008/1/31, agtdino <agtdino@teleline.es>:
>
> After a few days I have now the system in a stable branch, and my
> profile is now apoint to the correct 2007.0 :-)
>
> Now I'm more stable (xD) than when I decide to deinstall debian-amd64
> and install gentoo-amd64. In two, I probe testing or unnestable
> packages, because there was the only ( in there moment  ) way to probe
> this architecture.
>
> Thank's for the tip, regard's
>
>
> El mié, 30-01-2008 a las 09:18 +0100, Beso escribió:
> >
> >
> > 2008/1/30, Volker Armin Hemmann
> > <volker.armin.hemmann@tu-clausthal.de>:
> >         On Mittwoch, 30. Januar 2008, Beso wrote:
> >         > the real problem stands in the keyword.... the amd64 would
> >         downgrade a lot
> >         > of stuff.... before doing it it's better to identify the
> >         normal programs,
> >         > like kde, gnome, and similar and let them be for the moment
> >         as ~amd64....
> >         > but at least stuff like, gcc, glibc, baselayout, kernel and
> >         some other base
> >         > stuff should stay on the amd64 branch.... you won't be able
> >         to downgrade
> >         > glibc so that one for the moment would stay on the unstable
> >         branch.... but
> >         > if you don't feel in the mood to downgrade cause the  ~amd64
> >         being to
> >         > amd64, then just update the profile and you should see
> >         something like 100
> >         > packages....
> >         > also adding --as-needed as LDFLAGS should help you save some
> >         time in
> >         > recompiling stuff....
> >
> >         yeah - no. Don't do it. It breaks stuff.
> >
> > it doesn't anymore. it works very well.
> >
> >
> >         > the 2gb of ccache would help, but not a lot.... 400+
> >         packages would mean
> >         > about 3-4 days on a amd64 2ghz single core, so prepare for a
> >         looong time of
> >         > compile time.... also the 5 blockers are not good and should
> >         be fixed in
> >         > some way before proceeding to the recompile....
> >
> >         no, it would mean something around 12h. Depending on the
> >         packages.
> >
> > 400 packages of which gcc and gnome ones is more than 12h....
> >
> >
> >         > if you decide to modify the use flags when changing profile
> >         it's the best
> >         > time....
> >
> >         yeah, check which flags changed, and which ones you really
> >         need. That way you
> >         might be able to cut down the amount of packages.
> >
> >         > so my advice is the following:
> >         > 1. take some time to look at the use flags (emerge ufed and
> >         see a
> >         > description of them and also add/remove them from the ufed
> >         gui in
> >         > make.conf)
> >         > 2. add LDFLAGS="--as-needed" into make.conf
> >
> >         really, don't do it.
> >
> > really do it!!!! the flag works very well and doesn't give any
> > breakage anymore....  the packages that are broken by this flags have
> > all ldflags removed in the ebuild so there's no reason to not use it.
> >
> >
> >         > > Total: 478 packages (1 upgrade, 396 downgrades, 14 new, 1
> >         in new slot,
> >         > > 66 reinstalls, 5 blocks), Size of downloads: 480,074 kB
> >
> >         check your keywords - and blockers are easily solved. Usually
> >         you need to
> >         unmerge something. And the blocking ebuild tells you what.
> >
> >
> >         And agtdino and Beso:
> >
> >         DO NOT TOP POST.
> >
> >         This is not a Windows mailing list.
> >
> > this is how  web gmail works when replying.
> >
> >
> >         --
> >         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: 7193 bytes --]

Re: [gentoo-amd64] madwifi-ng not compile in amd64

[Beso]

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

this is not true!!!! i have madwifi-ng-0.9.3.3 updated on 17 jan 2008
compiled on 2.6.24 and it works very well (with sandbox disabled).

2008/1/29, Steev Klimaszewski <steev@gentoo.org>:
>
>
> On Tue, 2008-01-29 at 09:17 +0100, agtdino wrote:
> > Hi,
> Hi!
>
> I am the maintainer of madwifi-ng - it is currently incompatible (well
> there is a patch in bugzilla however it is not the proper fix) with
> 2.6.24 - if you absolutely must have 2.6.24, then you will need to
> compile the madwifi modules from svn, until they put out a release
> (which *should* be soon, they are only waiting on two patches) that is
> compatible with 2.6.24.
>
> Sorry for your troubles, for now, unless it is absolutely necessary, I
> would suggest continuing using 2.6.23-r6
>
> -- Steev
>
> --
> gentoo-amd64@lists.gentoo.org mailing list
>
>


-- 
dott. ing. beso

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

Re: [gentoo-amd64] madwifi-ng not compile in amd64

[agtdino]

I've 2.6.23-gentoo-r5 and all is now ok! 

*  net-wireless/madwifi-ng-tools
      Latest version available: 0.9.3.3
      Latest version installed: 0.9.3.3
      Size of files: 3,408 kB
      Homepage:      http://www.madwifi.org/
      Description:   Next Generation tools for configuration of Atheros
based IEEE 802.11a/b/g wireless LAN cards
      License:       || ( BSD GPL-2 )

Now I've madwifi-ng-tools too

Than'k for the tip, for me is solved. 


El mar, 29-01-2008 a las 09:47 +0000, Beso escribió:
> this is not true!!!! i have madwifi-ng-0.9.3.3 updated on 17 jan 2008
> compiled on 2.6.24 and it works very well (with sandbox disabled).
> 
> 2008/1/29, Steev Klimaszewski <steev@gentoo.org>:
>         
>         On Tue, 2008-01-29 at 09:17 +0100, agtdino wrote:
>         > Hi,
>         Hi!
>         
>         I am the maintainer of madwifi-ng - it is currently
>         incompatible (well
>         there is a patch in bugzilla however it is not the proper fix)
>         with
>         2.6.24 - if you absolutely must have 2.6.24, then you will
>         need to
>         compile the madwifi modules from svn, until they put out a
>         release
>         (which *should* be soon, they are only waiting on two patches)
>         that is
>         compatible with 2.6.24.
>         
>         Sorry for your troubles, for now, unless it is absolutely
>         necessary, I
>         would suggest continuing using 2.6.23-r6
>         
>         -- Steev
>         
>         --
>         gentoo-amd64@lists.gentoo.org mailing list
>         
> 
> 
> 
> -- 
> dott. ing. beso

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

[gentoo-amd64] Good Postfix / Mail Server how to...

[Mateusz Mierzwinski]

Hello!

I just want to ask if anyone know any good howto for Gentoo about 
Postfix and simple mail server? I've seen current howto on gentoo-wiki 
and it's old. Any tips or links?
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Good Postfix / Mail Server how to...

[Mark Haney]

Mateusz Mierzwinski wrote:
> Hello!
> 
> I just want to ask if anyone know any good howto for Gentoo about 
> Postfix and simple mail server? I've seen current howto on gentoo-wiki 
> and it's old. Any tips or links?

Not sure exactly what you need with postfix, but this is the one I used 
on a non-gentoo system and it worked pretty well for me.

http://www.gentoo.org/doc/en/virt-mail-howto.xml


-- 
Libenter homines id quod volunt credunt -- Caius Julius Caesar


Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415

Call (866) ERC-7110 for after hours support
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Good Postfix / Mail Server how to...

[Mateusz Mierzwinski]

I need only simple email server gentoo based on amd64 arch. Thanks for 
info ;)

Mark Haney pisze:
> Mateusz Mierzwinski wrote:
>> Hello!
>>
>> I just want to ask if anyone know any good howto for Gentoo about 
>> Postfix and simple mail server? I've seen current howto on 
>> gentoo-wiki and it's old. Any tips or links?
>
> Not sure exactly what you need with postfix, but this is the one I 
> used on a non-gentoo system and it worked pretty well for me.
>
> http://www.gentoo.org/doc/en/virt-mail-howto.xml
>
>

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

Re: [gentoo-amd64] Good Postfix / Mail Server how to...

[Isaac Conway]

Although not Gentoo based, this is one of the clearest and most
straightforward setups I have seen.  It really fully utilizes a lot of
the cool features in each package.  Config is basically identical, but
the install parts are easier on Gentoo.

http://www.wistful.net/wiki/Ed's_FreeBSD_Virtual_Mail_How-To

Isaac Conway

Mateusz Mierzwinski wrote:
> I need only simple email server gentoo based on amd64 arch. Thanks for
> info ;)
>
> Mark Haney pisze:
>> Mateusz Mierzwinski wrote:
>>> Hello!
>>>
>>> I just want to ask if anyone know any good howto for Gentoo about
>>> Postfix and simple mail server? I've seen current howto on
>>> gentoo-wiki and it's old. Any tips or links?
>>
>> Not sure exactly what you need with postfix, but this is the one I
>> used on a non-gentoo system and it worked pretty well for me.
>>
>> http://www.gentoo.org/doc/en/virt-mail-howto.xml
>>
>>
>


-- 
Isaac D. Conway
http://www.conwaynetworks.com

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

Re: [gentoo-amd64] Good Postfix / Mail Server how to...

[Peter Humphrey]

On Monday 28 January 2008 23:24:47 Mark Haney wrote:
> Mateusz Mierzwinski wrote:
> > Hello!
> >
> > I just want to ask if anyone know any good howto for Gentoo about
> > Postfix and simple mail server? I've seen current howto on gentoo-wiki
> > and it's old. Any tips or links?
>
> Not sure exactly what you need with postfix, but this is the one I used
> on a non-gentoo system and it worked pretty well for me.
>
> http://www.gentoo.org/doc/en/virt-mail-howto.xml

Isn't there something for the simple case of a home network with a few 
machines passing admin messages among themselves? The one you quote is way 
over the top for that case, though no doubt good at what it does do.

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