Regression in 8.2-STABLE bge code (from 7.4-STABLE)

[Michael L. Squires]

There is a bug in the Tyan S4881/S4882 PCI-X bridges that was fixed with a 
patch in 7.x (thank you very much).  This patch is not present in the 
8.2-STABLE code and the symptoms (watchdog timeouts) have recurred.


The watchdog timeouts do not appear to be present after I switched to an 
Intel gigabit PCI-X card.


I did a brute-force patch of the 8.2-STABLE bge code using the patches for
7.4-STABLE; the resulting code compiled and, other than odd behavior at
startup, seems to be working normally.

This is using FreeBSD 8.2-STABLE amd64; I don't know what happens with 
i386.


Given the age of the boards it may be easier if I just continue using the
Intel gigabit card but am happy to test anything that comes my way.

Thanks,

Mike Squires
mikes at siralan.org

Tyan S4882 (quad Opteron)

uname -a:

FreeBSD superxeon.familysquires.net 8.2-RELEASE-p5 FreeBSD 8.2-RELEASE-p5 #52:
at Jan 28 18:58:43 EST 2012 r...@superxeon.familysquires.net:/usr/obj/usr/
c/sys/OPTERON8  amd64

bge0 dmesg (bge1 same; verbose; note bge cksum error):

Jan 28 20:59:28 superxeon kernel: em0:  port 0x3000-0x303f mem 0xfe04-0xfe05 irq 26 at device 2.0 on
pci2
Jan 28 20:59:28 superxeon kernel: em0: Reserved 0x2 bytes for rid 0x10 type
3 at 0xfe04
Jan 28 20:59:28 superxeon kernel: em0: Reserved 0x40 bytes for rid 0x20 type 4 a
t 0x3000
Jan 28 20:59:28 superxeon kernel: ioapic1: routing intpin 2 (PCI IRQ 26) to lapi
c 0 vector 55
Jan 28 20:59:28 superxeon kernel: em0: [FILTER]
Jan 28 20:59:28 superxeon kernel: em0: bpf attached
Jan 28 20:59:28 superxeon kernel: em0: Ethernet address: 00:0e:0c:36:54:64
Jan 28 20:59:28 superxeon kernel: pci0:2:9:0: bad VPD cksum, remain 72
Jan 28 20:59:28 superxeon kernel: bge0:  mem 0xfe01-0xfe01,0xfe00-0xfe00 irq 24 at dev
ice 9.0 on pci2
Jan 28 20:59:28 superxeon kernel: bge0: Reserved 0x1 bytes for rid 0x10 type
 3 at 0xfe01
Jan 28 20:59:28 superxeon kernel: bge0: CHIP ID 0x2003; ASIC REV 0x02; CHIP
REV 0x20; PCI
Jan 28 20:59:28 superxeon kernel: miibus0:  on bge0
Jan 28 20:59:28 superxeon kernel: brgphy0:  PHY 1
 on miibus0
Jan 28 20:59:28 superxeon kernel: brgphy0: OUI 0x000818, model 0x0019, rev. 0
Jan 28 20:59:28 superxeon kernel: brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100
baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, au
to, auto-flow
Jan 28 20:59:28 superxeon kernel: bge0: bpf attached
Jan 28 20:59:28 superxeon kernel: bge0: Ethernet address: 00:e0:81:64:bc:7f
Jan 28 20:59:28 superxeon kernel: ioapic1: routing intpin 0 (PCI IRQ 24) to lapi
c 0 vector 56
Jan 28 20:59:28 superxeon kernel: bge0: [MPSAFE]
Jan 28 20:59:28 superxeon kernel: bge0: [ITHREAD]
Jan 28 20:59:28 superxeon kernel: pci0:2:9:1: bad VPD cksum, remain 72

ifconfig:

em0: flags=8802 metric 0 mtu 1500
options=9b
ether 00:0e:0c:36:54:64
media: Ethernet autoselect
status: no carrier
bge0: flags=8843 metric 0 mtu 1500
options=8009b
ether 00:e0:81:64:bc:7f
inet 10.1.5.160 netmask 0xff00 broadcast 10.1.5.255
media: Ethernet autoselect (1000baseT )
status: active
bge1: flags=8802 metric 0 mtu 1500
options=8009b
ether 00:e0:81:64:bc:7e
media: Ethernet autoselect (none)
status: no carrier
plip0: flags=8810 metric 0 mtu 1500
lo0: flags=8049 metric 0 mtu 16384
options=3
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
inet6 ::1 prefixlen 128
inet 127.0.0.1 netmask 0xff00
nd6 options=3

Changes to ./dev/bge/if_bgereg.h:

2813d2812
< #define BGE_FLAG_MBOX_REORDER 0x1000

Changes to ./dev/bge/if_bge.c
369,370d368
< static int bge_mbox_reorder(struct bge_softc *);
<
628,629d625
bge_flags & BGE_FLAG_MBOX_REORDER) != 0)
bge_flags & BGE_FLAG_4G_BNDRY_BUG) != 0)
---

  if ((sc->bge_flags & BGE_FLAG_4G_BNDRY_BUG) != 0) {

2487a2484,2493

  /*
   * XXX
   * watchdog timeout issue was observed on BCM5704 which
   * lives behind PCI-X bridge(e.g AMD 8131 PCI-X bridge).
   * Limiting DMA address space to 32bits seems to address
   * it.
   */
  if (sc->bge_flags & BGE_FLAG_PCIX)
  lowaddr = BUS_SPACE_MAXADDR_32BIT;
  }

