Port-sparc archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: anyone have a theory why net boot of a SPARC20 hangs?



Hi,

[trimmed out some lines for brevity]
> 
> Here is a good one ... everything seems to work but the root filesystem
>  is not found :

> <#0> ok boot /iommu@f,e0000000/sbus@f,e0001000/qec@0,20000/qe@0,0
> Boot device: /iommu@f,e0000000/sbus@f,e0001000/qec@0,20000/qe@0,0  File and
> args:

> [   1.0000000] bootpath:
> /iommu@f,e0000000/sbus@f,e0001000/qec@0,20000/qe@0,0

From the PROM command to our bootpath parser, things look OK.

> [   1.0000030] qec0 at sbus0 slot 0 offset 0x20000 level 4 (ipl 7): 128K
> memory
> [   1.0000030] qe0 at qec0 slot 0 offset 0x0 rev 1 address 08:00:20:00:de:ad
> [   1.0000030] qe1 at qec0 slot 1 offset 0x0 rev 1 address 08:00:20:00:de:ad
> [   1.0000030] qe2 at qec0 slot 2 offset 0x0 rev 1 address 08:00:20:00:de:ad
> [   1.0000030] qe3 at qec0 slot 3 offset 0x0 rev 1 address 08:00:20:00:de:ad

Then the devices attach OK.  Note here, that the qec device has 4 child qe
devices.

> [   6.2498235] can't determine root device

This is machine dependent code, so the sparc-specific bootpath code didn't
pass a useable value.

> [  26.8906720] root device (default qec0):
> [  26.9485770] dump device:
> device9704040] file system (default generic):

This looks strange to me - the default is "qec0" and I would expect it to
be "qe0".

> [  27.2303640] root device (default qec0): 172.16.35.44:/export/netbsd_sparc
> [  27.3325900] use one of: fd0[a-h] hme0 le0 qe0 qe1 qe2 qe3 be0 sd0[a-h]
> cd0[a-h] ddb halt reboot
> [  27.4309715] root device (default qec0):
> [  27.4916515] dump device: none

And there is hint in the "use one of" line, so typing "qe0" should work
here.  Faster would be to add "-a" or "-as" at the end of the PROM boot
line so that it asks (the bootloader will also ask for the kernel name,
so you'll need to type "netbsd" or just <return> for the default list.

> So it gets to looking for the root device which should be NFS and the NFS
> server is happy to offer that over NFSv3. Not sure what the hiccup
> is here.

I assume that the NFS server is OK, and the problem is in the sparc code.
Looking at:

  https://nxr.netbsd.org/xref/src/sys/arch/sparc/sparc/autoconf.c#device_register

I'm not sure that anyone has tried booting from a QEC card before, so we're
probably missing something specific for qec/qe cards.  I'm guessing that
we'll need something in device_register() or instance_match() to handle
them.

If you can compile your own kernel, adding DEBUG to get more output from
the autoconf routines would be useful.  Otherwise, let me know and I can
build some test kernels to try out.

Regards,

Julian

-- 


Home | Main Index | Thread Index | Old Index