Re: Boot NetBSD9.1 on a SUN Blade 100
Julian Coleman <[email protected]>
| Newsgroups | gmane.os.netbsd.ports.sparc64 |
|---|---|
| Message-ID | <YMsv5RMf3cZpXfL+@hrad> |
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) ...