Date: Sun, 27 Dec 2009 17:29:53 +0100 From: Marius Strobl <marius@alchemy.franken.de> To: Gavin Atkinson <gavin@FreeBSD.org> Cc: freebsd-sparc@FreeBSD.org Subject: Re: V480R: panic: schizo_attach: could not register interrupt controller for CDMA (17) Message-ID: <20091227162953.GA43157@alchemy.franken.de> In-Reply-To: <alpine.BSF.2.00.0912262111120.19685@ury.york.ac.uk> References: <alpine.BSF.2.00.0912262111120.19685@ury.york.ac.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Dec 26, 2009 at 09:48:45PM +0000, Gavin Atkinson wrote: > > Hi all, > (marius@ cc'd as the panic was introduced with r185133) > > I'm seeing this panic on a V480r I'm netbooting: > > panic: schizo_attach: could not register interrupt controller for CDMA (17) > > I've stuck the full verbose dmesg of the panic with SCHIZO_DEBUG set at > http://people.freebsd.org/~gavin/v480r/boot-panic > > If I replace the call to panic() with a printf() (patch I'm using is at > http://people.freebsd.org/~gavin/v480r/schizo.diff ) then the machine will > boot fully and soesn't seem to show any issues. I've put the dmesg from a > successful boot at > http://people.freebsd.org/~gavin/v480r/boot-withpatch > > Ss, I guess my question is: is the panic in the code appropriate for all > Schizo busses, or just the first one? Two of the four Schizo busses do > not seem to list this interrupt as one available on the bus. > > Output of "prtconf -pPv" here: > http://people.freebsd.org/~gavin/v480r/prtconf-pPv > Hi, the problem is that unlike all firmware versions I've seen so far this one actually includes the CDMA interrupt at RID 4 for all four host-PCI bridges. The workaround is applicable to all four Schizos and you most likely did not seen further problems with your hack due to your machine not having any PCI-PCI bridges. Could you please give the following patch a try instead? http://people.freebsd.org/~marius/schizo_cdma2.diff Have you used the Cassini interfaces in this machine so far? On the few E480R FreeBSD has been given a try so far (but which obviously are at least equipped with different firmware version if not even being another hardware revision) using the on-board NICs triggers a seemingly unrelated FATAL RESET in tl0_dmmu_miss which if the dump generated by the firmware can be trusted apparently is due to the fact that the CPUs erroneously report a TSB base of zero. Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091227162953.GA43157>