Zac Medico wrote:
> Linuxthreads are the *old* linux threading library and nplt
> is the *new* linux threading library. I've been using
> nptlonly for a couple months now with no noticeable problems.
> AFAICT it's a "drop in" replacement for linuxthreads and it
> supposed to give superior perf
Zac Medico wrote:
> Yep, here's another forum thread and an open bug:
>
> http://forums.gentoo.org/viewtopic-t-343187-highlight-.html
> http://bugs.gentoo.org/show_bug.cgi?id=90236
>
> I can tell you that it will work with i586 CHOST and
> USE="nptl nptlonly".
Hmm. I guess, on Linux Linux threa
Daniel Heemann wrote:
> Seems to be a known and not yet resolved problem on i586 hosts.
> http://forums.gentoo.org/viewtopic-t-329143-highlight-pthreadi
> nitialize+res.html
Daniel, thank your for this link. It will have saved me a lot of time...
--
Alex
--
gentoo-user@gentoo.org mailing list
Zac Medico wrote:
> Alexander Veit wrote:
> > Unfortunately, on my machine, it takes a long long time for
> > the first 3K files to be built...
> >
> > BTW is there a way to resume the build process at the point
> > where the error occurred? emerge --resume doe
Richard Fish wrote:
> [...]
> >MAKEOPTS="-j3"
> >
> >
>
> -j3 causes many build problems for many packages that build internal
> libraries and then try to link against them. -j1 is much safer.
OK, now make runs with -j1.
Unfortunately, on my machine, it takes a long long time for the first 3
Hi,
When I try to emerge -u world, the only package that's going to be updated
is glibc. However the build fails with the following error:
--- snip ---
/var/tmp/portage/glibc-2.3.5/work/build-default-i586-pc-linux-gnu-linuxthrea
ds/linuxthreads/libpthread_pic.a(pthread.os)(.text+0x1cd): In functi
Richard Fish wrote:
> I'm now in agreement with the others in this thread that your best
> chance is to fiddle with the kernel options in 2.6, maybe
> using the 2.4 kernel as a reference.
I will try. BTW on the kernel mailinglist I found some evidence that 2.6 may
have disk performance problems,
Richard Fish wrote:
> The geometry line above not-withstanding, I think the 2.4
> kernel on your old Knoppix disk doesn't support lba48
> (disks >137GB) addressing, which is changing the equation
> considerably on accessing the disk.
>
> Try going into the BIOS and change the disk access mode fr
Andrew Gaydenko wrote:
> I have
>
> readahead= 256 (on)
readahead 8 is even slower (15.48MB/sec). In the meantime I wonder if the
buffered-read value reported by hdparm has any significance. Perhaps I
should run some real benchmarks.
Alex
--
gentoo-user@gentoo.org mailing list
Robert G. Hays wrote:
> Well, we know what the drive can do; at least, At Least!, so
> I am left suspecting that the Gentoo kernel does not have the
> best setup for the mobo, --or-- has something in there for
> safety that has the effect of slowing the throughput down;
> make [ menuconfig | xmew
Richard Fish wrote:
> Alexander Veit wrote:
>
> > geometry = 4867/255/63, sectors = 78198750, start = 0
> > geometry = 65535/16/63, sectors = 4003776, start = 0
> >
> >
>
> Well, the obvious thing for me is the difference in the drive
> geo
Robert G. Hays wrote:
> In the Gentoo manual, in the early stages, it mentions -tT; nearby &
> below, it mentions another hdparm line to speed things up.
> Did you try that line?
I've tried it. The result is 19.11 MB/sec.
But why are the values posted before so different? hdparm -vid /dev/hda
Hello,
I've built Gentoo from stage 1 with the 2.6.11-gentoo-r5 kernel. The
hardware is a VIA EPIA PD6000E board (Samuel 2 processor).
hdparm -t /dev/hda reports slow buffered disk reads compared with values
that were measured with Knoppix 3.4 (2.4.23 kernel). The file sytem is xfs.
Gentoo root
13 matches
Mail list logo
