FreeBSD 8.4-RC3 is now available

[Glen Barber]

The third RC build of the 8.4-RELEASE release cycle is now available
on the FTP servers for the amd64, i386, and pc98 architectures. The
SHA256/MD5 sums are tacked on to the bottom of this message. The ISO
images and, for architectures that support it, the memory stick images
are available here:

ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/8.4/

(or any of the FreeBSD mirror sites).

If you notice problems you can report them through the normal GNATS PR
system or here on the -stable mailing list.

If you would like to use SVN to do a source based update of an existing
system use "releng/8.4".

Changes between -RC2 and -RC3 include:

- Fix a bug that allows NFS clients to issue READDIR on files
- Update sendmail to 8.14.7
- Fix rtld(1) $ORIGIN length
- Fix randomly-changing default routes

The freebsd-update(8) utility supports binary upgrades of i386 and amd64
systems running earlier FreeBSD releases. Systems running earlier
FreeBSD releases can upgrade as follows:

# freebsd-update upgrade -r 8.4-RC3

During this process, FreeBSD Update may ask the user to help by merging
some configuration files or by confirming that the automatically performed
merging was done correctly.

# freebsd-update install

The system must be rebooted with the newly installed kernel before
continuing.

# shutdown -r now

After rebooting, freebsd-update needs to be run again to install the new
userland components:

# freebsd-update install

It is recommended to rebuild and install all applications if possible,
especially if upgrading from an earlier FreeBSD release, for example,
FreeBSD 7.x. Alternatively, the user can install misc/compat7x and other
compatibility libraries, afterwards the system must be rebooted into the
new userland:

# shutdown -r now

Finally, after rebooting, freebsd-update needs to be run again to remove
stale files:

# freebsd-update install

Checksums:

8.4-RC3 amd64:

SHA256 (FreeBSD-8.4-RC3-amd64-bootonly.iso) = 3ff93b3870287f51fa6f2a05c98898699af1646c6e90c35a9ae3f33d7fa80f8e
SHA256 (FreeBSD-8.4-RC3-amd64-disc1.iso) = 5ba207726007dab001c502c190b6bb354c845c6ed142f25c8a1164d631ebb9b1
SHA256 (FreeBSD-8.4-RC3-amd64-disc2.iso) = a6ef99e7547fa322d6494332c7c2db8dc54cfcb92450127094f3a67ea3340efd
SHA256 (FreeBSD-8.4-RC3-amd64-disc3.iso) = 44cc186f4258bdc15072d83f600ce6fd05cbe06dbe20240805093012161edbad
SHA256 (FreeBSD-8.4-RC3-amd64-dvd1.iso) = f3394e4a90995a0b845b87f7c407c7a96aeffca502c9b70735310dd1e53259e5
SHA256 (FreeBSD-8.4-RC3-amd64-livefs.iso) = 73aa1f6b78e7cbf6ba5d375783c282f752487e0ebdab2f38a9ab903652eaddb9
SHA256 (FreeBSD-8.4-RC3-amd64-memstick.img) = dc4f0004cc16c3e1f5f8adec51d2c8a039abf53ed9b7159e95c9a5ea75842f89
MD5 (FreeBSD-8.4-RC3-amd64-bootonly.iso) = d2d1d66db2d5f2e72c8c4a38dbd18312
MD5 (FreeBSD-8.4-RC3-amd64-disc1.iso) = 108cd0e0272400a3cf9021a818b56dca
MD5 (FreeBSD-8.4-RC3-amd64-disc2.iso) = 279b7aa8cec90c998c71425e37b8c4dc
MD5 (FreeBSD-8.4-RC3-amd64-disc3.iso) = 398a832d1982afa0d48876afab1e3279
MD5 (FreeBSD-8.4-RC3-amd64-dvd1.iso) = 23691d46cc7455fdd9b7c144923fd4eb
MD5 (FreeBSD-8.4-RC3-amd64-livefs.iso) = d569535aff66de3f3c74bd178a2f00c4
MD5 (FreeBSD-8.4-RC3-amd64-memstick.img) = 1bcea93744c2e8443335c153d9556ac0

8.4-RC3 i386:

SHA256 (FreeBSD-8.4-RC3-i386-bootonly.iso) = 099b1ce82ed0bcb7d07777362d0d2c760009e384ce0ce6f3ecaa06e48d05395b
SHA256 (FreeBSD-8.4-RC3-i386-disc1.iso) = 32f5a30271db4719023a247c66db4fc01faf1e6fdcbaa4189f38c3bd2b6042d5
SHA256 (FreeBSD-8.4-RC3-i386-disc2.iso) = 43ef26e243f8bb3c131ca2c591286f64012612d4ef1855cac006de2c29ee41fd
SHA256 (FreeBSD-8.4-RC3-i386-disc3.iso) = e97dd2adebfc432e1fdf49f2ccf6cd787b2022b58f2d019704deee45d0bb8395
SHA256 (FreeBSD-8.4-RC3-i386-dvd1.iso) = bf7783105f1c1f72f5fdda9eabc058848ef0730ff508dd8bbdad6900ba692a86
SHA256 (FreeBSD-8.4-RC3-i386-livefs.iso) = 1cf71492ea711bfd95731ffe3f022ac7c4c78c63ad5c9e7d36085f622f12575b
SHA256 (FreeBSD-8.4-RC3-i386-memstick.img) = c8cccd2d2731ac30311585650b25c937e401f1ead73ea920865e65f59d240414
MD5 (FreeBSD-8.4-RC3-i386-bootonly.iso) = 7a8a734ea9ff2ed0c6e5ebe0d92d44e1
MD5 (FreeBSD-8.4-RC3-i386-disc1.iso) = dcfeee526c2704014733bc8435cc7a58
MD5 (FreeBSD-8.4-RC3-i386-disc2.iso) = b6f16061dc889957993c28f23b0274b8
MD5 (FreeBSD-8.4-RC3-i386-disc3.iso) = f8eac044f8d59ace934bc887b8b13620
MD5 (FreeBSD-8.4-RC3-i386-dvd1.iso) = b74e9ce95abdf3dc8c2cdcf40c8db8b4
MD5 (FreeBSD-8.4-RC3-i386-livefs.iso) = e1e9cbfb104f80a2eb45fd04c24fc098
MD5 (FreeBSD-8.4-RC3-i386-memstick.img) = 06e0cfb0733f8ab9d418d340c90d1007

8.4-RC3 pc98:

SHA256 (FreeBSD-8.4-RC3-pc98-bootonly.iso) = c258247f93c347a48b1b9b7a79009d6f2989b2f8d29959c884100af8c7be9704
SHA256 (FreeBSD-8.4-RC3-pc98-disc1.iso) = 8f04b9ab03eff0ded59bc61780325ab3a3f4e57d3044fe9318c7489eaa8b0345
SHA256 (FreeBSD-8.4-RC3-pc98-livefs.iso) = 0e22b94964cd69dc46cc8357ad65ec66b85bc02e9fa4548edc104f586641d9d8
MD5 (FreeBSD-8.4-RC3-pc98-bootonly.iso) = 467f027d46d094241416128f344b166a
MD5 (FreeBSD-8.4-RC3-pc98-disc1.iso) = a1ba10e8d957269cd90dc357ddcb6618
MD5 (FreeBSD-8.4-RC3-pc98-livefs.iso) = bd19c8ba32756cc1e62af7f14032bdfe

Glen

[Jeremy Chadwick]

On Sat, May 11, 2013 at 10:57:44PM -0400, Michael L. Squires wrote:
> I upgraded to FreeBSD 8.4-RC3 and noticed a problem with the fxp
> driver on an older Supermicro single CPU single core Xeon
> motherboard.
>
> I know that 8.3-Release does not have this issue, but don't know when in
> the updates to that release the regression was introduced.
>
> I use the fxp driver to connect to a Motorola Surfboard cable modem,
> and immediately saw the following occur many times:
>
> May 10 23:00:04 familysquires kernel: fxp0: link state changed to DOWN
> May 10 23:00:04 familysquires dhclient: New Subnet Mask (fxp0):
> 255.255.240.0
> May 10 23:00:04 familysquires dhclient: New Broadcast Address
> (fxp0): 255.255.25
> 5.255
> May 10 23:00:04 familysquires dhclient: New Routers (fxp0): xx.xxx.xxx.1
> May 10 23:00:06 familysquires kernel: fxp0: link state changed to UP
> May 10 23:00:22 familysquires dhclient: New IP Address (fxp0):
> xx.xxx.xxx.163
> May 10 23:00:22 familysquires kernel: fxp0: link state changed to DOWN
> May 10 23:00:22 familysquires dhclient: New Subnet Mask (fxp0):
> 255.255.240.0
> May 10 23:00:22 familysquires dhclient: New Broadcast Address
> (fxp0): 255.255.255.255
> May 10 23:00:22 familysquires dhclient: New Routers (fxp0): xx.xxx.xxx.1
> May 10 23:00:24 familysquires kernel: fxp0: link state changed to UP
>
> repeated without end.
>
> I reinsalled 8.3-Release p8
>
> FreeBSD familysquires.net 8.3-RELEASE-p8 FreeBSD 8.3-RELEASE-p8 #46:
> Sat May 11 00:05:26 EDT 2013
>
> which ended the string up fxp up/down messages. This kernel has now
> operated for 24 hours without generating this error.
>
> I've attached a verbose dmesg from 8.4-RC3 and a standard dmesg from
> 8.3-Release p8, and can provide whatever else you need.
>
> This is not a critical issue for me. The system has an unused bge interface
> (replaced by an Intel em0 interface during a previous bout of a problem with
> the bge driver).
>
> Mike Squires
> mi...@siralan.org

