I forgot that VMware is using Fusion MPT driver..
I got the right module name by running lspci -v for Fusion MPT,
I'm recompiling a kernel now.
Thanks for your help, KernelOfTruth!!


ok, back againSaundersx wrote:One thing I have noticed since upgrading to 2.6.31-zen2
hedgehog / $ modprobe it87
FATAL: Error inserting it87 (/lib/modules/2.6.31-zen2/kernel/drivers/hwmon/it87.ko): Device or resource busy
Anyone else having this?
Code: Select all
pnpacpi=offCode: Select all
acpi_enforce_resources=noCode: Select all
acpi_enforce_resources=lax
I did some reading as well. Now using "acpi_enforce_resources=lax" and it seems to work fine.mantoo wrote:ok, back againSaundersx wrote:One thing I have noticed since upgrading to 2.6.31-zen2
hedgehog / $ modprobe it87
FATAL: Error inserting it87 (/lib/modules/2.6.31-zen2/kernel/drivers/hwmon/it87.ko): Device or resource busy
Anyone else having this?
1st workaround:as kernelparameter, which i found hereCode: Select all
pnpacpi=off
2nd, and maybe better workaround:as kernel parameter, as suggested hereCode: Select all
acpi_enforce_resources=no
even switching to atk0110 as sensordriver was suggested. dont know which one of the approaches fits best, as i couldn´t test´em.
~~~~~~~~~
edit:
and some additional related stuff talking abount lm_sensors and patches/ebuilds here
~~~~~~~~~
my mobo is a asus p5v2d-mx btw
~~~~~~~~~
edit2:
andshould work tooCode: Select all
acpi_enforce_resources=lax
~~~~~~~~~
3rd and last edit:
one more time i should´ve trust a bit more in this powerful forum, as the problem is handled in that thread...![]()




In the bug you mention that you are looking at including TuxOnIce back in to zen-sources. Is that true?cheater1034 wrote:Hey guys, PLEASE vouch for zen on bugs.gentoo.org for inclusion into portage:
http://bugs.gentoo.org/show_bug.cgi?id=288512
I'm sure the more interest it shows the more likely it will get into gentoo (which many people would want, because they would get ebuilds again)

