Re: Boot NetBSD9.1 on a SUN Blade 100

[Julian Coleman <jdc%coris.org.uk@localhost>]

Hi,

> hmm, strange. Nothing attached to the Firewire-Ports. The code looks like that
> watchdog_clock never gets reset? Is there a way to disable the FW-ports  via a
> boot.conf or something?

Unfortunately, we need to remove it from the kernel.

> I downloaded the source for the 9.2-kernel and there seems to be a mismatch
> in the versions of firewire.c on the website you mentioned and what I have
> found in the kernel tree.
> The version in 9.2 seems to be 1.48 and the version on the website is 1.51.
> Actually, line 1323 in version 1.48 is in a different function...
> Which kernel is generated by the sources from the website?

nxr.netbsd.org has the current sources.  The 9.x kernels are on a different
branch, which is why you see the different versions.  There is also the
CVS history for the file at:

  http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/ieee1394/firewire.c

Looking at that code though, it hasn't changed for a long time.  So, I was
wondering if something other change is causing that problem.  It tempting
to try to increase the multiplier from 15 to something larger to see if we
just need to wait longer [1], or just to try a kernel without FW to really
check that it is the problem.  I've built a kernel from GENERIC without FW:

  http://ftp.netbsd.org/pub/NetBSD/misc/jdc/sparc64/netbsd

and if you are able to test boot that, then it would be useful [2].  There
is also the version with full debugging symbols [3]:

  http://ftp.netbsd.org/pub/NetBSD/misc/jdc/sparc64/netbsd.gdb

and the kernel configuration that I used:

  http://ftp.netbsd.org/pub/NetBSD/misc/jdc/sparc64/GENERIC-NOFW

Regards,

Julian

[1] Instead of waiting, we might just be able to check if we are running
with interrupts after start, like the check here:

  https://nxr.netbsd.org/xref/src/sys/arch/sparc/dev/ts102.c#1044

[2] my test netbsd-9 has a few local changes in some drivers, but nothing
that should affect this.

[3] The .gdb file is useful because we can match a backtrace to a source
line.  For example:

> firewire_watchdog(101d8a040, 101d8a041, 0, 1cba038, 1cba038, 101d8a040) at
netbsd:firewire_watchdog+0x48

:; gdb netbsd.gdb
(gdb) list *(firewire_watchdog+0x48)
  ...