> Copyright (c) 1992-2013 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 8.4-PRERELEASE #45: Fri May 10 09:43:40 EDT 2013
> ro...@familysquires.net:/usr/obj/usr/src/sys/NEWGATE i386
> gcc version 4.2.1 20070831 patched [FreeBSD]
> Preloaded elf kernel "/boot/kernel/kernel" at 0xc1060000.
> Timecounter "i8254" frequency 1193182 Hz quality 0
> Calibrating TSC clock ... TSC clock: 2666786988 Hz
> CPU: Intel(R) Xeon(TM) CPU 2.66GHz (2666.79-MHz 686-class CPU)
> Origin = "GenuineIntel" Id = 0xf25 Family = f Model = 2 Stepping = 5
> Features=0xbfebfbff<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,HTT,TM,PBE>
> Features2=0x4400<CNXT-ID,xTPR>
>
> Instruction TLB: 4 KB, 2 MB or 4 MB pages, fully associative, 128 entries
> Data TLB: 4 KB or 4 MB pages, fully associative, 64 entries
> 1st-level data cache: 8 KB, 4-way set associative, sectored cache, 64 byte line size
> Trace cache: 12K-uops, 8-way set associative
> 2nd-level cache: 512 KB, 8-way set associative, sectored cache, 64 byte line size
> real memory = 1073741824 (1024 MB)
> Physical memory chunk(s):
> 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages)
> 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages)
> 0x0000000001426000 - 0x000000003eda4fff, 1033367552 bytes (252287 pages)
> avail memory = 1032069120 (984 MB)
> Table 'FACP' at 0x3fff0030
> Table 'APIC' at 0x3fff00b0
> APIC: Found table at 0x3fff00b0
> MP Configuration Table version 1.4 found at 0xc00f0cb0
> APIC: Using the MADT enumerator.
> MADT: Found CPU APIC ID 0 ACPI ID 0: enabled
> SMP: Added CPU 0 (AP)
> MADT: Found CPU APIC ID 0 ACPI ID 1: disabled
> MADT: Found CPU APIC ID 0 ACPI ID 2: disabled
> MADT: Found CPU APIC ID 0 ACPI ID 3: disabled
> MADT: Found CPU APIC ID 0 ACPI ID 4: disabled
> MADT: Found CPU APIC ID 0 ACPI ID 5: disabled
> MADT: Found CPU APIC ID 0 ACPI ID 6: disabled
> MADT: Found CPU APIC ID 0 ACPI ID 7: disabled
> ACPI APIC Table: <RCC GCHE >
> APIC: CPU 0 has ACPI ID 0
> bios32: Found BIOS32 Service Directory header at 0xc00fdb70
> bios32: Entry = 0xfdb80 (c00fdb80) Rev = 0 Len = 1
> pcibios: PCI BIOS entry at 0xf0000+0xdba1
> pnpbios: Found PnP BIOS data at 0xc00f4500
> pnpbios: Entry = f0000:33a4 Rev = 1.0
> Other BIOS signatures found:
> x86bios: IVT 0x000000-0x0004ff at 0xc0000000
> x86bios: SSEG 0x09e000-0x09efff at 0xc4dc0000
> x86bios: EBDA 0x09f000-0x09ffff at 0xc009f000
> x86bios: ROM 0x0a0000-0x0fefff at 0xc00a0000
> ULE: setup cpu 0
> ACPI: RSDP 0xff900 00014 (v00 AMI )
> ACPI: RSDT 0x3fff0000 0002C (v01 RCC GCHE 00000001 MSFT 01000000)
> ACPI: FACP 0x3fff0030 00074 (v01 RCC GCHE 00000001 MSFT 01000000)
> ACPI: DSDT 0x3fff0150 049F1 (v01 RCC GCSL 00000100 MSFT 0100000D)
> ACPI: FACS 0x3ffff000 00040
> ACPI: APIC 0x3fff00b0 0009A (v01 RCC GCHE 00000001 MSFT 01000000)
> MADT: Found IO APIC ID 8, Interrupt 0 at 0xfec00000
> ioapic0: Routing external 8259A's -> intpin 0
> MADT: Found IO APIC ID 9, Interrupt 16 at 0xfec01000
> MADT: Found IO APIC ID 10, Interrupt 32 at 0xfec02000
> MADT: Interrupt override: source 0, irq 2
> ioapic0: Routing IRQ 0 -> intpin 2
> MADT: Forcing active-low polarity and level trigger for SCI
> ioapic0: intpin 9 polarity: low
> ioapic0: intpin 9 trigger: level
> ioapic0 <Version 1.1> irqs 0-15 on motherboard
> ioapic1 <Version 1.1> irqs 16-31 on motherboard
> ioapic2 <Version 1.1> irqs 32-47 on motherboard
> cpu0 BSP:
> ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff
> lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff
> timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400
> wlan: <802.11 Link Layer>
> random: <entropy source, Software, Yarrow>
> nfslock: pseudo-device
> kbd: new array size 4
> kbd1 at kbdmux0
> mem: <memory>
> Pentium Pro MTRR support enabled
> io: <I/O>
> null: <null device, zero device>
> hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2
> acpi0: <RCC GCHE> on motherboard
> ACPI Warning: Type override - [DEB_] had invalid type (Integer) for Scope operator, changed to type ANY
> (20101013/dswload-808)
> ACPI Warning: Type override - [MLIB] had invalid type (Integer) for Scope operator, changed to type ANY
> (20101013/dswload-808)
> ACPI Warning: Type override - [IO__] had invalid type (Integer) for Scope operator, changed to type ANY
> (20101013/dswload-808)
> ACPI Warning: Type override - [DATA] had invalid type (String) for Scope operator, changed to type ANY
> (20101013/dswload-808)
> ACPI Warning: Type override - [SIO_] had invalid type (String) for Scope operator, changed to type ANY
> (20101013/dswload-808)
> ACPI Warning: Type override - [SB__] had invalid type (String) for Scope operator, changed to type ANY
> (20101013/dswload-808)
> ACPI Warning: Type override - [PM__] had invalid type (String) for Scope operator, changed to type ANY
> (20101013/dswload-808)
> ACPI Warning: Type override - [ICNT] had invalid type (String) for Scope operator, changed to type ANY
> (20101013/dswload-808)
> ACPI Warning: Type override - [ACPI] had invalid type (String) for Scope operator, changed to type ANY
> (20101013/dswload-808)
> ACPI Warning: Type override - [IORG] had invalid type (String) for Scope operator, changed to type ANY
> (20101013/dswload-808)
> ACPI Warning: Type override - [SB__] had invalid type (String) for Scope operator, changed to type ANY
> (20101013/dswload-808)
> ACPI Warning: Type override - [PM__] had invalid type (String) for Scope operator, changed to type ANY
> (20101013/dswload-808)
> ACPI Warning: Type override - [SIO_] had invalid type (String) for Scope operator, changed to type ANY
> (20101013/dswload-808)
> ACPI Warning: Type override - [PM__] had invalid type (String) for Scope operator, changed to type ANY
> (20101013/dswload-808)
> ACPI Warning: Type override - [BIOS] had invalid type (Integer) for Scope operator, changed to type ANY
> (20101013/dswload-808)
> ACPI Warning: Type override - [CMOS] had invalid type (Integer) for Scope operator, changed to type ANY
> (20101013/dswload-808)
> ACPI Warning: Type override - [KBC_] had invalid type (Integer) for Scope operator, changed to type ANY
> (20101013/dswload-808)
> ACPI Warning: Type override - [OEM_] had invalid type (Integer) for Scope operator, changed to type ANY
> (20101013/dswload-808)
> ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48
> acpi0: [MPSAFE]
> acpi0: [ITHREAD]
> acpi0: Power Button (fixed)
> acpi0: wakeup code va 0xc4dbd000 pa 0x1000
> pci_open(1): mode 1 addr port (0x0cf8) is 0x800078ac
> pci_open(1a): mode1res=0x80000000 (0x80000000)
> pci_cfgcheck: device 0 [class=060000] [hdr=80] is there (id=00171166)
> pcibios: BIOS version 2.10
> unknown: I/O range not supported
> acpi0: reservation of 0, a0000 (3) failed
> acpi0: reservation of 100000, 3ff00000 (3) failed
> ACPI timer: 1/2 0/3 1/2 1/2 0/3 1/2 0/3 1/2 0/3 0/4 -> 5
> Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x508-0x50b on acpi0
> cpu0: <ACPI CPU> on acpi0
> cpu0: switching to generic Cx mode
> ACPI: Processor \\_PR_.CPU1 (ACPI ID 1) ignored
> ACPI: Processor \\_PR_.CPU2 (ACPI ID 2) ignored
> ACPI: Processor \\_PR_.CPU3 (ACPI ID 3) ignored
> ACPI: Processor \\_PR_.CPU4 (ACPI ID 4) ignored
> ACPI: Processor \\_PR_.CPU5 (ACPI ID 5) ignored
> ACPI: Processor \\_PR_.CPU6 (ACPI ID 6) ignored
> ACPI: Processor \\_PR_.CPU7 (ACPI ID 7) ignored
> pci_link0: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link1: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link2: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link3: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link4: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link5: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link6: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link7: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link8: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link9: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link10: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link11: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link12: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link13: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link14: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link15: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link16: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link17: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link18: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link19: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link20: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link21: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link22: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link23: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link24: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link25: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link26: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link27: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link28: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link29: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link30: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link31: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link32: Index IRQ Rtd Ref IRQs
> Initial Probe 0 10 N 0 10
> Validation 0 10 N 0 10
> After Disable 0 255 N 0 10
> pci_link33: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 11
> Validation 0 255 N 0 11
> After Disable 0 255 N 0 11
> acpi_button0: <Sleep Button> on acpi0
> pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
> ACPI: Found matching pin for 0.15.INTA at func 2: 10
> pci0: <ACPI PCI bus> on pcib0
> pci0: domain=0, physical bus=0
> found-> vendor=0x1166, dev=0x0017, revid=0x32
> domain=0, bus=0, slot=0, func=0
> class=06-00-00, hdrtype=0x00, mfdev=1
> cmdreg=0x0000, statreg=0x0000, cachelnsz=16 (dwords)
> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
> found-> vendor=0x1166, dev=0x0017, revid=0x00
> domain=0, bus=0, slot=0, func=1
> class=06-00-00, hdrtype=0x00, mfdev=1
> cmdreg=0x0000, statreg=0x0000, cachelnsz=16 (dwords)
> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
> found-> vendor=0x8086, dev=0x1026, revid=0x04
> domain=0, bus=0, slot=1, func=0
> class=02-00-00, hdrtype=0x00, mfdev=0
> cmdreg=0x0117, statreg=0x0230, cachelnsz=16 (dwords)
> lattimer=0x40 (1920 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns)
> intpin=a, irq=5
> powerspec 2 supports D0 D3 current D0
> map[10]: type Memory, range 64, base 0xfeb60000, size 17, enabled
> map[18]: type Memory, range 64, base 0xfeb00000, size 18, enabled
> map[20]: type I/O Port, range 32, base 0xe000, size 6, enabled
> pcib0: matched entry for 0.1.INTA
> pcib0: slot 1 INTA hardwired to IRQ 16
> found-> vendor=0x1002, dev=0x4752, revid=0x27
> domain=0, bus=0, slot=6, func=0
> class=03-00-00, hdrtype=0x00, mfdev=0
> cmdreg=0x0087, statreg=0x0290, cachelnsz=16 (dwords)
> lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns)
> intpin=a, irq=10
> powerspec 2 supports D0 D1 D2 D3 current D0
> map[10]: type Memory, range 32, base 0xfd000000, size 24, enabled
> map[14]: type I/O Port, range 32, base 0xe800, size 8, enabled
> map[18]: type Memory, range 32, base 0xfebff000, size 12, enabled
> pcib0: matched entry for 0.6.INTA
> pcib0: slot 6 INTA hardwired to IRQ 26
> found-> vendor=0x8086, dev=0x1229, revid=0x10
> domain=0, bus=0, slot=7, func=0
> class=02-00-00, hdrtype=0x00, mfdev=0
> cmdreg=0x0117, statreg=0x0290, cachelnsz=16 (dwords)
> lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x38 (14000 ns)
> intpin=a, irq=9
> powerspec 2 supports D0 D1 D2 D3 current D0
> map[10]: type Memory, range 32, base 0xfebfd000, size 12, enabled
> map[14]: type I/O Port, range 32, base 0xe400, size 6, enabled
> map[18]: type Memory, range 32, base 0xfeb80000, size 17, enabled
> pcib0: matched entry for 0.7.INTA
> pcib0: slot 7 INTA hardwired to IRQ 27
> found-> vendor=0x14e4, dev=0x16a6, revid=0x02
> domain=0, bus=0, slot=8, func=0
> class=02-00-00, hdrtype=0x00, mfdev=0
> cmdreg=0x0116, statreg=0x02b0, cachelnsz=16 (dwords)
> lattimer=0x40 (1920 ns), mingnt=0x40 (16000 ns), maxlat=0x00 (0 ns)
> intpin=a, irq=11
> powerspec 2 supports D0 D3 current D0
> MSI supports 8 messages, 64 bit
> map[10]: type Memory, range 64, base 0xfebe0000, size 16, enabled
> pcib0: matched entry for 0.8.INTA
> pcib0: slot 8 INTA hardwired to IRQ 28
> found-> vendor=0x1166, dev=0x0203, revid=0xa0
> domain=0, bus=0, slot=15, func=0
> class=06-00-00, hdrtype=0x00, mfdev=1
> cmdreg=0x0107, statreg=0x2200, cachelnsz=0 (dwords)
> lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
> found-> vendor=0x1166, dev=0x0213, revid=0xa0
> domain=0, bus=0, slot=15, func=1
> class=01-01-8a, hdrtype=0x00, mfdev=1
> cmdreg=0x0015, statreg=0x0200, cachelnsz=8 (dwords)
> lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
> map[20]: type I/O Port, range 32, base 0xffa0, size 4, enabled
> found-> vendor=0x1166, dev=0x0221, revid=0x05
> domain=0, bus=0, slot=15, func=2
> class=0c-03-10, hdrtype=0x00, mfdev=1
> cmdreg=0x0117, statreg=0x0280, cachelnsz=0 (dwords)
> lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x50 (20000 ns)
> intpin=a, irq=10
> map[10]: type Memory, range 32, base 0xfebfe000, size 12, enabled
> pcib0: matched entry for 0.15.INTA (src \\_SB_.LNUS:0)
> ioapic0: Changing trigger for pin 10 to level
> ioapic0: Changing polarity for pin 10 to low
> pcib0: slot 15 INTA routed to irq 10 via \\_SB_.LNUS
> unknown: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfebfe000
> ohci early: SMM active, request owner change
> found-> vendor=0x1166, dev=0x0227, revid=0x00
> domain=0, bus=0, slot=15, func=3
> class=06-01-00, hdrtype=0x00, mfdev=1
> cmdreg=0x0107, statreg=0x0200, cachelnsz=0 (dwords)
> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
> em0: <Intel(R) PRO/1000 Legacy Network Connection 1.0.5> port 0xe000-0xe03f mem 0xfeb60000-0xfeb7ffff,0xfeb00000-0xfeb3ffff irq 16 at device 1.0 on pci0
> em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfeb60000
> em0: Reserved 0x40 bytes for rid 0x20 type 4 at 0xe000
> ioapic1: routing intpin 0 (PCI IRQ 16) to lapic 0 vector 49
> em0: [FILTER]
> em0: bpf attached
> em0: Ethernet address: 00:04:23:df:fa:46
> vgapci0: <VGA-compatible display> port 0xe800-0xe8ff mem 0xfd000000-0xfdffffff,0xfebff000-0xfebfffff irq 26 at device 6.0 on pci0
> fxp0: <Intel 82551 Pro/100 Ethernet> port 0xe400-0xe43f mem 0xfebfd000-0xfebfdfff,0xfeb80000-0xfeb9ffff irq 27 at device 7.0 on pci0
> fxp0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfebfd000
> fxp0: using memory space register mapping
> fxp0: PCI IDs: 8086 1229 8086 1050 0010
> fxp0: Dynamic Standby mode is disabled
> miibus0: <MII bus> on fxp0
> inphy0: <i82555 10/100 media interface> PHY 1 on miibus0
> inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow
> fxp0: bpf attached
> fxp0: Ethernet address: 00:30:48:52:51:ae
> ioapic1: routing intpin 11 (PCI IRQ 27) to lapic 0 vector 50
> fxp0: [MPSAFE]
> fxp0: [ITHREAD]
> pci0:0:8:0: bad VPD cksum, remain 14
> bge0: <Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x001002> mem 0xfebe0000-0xfebeffff irq 28 at device 8.0 on pci0
> bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfebe0000
> bge0: CHIP ID 0x00001002; ASIC REV 0x01; CHIP REV 0x10; PCI on PCI-X 33 MHz; 32bit
> miibus1: <MII bus> on bge0
> brgphy0: <BCM5703 10/100/1000baseTX PHY> PHY 1 on miibus1
> brgphy0: OUI 0x000818, model 0x0016, rev. 2
> brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
> bge0: bpf attached
> bge0: Ethernet address: 00:30:48:52:51:af
> ioapic1: routing intpin 12 (PCI IRQ 28) to lapic 0 vector 51
> bge0: [MPSAFE]
> bge0: [ITHREAD]
> atapci0: <ServerWorks CSB6 UDMA100 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 15.1 on pci0
> atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xffa0
> ata0: <ATA channel> at channel 0 on atapci0
> atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0
> atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6
> ata0: reset tp1 mask=03 ostat0=50 ostat1=00
> ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00
> ata0: stat1=0x00 err=0x01 lsb=0x00 msb=0x00
> ata0: reset tp2 stat0=50 stat1=00 devices=0x1
> ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 52
> ata0: [MPSAFE]
> ata0: [ITHREAD]
> ata1: <ATA channel> at channel 1 on atapci0
> atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170
> atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376
> ata1: reset tp1 mask=01 ostat0=50 ostat1=ff
> ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb
> ata1: reset tp2 stat0=00 stat1=00 devices=0x10000
> ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 0 vector 53
> ata1: [MPSAFE]
> ata1: [ITHREAD]
> ohci0: <OHCI (generic) USB controller> mem 0xfebfe000-0xfebfefff irq 10 at device 15.2 on pci0
> ohci0: (New OHCI DeviceId=0x02211166)
> ioapic0: routing intpin 10 (ISA IRQ 10) to lapic 0 vector 54
> ohci0: [MPSAFE]
> ohci0: [ITHREAD]
> usbus0 on ohci0
> usbus0: bpf attached
> ohci0: usbpf: Attached
> isab0: <PCI-ISA bridge> at device 15.3 on pci0
> isa0: <ISA bus> on isab0
> atrtc0: <AT realtime clock> port 0x70-0x71 irq 8 on acpi0
> atrtc0: registered as a time-of-day clock (resolution 1000000us)
> psmcpnp0: <PS/2 mouse port> irq 12 on acpi0
> atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
> atkbd0: <AT Keyboard> irq 1 on atkbdc0
> atkbd: the current kbd controller command byte 0065
> atkbd: keyboard ID 0x41ab (2)
> kbd0 at atkbd0
> kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000
> ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 55
> atkbd0: [GIANT-LOCKED]
> atkbd0: [ITHREAD]
> psm0: current command byte:0065
> psm0: <PS/2 Mouse> irq 12 on atkbdc0
> ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 56
> psm0: [GIANT-LOCKED]
> psm0: [ITHREAD]
> psm0: model IntelliMouse, device ID 3-00, 3 buttons
> psm0: config:00000000, flags:00000008, packet size:4
> psm0: syncmask:08, syncbits:00
> fdc0: <floppy drive controller (FDE)> port 0x3f2-0x3f3,0x3f4-0x3f5,0x3f7 irq 6 drq 2 on acpi0
> fdc0: ic_type 90 part_id 73
> ioapic0: routing intpin 6 (ISA IRQ 6) to lapic 0 vector 57
> fdc0: [FILTER]
> fd0: <1440-KB 3.5" drive> on fdc0 drive 0
> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
> ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 0 vector 58
> uart0: [FILTER]
> uart0: fast interrupt
> uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0
> ioapic0: routing intpin 3 (ISA IRQ 3) to lapic 0 vector 59
> uart1: [FILTER]
> uart1: fast interrupt
> ppc0: using extended I/O port range
> ppc0: SPP ECP
> ppc0: <Parallel port> port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0
> ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode
> ppc0: FIFO with 16/16/8 bytes threshold
> ioapic0: routing intpin 7 (ISA IRQ 7) to lapic 0 vector 60
> ppc0: [MPSAFE]
> ppc0: [ITHREAD]
> ppbus0: <Parallel port bus> on ppc0
> plip0: <PLIP network interface> on ppbus0
> plip0: bpf attached
> plip0: [MPSAFE]
> plip0: [ITHREAD]
> lpt0: <Printer> on ppbus0
> lpt0: [MPSAFE]
> lpt0: [ITHREAD]
> lpt0: Interrupt-driven port
> ppi0: <Parallel I/O> on ppbus0
> ex_isa_identify()
> pnp_identify: Trying Read_Port at 203
> pnp_identify: Trying Read_Port at 243
> pnp_identify: Trying Read_Port at 283
> pnp_identify: Trying Read_Port at 2c3
> pnp_identify: Trying Read_Port at 303
> pnp_identify: Trying Read_Port at 343
> pnp_identify: Trying Read_Port at 383
> pnp_identify: Trying Read_Port at 3c3
> PNP Identify complete
> ahc_isa_probe 0: ioport 0xc00 alloc failed
> ahc_isa_probe 1: ioport 0x1c00 alloc failed
> ahc_isa_probe 2: ioport 0x2c00 alloc failed
> ahc_isa_probe 3: ioport 0x3c00 alloc failed
> ahc_isa_probe 4: ioport 0x4c00 alloc failed
> ahc_isa_probe 5: ioport 0x5c00 alloc failed
> ahc_isa_probe 6: ioport 0x6c00 alloc failed
> ahc_isa_probe 7: ioport 0x7c00 alloc failed
> ahc_isa_probe 8: ioport 0x8c00 alloc failed
> ahc_isa_probe 9: ioport 0x9c00 alloc failed
> ahc_isa_probe 10: ioport 0xac00 alloc failed
> ahc_isa_probe 11: ioport 0xbc00 alloc failed
> ahc_isa_probe 12: ioport 0xcc00 alloc failed
> ahc_isa_probe 13: ioport 0xdc00 alloc failed
> ahc_isa_probe 14: ioport 0xec00 alloc failed
> isa_probe_children: disabling PnP devices
> pmtimer0 on isa0
> ata: ata0 already exists; skipping it
> ata: ata1 already exists; skipping it
> atkbdc: atkbdc0 already exists; skipping it
> atrtc: atrtc0 already exists; skipping it
> fdc: fdc0 already exists; skipping it
> ppc: ppc0 already exists; skipping it
> sc: sc0 already exists; skipping it
> uart: uart0 already exists; skipping it
> uart: uart1 already exists; skipping it
> isa_probe_children: probing non-PnP devices
> orm0: <ISA Option ROMs> at iomem 0xc0000-0xc7fff,0xc8000-0xc97ff,0xc9800-0xcafff pnpid ORM0000 on isa0
> sc0: <System console> at flags 0x100 on isa0
> sc0: VGA <16 virtual consoles, flags=0x300>
> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal)
> vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
> wbwd0 failed to probe on isa0
> isa_probe_children: probing PnP devices
> p4tcc0: <CPU Frequency Thermal Control> on cpu0
> Device configuration finished.
> procfs registered
> lapic: Divisor 2, Frequency 66669679 Hz
> Timecounter "TSC" frequency 2666786988 Hz quality 800
> Timecounters tick every 1.000 msec
> vlan: initialized, using hash tables with chaining
> ipfw2 (+ipv6) initialized, divert enabled, nat loadable, rule-based forwarding disabled, default to accept, logging disabled
> ipfw0: bpf attached
> lo0: bpf attached
> hptrr: no controller detected.
> ata0: Identifying devices: 00000001
> ata0: New devices: 00000001
> usbus0: 12Mbps Full Speed USB v1.0
> ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire
> ad0: setting UDMA100
> ad0: 152627MB <WDC WD1600LB-55EDA0 15.05R15> at ata0-master UDMA100
> ad0: 312581808 sectors [310101C/16H/63S] 16 sectors/interrupt 1 depth queue
> ugen0.1: <0x1166> at usbus0
> uhub0: <0x1166 OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
> ad0: Adaptec check1 failed
> ad0: LSI (v3) check1 failed
> ad0: LSI (v2) check1 failed
> ad0: FreeBSD check1 failed
> ata1: Identifying devices: 00010000
> ata1: New devices: 00010000
> ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire
> acd0: setting UDMA33
> acd0: <MATSHITA CR-177/7T0D> CDROM drive at ata1 as master
> acd0: read 4125KB/s (4125KB/s), 128KB buffer, UDMA33
> acd0: Reads: CDR, CDRW, CDDA stream, packet
> acd0: Writes:
> acd0: Audio: play, 256 volume levels
> acd0: Mechanism: ejectable tray, unlocked
> acd0: Medium: no/blank disc
> ATA PseudoRAID loaded
> uhub0: 4 ports with 4 removable, self powered
> GEOM: new disk ad0
> GEOM: ad0s2: geometry does not match label (255h,63s != 16h,63s).
> Trying to mount root from ufs:/dev/ad0s2a
> start_init: trying /sbin/init
> em0: Link is up 1000 Mbps Full Duplex
> em0: Link is Down
> em0: Link is up 1000 Mbps Full Duplex
> fxp0: link state changed to UP
> fxp0: link state changed to DOWN
> fxp0: link state changed to UP
> fxp0: link state changed to DOWN
> fxp0: link state changed to UP
> fxp0: link state changed to DOWN
> fxp0: link state changed to UP
> fxp0: link state changed to DOWN
> fxp0: link state changed to UP
> fxp0: link state changed to DOWN
> fxp0: link state changed to UP
> fxp0: link state changed to DOWN
> fxp0: link state changed to UP
> fxp0: link state changed to DOWN
> fxp0: link state changed to UP
> fxp0: link state changed to DOWN
> fxp0: link state changed to UP
> fxp0: link state changed to DOWN
> fxp0: link state changed to UP
> fxp0: link state changed to DOWN
> fxp0: link state changed to UP
> fxp0: link state changed to DOWN
> fxp0: link state changed to UP
> fxp0: link state changed to DOWN
> fxp0: link state changed to UP
> fxp0: link state changed to DOWN
> fxp0: link state changed to UP
> fxp0: link state changed to DOWN
> fxp0: link state changed to UP
> fxp0: link state changed to DOWN
> fxp0: link state changed to UP
> splash: image decoder found: daemon_saver
> fxp0: link state changed to DOWN
> fxp0: link state changed to UP
> fxp0: link state changed to DOWN
> fxp0: link state changed to UP
> fxp0: link state changed to DOWN
> fxp0: link state changed to UP

