The following reply was made to PR system/5816; it has been noted by GNATS.
From: bsd@openbsd.rutgers.edu
To: Brad <brad@comstyle.com>
Cc: gnats@openbsd.org
Subject: Re: system/5816: MCP55 nfe watchdog timeout
Date: Wed, 14 May 2008 15:48:48 -0400
On 13 May 2008 at 20:28, Brad <brad@comstyle.com> wrote:
> On Tuesday 13 May 2008 10:03:22 bsd@openbsd.rutgers.edu wrote:
> > >Number: 5816
> > >Category: system
> > >Synopsis: nfe watchdog timeout
> > >Confidential: yes
> > >Severity: serious
> > >Priority: medium
> > >Responsible: bugs
> > >State: open
> > >Quarter:
> > >Keywords:
> > >Date-Required:
> > >Class: sw-bug
> > >Submitter-Id: unknown
> > >Arrival-Date: Tue May 13 14:10:01 GMT 2008
> > >Closed-Date:
> > >Last-Modified:
> > >Originator:
> > >Release: 4.3-current
> > >Organization:
> > >Environment:
> > System : OpenBSD 4.3
> > Details : OpenBSD 4.3-current (GENERIC.MP) #1660: Fri May 2 03:17:
51 MDT 2008
> > deraadt@amd64.openbsd.org:/usr/src/sys/arch/amd64/comp
ile/GENERIC.MP
> > Architecture: OpenBSD.amd64
> > Machine : amd64
> > % grep nfe /var/run/dmesg.boot
> > nfe0 at pci8 dev 8 function 0 "NVIDIA MCP55 LAN" rev 0xa3pci_intr_map: bus
128 dev 8 func 0 pin 1; line 10
> > nfe1 at pci8 dev 9 function 0 "NVIDIA MCP55 LAN" rev 0xa3: apic 4 int 15 (i
rq 11), address 00:aa:bb:cc:dd:ee
> > eephy0 at nfe1 phy 3: Marvell 88E1149 Gigabit PHY, rev. 3
> > (Yes it really looks like that)
> > >Description:
> > Right after going multiuser I get "nfe1: watchdog timeout"
> > Both on-board nfe's are unable to ping a peer on the local segment
> > >How-To-Repeat:
> > Boot an Ultra 40 with GENERIC.MP.
> > >Fix:
> > Not sure. Looks like a similar issue I saw with an Ultra 20.
>
> There is an issue with interrupts on this system. You didn't provide a
> full dmesg though. Are you using ACPI? Try disabling ACPI and see if
> there is any change in behavior. In the future always provide a full
> dmesg unless asked otherwise.
Thanks -- I won't make that mistake again.
http://openbsd.rutgers.edu/u40/ now contains dmesgs:
dmesg.without-acpi.UP.txt
dmesg.with-acpi.MP.txt
Those were the only combinations that go multiuser.
Disabling acpi lets GENERIC (UP) actually boot now; before, it would
crash with:
[...]
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu1: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative
uvm_fault(0xffffffff80b25200, 0xffff800000007000, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at k8pnow_acpi_init+0x62: movl 0x10(%rdx,%rax,8),%edx
k8pnow_acpi_init() at k8pnow_acpi_init+0x62
k8_powernow_init() at k8pnow_acpi_init+0xbe
mainbus_attach() at mainbus_attach+0x159
config_attach() at config_attach+0x11b
cpu_configure() at cpu_configure+0x1c
main() at main+0x3b2
end trace frame: 0x0, count: 5
Once GENERIC (UP) without acpi is booted, tcpdump shows me broadcasts
but I cannot seem to transmit or receive icmp or tcp (didn't try udp).
GENERIC.MP goes multiuser with acpi but throws watchdog timeouts for
nfe1, and nothing is seen with tcpdump (as in my original report).
GENERIC.MP with acpi disabled hangs at:
[...]
spkr0 at pcppi0
usb1 at ohci0: USB revision 1.0
uhub1 at usb1 "NVIDIA OHCI root hub" rev 1.00/1.00 addr 1
<hang>
No amount of disabling stuff has permitted it to go farther than that,
yet.
If there's any way I can help to get this machine fixed up, I'd be more
than happy to do my part... thanks.
