Date: Thu, 28 Apr 2005 13:17:24 +0100 From: Gavin Atkinson <gavin.atkinson@ury.york.ac.uk> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: freebsd-sparc64@freebsd.org Subject: Re: 5.4-RCx "jumping to kernel entry" hang on Ultra1/2/30 Message-ID: <1114690644.26778.9.camel@buffy.york.ac.uk> In-Reply-To: <20050427190459.GC41874@ns1.xcllnt.net> References: <Pine.SOC.4.61.0504270648130.20306@terminator.alaska.net> <20050427190459.GC41874@ns1.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2005-04-27 at 12:04 -0700, Marcel Moolenaar wrote: > On Wed, Apr 27, 2005 at 07:08:52AM -0800, Royce Williams wrote: > > > > On Sun, 17 Apr 2005, IX@pandora.be wrote: > > > > > > > > >On Thu, 14 Apr 2005, Gheorghe Ardelean wrote: > > > > > >>Hi, > > >> > > >>While trying to boot a plain U1 from a disk installed with > > >>5.4-RC2 > > >>(the disk was installed in a U5) the systems hangs just > > >>after entering the kernel. > > > > > > > > >I see the same hang on an ultra2, booting from the 5.4RC2 > > >bootonly iso. I don't know what details I need to provide. > > >If it's useful, I can send a NetBSD dmesg output. > > > > > >Kind regards, > > >dieter > > > > > > This is happening to me too, 5.4-RC3 disc 1, Ultra 30. I can't > > recreate using 5.2.1R or 5.3R disc 1 ISOs. This is now reportedly > > happening to three different people with three different models. Is > > there a boot-only ISO with full debugging/verbosity available? > > I think I have a fix for it, but it needs to be verified that to > really solves the problem before I run off to re@ and shout: "stop > the presses!" > > The patch is attached. I just don't know a good way (short of > creating a patched-up 5.4-RC install ISO for people to try it. > > Ken: did you build 5.4-RC3 for sparc64 and if yes do you still have > the $CHROOTDIR around? I don't know if it's a useful datapoint for you, but I have a SunFire 280R (UltraSparc III processors, and therefore unsupported) which hangs at this point as well. Your patch does not help. Reverting to ofw_console fixes it and lets the boot continue, so I guess you're right in the assumption that the problem is in the uart driver. The serial chipset seems to be either a sab82532 or a 16550, depending on which part of the device tree I should believe. If this information is of use to you, I have access to a netbooted setup where I can trivially test patches for you on the 280R. Gavin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1114690644.26778.9.camel>