> Copyright (c) 1992-2012 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 8.3-RELEASE-p8 #46: Sat May 11 00:05:26 EDT 2013
> ro...@familysquires.net:/usr/obj/usr/src/sys/NEWGATE i386
> Preloaded elf kernel "/boot/kernel/kernel" at 0xc102d000.
> Timecounter "i8254" frequency 1193182 Hz quality 0
> Calibrating TSC clock ... TSC clock: 2666782592 Hz
> CPU: Intel(R) Xeon(TM) CPU 2.66GHz (2666.78-MHz 686-class CPU)
> Origin = "GenuineIntel" Id = 0xf25 Family = f Model = 2 Stepping = 5
> Features=0xbfebfbff<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,HTT,TM,PBE>
> Features2=0x4400<CNXT-ID,xTPR>
>
> Instruction TLB: 4 KB, 2 MB or 4 MB pages, fully associative, 128 entries
> Data TLB: 4 KB or 4 MB pages, fully associative, 64 entries
> 1st-level data cache: 8 KB, 4-way set associative, sectored cache, 64 byte line size
> Trace cache: 12K-uops, 8-way set associative
> 2nd-level cache: 512 KB, 8-way set associative, sectored cache, 64 byte line size
> real memory = 1073741824 (1024 MB)
> Physical memory chunk(s):
> 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages)
> 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages)
> 0x0000000001426000 - 0x000000003eda4fff, 1033367552 bytes (252287 pages)
> avail memory = 1032085504 (984 MB)
> Table 'FACP' at 0x3fff0030
> Table 'APIC' at 0x3fff00b0
> APIC: Found table at 0x3fff00b0
> MP Configuration Table version 1.4 found at 0xc00f0cb0
> APIC: Using the MADT enumerator.
> MADT: Found CPU APIC ID 0 ACPI ID 0: enabled
> SMP: Added CPU 0 (AP)
> MADT: Found CPU APIC ID 0 ACPI ID 1: disabled
> MADT: Found CPU APIC ID 0 ACPI ID 2: disabled
> MADT: Found CPU APIC ID 0 ACPI ID 3: disabled
> MADT: Found CPU APIC ID 0 ACPI ID 4: disabled
> MADT: Found CPU APIC ID 0 ACPI ID 5: disabled
> MADT: Found CPU APIC ID 0 ACPI ID 6: disabled
> MADT: Found CPU APIC ID 0 ACPI ID 7: disabled
> ACPI APIC Table: <RCC GCHE >
> APIC: CPU 0 has ACPI ID 0
> bios32: Found BIOS32 Service Directory header at 0xc00fdb70
> bios32: Entry = 0xfdb80 (c00fdb80) Rev = 0 Len = 1
> pcibios: PCI BIOS entry at 0xf0000+0xdba1
> pnpbios: Found PnP BIOS data at 0xc00f4500
> pnpbios: Entry = f0000:33a4 Rev = 1.0
> Other BIOS signatures found:
> x86bios: IVT 0x000000-0x0004ff at 0xc0000000
> x86bios: SSEG 0x010000-0x01ffff at 0xc43b9000
> x86bios: EBDA 0x09f000-0x09ffff at 0xc009f000
> x86bios: ROM 0x0a0000-0x0effff at 0xc00a0000
> ULE: setup cpu 0
> ACPI: RSDP 0xff900 00014 (v00 AMI )
> ACPI: RSDT 0x3fff0000 0002C (v01 RCC GCHE 00000001 MSFT 01000000)
> ACPI: FACP 0x3fff0030 00074 (v01 RCC GCHE 00000001 MSFT 01000000)
> ACPI: DSDT 0x3fff0150 049F1 (v01 RCC GCSL 00000100 MSFT 0100000D)
> ACPI: FACS 0x3ffff000 00040
> ACPI: APIC 0x3fff00b0 0009A (v01 RCC GCHE 00000001 MSFT 01000000)
> MADT: Found IO APIC ID 8, Interrupt 0 at 0xfec00000
> ioapic0: Routing external 8259A's -> intpin 0
> MADT: Found IO APIC ID 9, Interrupt 16 at 0xfec01000
> MADT: Found IO APIC ID 10, Interrupt 32 at 0xfec02000
> MADT: Interrupt override: source 0, irq 2
> ioapic0: Routing IRQ 0 -> intpin 2
> MADT: Forcing active-low polarity and level trigger for SCI
> ioapic0: intpin 9 polarity: low
> ioapic0: intpin 9 trigger: level
> ioapic0 <Version 1.1> irqs 0-15 on motherboard
> ioapic1 <Version 1.1> irqs 16-31 on motherboard
> ioapic2 <Version 1.1> irqs 32-47 on motherboard
> cpu0 BSP:
> ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff
> lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff
> timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400
> wlan: <802.11 Link Layer>
> null: <null device, zero device>
> random: <entropy source, Software, Yarrow>
> nfslock: pseudo-device
> io: <I/O>
> kbd: new array size 4
> kbd1 at kbdmux0
> mem: <memory>
> Pentium Pro MTRR support enabled
> hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2
> acpi0: <RCC GCHE> on motherboard
> ACPI Warning: Type override - [DEB_] had invalid type (Integer) for Scope operator, changed to type ANY
> (20101013/dswload-808)
> ACPI Warning: Type override - [MLIB] had invalid type (Integer) for Scope operator, changed to type ANY
> (20101013/dswload-808)
> ACPI Warning: Type override - [IO__] had invalid type (Integer) for Scope operator, changed to type ANY
> (20101013/dswload-808)
> ACPI Warning: Type override - [DATA] had invalid type (String) for Scope operator, changed to type ANY
> (20101013/dswload-808)
> ACPI Warning: Type override - [SIO_] had invalid type (String) for Scope operator, changed to type ANY
> (20101013/dswload-808)
> ACPI Warning: Type override - [SB__] had invalid type (String) for Scope operator, changed to type ANY
> (20101013/dswload-808)
> ACPI Warning: Type override - [PM__] had invalid type (String) for Scope operator, changed to type ANY
> (20101013/dswload-808)
> ACPI Warning: Type override - [ICNT] had invalid type (String) for Scope operator, changed to type ANY
> (20101013/dswload-808)
> ACPI Warning: Type override - [ACPI] had invalid type (String) for Scope operator, changed to type ANY
> (20101013/dswload-808)
> ACPI Warning: Type override - [IORG] had invalid type (String) for Scope operator, changed to type ANY
> (20101013/dswload-808)
> ACPI Warning: Type override - [SB__] had invalid type (String) for Scope operator, changed to type ANY
> (20101013/dswload-808)
> ACPI Warning: Type override - [PM__] had invalid type (String) for Scope operator, changed to type ANY
> (20101013/dswload-808)
> ACPI Warning: Type override - [SIO_] had invalid type (String) for Scope operator, changed to type ANY
> (20101013/dswload-808)
> ACPI Warning: Type override - [PM__] had invalid type (String) for Scope operator, changed to type ANY
> (20101013/dswload-808)
> ACPI Warning: Type override - [BIOS] had invalid type (Integer) for Scope operator, changed to type ANY
> (20101013/dswload-808)
> ACPI Warning: Type override - [CMOS] had invalid type (Integer) for Scope operator, changed to type ANY
> (20101013/dswload-808)
> ACPI Warning: Type override - [KBC_] had invalid type (Integer) for Scope operator, changed to type ANY
> (20101013/dswload-808)
> ACPI Warning: Type override - [OEM_] had invalid type (Integer) for Scope operator, changed to type ANY
> (20101013/dswload-808)
> ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48
> acpi0: [MPSAFE]
> acpi0: [ITHREAD]
> acpi0: Power Button (fixed)
> acpi0: wakeup code va 0xc43b6000 pa 0x1000
> pci_open(1): mode 1 addr port (0x0cf8) is 0x800078ac
> pci_open(1a): mode1res=0x80000000 (0x80000000)
> pci_cfgcheck: device 0 [class=060000] [hdr=80] is there (id=00171166)
> pcibios: BIOS version 2.10
> unknown: I/O range not supported
> acpi0: reservation of 0, a0000 (3) failed
> acpi0: reservation of 100000, 3ff00000 (3) failed
> ACPI timer: 0/3 1/2 1/2 0/3 0/3 0/3 1/2 0/3 0/3 0/3 -> 3
> Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x508-0x50b on acpi0
> cpu0: <ACPI CPU> on acpi0
> cpu0: switching to generic Cx mode
> pci_link0: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link1: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link2: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link3: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link4: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link5: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link6: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link7: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link8: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link9: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link10: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link11: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link12: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link13: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link14: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link15: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link16: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link17: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link18: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link19: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link20: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link21: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link22: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link23: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link24: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link25: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link26: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link27: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link28: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link29: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link30: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link31: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 3 4 5 7 9 11 12 14 15
> Validation 0 255 N 0 3 4 5 7 9 11 12 14 15
> After Disable 0 255 N 0 3 4 5 7 9 11 12 14 15
> pci_link32: Index IRQ Rtd Ref IRQs
> Initial Probe 0 10 N 0 10
> Validation 0 10 N 0 10
> After Disable 0 255 N 0 10
> pci_link33: Index IRQ Rtd Ref IRQs
> Initial Probe 0 255 N 0 11
> Validation 0 255 N 0 11
> After Disable 0 255 N 0 11
> acpi_button0: <Sleep Button> on acpi0
> pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
> ACPI: Found matching pin for 0.15.INTA at func 2: 10
> pci0: <ACPI PCI bus> on pcib0
> pci0: domain=0, physical bus=0
> found-> vendor=0x1166, dev=0x0017, revid=0x32
> domain=0, bus=0, slot=0, func=0
> class=06-00-00, hdrtype=0x00, mfdev=1
> cmdreg=0x0000, statreg=0x0000, cachelnsz=16 (dwords)
> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
> found-> vendor=0x1166, dev=0x0017, revid=0x00
> domain=0, bus=0, slot=0, func=1
> class=06-00-00, hdrtype=0x00, mfdev=1
> cmdreg=0x0000, statreg=0x0000, cachelnsz=16 (dwords)
> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
> found-> vendor=0x8086, dev=0x1026, revid=0x04
> domain=0, bus=0, slot=1, func=0
> class=02-00-00, hdrtype=0x00, mfdev=0
> cmdreg=0x0117, statreg=0x0230, cachelnsz=16 (dwords)
> lattimer=0x40 (1920 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns)
> intpin=a, irq=5
> powerspec 2 supports D0 D3 current D0
> map[10]: type Memory, range 64, base 0xfeb60000, size 17, enabled
> map[18]: type Memory, range 64, base 0xfeb00000, size 18, enabled
> map[20]: type I/O Port, range 32, base 0xe000, size 6, enabled
> pcib0: matched entry for 0.1.INTA
> pcib0: slot 1 INTA hardwired to IRQ 16
> found-> vendor=0x1002, dev=0x4752, revid=0x27
> domain=0, bus=0, slot=6, func=0
> class=03-00-00, hdrtype=0x00, mfdev=0
> cmdreg=0x0087, statreg=0x0290, cachelnsz=16 (dwords)
> lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns)
> intpin=a, irq=10
> powerspec 2 supports D0 D1 D2 D3 current D0
> map[10]: type Memory, range 32, base 0xfd000000, size 24, enabled
> map[14]: type I/O Port, range 32, base 0xe800, size 8, enabled
> map[18]: type Memory, range 32, base 0xfebff000, size 12, enabled
> pcib0: matched entry for 0.6.INTA
> pcib0: slot 6 INTA hardwired to IRQ 26
> found-> vendor=0x8086, dev=0x1229, revid=0x10
> domain=0, bus=0, slot=7, func=0
> class=02-00-00, hdrtype=0x00, mfdev=0
> cmdreg=0x0117, statreg=0x0290, cachelnsz=16 (dwords)
> lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x38 (14000 ns)
> intpin=a, irq=9
> powerspec 2 supports D0 D1 D2 D3 current D0
> map[10]: type Memory, range 32, base 0xfebfd000, size 12, enabled
> map[14]: type I/O Port, range 32, base 0xe400, size 6, enabled
> map[18]: type Memory, range 32, base 0xfeb80000, size 17, enabled
> pcib0: matched entry for 0.7.INTA
> pcib0: slot 7 INTA hardwired to IRQ 27
> found-> vendor=0x14e4, dev=0x16a6, revid=0x02
> domain=0, bus=0, slot=8, func=0
> class=02-00-00, hdrtype=0x00, mfdev=0
> cmdreg=0x0116, statreg=0x02b0, cachelnsz=16 (dwords)
> lattimer=0x40 (1920 ns), mingnt=0x40 (16000 ns), maxlat=0x00 (0 ns)
> intpin=a, irq=11
> powerspec 2 supports D0 D3 current D0
> MSI supports 8 messages, 64 bit
> map[10]: type Memory, range 64, base 0xfebe0000, size 16, enabled
> pcib0: matched entry for 0.8.INTA
> pcib0: slot 8 INTA hardwired to IRQ 28
> found-> vendor=0x1166, dev=0x0203, revid=0xa0
> domain=0, bus=0, slot=15, func=0
> class=06-00-00, hdrtype=0x00, mfdev=1
> cmdreg=0x0107, statreg=0x2200, cachelnsz=0 (dwords)
> lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
> found-> vendor=0x1166, dev=0x0213, revid=0xa0
> domain=0, bus=0, slot=15, func=1
> class=01-01-8a, hdrtype=0x00, mfdev=1
> cmdreg=0x0015, statreg=0x0200, cachelnsz=8 (dwords)
> lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
> map[20]: type I/O Port, range 32, base 0xffa0, size 4, enabled
> found-> vendor=0x1166, dev=0x0221, revid=0x05
> domain=0, bus=0, slot=15, func=2
> class=0c-03-10, hdrtype=0x00, mfdev=1
> cmdreg=0x0117, statreg=0x0280, cachelnsz=0 (dwords)
> lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x50 (20000 ns)
> intpin=a, irq=10
> map[10]: type Memory, range 32, base 0xfebfe000, size 12, enabled
> pcib0: matched entry for 0.15.INTA (src \\_SB_.LNUS:0)
> ioapic0: Changing trigger for pin 10 to level
> ioapic0: Changing polarity for pin 10 to low
> pcib0: slot 15 INTA routed to irq 10 via \\_SB_.LNUS
> unknown: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfebfe000
> ohci early: SMM active, request owner change
> found-> vendor=0x1166, dev=0x0227, revid=0x00
> domain=0, bus=0, slot=15, func=3
> class=06-01-00, hdrtype=0x00, mfdev=1
> cmdreg=0x0107, statreg=0x0200, cachelnsz=0 (dwords)
> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
> em0: <Intel(R) PRO/1000 Legacy Network Connection 1.0.4> port 0xe000-0xe03f mem 0xfeb60000-0xfeb7ffff,0xfeb00000-0xfeb3ffff irq 16 at device 1.0 on pci0
> em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfeb60000
> em0: Reserved 0x40 bytes for rid 0x20 type 4 at 0xe000
> ioapic1: routing intpin 0 (PCI IRQ 16) to lapic 0 vector 49
> em0: [FILTER]
> em0: bpf attached
> em0: Ethernet address: 00:04:23:df:fa:46
> vgapci0: <VGA-compatible display> port 0xe800-0xe8ff mem 0xfd000000-0xfdffffff,0xfebff000-0xfebfffff irq 26 at device 6.0 on pci0
> fxp0: <Intel 82551 Pro/100 Ethernet> port 0xe400-0xe43f mem 0xfebfd000-0xfebfdfff,0xfeb80000-0xfeb9ffff irq 27 at device 7.0 on pci0
> fxp0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfebfd000
> fxp0: using memory space register mapping
> fxp0: PCI IDs: 8086 1229 8086 1050 0010
> fxp0: Dynamic Standby mode is disabled
> miibus0: <MII bus> on fxp0
> inphy0: <i82555 10/100 media interface> PHY 1 on miibus0
> inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow
> fxp0: bpf attached
> fxp0: Ethernet address: 00:30:48:52:51:ae
> ioapic1: routing intpin 11 (PCI IRQ 27) to lapic 0 vector 50
> fxp0: [MPSAFE]
> fxp0: [ITHREAD]
> pci0:0:8:0: bad VPD cksum, remain 14
> bge0: <Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x001002> mem 0xfebe0000-0xfebeffff irq 28 at device 8.0 on pci0
> bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfebe0000
> bge0: CHIP ID 0x00001002; ASIC REV 0x01; CHIP REV 0x10; PCI
> miibus1: <MII bus> on bge0
> brgphy0: <BCM5703 10/100/1000baseTX PHY> PHY 1 on miibus1
> brgphy0: OUI 0x000818, model 0x0016, rev. 2
> brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
> bge0: bpf attached
> bge0: Ethernet address: 00:30:48:52:51:af
> ioapic1: routing intpin 12 (PCI IRQ 28) to lapic 0 vector 51
> bge0: [MPSAFE]
> bge0: [ITHREAD]
> atapci0: <ServerWorks CSB6 UDMA100 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 15.1 on pci0
> atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xffa0
> ata0: <ATA channel> at channel 0 on atapci0
> atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0
> atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6
> ata0: reset tp1 mask=03 ostat0=50 ostat1=00
> ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00
> ata0: stat1=0x00 err=0x01 lsb=0x00 msb=0x00
> ata0: reset tp2 stat0=50 stat1=00 devices=0x1
> ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 52
> ata0: [MPSAFE]
> ata0: [ITHREAD]
> ata1: <ATA channel> at channel 1 on atapci0
> atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170
> atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376
> ata1: reset tp1 mask=01 ostat0=50 ostat1=ff
> ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb
> ata1: reset tp2 stat0=00 stat1=00 devices=0x10000
> ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 0 vector 53
> ata1: [MPSAFE]
> ata1: [ITHREAD]
> ohci0: <OHCI (generic) USB controller> mem 0xfebfe000-0xfebfefff irq 10 at device 15.2 on pci0
> ohci0: (New OHCI DeviceId=0x02211166)
> ioapic0: routing intpin 10 (ISA IRQ 10) to lapic 0 vector 54
> ohci0: [MPSAFE]
> ohci0: [ITHREAD]
> usbus0: <OHCI (generic) USB controller> on ohci0
> usbus0: bpf attached
> ohci0: usbpf: Attached
> isab0: <PCI-ISA bridge> at device 15.3 on pci0
> isa0: <ISA bus> on isab0
> atrtc0: <AT realtime clock> port 0x70-0x71 irq 8 on acpi0
> atrtc0: registered as a time-of-day clock (resolution 1000000us)
> psmcpnp0: <PS/2 mouse port> irq 12 on acpi0
> atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
> atkbd0: <AT Keyboard> irq 1 on atkbdc0
> atkbd: the current kbd controller command byte 0065
> atkbd: keyboard ID 0x41ab (2)
> kbd0 at atkbd0
> kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000
> ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 55
> atkbd0: [GIANT-LOCKED]
> atkbd0: [ITHREAD]
> psm0: current command byte:0065
> psm0: <PS/2 Mouse> irq 12 on atkbdc0
> ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 56
> psm0: [GIANT-LOCKED]
> psm0: [ITHREAD]
> psm0: model IntelliMouse, device ID 3-00, 3 buttons
> psm0: config:00000000, flags:00000008, packet size:4
> psm0: syncmask:08, syncbits:00
> fdc0: <floppy drive controller (FDE)> port 0x3f2-0x3f3,0x3f4-0x3f5,0x3f7 irq 6 drq 2 on acpi0
> fdc0: ic_type 90 part_id 73
> ioapic0: routing intpin 6 (ISA IRQ 6) to lapic 0 vector 57
> fdc0: [FILTER]
> fd0: <1440-KB 3.5" drive> on fdc0 drive 0
> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
> ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 0 vector 58
> uart0: [FILTER]
> uart0: fast interrupt
> uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0
> ioapic0: routing intpin 3 (ISA IRQ 3) to lapic 0 vector 59
> uart1: [FILTER]
> uart1: fast interrupt
> ppc0: using extended I/O port range
> ppc0: SPP ECP
> ppc0: <Parallel port> port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0
> ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode
> ppc0: FIFO with 16/16/8 bytes threshold
> ioapic0: routing intpin 7 (ISA IRQ 7) to lapic 0 vector 60
> ppc0: [MPSAFE]
> ppc0: [ITHREAD]
> ppbus0: <Parallel port bus> on ppc0
> plip0: <PLIP network interface> on ppbus0
> plip0: bpf attached
> plip0: [MPSAFE]
> plip0: [ITHREAD]
> lpt0: <Printer> on ppbus0
> lpt0: [MPSAFE]
> lpt0: [ITHREAD]
> lpt0: Interrupt-driven port
> ppi0: <Parallel I/O> on ppbus0
> unknown: status reg test failed ff
> unknown: status reg test failed ff
> unknown: status reg test failed ff
> unknown: status reg test failed ff
> unknown: status reg test failed ff
> unknown: status reg test failed ff
> ahc_isa_probe 0: ioport 0xc00 alloc failed
> ex_isa_identify()
> pnp_identify: Trying Read_Port at 203
> pnp_identify: Trying Read_Port at 243
> pnp_identify: Trying Read_Port at 283
> pnp_identify: Trying Read_Port at 2c3
> pnp_identify: Trying Read_Port at 303
> pnp_identify: Trying Read_Port at 343
> pnp_identify: Trying Read_Port at 383
> pnp_identify: Trying Read_Port at 3c3
> PNP Identify complete
> isa_probe_children: disabling PnP devices
> pmtimer0 on isa0
> ata: ata0 already exists; skipping it
> ata: ata1 already exists; skipping it
> atkbdc: atkbdc0 already exists; skipping it
> atrtc: atrtc0 already exists; skipping it
> fdc: fdc0 already exists; skipping it
> ppc: ppc0 already exists; skipping it
> sc: sc0 already exists; skipping it
> uart: uart0 already exists; skipping it
> uart: uart1 already exists; skipping it
> isa_probe_children: probing non-PnP devices
> orm0: <ISA Option ROMs> at iomem 0xc0000-0xc7fff,0xc8000-0xc97ff,0xc9800-0xcafff pnpid ORM0000 on isa0
> sc0: <System console> at flags 0x100 on isa0
> sc0: VGA <16 virtual consoles, flags=0x300>
> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal)
> vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
> isa_probe_children: probing PnP devices
> p4tcc0: <CPU Frequency Thermal Control> on cpu0
> Device configuration finished.
> procfs registered
> lapic: Divisor 2, Frequency 66669589 Hz
> Timecounter "TSC" frequency 2666782592 Hz quality 800
> Timecounters tick every 1.000 msec
> vlan: initialized, using hash tables with chaining
> ipfw2 (+ipv6) initialized, divert enabled, nat loadable, rule-based forwarding disabled, default to accept, logging disabled
> ipfw0: bpf attached
> lo0: bpf attached
> hptrr: no controller detected.
> ata0: Identifying devices: 00000001
> ata0: New devices: 00000001
> usbus0: 12Mbps Full Speed USB v1.0
> ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire
> ad0: setting UDMA100
> ad0: 152627MB <WDC WD1600LB-55EDA0 15.05R15> at ata0-master UDMA100
> ad0: 312581808 sectors [310101C/16H/63S] 16 sectors/interrupt 1 depth queue
> ugen0.1: <0x1166> at usbus0
> uhub0: <0x1166 OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
> ad0: Adaptec check1 failed
> ad0: LSI (v3) check1 failed
> ad0: LSI (v2) check1 failed
> ad0: FreeBSD check1 failed
> ata1: Identifying devices: 00010000
> ata1: New devices: 00010000
> ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire
> acd0: setting UDMA33
> acd0: <MATSHITA CR-177/7T0D> CDROM drive at ata1 as master
> acd0: read 4125KB/s (4125KB/s), 128KB buffer, UDMA33
> acd0: Reads: CDR, CDRW, CDDA stream, packet
> acd0: Writes:
> acd0: Audio: play, 256 volume levels
> acd0: Mechanism: ejectable tray, unlocked
> acd0: Medium: no/blank disc
> ATA PseudoRAID loaded
> uhub0: 4 ports with 4 removable, self powered
> GEOM: new disk ad0
> GEOM: ad0s2: geometry does not match label (255h,63s != 16h,63s).
> Trying to mount root from ufs:/dev/ad0s2a
> start_init: trying /sbin/init
> em0: Link is up 1000 Mbps Full Duplex
> em0: Link is Down
> em0: Link is up 1000 Mbps Full Duplex
> splash: image decoder found: daemon_saver

