This works for me fine on 1.6.2 with the arp entry added.
However on 2+ it fails.

-Ober


On Tue, 24 Oct 2006, Cory Bajus wrote:

> Date: Tue, 24 Oct 2006 11:53:37 -0500
> From: Cory Bajus <cbajus@mts.net>
> To: Jaime A Fournier <ober@linbsd.org>
> Cc: port-next68k@netbsd.org
> Subject: Re: next86k bootp hangs
> 
> I'm not sure if this is related, but I've found that the NeXT firmware
> does not respond to ARP requests from the boot server.  For me, it fails
> after receiving the bootp reply but before tftp'ing the bootloader.  The
> fix is to add a permanent arp entry on the boot server (assuming they are
> on the same subnet) with 'arp -s <ipaddr> <etheraddr>'.
>
> On Fri, Oct 13, 2006 at 02:40:22AM -0500, Jaime A Fournier wrote:
>> It seems to boil down to
>> src/sys/net/if.c:1581
>>                 error = ((*so->so_proto->pr_usrreq)(so, PRU_CONTROL,
>>                     (struct mbuf *)cmd, (struct mbuf *)data,
>>                     (struct mbuf *)ifp, p));
>> It hangs here and does not continue.
>> Can't figure out what it's trying to do here, but thought I would publish
>> what I have found so far.
>>
>>
>> -Ober
>>
>>
>> On Fri, 13 Oct 2006, Jaime A Fournier wrote:
>>
>>> Date: Fri, 13 Oct 2006 01:10:49 -0500 (CDT)
>>> From: Jaime A Fournier <ober@linbsd.org>
>>> To: port-next68k@NetBSD.org
>>> Subject: next86k bootp hangs
>>>
>>>
>>> I have isolated the line where the kernel hangs.
>>>
>>> The dmesg ends at:
>>> boot device: xe0
>>> root on xe0
>>> mountroot: trying nfs...
>>> nfs_boot: trying DHCP/BOOTP
>>>
>>> You can not break into ddb via NMI when it hangs.
>>>
>>> The last call is makes is the following:
>>>
>>> src/sys/nfs/nfs_boot.c:280
>>>
>>>      error = ifioctl(so, SIOCAIFADDR, (caddr_t)&iareq, procp);
>>>
>>> On 1.6.2 the nfs_boot line is followed by:
>>>     in6_ifattach: xe0 is not multicast capable, IPv6 not enabled
>>>
>>> Will keep digging, just wanted to submit what I have found so far.
>>>
>>>
>>>
>>> -Ober
>>>
>