2641,2680d2646
< bge_mbox_reorder(struct bge_softc *sc)
< {
< /* Lists of PCI bridges that are known to reorder mailbox writes. */

make buildworld fails with 8.2-RELEASE amd64 building STABLE

[Michael L. Squires]

"make buildworld" fails when trying to "make buildworld" (no options) 
with 8.2-RELEASE with 8.2-STABLE sources as of 2/6/2012 updated at 9:15 AM 
from ftp.freebsd.org.


The compile fails in the same spot every time; this is not a random 
failure.  I have seen some evidence, however, that there may be hardware 
problems.


The other hardware problem was a Broadcom GigE watchdog timeout and reset.

Hardware is a Tyan S2885 (dual dual-core Opteron) which has been running 
Windows XP SP3 for some time without problems, for what that's worth.


A Google search turns up nothing obviously related.

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

uname -a:

FreeBSD s2885.familysquires.net 8.2-RELEASE FreeBSD 8.2-RELEASE #0: 
Thu Feb 17 02:41:51 UTC 2011 
r...@amason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64


Error messages at failure:

===> gnu/usr.bin/gperf/doc 
(depend) c++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include 
-I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib 
-I/usr/src/gnu/usr.bin/gperf -c 
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/bool-array.cc
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/bool-array.cc: In 
destructor 'Bool_Array::~Bool_Array()':
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/bool-array.cc:39: 
internal compiler error: Illegal instruction: 4

Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
*** Error code 1

Stop in /usr/src/gnu/usr.bin/gperf.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
s2885#


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Regression in 8.2-STABLE bge code (from 7.4-STABLE)

[Michael L. Squires]

A patch which allows FreeBSD 8.3-STABLE to use the Broadcom GigE bge ports
on the Tyan S4882 quad Opteron motherboard (and almost certainly on the 
S4881 motherboard, which had the same problem with 7.4-STABLE) has been 
developed by YongHyeon Pyun.


The problem involves a bug in the PCI bridge which connects the Broadcom
bge Ethernet ports.

He will shortly be committing the patch to HEAD.

Thank you!

Mike Squires
mikes at siralan.org
UN*X at home
since 1986
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Broadcom watchdog timeout with 7.4-PRERELEASE

[Michael L. Squires]

I've been running 7.X on a Tyan S4881 (4 dual-core Opteron CPUs) since 
nearly the beginning of the 7.X cycle, and have just started to see 
watchdog timeouts on the Broadcom bge0 GigE port.


This occurs with a kernel and world compiled on 11/22, and also with a 
kernel compiled on 11/11 with the 11/22 world.


The errors occur when copying a large number (200-300GB) of files over
a GigE network to a WD USB drive attached to a PC running XP.

There are no Ethernet errors other than those caused by the timeouts.

The system uses an nVidia PCI-Express video board and an LSA 300-8X SATA
card which have not given any problems.  I have not been able, however, to
add a SCSI card and I've tried every Adaptec and LSI PCI, PCI-X, and 
PCI-Express card available to me.  The problem appears to be a mismatch of

the interrupt expected by the card and the interrupt provided by the board.
I haven't found a solution for that problem (yet).

The error is the usual watchdog timeout:

Nov 27 15:34:11 superxeon kernel: bge0: watchdog timeout -- resetting
Nov 27 15:34:11 superxeon kernel: bge0: link DOWN
Nov 27 15:34:11 superxeon kernel: bge0: link state changed to DOWN
Nov 27 15:34:15 superxeon kernel: bge0: link state changed to UP

I intend to switch over to an Intel Pro1000 card since I saw the same 
problem some timea ago on another box and switching GigE hardware solved 
the problem.


uname -a:

FreeBSD superxeon.familysquires.net 7.4-PRERELEASE FreeBSD 7.4-PRERELEASE 
#12: Mon Nov 22 15:45:36 EST 2010 
r...@superxeon.familysquires.net:/usr/obj/usr/src/sys/OPTERON8  amd64


dmesg output for bge0/1:

bge0:  mem 0
xd011-0xd011,0xd010-0xd010 irq 26 at device 2.0 on pci17
bge0: Reserved 0x1 bytes for rid 0x10 type 3 at 0xd011
bge0: CHIP ID 0x2003; ASIC REV 0x02; CHIP REV 0x20; PCI-X
miibus0:  on bge0
bge0: bpf attached
bge0: Ethernet address: 00:e0:81:58:2d:e3
bge0: [MPSAFE]
bge0: [ITHREAD]
bge1:  mem 0
xd013-0xd013,0xd012-0xd012 irq 27 at device 2.1 on pci17
bge1: Reserved 0x1 bytes for rid 0x10 type 3 at 0xd013
bge1: CHIP ID 0x2003; ASIC REV 0x02; CHIP REV 0x20; PCI-X
miibus1:  on bge1
bge1: bpf attached
bge1: Ethernet address: 00:e0:81:58:2d:e4
bge1: [MPSAFE]
bge1: [ITHREAD]
bge0: link state changed to UP

Mike Squires
mi...@siralan.org

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Broadcom watchdog timeout with 7.4-PRERELEASE

[Michael L. Squires]

Problem is watchdog timeouts with a Broadcom GigE interface on a Tyan 
S4881 using 7.4-PRERELEASE as of 11/22 and 7.3-STABLE as of 11/11.


I've done the following, with no success:

(1)  Tried the second port, bge1, in case the first had gone bad, and

(2)  Recompiled samba34 (failure occurs when copying large files using 
samba)


I'm currently cvup'ing Release 7.3 and will see if compiling and 
installing that version eliminates the problem.


The ultimate solution may involve replacing the Tyan S4881 with a S4882 so 
I can install other PCI-X cards (I'm unable to get the S4881 to assign 
interrupts to PCI-X or PCI-E cards, a problem I've never seen before)


Mike Squires mi...@siralan.org


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Broadcom watchdog timeout with 7.4-PRERELEASE

[Michael L. Squires]

The Tyan S4881 works perfectly with 7.3-RELEASE-p3; I'll be reinstalling 
7.4 and providing the requested diagnostics once I have a backup made.


(Broadcom bge watchdog timeouts under moderate (25% max of GigE) load)

Mike Squires
mi...@siralan.org


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

bge driver regression in 7.4-PRERELEASE, Tyan S4881

[Michael L. Squires]

I'm having watchdod timeout problems with the bge driver in 7.4-PRERELEASE 
on a Tyan S4881 motherboard (the S4881 has 4 Opteron sockets, 2 PCI-E 
slots, and 3 PCI-X slots, plus VGA and dual Broadcom "bge" GigE ports.)


I don't know if this problem also affects the similar Tyan S4882 motherboard,
which appears to be much more common.  I have a S4882 and can swap it for
the S4881 and test this, if anyone is interested (there are a lot things
to unplug and unscrew, so I'd rather not if there's no reason for it).

I've been able to isolate the problem to the following patches

 Edit src/sys/dev/bge/if_bge.c
  Add delta 1.198.2.48 2010.10.08.18.46.02 yongari
  Add delta 1.198.2.49 2010.10.08.18.51.28 yongari
 Edit src/sys/dev/bge/if_bgereg.h
  Add delta 1.73.2.22 2010.10.08.18.46.02 yongari
 Edit src/sys/dev/et/if_et.c
  Add delta 1.1.2.9 2010.10.08.19.25.46 yongari
 Edit src/sys/dev/mii/brgphy.c
  Add delta 1.70.2.14 2010.10.08.19.00.36 yongari
 Edit src/sys/dev/mii/brgphyreg.h
  Add delta 1.10.2.3 2010.10.08.19.00.36 yongari
  Add delta 1.7.2.6 2010.10.08.20.13.42 yongari
  Add delta 1.7.2.7 2010.10.08.20.27.51 yongari
  Add delta 1.7.2.8 2010.10.08.20.31.35 yongari
  Add delta 1.7.2.9 2010.10.08.20.37.13 yongari
  Add delta 1.7.2.10 2010.10.08.20.41.15 yongari
  Add delta 1.7.2.11 2010.10.08.20.44.35 yongari
  Add delta 1.7.2.12 2010.10.08.20.49.44 yongari
  Add delta 1.7.2.13 2010.10.08.20.52.47 yongari
  Add delta 1.7.2.14 2010.10.08.23.14.21 yongari
  Add delta 1.7.2.15 2010.10.08.23.29.45 yongari
  Add delta 1.7.2.16 2010.10.08.23.34.45 yongari

Reverting if_bge.c, if_bgerec.h, brgphy.c, and brgphyreg.h to the version 
that existed on 10/7/2010 allows me to do a 7.4-PRERELEASE buildworld/

buildkernel/installkernel cycle and the resulting kernel does not exhibit
the watchdog timeout problem.

The problem appears only on samba shares exported to a Windows XP Pro client
(I've been copying a directory with 17GB of "Ghost" images as a test).

The dmesg for a kernel that failed (containing the patches above) is as 
follows:


bge0:  mem 
0xd011-0xd011,0xd010-0xd010 irq 26 at device 2.0 on pci17
miibus0:  on bge0
bge0: Ethernet address: 00:e0:81:58:2d:e3
bge0: [ITHREAD]
bge1:  mem 
0xd013-0xd013,0xd012-0xd012 irq 27 at device 2.1 on pci17
miibus1:  on bge1
bge1: Ethernet address: 00:e0:81:58:2d:e4
bge1: [ITHREAD]
bge1: link state changed to UP
bge1: watchdog timeout -- resetting
bge1: link state changed to DOWN
bge1: link state changed to UP
bge1: watchdog timeout -- resetting
bge1: link state changed to DOWN
bge1: link state changed to UP
bge1: watchdog timeout -- resetting
bge1: link state changed to DOWN
bge1: link state changed to UP
bge1: watchdog timeout -- resetting
bge1: link state changed to DOWN
bge1: link state changed to UP

Mike Squires
mi...@siralan.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: bge driver regression in 7.4-PRERELEASE, Tyan S4881

[Michael L. Squires]

On Thu, 30 Dec 2010, Jeremy Chadwick wrote:


Please provide output from the following command, as root:

pciconf -lbvc

And only include the bge1 and bge0 devices in your output.  Thanks.



This is the output, as root, using the kernel with the 10/7/2010 bge code
(which works for me).  I can provide the code with the 7.4-PRERELEASE
kernel if you want that.

OS is compiled as amd64.

b...@pci0:17:2:0:   class=0x02 card=0x164814e4 chip=0x164814e4 rev=0x03
hdr=0x00
vendor = 'Broadcom Corporation'
device = 'NetXtreme Dual Gigabit Adapter (BCM5704)'
class  = network
subclass   = ethernet
bar   [10] = type Memory, range 64, base 0xd011, size 65536, enabled
bar   [18] = type Memory, range 64, base 0xd010, size 65536, enabled
cap 07[40] = PCI-X 64-bit supports 133MHz, 2048 burst read, 1 split transact
ion
cap 01[48] = powerspec 2  supports D0 D3  current D0
cap 03[50] = VPD
cap 05[58] = MSI supports 8 messages, 64 bit
b...@pci0:17:2:1:   class=0x02 card=0x164814e4 chip=0x164814e4 rev=0x03
hdr=0x00
vendor = 'Broadcom Corporation'
device = 'NetXtreme Dual Gigabit Adapter (BCM5704)'
class  = network
subclass   = ethernet
bar   [10] = type Memory, range 64, base 0xd013, size 65536, enabled
bar   [18] = type Memory, range 64, base 0xd012, size 65536, enabled
cap 07[40] = PCI-X 64-bit supports 133MHz, 2048 burst read, 1 split transact
ion
cap 01[48] = powerspec 2  supports D0 D3  current D0
cap 03[50] = VPD
cap 05[58] = MSI supports 8 messages, 64 bit

This is a hobby system supporting a home server,
so it's not "mission-critical" and my current hack is working properly.

Thanks to both of you for your assistance.

Mike Squires
mi...@siralan.org
UN*X at home
since 1986
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Apparent fxp regression in FreeBSD 8.4-RC3

[Michael L. Squires]

Here is pciconf -lvbc under 8.3-RELEASE p8:

hostb0@pci0:0:0:0:  class=0x06 card=0x 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=0x06 card=0x 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=0x02 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 0xfeb6, size 131072, enabled
bar   [18] = type Memory, range 64, base 0xfeb0, 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=0x03 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 0xfd00, 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=0x02 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 0xfeb8, size 131072, enabled
cap 01[dc] = powerspec 2  supports D0 D1 D2 D3  current D0
bge0@pci0:0:8:0:class=0x02 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 0xfebe, 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=0x06 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
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Apparent fxp regression in FreeBSD 8.4-RC3

[Michael L. Squires]

On Sun, 12 May 2013, Glen Barber wrote:


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
r...@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


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
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Apparent fxp regression in FreeBSD 8.4-RC3

[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

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Apparent fxp regression in FreeBSD 8.4-RC3

[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
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Apparent fxp regression in FreeBSD 8.4-RC3

[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
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Apparent fxp regression in FreeBSD 8.4-RC3

[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
msqui...@iga.in.gov (where the test box lives)


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Apparent fxp regression in FreeBSD 8.4-RC3

[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  wrote
  in <20130524.162926.395058052118975996@allbsd.org>:

hr> YongHyeon PYUN  wrote
hr>   in <20130524054720.ga1...@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 r...@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
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Apparent fxp regression in FreeBSD 8.4-RC3

[Michael L. Squires]

Short answer:  it didn't work.

On Tue, 28 May 2013, YongHyeon PYUN wrote:


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  wrote
 in <20130524.162926.395058052118975996@allbsd.org>:

hr> YongHyeon PYUN  wrote
hr>   in <20130524054720.ga1...@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 r...@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?


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 r...@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
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Regression in FreeBSD-STABLE 10.2-BETA1 r28551

[Michael L. Squires]

I've not worked with 10.x a lot, so please excuse novice mistakes.

I upgraded the OS on a quad Opteron Tyan S4881 (known to have SMP 
bugs, but I haven't seen any and I've been running this system for 
years).  I upgraded from an earlier version of FreeBSD-10.x to

FreeBSD 10.2-BETA1 r285551.

Problem:  during boot, when accessing the DVD drive attached to the 
EIDE bus there is an interrupt storm on interrupt 16.  After a few 
minutes of errors the boot continues successfully and the system 
appears to behave normally after that.  I do not use the DVD drive 
except for installs, which are infrequent.


The earlier kernel does not exhibit this behavior.

This is part of a verbose dmesg during a boot.  The complete dmesg is 
attached.


This does not appear to be a serious issue, and this is a home server 
system.


Mike Squires
mi...@siralan.org or michael.leslie.squi...@gmail.com
UN*X at home since 1986

FreeBSD 10.2-BETA1 #5 r285551: Tue Jul 14 23:13:18 EDT 2015
r...@superxeon.familysquires.net:/usr/obj/usr/src/sys/OPTERON8 amd64
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
CPU: AMD Opteron(tm) Processor 850 (2405.51-MHz K8-class CPU)
  Origin="AuthenticAMD"  Id=0x20f51  Family=0xf  Model=0x25  Stepping=1
  
Features=0x78bfbff
  Features2=0x1
  AMD Features=0xe2500800
  AMD Features2=0x1

[stuff deleted]

ata0: stat0=0x20 err=0x20 lsb=0x20 msb=0x20
ata0: stat1=0x30 err=0x30 lsb=0x30 msb=0x30
ata0: reset tp2 stat0=20 stat1=30 devices=0x0
ata1: reset tp1 mask=03 ostat0=50 ostat1=01
ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb
ata1: stat1=0x00 err=0x01 lsb=0x00 msb=0x00
ata1: reset tp2 stat0=00 stat1=00 devices=0x1
(noperiph:ahc0:0:-1:): SCSI bus reset delivered. 0 SCBs aborted.
interrupt storm detected on "irq16:"; throttling interrupt source
(noperiph:ahc1:0:-1:): SCSI bus reset delivered. 0 SCBs aborted.Table 'FACP' at 0x7ff73307
Table 'SRAT' at 0x7ff75c74
Table 'HPET' at 0x7ff75dac
Table 'SSDT' at 0x7ff75de4
Table 'SSDT' at 0x7ff75e81
Table 'APIC' at 0x7ff75f1e
APIC: Found table at 0x7ff75f1e
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 1 ACPI ID 1: enabled
SMP: Added CPU 1 (AP)
MADT: Found CPU APIC ID 2 ACPI ID 2: enabled
SMP: Added CPU 2 (AP)
MADT: Found CPU APIC ID 3 ACPI ID 3: enabled
SMP: Added CPU 3 (AP)
Copyright (c) 1992-2015 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 10.2-BETA1 #5 r285551: Tue Jul 14 23:13:18 EDT 2015
r...@superxeon.familysquires.net:/usr/obj/usr/src/sys/OPTERON8 amd64
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Preloaded elf kernel "/boot/kernel/kernel" at 0x819f4000.
Preloaded elf obj module "/boot/modules/vboxdrv.ko" at 0x819f4cb0.
Calibrating TSC clock ... TSC clock: 2405511005 Hz
CPU: AMD Opteron(tm) Processor 850 (2405.51-MHz K8-class CPU)
  Origin="AuthenticAMD"  Id=0x20f51  Family=0xf  Model=0x25  Stepping=1
  
Features=0x78bfbff
  Features2=0x1
  AMD Features=0xe2500800
  AMD Features2=0x1
L1 2MB data TLB: 8 entries, fully associative
L1 2MB instruction TLB: 8 entries, fully associative
L1 4KB data TLB: 32 entries, fully associative
L1 4KB instruction TLB: 32 entries, fully associative
L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative
L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative
L2 2MB unified TLB: 0 entries, disabled/not present
L2 4KB data TLB: 512 entries, 4-way associative
L2 4KB instruction TLB: 512 entries, 4-way associative
L2 unified cache: 1024 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative
WARNING: This architecture revision has known SMP hardware bugs which may cause 
random instability
real memory  = 17179869184 (16384 MB)
Physical memory chunk(s):
0x0001 - 0x00096fff, 552960 bytes (135 pages)
0x0010 - 0x001f, 1048576 bytes (256 pages)
0x01a2a000 - 0x7ff6, 2119458816 bytes (517446 pages)
0x0001 - 0x0003e5ea8fff, 12447289344 bytes (3038889 pages)
avail memory = 14476759040 (13806 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table: 
INTR: Adding local APIC 1 as a target
INTR: Adding local APIC 2 as a target
INTR: Adding local APIC 3 as a target
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 4 package(s) x 1 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
 cpu2 (AP): APIC ID:  2
 cpu3 (AP): APIC ID:  3
APIC: CPU 0 has ACPI ID 0
APIC: CPU 1 has ACPI ID 1
APIC: CPU 2 has ACPI ID 2
APIC: CPU 3 has ACPI ID 3
x86bios:  IVT 0x00-0x0004ff at 0xf800
x86bios: SSEG 0x096000-0x096fff at 0xfe03cc1ac000
x86bios: EBDA 0x09a000-0x09 at 0xf809a000
x86bios:  ROM 0x0a-0x0fefff at 0xf80a
XEN: CP

Re: Regression in FreeBSD-STABLE 10.2-BETA1 r28551

[Michael L. Squires]

On Thu, 16 Jul 2015, Michael L. Squires wrote:


I've not worked with 10.x a lot, so please excuse novice mistakes.

I upgraded the OS on a quad Opteron Tyan S4881 (known to have SMP bugs, but I 
haven't seen any and I've been running this system for years).  I upgraded 
from an earlier version of FreeBSD-10.x to

FreeBSD 10.2-BETA1 r285551.

Problem:  during boot, when accessing the DVD drive attached to the EIDE bus 
there is an interrupt storm on interrupt 16.  After a few minutes of errors 
the boot continues successfully and the system appears to behave normally 
after that.  I do not use the DVD drive except for installs, which are 
infrequent.


The earlier kernel does not exhibit this behavior.



This problem has vanished with FreeBSD 10.2-BETA2.

I think the original posting was incorrect, problem was with the Adaptec
SCSI card at boot.

Mike Squires

Copyright (c) 1992-2015 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 10.2-BETA2 #7 r285816: Fri Jul 24 00:32:09 EDT 2015
r...@superxeon.familysquires.net:/usr/obj/usr/src/sys/OPTERON8 amd64
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
CPU: AMD Opteron(tm) Processor 850 (2405.51-MHz K8-class CPU)
  Origin="AuthenticAMD"  Id=0x20f51  Family=0xf  Model=0x25  Stepping=1
  
Features=0x78bfbff
  Features2=0x1
  AMD Features=0xe2500800
  AMD Features2=0x1
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Change in ssh connection behavior with 7.2-PRERELEASE

[Michael L. Squires]

I'm using an older Supermicro 1U box as my NAT box for my home network; I 
also read email on it by logging in remotely using Cygwin's ssh to run 
pine.


I've noticed a change in behavior which ocurred when I upgraded from 7.1-STABLE 
compiled 2/8/2009 to 7.2-PRERELEASE compiled 4/24/2009.

The change is that the system can't display full screens in the Cygwin 
window.  The screen gets filled slowly, with long pauses between 
successive partial fills.


This seems to only occur when I'm logged in from work using Cygwin SSH 
over the Internet to my home box; the final link is via Comcast, if that 
makes a difference.


Connecting from witnin my local network, also using Cygwin SSH, no such problem.

Rebooting the old kernel solves the problem.

The work PC is running Cygwin OpenSSH 5.1p1/OpenSSL 0.9.8j (7 Jan 2009); 
the home PC is running Cygwin OpenSSH 5.1p1/OpenSSL 0.9.8i (9/15/2008).


The results of "stty -a" under new and old kernels yeilds exactly the same 
thing:


speed 38400 baud; 90 rows; 80 columns;
lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl
-echoprt -altwerase -noflsh -tostop -flusho pendin -nokerninfo
-extproc
iflags: -istrip icrnl -inlcr -igncr ixon ixoff -ixany -imaxbel -ignbrk
brkint -inpck -ignpar -parmrk
oflags: opost onlcr -ocrnl -oxtabs -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
-dtrflow -mdmbuf
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = ;
eol2 = ; erase = ^H; erase2 = ^H; intr = ^C; kill = ^U;
lnext = ^V; min = 1; quit = ^\; reprint = ^R; start = ^Q;
status = ^T; stop = ^S; susp = ^Z; time = 0; werase = ^W;

Mike Squires
mi...@siralan.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

net.inet.tcp.tso=1 still neceesary with fxp was Re: TCP differences in 7.2 vs 7.1

[Michael L. Squires]

I started having speed problems after shifting from 7.1-STABLE to 
7.1-PRERELEASE.  They have continued with 7.2-STABLLE.


Reverting to the 7.1-STABLE kernel eliminated the problem.

After downloading 7.2-STABLE from cvsup.freebsd.org at about 10:40 AM EST
on 5/20/2009, doing a buildworld/buildkernel/installkernel/installworld
cycle I still need to execute "net.inet.tcp.tso=1" to elminate throughput
problems between my home system (on Comcast) and my office PC (connected
via a Time-Warner connection).  This also affects connections to other
systems; downloading Web pages (ebay.com) speeds up after I change the TSO
entry.

The box in question runs NAT and has an fxp (Intel Pro100) interface connected 
to a Comcast cable modem and an em (Intel Pro1000) interface connected to the 
internal network.


There are no network errors in "netstat -i" on either interface.

The "if_fxp.c" code appears to be the May 7 version.

This is the dmesg entry for the card in question.  The system is a dual Xeon
Supermicro 1U box, 1GB RAM, single 300GB IDE hard drive.

fxp0:  port 0xe400-0xe43f mem 
0xfebfd000-0xfebfdfff,0xfeb8-0xfeb9 irq 27 at device 7.0 on pci0
miibus0:  on fxp0

Mike Squires
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: net.inet.tcp.tso=1 still neceesary with fxp was Re: TCP differences in 7.2 vs 7.1

[Michael L. Squires]

On Thu, 21 May 2009, Pyun YongHyeon wrote:


On Wed, May 20, 2009 at 05:55:29PM -0400, Michael L. Squires wrote:

I started having speed problems after shifting from 7.1-STABLE to
7.1-PRERELEASE.  They have continued with 7.2-STABLLE.

Reverting to the 7.1-STABLE kernel eliminated the problem.

After downloading 7.2-STABLE from cvsup.freebsd.org at about 10:40 AM EST
on 5/20/2009, doing a buildworld/buildkernel/installkernel/installworld
cycle I still need to execute "net.inet.tcp.tso=1" to elminate throughput
problems between my home system (on Comcast) and my office PC (connected
via a Time-Warner connection).  This also affects connections to other
systems; downloading Web pages (ebay.com) speeds up after I change the TSO
entry.

The box in question runs NAT and has an fxp (Intel Pro100) interface
connected to a Comcast cable modem and an em (Intel Pro1000) interface
connected to the internal network.

There are no network errors in "netstat -i" on either interface.

The "if_fxp.c" code appears to be the May 7 version.



You should have cvs rev. 1.266.2.15 of if_fxp.c.


This is the dmesg entry for the card in question.  The system is a dual Xeon
Supermicro 1U box, 1GB RAM, single 300GB IDE hard drive.

fxp0:  port 0xe400-0xe43f mem
0xfebfd000-0xfebfdfff,0xfeb8-0xfeb9 irq 27 at device 7.0 on pci0
miibus0:  on fxp0



Since you use both em(4) and fxp(4) I'd like to know which driver
has the issue. Instead of disabling TSO of network stack try
disabling TSO for each interface. For instance,
1. Diable TSO of em(4) and check you see the same issue
   (ifconfig em0 -tso).
2. Diable TSO of fxp(4) and check you see the same issue
   (ifconfig fxp0 -tso).



The version of if_fpx.c is in fact 1.266.2.15.

Connecting to the FreeBSD box from a PC with a bash shell under XP 
SP3/Cygwin OpenSSH I find


(1)  disable "tso" on the internal "em0" interface has no effect; but

(2)  disabling "tso" on the external "fxp0" inteface eliminates the 
througput problem.  The effect appears to be the same as using sysctl to 
disable tso on all interfaces.


With "tso" enabled on the "fxp0" interface the connection (reading email 
using "pine" in a large window) hung completely.


There are no errors in "netstat -i" nor in /var/log/messages.

"netstat -e" on the XP PC shows no discards or errors; however, I don't
think I've ever seen a PC under Windows admit to network errors.

The fxp0 interface connects to a Comcast cable modem, which eventually 
connects to my office PC which is in the "iga.in.gov" domain hosted by 
TimeWarner.


I'll be happy to run anything else you want.

Mike Squires
UN*X at home
Since 1985


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Building 7.2 Stable fails to compile dtmalloc

[Michael L. Squires]

I had a similar build error with 7.2-STABLE with a different error - 
internal compiler error.


After updating and having buildworld fail in the same spot I completely 
cleaned my /usr/obj and /usr/src directories (need "cd /usr/obj;chflags -R 
noschg *;rm -rf *" for /usr/obj and then downloaded the sources again.


This time there were no problems compiling.  I don't know if the cause was 
a hardware problem, a corrupted /usr/src, or a bug that was fixed by the 
time I downloaded /usr/src.


This is hardware on which I've been compiling FreeBSD for some time, so my 
guess is the corrupted /usr/src (given that there are no repots of a 
similar error from other users).


Mike Squires
mikes at siralan.org


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Problem with AHC after updating from 4.11 to 6.1 on the same server hardware

[Michael L. Squires]

Not that it will help you, but I'm running 6.2-PRERELEASE compiled 9/23
with three Adaptec controllers and no problems; none of them is a 29160, 
however.


ahc0:  port 0xe000-0xe0ff mem 
0xfebfd000

-0xfebfdfff irq 16 at device 14.0 on pci0
ahc0: [GIANT-LOCKED]
ahc1:  port 0xe400-0xe4ff mem 
0xfebfe000

-0xfebfefff irq 16 at device 14.1 on pci0
ahc1: [GIANT-LOCKED]
ahc2:  port 0xee00-0xeeff mem 
0xfebfc000-0xfebf

cfff irq 18 at device 18.0 on pci0
ahc2: [GIANT-LOCKED]
ahc3:  port 0xed00-0xedff mem 
0xfebfb000-0xfebf

bfff irq 19 at device 20.0 on pci0
ahc3: [GIANT-LOCKED]

The motherboard is a Supermicro P6DGH with an onboard 78XX Adaptec 
controller, plus 2940 and 2944 (HV diff) for controlling two tape 
changers.


I have a 39160 in another system running 4.11; I'll try booting that under 
6.1 and see what happens.


Mike Squires
mikes at siralan.org


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: slow mouse in X11

[Michael L. Squires]

On Mon, 29 Nov 2004, Jon Noack wrote:
alex bustamante wrote:
How come that when i run X11 under FreeBSD my Intellimouse is a lot slower
than in X11 under Linux? I use Option Protocol "auto" under FreeBSD and
I had a very slow mouse when running a kernel with the debug options 
enabled, running 5.x-CURRENT.  This was particularly noticeable under 
KDE/X11.

Recompiling without the debugging options, of course, fixed that.
Mike Squires
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: the best graphicscard for FreeBSD

[Michael L. Squires]

I've been experimenting with various cards, most cheap.  The monitors are 
HP P1110 21" surplus, very bright (too bright) and very sharp.  These are 
the PC version with VGA connectors, not the ones with BNC connectors.

I currently have a Matrox G450 in dual-head mode under 5.3-STABLE with 
Xorg, updated a couple of days ago from ports.  Xinerama is very 
nice; the only problem I have is that MS Windows XP appears to leave the 
card in a wierd state, and I have to power cycle the system sometimes 
before the second monitor works correctly.  This system is an old SM P6DGH 
dual PII/300 with an early AGP slot.

I am moving to a newer machine, SM P4DCE+ dual Xeon 1.8GHZ.  It came with 
a Radeon 7000 VE board which works fine with 5.3-STABLE/Xorg using the 
config written by Xorg.  With versions before 5.3 I had to add 
radeondrm support, not now.  Both agp/drm show on dmesg.  This card 
works very well at 1280x1024, using very small characters - combination is
as good as the 19" NEC plasma I have at work, except bigger (and hotter).
(The Dell at work has a dual-head nVidia 5200 board).

I bought a new nVida based FX5500 board to experiment.  Trouble.  The main 
problem is that the video amps don't have the bandwidth to show sharp 
characters on the screen at 1280x1024 at any refresh I've tried.  nVidia 
does have drivers for FreeBSD 5.21 and later, but I haven't tried them.
(I tried both FreeBSD with the "nv" driver and MS Windows XP using the MS 
certified nVidia FX5500 driver).

I suspect that name-brand nVida-based cards would be better (I can't even 
find a name on this one, other than "nVidia"), but my mind is already made 
up.

For the moment I'm sticking with ATI-made Radeon cards; my next one will 
probably be either an 8400 dual head or a 9200 dual head.  I just have to 
find a game player who wants an nVidia FX5500/256MB dual head card cheap.

Mike Squires
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Problem booting a Compaq Proliant 1600.

[Michael L. Squires]

I had a similar problem with a machine with two Adaptec 2940UW 
controllers.  When I upgraded from somethng like 4.7 to 4.8 the machine 
stopped booting.  My workaround was to go with a single controller.

The problem seems to be that at some point in the 4.X development cycle 
the way in which SCSI controllers and disks are enumerated was changed. 
You might have more luck getting an answer on the freebsd-scsi mailing list.

(I'm afraid I didn't, I asked about the same question and got no answers)
I'm about to start working with a 5.3-STABLE box with an onboard 
dual-channel controller and an Adaptec 39160 dual channel controller in a 
PCI slot, so I'm expecting to run into this again.

(I do know that the controllers and disks are enumerated by sysctl 
entries ("sysctl -a").  I am wondering if booting off a live CD would 
allow you to run sysctl and find out how the physical disks and 
controllers are mapped to devices.

Mike Squires
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Wiring down SCSI devices - was Re: Problem booting a Compaq Proliant 1600.

[Michael L. Squires]

The information needed to wire down SCSI devices (which appears to be 
necesary in some cases with systems that have more than 1 SCSI controller) 
is contained in

/usr/src/sys/i386/conf/NOTES for v4.10, and
/sys/conf/NOTES for 5.3-STABLE
Thanks to Scott Long for pointing out the latter.
Mike Squires
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

LINUX base upgrade and rpm 4.04 port

[Michael L. Squires]

For security reasons the linux-base version has been updated from 7 to 8; 
when I follow the instructions in /usr/ports/UPDATING I get a message from 
the linux-8 make process that I should have first installed rpm 4.0.4 
(apparently /var/lib/rpm/packages.rpm is in db1 format, and linux-8 wants 
it in db3 format; also, the user "rpm" is apparently missing).

Should rpm 4.0.4 be installed before updating, or after, or not at all?
Mike Squires
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Starting gvinum/vinum with RAID 5 and Compaq 39160 - 5.3-STABLE

[Michael L. Squires]

I've been playing with vinum and gvinum with a RAID-1 boot setup (now 
abandoned, hardware RAID was $29 - SM P4DC6+ with Adaptec 2005S) and with 
a RAID5 array using a Compaq version of the Adaptec 39160 card.

I've found that only "geom_vinum_load="YES" works in order to get the RAID 
5 array mounted at boot time; "vinum_load" with or without 
"vinum.autostart" doesn't work.  (Doesn't work means that the boot fails 
when /dev/vinum/raid can't be mounted as per /etc/fstab, and I have to 
execute "vinum" before I can mount it while running single user after the 
crash).

I've seen one other message that "vinum_load" didn't work for one other 
5.3-R user, but I don't know if we both made the same mistake or if 
something else is wrong.

(The Compaq card won't configure on my system; I found that I could 
flash it using the v2.57 Adaptec BIOS update and after that I could 
set the bus speed and turn off the BIOS (otherwise the disks are all 
attached "async" and the system tries to boot off the 39160). Adaptec 
warns of dire consequences, and the flash does not remove the 
identification of the card as a Compaq OEM version, but I haven't had 
problems after the BIOS update).

Mike Squires
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Possible 5.3-STABLE tar bug

[Michael L. Squires]

I have an NFS exported directory "/share" which contains "/share/Mac"; the 
"Mac" directory is itself exported vi netatalk, and contains several GB of 
Macintosh files.

If I execute
tar cf /dev/null Mac when "/share" is my current directory on the 4.10 box 
nothing happens, other than consuming a lot of machine cycles.

On a 5.3-STABLE box, where the /share directory is NFS-mounted, when I 
execute

tar cvf /dev/null Mac
when /share is my current directory I get
p4dc6# tar cf /dev/null Mac
archive_write_pax_header: 'x' header failed?!  This can't happen.
p4dc6#
This is reproducible, and happens after a specific file in an Apple 
network software installation directory.

There is nothing in /var/log/messages.
A Google search found only a reference to one message in the "perforce"
FreeBSD mailing list (change 66084) which appears to show that this 
error message was added on 11/30/2004.

dmesg header is (there are two physical CPUs, the kernel is SMP):
FreeBSD 5.3-STABLE #0: Sun Jan 23 21:24:20 EST 2005
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/XEON
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) XEON(TM) CPU 1.80GHz (1784.28-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0xf24  Stepping = 4
Features=0x3febfbff
  Hyperthreading: 2 logical CPUs
I can provide additional information, assuming that this is something as 
yet uncorrected.

Mike Squires
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Panics with 5-stable - vinum? raid5?

[Michael L. Squires]

On Tue, 22 Feb 2005 [EMAIL PROTECTED] wrote:
Hi there,
I have carried out extensive hardware tests and most of the hardware
(including most of the memory, the cpu and main board) have already been
replaced but this makes no difference to stability. I also believe this issue
was already there when running 4-STABLE. I have tried out the new geom feature
and gvinum but crashes where more frequent and panic dumps were specifically
mentioning vinum, so I turned back to non-geom vinum (which also has a
significantly higher performance).
I tried 5.3-STABLE with vinum and gvinum and had a number of crashes with 
a Supermicro P4DC6 dual 1.8GHZ Xeon/512MB, RAID 1 boot device using the 
Adaptec 2005S + onboard SCSI, Compaq OEM Adaptec 39160 (flashed to Adaptec 
v 2.57 BIOS), 8 Seagate 43GB drives in a RAID 5 array.

I dropped back to 4.11-STABLE, same hardware, no crashes.  I had two 
processes copying 150GB from an NFS-mounted volume to the RAID 5 array for 
several days.

On the other hand I'm running 5.3-STABLE on a Toshiba 8100 notebook and 
dual PIII/Supermicro P6DGH which have been rock solid.

I personally would not use the 8139 Ethernet cards in a server (see "man 
rl" or read the code, the author of the driver obviously thinks the 8139 
chipset is a horrible kludge.  I personally use only Intel Pro100 and 
variants (the P4DC6 has one built in).

(I can't tell you if the problems I had were hardware (I did change memory 
at one point, but that didn't solve the problem), some configuration 
mistake I made, or bugs triggered by my hardware version (I do have HTT 
turned off).

Mike Squires
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ACPI errors on boot

[Michael L. Squires]

On Sat, 12 Mar 2005, Dan Ponte wrote:
Hi all.
I've been seeing lots of ACPI errors in my dmesg lately. They haven't

FreeBSD 5.3-STABLE #3: Wed Jan 12 16:34:03 EST 2005
There were some changes to ACPI at about that time which caused 
motherboards with buggy BIOSes to have problems.  These were fixed, at 
least for me, pretty quickly.  See the freebsd-acpi mailing list for more 
details, but I'd suggest updating your kernel/world to something in March.

I am running 5.3-STABLE on a Supermicro P6DGH (nice board, but really 
weird - I20, many PCI slots, etc) and a Toshiba 8100 Tecra; the Tecra 
wouldn't boot at all while this problem existed.

Mike Squires
UN*X at home
since 1986
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

6.1-PR - bsdtar fails with bogus modification dates

[Michael L. Squires]

Problem:  Bogus modification dates cause tar/bsdtar 1.02.023 failure, 
gnutar works


The files were created from old Macintosh files using netatalk.  One file 
has a bogus modification date of Nov 16, 1913, which appears to cause 
"bsdtar" to fail:


newserv# tar cvf /tmp/test.tar hpLaserJet456Installer.gz 
hpLaserJet456Installer.sit.gz
a hpLaserJet456Installer.gzarchive_write_pax_header: 'x' header failed?! 
This can't happen.


Create a tar archive using gnutar (compiled from GNU tar 1.15 sources from 
ftp.gnu.org):


newserv# gnutar cvf /tmp/test.tar hpLaserJet456Installer.gz 
hpLaserJet456Installer.sit.gz

hpLaserJet456Installer.gz
hpLaserJet456Installer.sit.gz

"touch" the files and force the modification dates to 2/26/2006:

newserv# tar cvf /tmp/test.tar hpL*
a hpLaserJet456Installer.gz
a hpLaserJet456Installer.sit.gz

Mike Squires

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: big trouble with /usr/ports/textproc/wv

[Michael L. Squires]

On Thu, 9 Mar 2006, Peter Guhl wrote:


Hi again

On Thu, 2006-03-09 at 11:11 +0100, Peter Guhl wrote:


/usr/ports/textproc/wv, part of the dependencies, fails:
configure: error: * * * unable to find libwmf-config; unable to continue
* * *

libwmf is installed. libwmf-config is in /usr/local/bin.




I had a similar problem when I tried to run portupgrade by doing an "su" 
from my user account; in my case the PATH used by the shell was different 
with "su" than with "su -".


Mike Squires

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 6.0 hangs at boot on Toshiba laptop

[Michael L. Squires]

This looks like the problem I have with 5.4-STABLE after a kernel change 
on 9/5/2005 to /usr/src/sys/dev/pci/pci.c.


The sysclt paramater "hw.pci.enable_io_modes" is supposed to allow PCs 
with "lazy" BIOSes to boot, but this setting had no effect on my 8100.


If your problem is the same as mine then I'm not sure what, if anything, 
you can do to get 6.X to boot.  In my case I can bootstrap from 5.X to 
6.X, assuming I figure out how to kludge my way around the 8100 BIOS 
problem on 6.X.


My original message had "Toshiba 8100 Fix" at the beginning of the subject 
line.  There was related material with "changes breaks IDE boot" in the 
subject line, also.


Mike Squires

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

gvinum RAID5 stable in 5.4-RELEASE?

[Michael L. Squires]

I tried to install a RAID5 array using both vinum and gvinum under 
5.3-RELEASE and couldn't get a reliable system running.  I reinstalled 
using 4.11-STABLE and so far the system (and vinum) have been error-free.

The 5.4-RELEASE documentation only mentions that "geom_vinum" provides a 
GEOM compatible replacement for vinum.  I've seen contradictory messages 
on this mailing list and the geom mailing list about whether 
5.4-RELEASE's "gvinum" provides a stable RAID5 solution.

Hardware is a Supermicro P4DC6+, dual 1.7Ghz Xeon, 512MB RAMBUS, boot 
device is a RAID1 array using an Adaptec 2005 in the RAID adapter slot,
8 Seagate 43GB SCSI disks attached to a Compaq/Adaptec 39160 controller
using vinum.  I don't want to use the on-board controller for the RAID5 
array since I believe the cabling will be problematical with two external 
SCSI towers plus the long run from the SCSI port to the back of the case.

I tried installing 5.3_RELEASE/RAID5 several times using both vinum and 
gvinum; I also tried installing and then upgrading to 5.3-STABLE in the 
hopes that a bugfix had appeared.  I had gvinum working for almost a day 
before the system crashed under heavy load; since this is a hobby and not 
my employment I decided to back off to 4.11 and try again.

I do have an alternative - a DPT SmartRAID V - but vinum has been so 
reliable under 4.x that I'd like to continue with it, if possible.

Mike Squires
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

5.4-STABLE changes breaks IDE boot (was Re: 5.3 -> 5.4 breaks ATA (Intel ICH2))

[Michael L. Squires]

This may be a similar problem to the one discussed in the Intel ICH2 
thread.


System is a Toshiba 8100.  System boots from a 5.4-STABLE kernel compiled 
5/3/2005 but locks up on boot with kernels compiled in the past few days.


I re-cvsup'd after the first lockup and build a GENERIC kernel, same 
results.  The atapci0 lines were divided by the mailer to fit into an 80 
col line, I've added the "\".


The only difference I can see is that the working kernel allocates port 
0xfff0-0x to atapci0, and both the non-working kernels don't allocate 
those ports.  This is the only difference I can see between the working 
and non-working output from the boot process.


The complete old dmesg is attached.

Mike Squires

--hopefully relevant parts of old dmesg--
FreeBSD 5.4-STABLE #0: Tue May  3 21:29:44 EST 2005
[EMAIL PROTECTED]:/usr/src/sys/i386/compile/PORT
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel Pentium III (697.42-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x686  Stepping = 6
  
Features=0x383f9ff
real memory  = 402522112 (383 MB)
avail memory = 384188416 (366 MB)
npx0:  on motherboard
npx0: INT 16 interface
acpi0:  on motherboard
acpi0: Power Button (fixed)
Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0xfe08-0xfe0b on acpi0
cpu0:  on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
agp0:  mem 0xd000-0xdfff at 
device 0.0 on pci0
pcib1:  at device 1.0 on pci0
pci1:  on pcib1
pci1:  at device 0.0 (no driver attached)
isab0:  at device 3.0 on pci0
isa0:  on isab0
isab1:  at device 5.0 on pci0
device_attach: isab1 attach returned 6
atapci0:  port \
0xfff0-0x,0x376,0x170-0x177,0x3f6,D0x1f0-0x1f7 at device 5.1 on pci0
ata0: channel #0 on atapci0
ata1: channel #1 on atapci0

---nonworking atapci0 command, hand copied--

atapci0:  port \
0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 5.1 on pci0
Copyright (c) 1992-2005 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 5.4-STABLE #0: Tue May  3 21:29:44 EST 2005
[EMAIL PROTECTED]:/usr/src/sys/i386/compile/PORT
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel Pentium III (697.42-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x686  Stepping = 6
  
Features=0x383f9ff
real memory  = 402522112 (383 MB)
avail memory = 384188416 (366 MB)
npx0:  on motherboard
npx0: INT 16 interface
acpi0:  on motherboard
acpi0: Power Button (fixed)
Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0xfe08-0xfe0b on acpi0
cpu0:  on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
agp0:  mem 0xd000-0xdfff at 
device 0.0 on pci0
pcib1:  at device 1.0 on pci0
pci1:  on pcib1
pci1:  at device 0.0 (no driver attached)
isab0:  at device 3.0 on pci0
isa0:  on isab0
isab1:  at device 5.0 on pci0
device_attach: isab1 attach returned 6
atapci0:  port 
0xfff0-0x,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 5.1 on pci0
ata0: channel #0 on atapci0
ata1: channel #1 on atapci0
uhci0:  port 0xff80-0xff9f irq 11 at 
device 5.2 on pci0
usb0:  on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
pci0:  at device 5.3 (no driver attached)
pcib2:  at device 6.0 on pci0
pci2:  on pcib2
sym0: <875> port 0xce00-0xceff mem 0xefefe000-0xefefefff,0xefefff00-0xefef 
irq 11 at device 1.0 on pci2
sym0: Symbios NVRAM, ID 7, Fast-20, SE, parity checking
sym0: open drain IRQ line driver, using on-chip SRAM
sym0: using LOAD/STORE-based firmware.
atapci1:  port 
0xcdd0-0xcddf,0xcde4-0xcde7,0xcde8-0xcdef,0xcdf4-0xcdf7,0xcdf8-0xcdff irq 11 at 
device 3.0 on pci2
ata2: channel #0 on atapci1
ata3: channel #1 on atapci1
pci0:  at device 7.0 (no driver attached)
pci0:  at device 9.0 (no driver attached)
cbb0:  at device 11.0 on pci0
cardbus0:  on cbb0
pccard0: <16-bit PCCard bus> on cbb0
cbb1:  at device 11.1 on pci0
cardbus1:  on cbb1
pccard1: <16-bit PCCard bus> on cbb1
pcm0:  port 0xbf3c-0xbf3f,0xbf40-0xbf7f mem 
0xefdf8000-0xefdf irq 11 at device 12.0 on pci0
pcm0: 
xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xbe80-0xbeff mem 
0xefdf7f80-0xefdf7fff irq 11 at device 15.0 on pci0
miibus0:  on xl0
xlphy0: <3c905C 10/100 internal PHY> on miibus0
xlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
xl0: Ethernet address: 00:00:39:9b:35:2d
acpi_lid0:  on acpi0
acpi_cmbat0:  on acpi0
acpi_cmbat1:  on acpi0
acpi_acad0:  on acpi0
acpi_tz0:  on acpi0
atkbdc0:  port 0x64,0x60 irq 1 on acpi0
atkbd0:  irq 1 on atkbdc0
kbd0 at atkbd0
psm0:  irq 12 on atkbdc0
psm0: model Generic PS/2 mouse, device ID 0
fdc0:  port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
sio0: type 16550A
ppc0:  port 0x778-

Re: 5.4-STABLE changes breaks IDE boot (was Re: 5.3 -> 5.4 breaks ATA (Intel ICH2))

[Michael L. Squires]

A new kernel based on sources of 9/28/2005 still fails to boot on a 
Toshiba 8100 with a UDMA33 IDE onboard controller.  The parameters passed 
to atapci0 are different from those passed by the earlier kernel, and the 
system locks up this point.


I'm not including the dmesg, etc., since that's the same as I posted 
earlier.


Mike Squires

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 5.4-STABLE changes breaks IDE boot (was Re: 5.3 -> 5.4 breaks ATA (Intel ICH2))

[Michael L. Squires]

On Thu, 29 Sep 2005, Michael L. Squires wrote:

A new kernel based on sources of 9/28/2005 still fails to boot on a Toshiba 
8100 with a UDMA33 IDE onboard controller.  The parameters passed to atapci0 
are different from those passed by the earlier kernel, and the system locks 
up this point.




Following suggestions elswhere I replaced acpi.ko in the new kernel 
directory with the acpi.ko from the last working kernel and the new kernel 
now boots.


I'll run the usual ACPI debugging info and post to the freebsd-acpi 
mailing list.


Mike Squires
Toshiba 8100

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 5.3 -> 5.4 breaks ATA (Intel ICH2)

[Michael L. Squires]

On Sat, 24 Sep 2005, Billy Newsom wrote:

Okay, Tim, I just reported the same bug in a previous post. So did Julian C. 
Dunn. I think this is an issue with some recent code changes in CVS...


See these threads:

critical BOOT failure updating to latest 5-Stable (5.4)
9/23/2005 12:07 AM

ATA lockup with 5.4-STABLE
9/21/2005 10:19 PM



I have a similar problem (previously posted to this mailing list) with a 
Toshiba 8100 which locks up when atapci0 is called during the boot using 
recent kernels.


I can boot off an old 5.4-RELEASE kernel (May 2005) and can boot off the 
more recent kernels if I copy the old version of acpi.ko over the new 
version, which leads me to believe that it is changes in the ACPI code 
which are the source of the problem.


I've posted to the ACPI mailing list (I'm not aware of any responses).

Mike Squires

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Toshiba 8100 Fix (was Re: 5.4-STABLE changes breaks IDE boot (was Re: 5.3 -> 5.4 breaks ATA (Intel ICH2))

[Michael L. Squires]

I have a Toshiba 8100 notebook which runs 5.4-STABLE.  Kernels compiled 
after some time in September 2005 fail to boot; the machine locks up right 
after the ata controller is called in the boot messages.


I have traced the problem to a change to /usr/src/sys/dev/pci.c, (see 
below from my cvsup log).  I found the problem by cvsup'ing /usr/src for 
dates starting with my last working kernel and once I had the date of 
problem code tied down to a couple of days adding in each update to see if 
it caused the failure to boot.  I then added the fix to the latest 5.4 
sources to make sure that the fix still worked.


The problem (really the Toshiba 8100 BIOS problem) was 
triggered by:


 Edit src/sys/dev/pci/pci.c
  Add delta 1.264.2.12 2005.09.05.18.09.20 imp

which changes line 835 of pci.c from

if (base == 0)
to
if (base == 0 || map == testval)

The sysctl parameter "hw.pci.enable_io_modes" is supposed to allow PCs 
with "lazy" BIOSes to boot, but in the case of the 8100 setting


hw.pci.enable_io_modes: 0

doesn't allow the system to boot.

This is obviously a problem with the Toshiba BIOS, which I know from other 
times has other problems; I am putting this here in case someone else has 
the same problem and wants to boot FreeBSD 5.4-STABLE with a kernel 
revision after 9/5/2005.


Mike Squires
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Still seeing SMP panics on a older dual PIII (with debug kerneland crash dumps)

[Michael L. Squires]

> Its an older dual PIII.  Can anyone tell me if the dumps point to a 
> hardware issue, or if its crashing in the same spot each time ? I can blast 
> it with buildworlds and it never dies.  Generally I have yet to find bad 
> hardware that could pass that But always a first time.

I have a P6DGH with two PII/300's running 4.8-RC2; mptable crashes with
a "HOSED" error message for the extended table (indicative of a BIOS
problems) but no crashes.

MLS

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message

4.10-BETA, Supermicro P6DGH, SMP = no problems

[Michael L. Squires]

4.10-BETA caused no problems during building world, the kernel, or
portupgrade compared to 4.9-STABLE of early March.

Bytebench results for 4.10-BETA and 4.9-STABLE are very similar, for
what that's worth.

Hardware is a P6DGH/dual PII/300/two vinum RAID5 arrays using old Seagate
Elite drives (5 x 23GB and 4 x 46GB)/Intel Pro100+.

No problems with SMP, either, other than "mptable" having its extended
table "hosed" which has been true of this MB from day 1.

Mike Squires
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"