CC'ing Yong-Hyeon PYUN who may be able to help with this.

If you could also provide "pciconf -lvbc" output that would be useful.

--
| Jeremy Chadwick j...@koitsu.org |
| UNIX Systems Administrator http://jdc.koitsu.org/ |
| Mountain View, CA, US |
| Making life hard for others since 1977. PGP 4BD6C0CB |
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stabl...@freebsd.org"

[Glen Barber]

On Sat, May 11, 2013 at 10:57:44PM -0400, Michael L. Squires wrote:
> I upgraded to FreeBSD 8.4-RC3 and noticed a problem with the fxp
> driver on an older Supermicro single CPU single core Xeon
> motherboard.
>

> [...]

> Copyright (c) 1992-2013 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 8.4-PRERELEASE #45: Fri May 10 09:43:40 EDT 2013
> ro...@familysquires.net:/usr/obj/usr/src/sys/NEWGATE i386

Your attached dmesg of -RC3 is not -RC3, it is 8-STABLE. At this point,
there have been changes between the stable/8 and releng/8.4 branches
enough say that the two have diverged, and the stable/8 code is _not_
what will be the 8.4-RELEASE.

While your issue does concern me, it is still unclear that this is
a problem with the upcoming 8.4-RELEASE. Can you please try upgrading
to the releng/8.4 branch to see if this issue persists?

