Re: various rants about 7-currnet on AMD64

From: Aryeh Friedman <aryeh.friedman_at_gmail.com>
Date: Mon, 1 Oct 2007 08:20:15 +0000
> > intel p35 mobo (ihc9)
>
> This is an incredibly new chipset.  Heck, there's even reports of
> driver issues on Windows.  I don't doubt the P35/ICH9 will be fantastic
> (I'm a big advocate of Intel chipsets), but right now it *is* very new,
> and you should keep that in mind.
>
> I'd also like to know what motherboard vendor you went with.  You'd be
> surprised how many issues are caused by BIOSes; there isn't anything you
> or anyone else can do about BIOS problems, though.  It's all up to the
> mainboard vendor.

MSI Neo-F ... some sort of AMI bios (the OEM version number makes no
sense and I doubt if it can be translated to a AMI version number
[1.1])... here are the feaures  (from vendors product description):

 	CPU
  	  	
• 	Supports Socket 775 for Intel Core2 Extreme, Core2 Duo, Pentium 4
(Prescott, P4EE), Pentium D, Pentium XE/Celeron D processors in LGA
775 package
• 	Supports FSB 800/1066/1333 MHz
• 	Supoprts Intel 05B/05A and 04B/04A processors
• 	Supoprts EIST techonology
• 	Supports Intel Hyper-Threading (HT) Technology
• 	Supports Intel Quad Core Technology to 1333MHz and up
  	  	
  	Chipset
  	  	
Intel(r) P35 Chipset
• 	Supports FSB 800MHz, 1066MHz & 1333MHz
• 	Support Dual channel DDR2 667/800 memory interface up to 8GB
• 	Support Dual PCI Express 16X interface
  	
Intel(r) ICH9 Chipset
• 	Integrated Hi-Speed USB 2.0 controller, 480Mb/sec, 12ports
• 	4 Serial ATAII ports w/ transfer rate up to 3Gb/s
• 	PCI Master v 2.3, I/O ACPI 2.0 Compliant
• 	Integrated AHCI controller
  	  	
  	FSB
  	  	
• 	Support FSB 800MHz, 1066MHz & 1333MHz
  	  	
  	Main Memory
  	  	
• 	Supports 4 unbuffered DIMM of 1.8 Volt DDR2 SDRAM
• 	Supports up to 8GB memory size
• 	Support Dual Channel DDR2 667/800MHz and up (Intel P35 chipset
supports up to DDR2-800 officially. For DDR2 800+, manually BIOS
adjustment is needed.
  	  	
  	Slots
  	  	
• 	One PCI Express 16X slots(PCI Express Bus SPEC V1.0a compliant;
supports CrossFire Technology)
• 	Three PCI Express 1X slot
• 	Two PCI 2.3 32-bit Master PCI Bus slots. (support 3.3v/5v PCI bus interface)
  	  	
  	On-Board IDE
  	  	
One Ultra DMA 66/100/133 IDE controller integrated in Marvell 88SE6111
• 	Supports PIO, Bus Master operation modes
• 	Can connect up to 2 Ultra ATA 100 drives
  	
Serial ATAII controller integrated in ICH9 and Marvell 88SE6111
• 	Up to 300MB/s transfer speed
• 	Can connect up to 5 Serial ATA II drives (4 internal drives from
ICH9, 1 drive from 88SE6111)
  	  	
  	On-Board Peripherals
  	  	



• 	1 floppy port supports 1 FDD with 360K, 720K, 1.2M, 1.44M and 2.88Mbytes
• 	1 Serial port
• 	1 parallel port supports SPP/EPP/ECP mode
• 	12 USB 2.0 ports (Rear x 4/** Front x 8)(** Front USB ports are
supported by pin-out)
• 	1 6-in-1 audio jack (S/SPDIF out)
• 	2 PS/2 connectors
• 	1 LAN RJ45 connector
  	  	
  	Audio
  	  	
High Definition link controller integrated in Intel ICH9 chip
• 	Audio codec Realtek 888
• 	Compliance with Azalia 1.0 spec
• 	Flexible 8 Ch. audio with jack sensing
  	  	
  	LAN
  	  	
• 	Realtek RTL8111B PCI-Express Gb LAN Controller
  	  	
  	BIOS
  	  	
• 	The mainboard BIOS provides "Plug & Play" BIOS which detects the
peripheral devices and expansion cards of the board automatically.
• 	The mainboard provides a Desktop Management Interface(DMI) function
which records your mainboard specifications.

> > * Many TCP/IP stack issues
>
> I *really* want to hear about this.  If there's any evidence you can
> provide, I'm all ears.  I'm not doubting your claims, I just want to
> know what you experienced.
>
> Additionally, since you didn't state what PHY and NIC are used on your
> motherboard, it's hard for me to accept that there's IP stack problems.
> What PHY and NIC is on the motherboard?

Have no direct physical evidence any more but see thread between me
and kris on -questions and here is the dmesg output for the phy and
nic:

re0: <RealTek 8168/8111B PCIe Gigabit Ethernet> port 0xe800-0xe8ff mem
0xfcfff000-0xfcffffff irq 17 at device 0.0 on pci4
re0: Using 2 MSI messages
miibus0: <MII bus> on re0
rgephy0: <RTL8169S/8110S media interface> PHY 1 on miibus0
rgephy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-FDX, auto
re0: Ethernet address: 00:19:db:b5:f8:0f
re0: [FILTER]
re0: [FILTER]

I am on 100basetx.

Related:

in all versions of freebsd I have tried the re0 interface doesn't come
up by default I have to force it up with "ifconfig re0 up" before
assigning addrs (both static and dhcp)

On all versions of 7-current (i386 and amd64) I get error messages
like this on the console all the time:

TCP: [217.230.39.58]:1145 to [67.84.39.90]:6881 tcpflags 0x18<PUSH,ACK>
; tcp_do_segment: FIN_WAIT_2: Received data after socket was closed, sending RST
 and removing tcpcb
TCP: [217.230.39.58]:1145 to [67.84.39.90]:6881 tcpflags 0x11<FIN,ACK>; syncache
_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spo
ofed)
TCP: [211.55.152.196]:55206 to [67.84.39.90]:6881 tcpflags 0x18<PUSH,ACK>; tcp_d
o_segment: FIN_WAIT_2: Received data after socket was closed, sending RST and re
moving tcpcb
TCP: [211.55.152.196]:55206 to [67.84.39.90]:6881 tcpflags 0x11<FIN,ACK>; syncac
he_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably s
poofed)


>

> > 7-CURRENT i386 --
> >
> > * Horrid performence under default kernel needed to switch to
> > ULE/IPI_PREMEPTION/DEVICE_POLLING
>
> Expand on "horrid" if you could.  I run CURRENT i386 on my home machine,
> and I've never had any need for device polling (in fact, I've never had
> any need for it *ever* -- the one time I tried it back in the 5.x days,
> the system became absurdly sluggish to keyboard input, serial I/O, or
> anything else.  Network I/O was just fine though.)

Without ULE and IPI_PREMEPTION it was slower then my p4 2.8 device
polling I tossed in for good measure and can't tell the diff one way
or the other.

>
> > 7-CURRENT amd64
> >

> > Misc Rants:
> >
> > CPUTYPE naming --
> >
> >     For people who have been around for a while (read mid-90's) and
> > have never used any AMD mobo's we are used to "historical" differences
> > between early pentiums and amd equivs (for that reason I have never
> > bought a AMD machine)... so calling the 64bit x86 architure amd64 is
> > confusing and misleading.
>
> Okay, you're confusing two things here: the "amd64" nomenclature used
> on FreeBSD to describe the 64-bit OS, and CPUTYPE, which is used mainly
> by gcc (and some portions of the /usr/src framework) to determine what
> processor architecture to optimise for.

Ok thanks for the clarification.


>
> This argument is flawed, in my opinion.
>
> I think a more appropriate phrase would be: "amd64 should be recommended
> for anyone that uses 4GB of RAM or more, and doesn't want to be hit by
> performance penalties induced by PAE on i386".

See thread in -questions... PAE is broken for my hw.
Received on Mon Oct 01 2007 - 06:20:18 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:18 UTC