Thanks, thats a big help. At least I now know not to waste my time
trying to make one box behave like the other :-). I'll see if I can find
anything reasonable, but I suspect I'm out of my depth skillwise. I guess
its either Linux or single CPU and may end up being single CPU. FreeBSD with
kernel cruft such as ktrace and IPV6 removed does ~700 Mbps on a non SNMP
kernel at about %30 CPU, the dual Linux kernel is using almost all of one
CPU at a slightly slower throughput (of course it also then has the other
CPU to play with).
Peter Van Epp / Operations and Technical Support
Simon Fraser University, Burnaby, B.C. Canada
>
> Peter Van Epp wrote:
> > Before I try and beat up my vendor more :-) are there known problems
> > with APIC I/O on dual Athelons with FreeBSD 4-5 Release? I have a pair of
> > Tyan Thunder K7X S2468NG Motherboards each with 512 Megs of ECC ram and
> > dual MP1900 (1.6 Gig) AMD Athelon CPUs. Redhat Linux 7.3 (out of our beowolf
> > cluster which is 96 nodes of dual Athelons) runs fine on both boxes. FreeBSD
> > 4.5-Release runs fine on one of them and fails most of the time during boot
> > on the other one. Our Linux expert told me there were a lot of problems with
> > the APIC I/O support for the Athelons on Linux (and in fact he ran for a long
> > time without APIC I/O enabled which doesn't appear to be an option on FreeBSD).
> > He suggests that since it was intermittent that may be in fact what I'm seeing
> > here and why one board seems to work when the other doesn't (as opposed to one
> > board/CPU has a hardware problem). The vendor has swapped the Motherboard on
> > the problem machine without effect. Before continuing to chase hardware problems
> > (which may not exist) I thought I'd ask if there are known issues with
> > Athelons.
>
> Your Linux guy was right: it's an Athlon problem.
>
> Please see the release notes for the most recent Linux release,
> which describe somewhat what Linux changed in order to get
> around the problem.
>
> For a more detailed approach that you could then apply to FreeBSD,
> you will need access to the unpublished vendor Errata and/or to
> look at the Linux kernel source code VM system changes between
> the release that had the problem, and the release that didn't.
>
> -- Terry
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message