Glen

[Michael L. Squires]

Here is pciconf -lvbc under 8.3-RELEASE p8:

hostb0@pci0:0:0:0: class=0x060000 card=0x00000000 chip=0x00171166 rev=0x32 hdr=0x00
vendor = 'ServerWorks (Was: Reliance Computer Corp)'
device = 'CMIC-SL'
class = bridge
subclass = HOST-PCI
hostb1@pci0:0:0:1: class=0x060000 card=0x00000000 chip=0x00171166 rev=0x00 hdr=0x00
vendor = 'ServerWorks (Was: Reliance Computer Corp)'
device = 'CMIC-SL'
class = bridge
subclass = HOST-PCI
em0@pci0:0:1:0: class=0x020000 card=0x10018086 chip=0x10268086 rev=0x04 hdr=0x00
vendor = 'Intel Corporation'
device = 'Gigabit Ethernet Controller (82545ep)'
class = network
subclass = ethernet
bar [10] = type Memory, range 64, base 0xfeb60000, size 131072, enabled
bar [18] = type Memory, range 64, base 0xfeb00000, size 262144, enabled
bar [20] = type I/O Port, range 32, base 0xe000, size 64, enabled
cap 01[dc] = powerspec 2 supports D0 D3 current D0
cap 07[e4] = PCI-X 64-bit supports 133MHz, 2048 burst read, 1 split transaction
vgapci0@pci0:0:6:0: class=0x030000 card=0x00081002 chip=0x47521002 rev=0x27 hdr=0x00
vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.'
device = 'ATI On-Board VGA for HP Proliant 350 G3 (Rage XL PCI)'
class = display
subclass = VGA
bar [10] = type Memory, range 32, base 0xfd000000, size 16777216, enabled
bar [14] = type I/O Port, range 32, base 0xe800, size 256, enabled
bar [18] = type Memory, range 32, base 0xfebff000, size 4096, enabled
cap 01[5c] = powerspec 2 supports D0 D1 D2 D3 current D0
fxp0@pci0:0:7:0: class=0x020000 card=0x10508086 chip=0x12298086 rev=0x10 hdr=0x00
vendor = 'Intel Corporation'
device = '82550/1/7/8/9 EtherExpress PRO/100(B) Ethernet Adapter'
class = network
subclass = ethernet
bar [10] = type Memory, range 32, base 0xfebfd000, size 4096, enabled
bar [14] = type I/O Port, range 32, base 0xe400, size 64, enabled
bar [18] = type Memory, range 32, base 0xfeb80000, size 131072, enabled
cap 01[dc] = powerspec 2 supports D0 D1 D2 D3 current D0
bge0@pci0:0:8:0: class=0x020000 card=0x800914e4 chip=0x16a614e4 rev=0x02 hdr=0x00
vendor = 'Broadcom Corporation'
device = 'BCM5702X NetXtreme Gigabit Ethernet'
class = network
subclass = ethernet
bar [10] = type Memory, range 64, base 0xfebe0000, size 65536, enabled
cap 07[40] = PCI-X 64-bit supports 133MHz, 2048 burst read, 1 split transaction
cap 01[48] = powerspec 2 supports D0 D3 current D0
cap 03[50] = VPD
cap 05[58] = MSI supports 8 messages, 64 bit
hostb2@pci0:0:15:0: class=0x060000 card=0x425515d9 chip=0x02031166 rev=0xa0 hdr=0x00
vendor = 'ServerWorks (Was: Reliance Computer Corp)'
device = 'PCI to ISA Bridge (CSB6)'
class = bridge
subclass = HOST-PCI
atapci0@pci0:0:15:1: class=0x01018a card=0x021211d9 chip=0x02131166 rev=0xa0 hdr=0x00
vendor = 'ServerWorks (Was: Reliance Computer Corp)'
device = 'OSB6/CSB6 PCI EIDE Controller'
class = mass storage
subclass = ATA
bar [10] = type I/O Port, range 32, base 0x1f0, size 8, enabled
bar [14] = type I/O Port, range 32, base 0x3f4, size 1, enabled
bar [18] = type I/O Port, range 32, base 0x170, size 8, enabled
bar [1c] = type I/O Port, range 32, base 0x374, size 1, enabled
bar [20] = type I/O Port, range 32, base 0xffa0, size 16, enabled
ohci0@pci0:0:15:2: class=0x0c0310 card=0x425515d9 chip=0x02211166 rev=0x05 hdr=0x00
vendor = 'ServerWorks (Was: Reliance Computer Corp)'
device = 'OHCI Compliant USB Controller (OSB6)'
class = serial bus
subclass = USB
bar [10] = type Memory, range 32, base 0xfebfe000, size 4096, enabled
isab0@pci0:0:15:3: class=0x060100 card=0x425515d9 chip=0x02271166 rev=0x00 hdr=0x00
vendor = 'ServerWorks (Was: Reliance Computer Corp)'
device = 'PCI Bridge (CSB6)'
class = bridge
subclass = PCI-ISA

[Michael L. Squires]

I installed RELENG_8_4 using cvsup (yes, I'm planning on updating) and got
8.4-BETA; this had the same behavior as 8-STABLE.

I tried booting the 8.3-RELEASE p8 kernel and got the same behavior, which
makes me wonder if I had made some earlier mistake. I reinstalled
8.3-RELEASE p8 (world and kernel) from source and the system is now
operating normally.

The differences between the kernel file I'm using and GENERIC are that I
have options for "ipfirewall" and the "amd" driver for the AMD 53C974 and
do not have devices "esp" nor "isci" (revised amd and iscsi). I'm going
to revise my kernel file to be more up-to-date and will test that.

I'm not having problems with two other systems, one a Tyan S4882 with 4
single-core Opterons and a Tyan S2882 with two dual-core Opterons.
Neither one uses the "fxp" driver; both are operating in x64 mode.

Mike Squires
mi...@siralan.org
UN*X at home since 1986

[Glen Barber]

On Sun, May 12, 2013 at 09:50:18PM -0400, Michael L. Squires wrote:
> I installed RELENG_8_4 using cvsup (yes, I'm planning on updating)
> and got 8.4-BETA; this had the same behavior as 8-STABLE.
>

Right. releng/8.4 is not exported to cvsup. Please update your tree
with svn or svnup (net/svnup in ports).

If 'uname -a' shows -BETA*, that is older than -PRERELEASE.

Glen

[YongHyeon PYUN]

On Sat, May 11, 2013 at 10:57:44PM -0400, Michael L. Squires wrote:
> I upgraded to FreeBSD 8.4-RC3 and noticed a problem with the fxp driver on
> an older Supermicro single CPU single core Xeon motherboard.
>

> I know that 8.3-Release does not have this issue, but don't know when in
> the updates to that release the regression was introduced.
>
> I use the fxp driver to connect to a Motorola Surfboard cable modem, and
> immediately saw the following occur many times:
>
> May 10 23:00:04 familysquires kernel: fxp0: link state changed to DOWN
> May 10 23:00:04 familysquires dhclient: New Subnet Mask (fxp0):
> 255.255.240.0
> May 10 23:00:04 familysquires dhclient: New Broadcast Address (fxp0):
> 255.255.25
> 5.255
> May 10 23:00:04 familysquires dhclient: New Routers (fxp0): xx.xxx.xxx.1
> May 10 23:00:06 familysquires kernel: fxp0: link state changed to UP
> May 10 23:00:22 familysquires dhclient: New IP Address (fxp0):
> xx.xxx.xxx.163
> May 10 23:00:22 familysquires kernel: fxp0: link state changed to DOWN
> May 10 23:00:22 familysquires dhclient: New Subnet Mask (fxp0):
> 255.255.240.0
> May 10 23:00:22 familysquires dhclient: New Broadcast Address (fxp0):
> 255.255.255.255
> May 10 23:00:22 familysquires dhclient: New Routers (fxp0): xx.xxx.xxx.1
> May 10 23:00:24 familysquires kernel: fxp0: link state changed to UP
>
> repeated without end.

If you assign static IP address, fxp(4) works?

>
> I reinsalled 8.3-Release p8
>
> FreeBSD familysquires.net 8.3-RELEASE-p8 FreeBSD 8.3-RELEASE-p8 #46: Sat
> May 11 00:05:26 EDT 2013
>
> which ended the string up fxp up/down messages. This kernel has now
> operated for 24 hours without generating this error.

There were several fxp(4)changes made since FreeBSD 8.3-RELEASE but
I don't see any fxp(4) commits that may result in DHCP issue above.
I recall there was a dhclient(8) change that makes dhclient track
link state. Could you rebuild dhclient(8) and try again without
that change(i.e. locally back out r247336)?

>
> I've attached a verbose dmesg from 8.4-RC3 and a standard dmesg from
> 8.3-Release p8, and can provide whatever else you need.
>
> This is not a critical issue for me. The system has an unused bge interface
> (replaced by an Intel em0 interface during a previous bout of a problem with
> the bge driver).
>
> Mike Squires
> mi...@siralan.org

[Michael L. Squires]

I'm not sure this is a kernel issue.

I re-installed 8.3Release p8 (have to get work done!) and then installed a
8.4 Prerelease kernel (I'm still running cvsup, going to svn is a number
of crisis problems down from the list of things to fix today).

Booted with the 8.4 Prerelease kernel but using the 8.3R p8 world - no
problems with fxp0.

I've tried that twice, same results.

This suggests to me that the problem may not be in 8.4 at all, but in some
weirdness of my setup.

The motherboard is old; it's one of the Supermicro Xeon boards using the
Serverworks chipset which they had to produce when the Intel support
chipset turned out to be buggy, which is a number of years ago.

I have another box at work which I will set up as my NAT box (the system
in question is my NAT box) from scratch with 8.4 and then take the current
box off-line, and then reinstall 8.4 from scratch on that system. When
that is done I'll report.

This probably won't happen until later this week, Friday.

No issues with 8.4 with the other two systems at home, one a Tyan S4882
and the other a Tyan S2882.

Mike Squires

[Craig Rodrigues]

I recently upgraded one of my systems from FreeBSD 7.4 to FreeBSD releng/8,
and had DHCP problems.
My system though is running a bge NIC, not fxp.
I don't know if this solution can help your case, but I found
that this helped me. I added the following line to my /etc/rc.conf:

synchronous_dhclient="YES"

Without that line, my system would not boot up properly with networking
working.

--
Craig

[Michael L. Squires]

The problem is not with the kernel/motherboard combination but with the
world/motherboard combination.

8.3-R p8 with the 8.3R p8 world works fine.

8.4-Prerelease (what I get using cvsup "8_4") works fine.

8.3R p8 with the 8.4 Pre world has DHCP problems (see example below)

8.4 Pre with the 8.4 Pre world has the same problems.

I'm currently running 8.3R p8 while trying to get the backup 1U to work,
having problems with booting (8.4 RC3 installs fine).

May 12 19:00:01 familysquires kernel: fxp0: link state changed to UP
May 12 19:00:01 familysquires kernel: fxp0: link state changed to DOWN
May 12 19:00:01 familysquires dhclient: New IP Address (fxp0):
xx.xxx.xxx.163
May 12 19:00:01 familysquires dhclient: New Subnet Mask (fxp0):
255.255.240.0
May 12 19:00:01 familysquires dhclient: New Broadcast Address (fxp0):
255.255.25
5.255
May 12 19:00:01 familysquires dhclient: New Routers (fxp0): xxx.xxx.xxx.1
May 12 19:00:03 familysquires kernel: fxp0: link state changed to UP
May 12 19:00:03 familysquires dhclient: New IP Address (fxp0):
xx.xxx.xxx.163
May 12 19:00:03 familysquires kernel: fxp0: link state changed to DOWN
May 12 19:00:03 familysquires dhclient: New Subnet Mask (fxp0):
255.255.240.0
May 12 19:00:03 familysquires dhclient: New Broadcast Address (fxp0):
255.255.25
5.255
May 12 19:00:03 familysquires dhclient: New Routers (fxp0): xxx.xxx.xxx.1

It will be next Wednesday before I can get to replacing the existing 8.3R p8
box.

The suggestion to use "synchronous_dhclient="YEs"" did not help.

I'll be trying fixed IP briefly this afternoon.

Mike Squires
mi...@siralan.org
UNI*X at home
since 1986

[Michael L. Squires]

I've just tested 8.4-RC3 using a different Supermicro 1U box with a fresh
installation of 8.4-RC3. I had problems with the installation, wouldn't
boot until I used a Windows 98 FDISK to write a master boot record (no
idea why; this system uses an Adaptec SATA 1.5 6-channel PCI-X board with two
drives in RAID 1).

Using the em0 interface there are no problems with DHCP; when I switch to
the fxp0 interface the interface starts going up/down in the same manner as
reported.

The problem appears associated with "world", not with the kernel (running
the 8.4 kernel with the 8.3 world does not have this problem).

This motherboard is an X5DPL-iGM with 2 Xeon 2.8GHz CPUs and 4 GB of RAM.
The other unit (an earlier board) has a Serverworks chipset with a single
Xeon CPU but also with a 100Mbit Intel Pro100 Ethernet port and a 1000Mbit
Intel Pro1000 Ethernet port.

This unit isn't doing anything useful, so testing isn't a problem.

Mike Squires
mi...@siralan.org

[Jeremy Chadwick]

On Thu, May 23, 2013 at 08:18:33PM -0400, Michael L. Squires wrote:
> I've just tested 8.4-RC3 using a different Supermicro 1U box with a fresh
> installation of 8.4-RC3. I had problems with the installation, wouldn't
> boot until I used a Windows 98 FDISK to write a master boot record
> (no idea why; this system uses an Adaptec SATA 1.5 6-channel PCI-X
> board with two
> drives in RAID 1).
>
> Using the em0 interface there are no problems with DHCP; when I
> switch to the fxp0 interface the interface starts going up/down in
> the same manner as reported.
>
> The problem appears associated with "world", not with the kernel (running
> the 8.4 kernel with the 8.3 world does not have this problem).
>
> This motherboard is an X5DPL-iGM with 2 Xeon 2.8GHz CPUs and 4 GB of RAM.
> The other unit (an earlier board) has a Serverworks chipset with a single
> Xeon CPU but also with a 100Mbit Intel Pro100 Ethernet port and a 1000Mbit
> Intel Pro1000 Ethernet port.
>
> This unit isn't doing anything useful, so testing isn't a problem.

Mike, Yong-Hyeon asked you a very important question which you didn't
answer:

http://lists.freebsd.org/pipermail/freebsd-stable/2013-May/073458.html

If you assign a static IP address, does fxp0 behave properly?

I'm also re-adding Yong-Hyeon to the CC list here.

--
| Jeremy Chadwick j...@koitsu.org |
| UNIX Systems Administrator http://jdc.koitsu.org/ |
| Mountain View, CA, US |
| Making life hard for others since 1977. PGP 4BD6C0CB |

[Glen Barber]

On Thu, May 23, 2013 at 06:09:43PM -0700, Jeremy Chadwick wrote:
> On Thu, May 23, 2013 at 08:18:33PM -0400, Michael L. Squires wrote:
> > I've just tested 8.4-RC3 using a different Supermicro 1U box with a fresh
> > installation of 8.4-RC3. I had problems with the installation, wouldn't
> > boot until I used a Windows 98 FDISK to write a master boot record
> > (no idea why; this system uses an Adaptec SATA 1.5 6-channel PCI-X
> > board with two
> > drives in RAID 1).
> >
> > Using the em0 interface there are no problems with DHCP; when I
> > switch to the fxp0 interface the interface starts going up/down in
> > the same manner as reported.
> >
> > The problem appears associated with "world", not with the kernel (running
> > the 8.4 kernel with the 8.3 world does not have this problem).
> >
> > This motherboard is an X5DPL-iGM with 2 Xeon 2.8GHz CPUs and 4 GB of RAM.
> > The other unit (an earlier board) has a Serverworks chipset with a single
> > Xeon CPU but also with a 100Mbit Intel Pro100 Ethernet port and a 1000Mbit
> > Intel Pro1000 Ethernet port.
> >
> > This unit isn't doing anything useful, so testing isn't a problem.
>
> Mike, Yong-Hyeon asked you a very important question which you didn't
> answer:
>
> http://lists.freebsd.org/pipermail/freebsd-stable/2013-May/073458.html
>
> If you assign a static IP address, does fxp0 behave properly?
>
> I'm also re-adding Yong-Hyeon to the CC list here.
>

At this point, I am not convinced we have a problem with what will turn
out to be 8.4-RELEASE.

There have been several attempts to ensure the upgraded version is
actually 8.4-RC3 (and again, 'uname -a' is not provided in this
email...).

I find it very hard to believe that we have exactly one fxp(4) user
upgrading to 8.4-*.

I'd really like to make sure that this is not an issue that will affect
an uncountable number of users, but truthfully, at this point have to
consider it a local configuration problem.

Glen

[Jeremy Chadwick]

I have numerous Supermicro 1U boxes sitting in my garage from closing
down my hosting organisation back in August 2012. I am certain one or
two of them have Intel NICs that use fxp(4) -- the problem is that I
don't know what exact NIC and PHY model they use.

From what I can tell, there are at least two systems Mike has which
experience this anomaly. One of those systems' dmesg:

http://lists.freebsd.org/pipermail/freebsd-stable/2013-May/073440.html

The relevant lines start at "fxp0: <Intel 82551 ..." and continue all
the way down to "pci0:0:8:0: bad VPD cksum, remain 14". I'm not sure if
the bad VPD checksum message is relevant to the fxp0 device or not.

The 2nd system is mentioned above/in this post:

http://lists.freebsd.org/pipermail/freebsd-stable/2013-May/073530.html

But there's no verbose dmesg etc. for the 2nd system so I don't know if
it has the same NIC/PHY.

The model of NIC and PHY matters greatly; most users don't seem to
realise how important this is, they think in terms of "Intel vs.
Broadcom vs. Realtek".

Output from "pciconf -lvbc", specifically the lines relevant to the fxp0
device, from both systems, would be highly beneficial.

In the meantime, I'll head down to my garage to see if I can find those
fxp(4) boxes and see if they're 85551s (I sure hope I haven't pulled the
CPUs/RAM from them). If I find a match, I can try to reproduce this.

[Glen Barber]

My understanding from the start of this thread is that "both" machines
are actually the same machine, but with different combinations of
userland/kernel. (No, not arguing anything - only one person can answer
if my understanding is correct or not.)

> The model of NIC and PHY matters greatly; most users don't seem to
> realise how important this is, they think in terms of "Intel vs.
> Broadcom vs. Realtek".
>
> Output from "pciconf -lvbc", specifically the lines relevant to the fxp0
> device, from both systems, would be highly beneficial.
>
> In the meantime, I'll head down to my garage to see if I can find those
> fxp(4) boxes and see if they're 85551s (I sure hope I haven't pulled the
> CPUs/RAM from them). If I find a match, I can try to reproduce this.
>