Code: Select all
rzscontrol /dev/ramzswap0 --init
swapon -p 1 /dev/ramzswap0
Ahhh man! Reiser4 is broken? GRRRR! I have the Btrfs guys telling me to bump to 2.6.32 and that zen-sources has the latest btrfs pulled from git. I'm looking to test how the little panic once disk is 90% full works out, but my root is on R4cheater1034 wrote:Hey guys, bunch of great new things
1. BFQ is the default i/o scheduler in ALL the trees (2.6.30/2.6.31, unstable)
- Test it, fabio is interested in both bug reports and any benchmarks/results!!!!! so give them to me and i can forward them
2. new 2.6.31 patch released in the past few days (new one will follow shortly due to alsa and drm fixes in git)
3. new 2.6.30 patch released (includes bfs 303 and 2.6.30.9)
4. new 2.6.32-rc3-zen1 patch released (YES! it's very solid and builds with the allmodconfig A OK, reiser4 is broken however)
BFS/BFQ make zen more geared for desktop usage than ever before!
Plus, now is the time to try zen if you haven't, it's growing in popularity - a few devs want their patches in to get tested and forwarded results/bug reports - so do it! I know people use it on several distributions now (varying from momongo to sourcemage to arch to debian to fedora to ubuntu to sidux to gentoo to exherbo to yoper) - quite impressive!
Code: Select all
* [new branch] btrfs -> origin/btrfs
DigitalCorpus try to revert reiser4 from mmotm and replace it with the one from 2.6.31 (it worked at least with 2.6.31-zen2 for me - I manually removed itDigitalCorpus wrote:Ahhh man! Reiser4 is broken? GRRRR! I have the Btrfs guys telling me to bump to 2.6.32 and that zen-sources has the latest btrfs pulled from git. I'm looking to test how the little panic once disk is 90% full works out, but my root is on R4cheater1034 wrote:Hey guys, bunch of great new things
1. BFQ is the default i/o scheduler in ALL the trees (2.6.30/2.6.31, unstable)
- Test it, fabio is interested in both bug reports and any benchmarks/results!!!!! so give them to me and i can forward them
2. new 2.6.31 patch released in the past few days (new one will follow shortly due to alsa and drm fixes in git)
3. new 2.6.30 patch released (includes bfs 303 and 2.6.30.9)
4. new 2.6.32-rc3-zen1 patch released (YES! it's very solid and builds with the allmodconfig A OK, reiser4 is broken however)
BFS/BFQ make zen more geared for desktop usage than ever before!
Plus, now is the time to try zen if you haven't, it's growing in popularity - a few devs want their patches in to get tested and forwarded results/bug reports - so do it! I know people use it on several distributions now (varying from momongo to sourcemage to arch to debian to fedora to ubuntu to sidux to gentoo to exherbo to yoper) - quite impressive!. cheater1034, could you please post when this gets fixed? I'm extremely anxious....
Okay so I just updated zen-stable and I seeWhat version or git pull is this of btrfs?Code: Select all
* [new branch] btrfs -> origin/btrfs
I'm seeing this too.tranquilcool wrote:LD .tmp_vmlinux1
kernel/built-in.o: In function `__mutex_lock_interruptible_slowpath':
mutex.c:(.sched.text+0x14db): undefined reference to `__schedule'
kernel/built-in.o: In function `__mutex_lock_slowpath':
mutex.c:(.sched.text+0x16d6): undefined reference to `__schedule'
kernel/built-in.o: In function `__mutex_lock_killable_slowpath':
mutex.c:(.sched.text+0x1842): undefined reference to `__schedule'
make: *** [.tmp_vmlinux1] Error 1
latest zen 2.6.30-zen6 with bfs/bfq checkout errors.

+1cheater1034 wrote:Hey guys, PLEASE vouch for zen on bugs.gentoo.org for inclusion into portage:
http://bugs.gentoo.org/show_bug.cgi?id=288512
I'm sure the more interest it shows the more likely it will get into gentoo (which many people would want, because they would get ebuilds again)
Am using a 2Gb ramdisk for portage temp and ccache and i must say it makesAnt_P wrote:Will compcache ever work with BFS?
If not I might just go out and buy two extra RAM sticks instead
Code: Select all
vger ~ # genlop -t glibc
* sys-libs/glibc
Tue Sep 22 15:35:07 2009 >>> sys-libs/glibc-2.10.1
merge time: 1 hour, 58 minutes and 26 seconds.
Tue Sep 22 18:15:39 2009 >>> sys-libs/glibc-2.10.1
merge time: 7 minutes and 39 seconds.
you most be doing something wrong:Jupiter1TX wrote: Am using a 2Gb ramdisk for portage temp and ccache and i must say it makes
a HUGE difference as seen in this before and after.Code: Select all
vger ~ # genlop -t glibc * sys-libs/glibc Tue Sep 22 15:35:07 2009 >>> sys-libs/glibc-2.10.1 merge time: 1 hour, 58 minutes and 26 seconds. Tue Sep 22 18:15:39 2009 >>> sys-libs/glibc-2.10.1 merge time: 7 minutes and 39 seconds.
without ccache and tmpfs only on and E6600 (Core2Duo @stock clock, 2.4 GHz)Mon May 18 20:16:19 2009 >>> sys-libs/glibc-2.10.1
merge time: 32 minutes and 50 seconds.
Mon Aug 10 12:52:50 2009 >>> sys-libs/glibc-2.10.1
merge time: 23 minutes and 8 seconds.
Mon Aug 10 14:10:42 2009 >>> sys-libs/glibc-2.10.1
merge time: 25 minutes and 20 seconds.

Am using -j8. In the first emerge i was booted from the NEO cd.kernelOfTruth wrote:you most be doing something wrong:Jupiter1TX wrote: Am using a 2Gb ramdisk for portage temp and ccache and i must say it makes
a HUGE difference as seen in this before and after.Code: Select all
vger ~ # genlop -t glibc * sys-libs/glibc Tue Sep 22 15:35:07 2009 >>> sys-libs/glibc-2.10.1 merge time: 1 hour, 58 minutes and 26 seconds. Tue Sep 22 18:15:39 2009 >>> sys-libs/glibc-2.10.1 merge time: 7 minutes and 39 seconds.
without ccache and tmpfs only on and E6600 (Core2Duo @stock clock, 2.4 GHz)Mon May 18 20:16:19 2009 >>> sys-libs/glibc-2.10.1
merge time: 32 minutes and 50 seconds.
Mon Aug 10 12:52:50 2009 >>> sys-libs/glibc-2.10.1
merge time: 23 minutes and 8 seconds.
Mon Aug 10 14:10:42 2009 >>> sys-libs/glibc-2.10.1
merge time: 25 minutes and 20 seconds.
try to raise MAKEOPTS at least to -j5 that should make it even faster
Code: Select all
CFLAGS="-O2 -march=native -msse4 -pipe"
LDFLAGS="-Wl,--hash-style=gnu -Wl,--sort-common -Wl,--as-needed"

6Gb of ramDigitalCorpus wrote:How much RAM do you have?
What filesystem is /usr/portage residing?
What is your root filesystem?
What I/O scheduler do you use?
-msse4 should be implied by -march=native
Your LDFLAGS and CFLAGS are sane.

Code: Select all
hdparm -t /dev/hd* or sd*
heh, yea not very fastDigitalCorpus wrote:what are the outputs offor each or your hard drives?Code: Select all
hdparm -t /dev/hd* or sd*
Code: Select all
vger ~ # hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 226 MB in 3.02 seconds = 74.72 MB/sec

Code: Select all
echo 1 > /proc/sys/vm/drop_caches
time emerge -pev @system @world
Total: 893 packages (7 upgrades, 2 downgrades, 884 reinstalls), Size of downloads: 1,155,829 kBDigitalCorpus wrote:Those are the basic for what will slow you down. Unless Ext4 suffers major degradation from fragmentation, I'm not sure why you have that much of a slow down. Try one more thing for me please:On a Reiser4 partition I get about 16 secondsCode: Select all
echo 1 > /proc/sys/vm/drop_caches time emerge -pev @system @world
Code: Select all
Total: 893 packages (893 reinstalls), Size of downloads: 1,140,966 kB
Portage tree and overlays:
[0] /usr/portage
[1] /usr/portage/local/layman/redspot
[2] /usr/portage/local/layman/desktop-effects
real 0m11.388s
user 0m11.128s
sys 0m0.127s