It has been quite costly now (time) waiting for information on this
particular issue at this point, unfortunately.

Glen

[Jeremy Chadwick]

I made a typo above -- I meant to say "82551" not "85551". Anyways...

Hearing you on FM. :-)

Inventory of old systems of mine didn't take long. I had 3 systems;
one used dual Broadcom NICs (so that's out), the other used dual Intel
82541EI NICs (which is driven by em(4) so that's out). The remaining
system:

- Supermicro 5010E
-- Have CPU + RAM
-- NIC: Intel DA82562EM
-- NIC: Intel GD82559
-- Supermicro site states (1) Intel 82559 and (1) Intel VE CNR
-- http://www.supermicro.com/products/system/1U/5010/SYS-5010E.cfm
-- fxp(4) driver claims to support 82562EM and 82559
-- http://svnweb.freebsd.org/base/stable/8/sys/dev/fxp/if_fxp.c?revision=242909&view=markup

However neither of these are 82551.

Summary: I do have a system I can use to test fxp(4), however it does
not use the Intel 82551 (in case this turns out to be a chip-specific
driver bug).

If someone wants me to test DHCP via fxp(4) on the above system (I can
do so with both NICs), just let me know; it should only take me half an
hour or so.

I'll politely wait for someone to say "please do so" else won't bother.

[Glen Barber]

On Thu, May 23, 2013 at 08:38:06PM -0700, Jeremy Chadwick wrote:
> If someone wants me to test DHCP via fxp(4) on the above system (I can
> do so with both NICs), just let me know; it should only take me half an
> hour or so.
>
> I'll politely wait for someone to say "please do so" else won't bother.
>

For the sake of completeness...

"Please do so." :)

Glen

[Jeremy Chadwick]

Issue reproduced 100% reliably, even within sysinstall.

ISO image used:

ftp://ftp4.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/8.4/FreeBSD-8.4-RC3-i386-disc1.iso

I just chose to Configure the system, selected Networking, chose NO to
the IPv6 configuration choice, and YES to the DHCP configuration choice,
then hit Alt-F2 to watch relevant output.

This was the result:

http://imgbin.org/index.php?page=image&id=13718

...with the fxp0 physif up/down messages continuing indefinitely.

fxp0 on the system is the Intel 82559. Shot of console's dmesg:

http://imgbin.org/index.php?page=image&id=13720

Nothing is connected to fxp1.

Key points for those asking me to help debug:

- I only have VGA console on this box
- I do not have an IDE hard disk of any sort for temporary OS
installation, setup, kernel testing, etc..
- The system cannot boot USB media of any sort, so memsticks are out
- The ATAPI drive is CD-only; there is no DVD support, so there's no
easy way to get a "real" shell with full utilities (i.e. "Fixit")

So if someone wants to take a stab at this, they'll need to do so and
make me an ISO. Sorry that I can't make things easier. :-(

This definitely needs to get fixed before 8.4-RELEASE.

[Jeremy Chadwick]

On Thu, May 23, 2013 at 09:40:35PM -0700, Jeremy Chadwick wrote:
> On Thu, May 23, 2013 at 11:42:44PM -0400, Glen Barber wrote:
> > On Thu, May 23, 2013 at 08:38:06PM -0700, Jeremy Chadwick wrote:
> > > If someone wants me to test DHCP via fxp(4) on the above system (I can
> > > do so with both NICs), just let me know; it should only take me half an
> > > hour or so.
> > >
> > > I'll politely wait for someone to say "please do so" else won't bother.
> > >
> >
> > For the sake of completeness...
> >
> > "Please do so." :)
>
> Issue reproduced 100% reliably, even within sysinstall.
>

> {snip}

Forgot to add:

This issue ONLY happens when using DHCP.

Statically assigning the IP address works fine; fxp0 goes down once,
up once, then stays up indefinitely.

I also tested network I/O in the statically-assigned scenario. Pinging
the box from another machine on the LAN:

$ ping 192.168.1.192
PING 192.168.1.192 (192.168.1.192): 56 data bytes
64 bytes from 192.168.1.192: icmp_seq=0 ttl=64 time=0.180 ms
64 bytes from 192.168.1.192: icmp_seq=1 ttl=64 time=0.138 ms
64 bytes from 192.168.1.192: icmp_seq=2 ttl=64 time=0.214 ms
64 bytes from 192.168.1.192: icmp_seq=3 ttl=64 time=0.165 ms
64 bytes from 192.168.1.192: icmp_seq=4 ttl=64 time=0.114 ms
^C
--- 192.168.1.192 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.114/0.162/0.214/0.034 ms

[Glen Barber]

On Thu, May 23, 2013 at 09:40:35PM -0700, Jeremy Chadwick wrote:

> [...]

> So if someone wants to take a stab at this, they'll need to do so and
> make me an ISO. Sorry that I can't make things easier. :-(
>
> This definitely needs to get fixed before 8.4-RELEASE.
>

*sigh*....

At this point, it is highly unlikely this will be fixed before
8.4-RELEASE. We are _far_ too deep into the release cycle. In fact, we
are effectively done with the release, and waiting on release notes to
be completed.

I think this will likely be included in errata notes for the release.

It is very unfortunate that this waited so long to be reported, as much
time has passed since 8.4-BETA1...

Glen

[Charles Sprickman]

On May 24, 2013, at 12:40 AM, Jeremy Chadwick wrote:

> On Thu, May 23, 2013 at 11:42:44PM -0400, Glen Barber wrote:
>> On Thu, May 23, 2013 at 08:38:06PM -0700, Jeremy Chadwick wrote:
>>> If someone wants me to test DHCP via fxp(4) on the above system (I can
>>> do so with both NICs), just let me know; it should only take me half an
>>> hour or so.
>>>
>>> I'll politely wait for someone to say "please do so" else won't bother.
>>>
>>
>> For the sake of completeness...
>>
>> "Please do so." :)
>
> Issue reproduced 100% reliably, even within sysinstall.
>
> ISO image used:
>
> ftp://ftp4.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/8.4/FreeBSD-8.4-RC3-i386-disc1.iso
>
> I just chose to Configure the system, selected Networking, chose NO to
> the IPv6 configuration choice, and YES to the DHCP configuration choice,
> then hit Alt-F2 to watch relevant output.
>
> This was the result:
>
> http://imgbin.org/index.php?page=image&id=13718
>
> ...with the fxp0 physif up/down messages continuing indefinitely.
>
> fxp0 on the system is the Intel 82559. Shot of console's dmesg:
>
> http://imgbin.org/index.php?page=image&id=13720
>
> Nothing is connected to fxp1.
>
> Key points for those asking me to help debug:
>
> - I only have VGA console on this box
> - I do not have an IDE hard disk of any sort for temporary OS

There are machines in my garage that are supposed to go to the recycling dump.

I have old boot messages from one P-III box that indicates there's an Intel 82559 chip onboard.

I do have drives, and I do have a CD drive, although I'm uncertain as to its condition.

I can make a serial console available.

USB booting is out of the question.

I am currently out of blank CD-R's, but might be able to find my meager stash of CD-RWs that I couldn't find last week… Failing that, can I dd a memstick image onto a drive?

Mr. Barber loves these machines, they are his favorites. :)

C

[Jeremy Chadwick]

On Fri, May 24, 2013 at 12:56:20AM -0400, Glen Barber wrote:
> On Thu, May 23, 2013 at 09:40:35PM -0700, Jeremy Chadwick wrote:
> > [...]
> > So if someone wants to take a stab at this, they'll need to do so and
> > make me an ISO. Sorry that I can't make things easier. :-(
> >
> > This definitely needs to get fixed before 8.4-RELEASE.
> >
>
> *sigh*....
>
> At this point, it is highly unlikely this will be fixed before
> 8.4-RELEASE. We are _far_ too deep into the release cycle. In fact, we
> are effectively done with the release, and waiting on release notes to
> be completed.
>
> I think this will likely be included in errata notes for the release.

I urge you to meet with others in Release Engineering and discuss this
fully. This is major enough that, once fixed, it warrants an immediate
binary update (to the kernel + if_fxp.ko) pushed out via freebsd-update.

fxp(4) is a commonly-used driver; it isn't something rare/uncommon.

Also remember at this stage we don't know if it's a specific PHY model
or specific NIC model (or series) which triggers it. For all we know it
could affect everything that fxp(4) drives.

Please don't forget that FreeBSD has a very well-established history of
having rock-solid Intel NIC support. Sure, mistakes happen, we're
human, bugs get introduced, but this does not bode well -- meaning I
would expect Slashdot et al to pick up on this.

> It is very unfortunate that this waited so long to be reported, as much
> time has passed since 8.4-BETA1...

This is what happens when people socially proliferate the belief that
"RELEASE is rock solid/stable, don't run stable/X" -- the number of
people who test what changes between RELEASE builds is vastly smaller
comparatively. I've only been saying this for the past 15 years, so
it's even more unfortunate that people keep believing it. :/

[Glen Barber]

Speaking entirely on behalf of myself now...

On Thu, May 23, 2013 at 10:11:39PM -0700, Jeremy Chadwick wrote:
> > I think this will likely be included in errata notes for the release.
>
> I urge you to meet with others in Release Engineering and discuss this
> fully. This is major enough that, once fixed, it warrants an immediate
> binary update (to the kernel + if_fxp.ko) pushed out via freebsd-update.
>

It can be solved with a -pN update after 8.4-RELEASE is out.

> fxp(4) is a commonly-used driver; it isn't something rare/uncommon.
>

Right. So why do we have exactly 1 (now 2) reports of this?

We are already behind the release schedule. There have been 4 "Hey,
the next release is available for testing, so please do so"
announcements.

At this stage, holding up this release for last-minute (not last-minute
code changes, either) reports will do nothing for the FreeBSD Project as
a whole but hold up the remaining releases scheduled for the remainder
of the year.

> Also remember at this stage we don't know if it's a specific PHY model
> or specific NIC model (or series) which triggers it. For all we know it
> could affect everything that fxp(4) drives.
>

Right. Without this information, we simply cannot hold off the release
indefinitely. I've asked the OP to do some very specific things, all
without yielding results, as well as replies from others.

> Please don't forget that FreeBSD has a very well-established history of
> having rock-solid Intel NIC support. Sure, mistakes happen, we're
> human, bugs get introduced, but this does not bode well -- meaning I
> would expect Slashdot et al to pick up on this.
>

This is not a last minute bug. This is a last minute report, sadly.

Glen

[Josh Paetzel]

At this point fxp hardware is over a decade old. I'm loath to introduce delays at the end of the runway for this issue.

Keep in mind that delays to 8.4 are pushed directly on to delays for 9.2, which won't be started until 8.4 is completed, and is desperately needed. (9.1 doesn't have drivers for common shipping hardware for example). Factors like these as well as the age of fxp hardware drive my decision to complete 8.4 and push this fix in to EN territory.

Thanks,

Josh Paetzel
FreeBSD - The Power to Serve

[Hiroki Sato]

Jeremy Chadwick <j...@koitsu.org> wrote
in <20130524044...@icarus.home.lan>:

jd> On Thu, May 23, 2013 at 11:42:44PM -0400, Glen Barber wrote:
jd> > On Thu, May 23, 2013 at 08:38:06PM -0700, Jeremy Chadwick wrote:
jd> > > If someone wants me to test DHCP via fxp(4) on the above system (I can
jd> > > do so with both NICs), just let me know; it should only take me half an
jd> > > hour or so.
jd> > >
jd> > > I'll politely wait for someone to say "please do so" else won't bother.
jd> > >
jd> >
jd> > For the sake of completeness...
jd> >
jd> > "Please do so." :)
jd>
jd> Issue reproduced 100% reliably, even within sysinstall.
jd>
jd> ISO image used:
jd>
jd> ftp://ftp4.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/8.4/FreeBSD-8.4-RC3-i386-disc1.iso
jd>
jd> I just chose to Configure the system, selected Networking, chose NO to
jd> the IPv6 configuration choice, and YES to the DHCP configuration choice,
jd> then hit Alt-F2 to watch relevant output.
jd>
jd> This was the result:
jd>
jd> http://imgbin.org/index.php?page=image&id=13718
jd>
jd> ...with the fxp0 physif up/down messages continuing indefinitely.
jd>
jd> fxp0 on the system is the Intel 82559. Shot of console's dmesg:
jd>
jd> http://imgbin.org/index.php?page=image&id=13720

Hmm, I tried RC3 on one of my test machines which has fxp0:

----
FreeBSD 8.4-RC3 #0 r250307: Tue May 7 04:40:16 UTC 2013
ro...@bake.isc.freebsd.org:/usr/obj/usr/src/sys/GENERIC i386
...
fxp0: <Intel 82559 Pro/100 Ethernet> port 0x2800-0x283f mem 0xc4ffe000-0xc4ffefff,0xc4e00000-0xc4efffff irq 10 at device 3.0 on pci0

miibus0: <MII bus> on fxp0
inphy0: <i82555 10/100 media interface> PHY 1 on miibus0
inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow

fxp0: Ethernet address: 00:02:a5:eb:14:93
fxp0: [ITHREAD]

fxp0@pci0:0:3:0: class=0x020000 card=0xb1340e11 chip=0x12298086 rev=0x08 hdr=0x00

vendor = 'Intel Corporation'
device = '82550/1/7/8/9 EtherExpress PRO/100(B) Ethernet Adapter'
class = network
subclass = ethernet

dev.inphy.0.%desc: i82555 10/100 media interface
dev.inphy.0.%driver: inphy
dev.inphy.0.%location: phyno=1
dev.inphy.0.%pnpinfo: oui=0xaa00 model=0x15 rev=0x4
dev.inphy.0.%parent: miibus0
----

It worked well for a PXE boot at least. I will give dhclient a try
later.

-- Hiroki

[Jeremy Chadwick]

On Fri, May 24, 2013 at 01:24:24AM -0400, Glen Barber wrote:
> Speaking entirely on behalf of myself now...
>
> On Thu, May 23, 2013 at 10:11:39PM -0700, Jeremy Chadwick wrote:
> > > I think this will likely be included in errata notes for the release.
> >
> > I urge you to meet with others in Release Engineering and discuss this
> > fully. This is major enough that, once fixed, it warrants an immediate
> > binary update (to the kernel + if_fxp.ko) pushed out via freebsd-update.
> >
>
> It can be solved with a -pN update after 8.4-RELEASE is out.

Not that I'm calling the shots or anything, but:

Let's go with that, combined with an included mention in the Errata
section of the Release Notes as you initially mentioned.

Sorry I can't be of more help; Charles' environment sounds like it would
be better-suited for testing, and I'm sure Michael can test out a patch
if/when someone gets around to poking at things.

[YongHyeon PYUN]

On Thu, May 23, 2013 at 09:49:19PM -0700, Jeremy Chadwick wrote:
> On Thu, May 23, 2013 at 09:40:35PM -0700, Jeremy Chadwick wrote:
> > On Thu, May 23, 2013 at 11:42:44PM -0400, Glen Barber wrote:
> > > On Thu, May 23, 2013 at 08:38:06PM -0700, Jeremy Chadwick wrote:
> > > > If someone wants me to test DHCP via fxp(4) on the above system (I can
> > > > do so with both NICs), just let me know; it should only take me half an
> > > > hour or so.
> > > >
> > > > I'll politely wait for someone to say "please do so" else won't bother.
> > > >
> > >
> > > For the sake of completeness...
> > >
> > > "Please do so." :)
> >
> > Issue reproduced 100% reliably, even within sysinstall.
> >
> > {snip}
>
> Forgot to add:
>
> This issue ONLY happens when using DHCP.
>
> Statically assigning the IP address works fine; fxp0 goes down once,
> up once, then stays up indefinitely.

I asked Mike to try backing out dhclient(8) change(r247336) but it
seems he missed that. Jeremy, could you try that?

I guess dhclient(8) does not like flow-control negotiation of
fxp(4) after link establishment.

>
> I also tested network I/O in the statically-assigned scenario. Pinging
> the box from another machine on the LAN:
>
> $ ping 192.168.1.192
> PING 192.168.1.192 (192.168.1.192): 56 data bytes
> 64 bytes from 192.168.1.192: icmp_seq=0 ttl=64 time=0.180 ms
> 64 bytes from 192.168.1.192: icmp_seq=1 ttl=64 time=0.138 ms
> 64 bytes from 192.168.1.192: icmp_seq=2 ttl=64 time=0.214 ms
> 64 bytes from 192.168.1.192: icmp_seq=3 ttl=64 time=0.165 ms
> 64 bytes from 192.168.1.192: icmp_seq=4 ttl=64 time=0.114 ms
> ^C
> --- 192.168.1.192 ping statistics ---
> 5 packets transmitted, 5 packets received, 0.0% packet loss
> round-trip min/avg/max/stddev = 0.114/0.162/0.214/0.034 ms

[Jeremy Chadwick]

On Fri, May 24, 2013 at 02:47:20PM +0900, YongHyeon PYUN wrote:
> On Thu, May 23, 2013 at 09:49:19PM -0700, Jeremy Chadwick wrote:
> > On Thu, May 23, 2013 at 09:40:35PM -0700, Jeremy Chadwick wrote:
> > > On Thu, May 23, 2013 at 11:42:44PM -0400, Glen Barber wrote:
> > > > On Thu, May 23, 2013 at 08:38:06PM -0700, Jeremy Chadwick wrote:
> > > > > If someone wants me to test DHCP via fxp(4) on the above system (I can
> > > > > do so with both NICs), just let me know; it should only take me half an
> > > > > hour or so.
> > > > >
> > > > > I'll politely wait for someone to say "please do so" else won't bother.
> > > > >
> > > >
> > > > For the sake of completeness...
> > > >
> > > > "Please do so." :)
> > >
> > > Issue reproduced 100% reliably, even within sysinstall.
> > >
> > > {snip}
> >
> > Forgot to add:
> >
> > This issue ONLY happens when using DHCP.
> >
> > Statically assigning the IP address works fine; fxp0 goes down once,
> > up once, then stays up indefinitely.
>
> I asked Mike to try backing out dhclient(8) change(r247336) but it
> seems he missed that. Jeremy, could you try that?
>
> I guess dhclient(8) does not like flow-control negotiation of
> fxp(4) after link establishment.

I can't test anything without an ISO -- the system in question is truly
"bare-bones" (no hard disk, can't boot USB memsticks, etc.). I'm not a
good test subject for changes on this one, I'm sorry to say. :-(

If there's some way to disable flow-control negotiation in fxp(4) or
miibus(4) via loader, I can try that, but I don't know what the MIB
name would be.

<ignore me, I'm just pissed off>
If r247336 turns out to be the cause: ironic, as r247336 references PR
166656, which was tested against -- wait for it -- xl(4).

People in *this* thread are saying "screw legacy hardware" yet the PR is
for something as old as the 3C905B? Maybe I should bow out of this
thread before I have an aneurysm.
</ignore>

--
| Jeremy Chadwick j...@koitsu.org |
| UNIX Systems Administrator http://jdc.koitsu.org/ |
| Mountain View, CA, US |
| Making life hard for others since 1977. PGP 4BD6C0CB |

[Craig Rodrigues]

On May 24, 2013 1:58 AM, "Jeremy Chadwick" <j...@koitsu.org> wrote:
>
> I can't test anything without an ISO -- the system in question is truly
> "bare-bones" (no hard disk, can't boot USB memsticks, etc.). I'm not a

> good test subject for changes on this one, I'm afraid.

On another system, if you can set up an NFS root file system of 8.4 and PXE
boot it, then you can help test individual changes to binaries such as
dhclient. See:

http://www.freebsd.org/doc/en/books/handbook/network-pxe-nfs.html

PXE booting environment may or may not repro the problem, but
it would be very helpful if you could try it since you have the right
hardware.

As Glen and Josh have mentioned, unfortunately this is probably too late in
the 8.4 release cycle to fix and will have to be release noted.
--
Craig

[Hiroki Sato]

YongHyeon PYUN <pyu...@gmail.com> wrote
in <2013052405...@michelle.cdnetworks.com>:

py> On Thu, May 23, 2013 at 09:49:19PM -0700, Jeremy Chadwick wrote:
py> > On Thu, May 23, 2013 at 09:40:35PM -0700, Jeremy Chadwick wrote:
py> > > On Thu, May 23, 2013 at 11:42:44PM -0400, Glen Barber wrote:
py> > > > On Thu, May 23, 2013 at 08:38:06PM -0700, Jeremy Chadwick wrote:
py> > > > > If someone wants me to test DHCP via fxp(4) on the above system (I can
py> > > > > do so with both NICs), just let me know; it should only take me half an
py> > > > > hour or so.
py> > > > >
py> > > > > I'll politely wait for someone to say "please do so" else won't bother.
py> > > > >
py> > > >
py> > > > For the sake of completeness...
py> > > >
py> > > > "Please do so." :)
py> > >
py> > > Issue reproduced 100% reliably, even within sysinstall.
py> > >
py> > > {snip}
py> >
py> > Forgot to add:
py> >
py> > This issue ONLY happens when using DHCP.
py> >
py> > Statically assigning the IP address works fine; fxp0 goes down once,
py> > up once, then stays up indefinitely.
py>
py> I asked Mike to try backing out dhclient(8) change(r247336) but it
py> seems he missed that. Jeremy, could you try that?
py>
py> I guess dhclient(8) does not like flow-control negotiation of
py> fxp(4) after link establishment.

Okay, I could reproduce this issue on my box. After invocation of
dhclient(8), a link is up and then state_reboot() drops the link
establishment. Removing the changes around RTM_IFINFO in r247336
makes it work with no problem.

A workaround is specifying the following line in rc.conf:

ifconfig_fxp0="DHCP media 100baseTX mediaopt full-duplex"

-- Hiroki

[Charles Sprickman]

On May 24, 2013, at 1:47 AM, YongHyeon PYUN wrote:

> On Thu, May 23, 2013 at 09:49:19PM -0700, Jeremy Chadwick wrote:
>> On Thu, May 23, 2013 at 09:40:35PM -0700, Jeremy Chadwick wrote:
>>> On Thu, May 23, 2013 at 11:42:44PM -0400, Glen Barber wrote:
>>>> On Thu, May 23, 2013 at 08:38:06PM -0700, Jeremy Chadwick wrote:
>>>>> If someone wants me to test DHCP via fxp(4) on the above system (I can
>>>>> do so with both NICs), just let me know; it should only take me half an
>>>>> hour or so.
>>>>>
>>>>> I'll politely wait for someone to say "please do so" else won't bother.
>>>>>
>>>>
>>>> For the sake of completeness...
>>>>
>>>> "Please do so." :)
>>>
>>> Issue reproduced 100% reliably, even within sysinstall.
>>>
>>> {snip}
>>
>> Forgot to add:
>>
>> This issue ONLY happens when using DHCP.
>>
>> Statically assigning the IP address works fine; fxp0 goes down once,
>> up once, then stays up indefinitely.
>
> I asked Mike to try backing out dhclient(8) change(r247336) but it
> seems he missed that. Jeremy, could you try that?

I have a system up and running and showing the problem (that was
non-trival, just for the record - one machine blew the PSU after
POST, the other refused to boot off an IDE drive, and then required
two CD-ROM drives before I found a functional one, and it took a
good half-hour to find what's apparently the last piece of writable
CD-R media I own).

I am not awesome with svn, but I'll see if I can manually undo
r247336 and give it a spin.

Charles

[Hiroki Sato]

Hiroki Sato <h...@FreeBSD.org> wrote
in <20130524.162926.395...@allbsd.org>:

hr> YongHyeon PYUN <pyu...@gmail.com> wrote
hr> in <2013052405...@michelle.cdnetworks.com>:
hr>
hr> A workaround is specifying the following line in rc.conf:
hr>
hr> ifconfig_fxp0="DHCP media 100baseTX mediaopt full-duplex"

Hmm, I guess this can happen on other NICs when the link negotiation
causes a link-state flap. Is it true?

-- Hiroki

[John]

I can confirm that backing out r247336 on a box running 9.1-stable.r250229
fixes the problem. I hadn't seen the problem before because the box normally
has a static ip address.

John Theus
TheUsGroup.com

[Charles Sprickman]

On May 24, 2013, at 1:47 AM, YongHyeon PYUN wrote:

> On Thu, May 23, 2013 at 09:49:19PM -0700, Jeremy Chadwick wrote:
>> On Thu, May 23, 2013 at 09:40:35PM -0700, Jeremy Chadwick wrote:
>>> On Thu, May 23, 2013 at 11:42:44PM -0400, Glen Barber wrote:
>>>> On Thu, May 23, 2013 at 08:38:06PM -0700, Jeremy Chadwick wrote:
>>>>> If someone wants me to test DHCP via fxp(4) on the above system (I can
>>>>> do so with both NICs), just let me know; it should only take me half an
>>>>> hour or so.
>>>>>
>>>>> I'll politely wait for someone to say "please do so" else won't bother.
>>>>>
>>>>
>>>> For the sake of completeness...
>>>>
>>>> "Please do so." :)
>>>
>>> Issue reproduced 100% reliably, even within sysinstall.
>>>
>>> {snip}
>>
>> Forgot to add:
>>
>> This issue ONLY happens when using DHCP.
>>
>> Statically assigning the IP address works fine; fxp0 goes down once,
>> up once, then stays up indefinitely.
>
> I asked Mike to try backing out dhclient(8) change(r247336) but it
> seems he missed that. Jeremy, could you try that?
>
> I guess dhclient(8) does not like flow-control negotiation of
> fxp(4) after link establishment.

Confirmed here that removing the linkstate stuff from r247336 fixes it.

Before:

May 24 08:00:17 fxptest dhclient: New Subnet Mask (fxp0): 255.255.255.0
May 24 08:00:17 fxptest dhclient: New Broadcast Address (fxp0): 10.3.2.255
May 24 08:00:17 fxptest dhclient: New Routers (fxp0): 10.3.2.1
May 24 08:00:19 fxptest kernel: fxp0: link state changed to UP
May 24 08:00:19 fxptest kernel: fxp0: link state changed to DOWN
May 24 08:00:19 fxptest dhclient: New IP Address (fxp0): 10.3.2.109
May 24 08:00:19 fxptest dhclient: New Subnet Mask (fxp0): 255.255.255.0
May 24 08:00:19 fxptest dhclient: New Broadcast Address (fxp0): 10.3.2.255
May 24 08:00:19 fxptest dhclient: New Routers (fxp0): 10.3.2.1
May 24 08:00:21 fxptest kernel: fxp0: link state changed to UP
May 24 08:00:21 fxptest dhclient: New IP Address (fxp0): 10.3.2.109
May 24 08:00:21 fxptest kernel: fxp0: link state changed to DOWN
May 24 08:00:21 fxptest dhclient: New Subnet Mask (fxp0): 255.255.255.0
May 24 08:00:21 fxptest dhclient: New Broadcast Address (fxp0): 10.3.2.255
May 24 08:00:21 fxptest dhclient: New Routers (fxp0): 10.3.2.1
May 24 08:00:23 fxptest kernel: fxp0: link state changed to UP
May 24 08:00:23 fxptest dhclient: New IP Address (fxp0): 10.3.2.109
May 24 08:00:23 fxptest kernel: fxp0: link state changed to DOWN

After:

May 24 08:07:05 fxptest kernel: fxp0: link state changed to DOWN
May 24 08:07:07 fxptest kernel: fxp0: link state changed to UP
May 24 08:07:12 fxptest dhclient: New IP Address (fxp0): 10.3.2.109
May 24 08:07:12 fxptest kernel: fxp0: link state changed to DOWN
May 24 08:07:12 fxptest dhclient: New Subnet Mask (fxp0): 255.255.255.0
May 24 08:07:12 fxptest dhclient: New Broadcast Address (fxp0): 10.3.2.255
May 24 08:07:12 fxptest dhclient: New Routers (fxp0): 10.3.2.1
May 24 08:07:14 fxptest kernel: fxp0: link state changed to UP
root@fxptest:/usr/home/spork # date
Fri May 24 08:10:32 UTC 2013

Note there is still a down/up/down/up transition on starting dhclient…

Am I correct that the linkstate changes are meant to allow for an automatic retry for a lease when the ethernet connection is dropped? That doesn't seem wrong, it just seems like somewhere we should be waiting a few seconds. It appears that each time dhclient gets a lease, even without the linkstate code, the connection briefly drops…'

Charles

[Michael L. Squires]

I'll have access to the test box on Tuesday, will test a fixed IP number
then. I'm unable to test that here since reinstalling 8.4 on the NAT box
will require eventually reinstalling 8.3-RELEASE and I'm not the only one
using the NAT box for Internet access.

The test box had 8.3-RC3 installed from a downloaded 8.3-RC3 CD using
installation from the CD and with all binaries taken off the CD. No
changes were made after installation and reboot.

I agree that this seems to be a problem only experienced by those still
using the fxp interface and DHCP on a certain subset of Supermicro
systems, which has to be a very small group.

I did find one other reference to a similar problem at

http://forum.pfsense.org/index.php?topic=61102.0)

However, one of the posters was using 8.3p7 which predates my 8.3p8. The
posters also report that this issue affects only a small subset of similar
machines and can be solved by either changing the boot order of the
connected systems (not possible for me) or by forcing fxp to 100Mbit full
duplex, which I haven't tried.

I definitely don't want this issue to hold up 8.4-RELEASE; if it is a
problem it can be fixed for those affected with a patch after release.

Mike Squires
mi...@siralan.org
msqu...@iga.in.gov (where the test box lives)

[John-Mark Gurney]

Just as a bit of history of this change (since I think I may have
introduced part of this issue in 163061 of if_fxp.c)... fxp used to
previously not drop link when you would switch from autoneg to a fixed
media...

The problem with this was that if you booted it always defaults to
autoneg and if your switch was autoneg, then the switch would negotiate
100/full. If you then manually switched fxp to 100/full, things would
be fine till either the switch was reset and/or the cable pulled. Then
when the switch came back and was not be able to autoneg, it then would
make the link 100/half, which of course would cause problems.... I made
this change because it was better to flap the link on media switch, and
force and earlier detection that there was this mismatch between the
switch, then possibly months or years later...

I actually believe all 100Mbps cards should do this on media change in
order to prevent the above issue... Unless of course the card can do both
autoneg and fixed media at the same time, which is probably the problem
with this fxp chip/phy...

Hope this helps with some history behind this issue..

--
John-Mark Gurney Voice: +1 415 225 5579

"All that I will do, has been done, All that I have, has not."

[John]

>
>I agree that this seems to be a problem only experienced by those still
>using the fxp interface and DHCP on a certain subset of Supermicro
>systems, which has to be a very small group.
>

This isn't entirely correct. The test box I used has an Intel Pro 100 pci card
plugged into an Intel motherboard.

fxp0: <Intel 82559 Pro/100 Ethernet> port 0xe000-0xe03f mem 0xfe600000-0xfe600fff,0xfe500000-0xfe5fffff irq 22 at device 1.0 on pci3

miibus0: <MII bus> on fxp0
inphy0: <i82555 10/100 media interface> PHY 1 on miibus0

John Theus
TheUsGroup.com

[YongHyeon PYUN]

Probably not. AFAIK fxp(4) is the only controller that requires two
full resets to support flow control. Multicast programming for
fxp(4) also requires full controller reset so trying to renew its
existing lease for fxp(4) looks wrong to me.

>
> -- Hiroki

[YongHyeon PYUN]

Download
http://svnweb.freebsd.org/base/stable/8/sbin/dhclient/dhclient.c?r1=231278&r2=247336&view=patch

And apply the patch with -R.

[YongHyeon PYUN]

On Sun, May 26, 2013 at 08:38:41PM +0900, YongHyeon PYUN wrote:
> On Fri, May 24, 2013 at 04:36:46PM +0900, Hiroki Sato wrote:
> > Hiroki Sato <h...@FreeBSD.org> wrote
> > in <20130524.162926.395...@allbsd.org>:
> >
> > hr> YongHyeon PYUN <pyu...@gmail.com> wrote
> > hr> in <2013052405...@michelle.cdnetworks.com>:
> > hr>
> > hr> A workaround is specifying the following line in rc.conf:
> > hr>
> > hr> ifconfig_fxp0="DHCP media 100baseTX mediaopt full-duplex"
> >
> > Hmm, I guess this can happen on other NICs when the link negotiation
> > causes a link-state flap. Is it true?
>
> Probably not. AFAIK fxp(4) is the only controller that requires two
> full resets to support flow control. Multicast programming for
> fxp(4) also requires full controller reset so trying to renew its
> existing lease for fxp(4) looks wrong to me.
>

After reading code again, I think the dhclient change may affect
all controllers that don't have protection against multiple
initialization of upper stack. if_init() of driver is called
whenever an IP address is assigned to an interface. The stack could
be changed to call if_init() only when IFF_DRV_RUNNING flag is not
set but that would break old drivers which may require full
controller reset for multicast filter reprogramming. I also guess
there may be several drivers that do not implement reinitialization
protection in arm/mips.
It seems fxp(4)'s simple protection against unnecessary controller
initialization does not work well due to the limitation of
controller. We may be able to improve fxp(4) case but other
old/buggy drivers should be fixed too.

[Michael L. Squires]

On Mon, 27 May 2013, YongHyeon PYUN wrote:

> On Sun, May 26, 2013 at 08:38:41PM +0900, YongHyeon PYUN wrote:
>> On Fri, May 24, 2013 at 04:36:46PM +0900, Hiroki Sato wrote:
>>> Hiroki Sato <h...@FreeBSD.org> wrote
>>> in <20130524.162926.395...@allbsd.org>:
>>>
>>> hr> YongHyeon PYUN <pyu...@gmail.com> wrote
>>> hr> in <2013052405...@michelle.cdnetworks.com>:
>>> hr>
>>> hr> A workaround is specifying the following line in rc.conf:
>>> hr>
>>> hr> ifconfig_fxp0="DHCP media 100baseTX mediaopt full-duplex"
>>>

Sorry I've been offline, two trips last week.

I've installed 8.4-RELEASE on the NAT box with the fxp interface:

FreeBSD familysquires.net 8.4-RELEASE FreeBSD 8.4-RELEASE #54: Sun May 26 22:56:19 EDT 2013 ro...@familysquires.net:/usr/obj/usr/src/sys/NEWGATE i386

and am using the workaround given above which has stopped the fxp interface
cycling on/off.

I'll have access to the other box on Wednesday and will try the other test.

Mike Squires
mi...@siralan.org

[YongHyeon PYUN]

On Mon, May 27, 2013 at 01:02:14PM -0400, Michael L. Squires wrote:
>
> On Mon, 27 May 2013, YongHyeon PYUN wrote:
>
> >On Sun, May 26, 2013 at 08:38:41PM +0900, YongHyeon PYUN wrote:
> >>On Fri, May 24, 2013 at 04:36:46PM +0900, Hiroki Sato wrote:
> >>>Hiroki Sato <h...@FreeBSD.org> wrote
> >>> in <20130524.162926.395...@allbsd.org>:
> >>>
> >>>hr> YongHyeon PYUN <pyu...@gmail.com> wrote
> >>>hr> in <2013052405...@michelle.cdnetworks.com>:
> >>>hr>
> >>>hr> A workaround is specifying the following line in rc.conf:
> >>>hr>
> >>>hr> ifconfig_fxp0="DHCP media 100baseTX mediaopt full-duplex"
> >>>
>
> Sorry I've been offline, two trips last week.
>
> I've installed 8.4-RELEASE on the NAT box with the fxp interface:
>
> FreeBSD familysquires.net 8.4-RELEASE FreeBSD 8.4-RELEASE #54: Sun May 26
> 22:56:19 EDT 2013 ro...@familysquires.net:/usr/obj/usr/src/sys/NEWGATE
> i386
>
> and am using the workaround given above which has stopped the fxp interface
> cycling on/off.
>
> I'll have access to the other box on Wednesday and will try the other test.

Here is patch I'm testing and it seems to work with dhclient on
CURRENT.
Mike, could you try attached patch?

>
> Mike Squires
> mi...@siralan.org

[Michael L. Squires]

Short answer: it didn't work.

Patch did not solve the problem on the home NAT box. I'll try it on the
second 1U box at work tomorrow.

I applied the patch (see below) and recompiled/reinstalled world.

root@familysquires:/usr/src/sys/dev/fxp # uname -a

FreeBSD familysquires.net 8.4-RELEASE FreeBSD 8.4-RELEASE #54: Sun May 26 22:56:19 EDT 2013 ro...@familysquires.net:/usr/obj/usr/src/sys/NEWGATE i386

drwxr-xr-x 236 root 3584 May 28 10:28 ../
-rw-r--r-- 1 root 95366 May 28 10:28 if_fxp.c
-rw-r--r-- 1 root 94968 Mar 28 09:04 if_fxp.c.orig
-rw-r--r-- 1 root 15638 Mar 28 09:04 if_fxpreg.h
-rw-r--r-- 1 root 8717 Mar 28 09:04 if_fxpvar.h
-rw-r--r-- 1 root 23009 Mar 28 09:04 rcvbundl.h

One immediate difference in behavior is that without the modified rc.conf
the box was unable to use ntp to the outside world; it eventually sync'd on
my internal ntp server. With the modified rc.conf the box immediately
sync'd to an ntp server in the outside world.

Result in messages was:

May 28 13:39:24 familysquires kernel: fxp0: link state changed to DOWN
May 28 13:39:24 familysquires dhclient: New Subnet Mask (fxp0): 255.255.240.0
May 28 13:39:24 familysquires dhclient: New Broadcast Address (fxp0): 255.255.25
5.255
May 28 13:39:24 familysquires dhclient: New Routers (fxp0): xx.xxx.xxx.1
May 28 13:39:26 familysquires kernel: fxp0: link state changed to UP
May 28 13:39:26 familysquires dhclient: New IP Address (fxp0): xx.xxx.xxx.163
May 28 13:39:26 familysquires kernel: fxp0: link state changed to DOWN
May 28 13:39:26 familysquires dhclient: New Subnet Mask (fxp0): 255.255.240.0
May 28 13:39:26 familysquires dhclient: New Broadcast Address (fxp0): 255.255.25
5.255
May 28 13:39:26 familysquires dhclient: New Routers (fxp0): xx.xxx.xxx.1
May 28 13:39:28 familysquires kernel: fxp0: link state changed to UP
May 28 13:39:31 familysquires dhclient: New IP Address (fxp0): xx.xxx.xxx.163
May 28 13:39:31 familysquires kernel: fxp0: link state changed to DOWN
May 28 13:39:31 familysquires dhclient: New Subnet Mask (fxp0): 255.255.240.0
May 28 13:39:31 familysquires dhclient: New Broadcast Address (fxp0): 255.255.25
5.255
May 28 13:39:31 familysquires dhclient: New Routers (fxp0): xx.xxx.xxx.1
May 28 13:39:33 familysquires kernel: fxp0: link state changed to UP
May 28 13:39:36 familysquires dhclient: New IP Address (fxp0): xx.xxx.xxx.163
May 28 13:39:36 familysquires kernel: fxp0: link state changed to DOWN
May 28 13:39:36 familysquires dhclient: New Subnet Mask (fxp0): 255.255.240.0
May 28 13:39:36 familysquires dhclient: New Broadcast Address (fxp0): 255.255.25
5.255
May 28 13:39:36 familysquires dhclient: New Routers (fxp0): xx.xxx.xxx.1
May 28 13:39:38 familysquires kernel: fxp0: link state changed to UP
May 28 13:39:40 familysquires reboot: rebooted by root

Mike Squires
mi...@siralan.org
UN*X at home
since 1986

[Hiroki Sato]

YongHyeon PYUN <pyu...@gmail.com> wrote
in <2013052802...@michelle.cdnetworks.com>:

py> > I'll have access to the other box on Wednesday and will try the other test.
py>
py> Here is patch I'm testing and it seems to work with dhclient on
py> CURRENT.
py> Mike, could you try attached patch?

On my box it worked without problem. Link status change of fxp0 was
down->up only in the patched driver.

-- Hiroki

[YongHyeon PYUN]

Thanks for testing!

>
> -- Hiroki

[YongHyeon PYUN]

On Tue, May 28, 2013 at 03:34:00PM -0400, Michael L. Squires wrote:
> Short answer: it didn't work.

[...]

> Patch did not solve the problem on the home NAT box. I'll try it on the

Hmm, I can't reproduce it on my box. I double checked every
possible controller initialization sequences in driver but couldn't
find a clue. Let you know if I manage to narrow down the issue.

> second 1U box at work tomorrow.
>
> I applied the patch (see below) and recompiled/reinstalled world.
>

Rebuilding kernel should be enough.

> root@familysquires:/usr/src/sys/dev/fxp # uname -a
> FreeBSD familysquires.net 8.4-RELEASE FreeBSD 8.4-RELEASE #54: Sun May 26
> 22:56:19 EDT 2013 ro...@familysquires.net:/usr/obj/usr/src/sys/NEWGATE
> i386
>
> drwxr-xr-x 236 root 3584 May 28 10:28 ../
> -rw-r--r-- 1 root 95366 May 28 10:28 if_fxp.c
> -rw-r--r-- 1 root 94968 Mar 28 09:04 if_fxp.c.orig
> -rw-r--r-- 1 root 15638 Mar 28 09:04 if_fxpreg.h
> -rw-r--r-- 1 root 8717 Mar 28 09:04 if_fxpvar.h
> -rw-r--r-- 1 root 23009 Mar 28 09:04 rcvbundl.h
>
> One immediate difference in behavior is that without the modified rc.conf
> the box was unable to use ntp to the outside world; it eventually sync'd on
> my internal ntp server. With the modified rc.conf the box immediately
> sync'd to an ntp server in the outside world.
>

There is a side-effect of the rc.conf workaround. Parallel
detection may or may not work and generally can result in duplex
mismatch.