headers
Zafer Aydogan | 3 Jun 2007 13:54
Picon

sparc64 and LFS success

hello list,

some of you might know that LFS works fine with sparc64.
I've been successfully working with LFS on a root partition on i386,
an i've tried to do the same on sparc64.

Whereas i386 can really boot from LFS (bootstrap code), i've did some
tricks to get it working on sparc64.

I've created a small ffsv1 partition where the netbsd kernel and ofwboot relies
and a big LFS partition. Then I compiled a custom kernel that dumps
root on the LFS partition.
This works fine.

$ uname -a
NetBSD sparc64.aydogan.net 4.99.20 NetBSD 4.99.20 (ZASPARC) #2: Fri
Jun  1 00:38:25 CEST 2007
zafer <at> h980372:/home/zafer/netbsd/usr/src/sys/arch/sparc64/compile/obj/ZASPARC
sparc64

$ mount
/dev/wd0d on / type lfs (local)
ptyfs on /dev/pts type ptyfs (local)
tmpfs on /tmp type tmpfs (local)

Regards,
Zafer Aydogan.
Permalink | Reply | 0 comments |
headers
Pierre Pronchery | 4 Jun 2007 14:08
Gravatar

Could not compile -current

	Hi port-sparc64 <at> ,

compiling -current failed for me yesterday with the following error:

#   compile  libc/memmove.o
/usr/tools/bin/sparc64--netbsd-gcc -O2 -Wall -Wstrict-prototypes
-Wmissing-proto
types -Wpointer-arith -Wno-sign-compare -Wno-traditional -Wreturn-type
-Wswitch
-Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wno-unused-parameter
-std=gnu99  -
Werror  -fstack-protector -Wstack-protector --param ssp-buffer-size=1
-D_LIBC
-DLIBC_SCCS -DSYSLIBC_SCCS -D_REENTRANT -DHESIOD -DINET6 -DNLS -DYP
-I/usr/src/l
ib/libc/include -I/usr/src/lib/libc -DSOFTFLOATSPARC64_FOR_GCC
-I/usr/src/lib/li
bc/arch/sparc64/softfloat -I/usr/src/lib/libc/softfloat
-I/usr/src/lib/libc/sof
tfloat/bits64 -I/usr/src/sys -I/usr/src/lib/libc/compat/stdlib
-I/usr/src/lib/li
bc/compat/../stdlib -I/usr/src/lib/libc/../../common/lib/libc/quad
-I/usr/src/li
b/libc/../../common/lib/libc/string
-I/usr/src/lib/libc/../../common/lib/libc/ar
ch/sparc64/string -D__DBINTERFACE_PRIVATE -DI18NMODULE_MAJOR=4 -DCITRUS
-I/usr/s
rc/libexec/ld.elf_so -I/usr/src/lib/libc/dlfcn -I/usr/src/lib/libc/gdtoa
-DNO_FE
NV_H -I/usr/src/lib/libc/arch/sparc64/gdtoa -DCITRUS_ICONV -DWITH_RUNE
(Continue reading)

Permalink | Reply | 1 comment |
headers
Pierre Pronchery | 6 Jun 2007 13:15
Gravatar

Re: Could not compile -current

Pierre Pronchery wrote:
> compiling -current failed for me yesterday with the following error:
> 
> #   compile  libc/memmove.o

From the CVS logs It looks like this is fixed now:
http://cvsweb.netbsd.org/bsdweb.cgi/src/common/lib/libc/string/

Cheers,
--

-- 
khorben
Permalink | Reply | 0 comments |
headers
Shawn W. | 7 Jun 2007 21:11
Picon

Load average and trying -current

I have an Ultra 5 with a 270mhz UltraSparc IIi running NetBSD 3.1,  
that usually sits around running dhcpd and hosting a ssh login. Its  
load average when idle is consistently in the 0.08-0.10 range.  
Looking at top, [ioflush] is consistently at the top of CPU-usage.  
I'm used to other operating systems having a load average of 0 when  
idle like that. Any idea what's happening?

Also, since while 3.1 is the latest release, it seems to be based on  
a many-years-old version of the development tree, I'm thinking about  
updating to a 4.0 beta (If I can find a recent one compiled for  
sparc64) or a -current snapshot (They're not the same thing, right?  
Trying to find out any information about what'll be in future  
releases and how -current relates to 4.0 on the netbsd web page was  
frustrating) so I can play with the latest and greatest -- in  
particular, hardware accelerated GL, since my Ultra 5 has an ATI Mach  
64 card (I don't think I'd /use/ it since I usually don't have a  
monitor even hooked up to the machine, but it would be rewarding to  
see a fast glxgears). Getting the thread bug fix would be nice too.  
And, mmm... do any of the development versions support SMP on  
sparc64? I have a dual-cpu Ultra 60 with an old version of FreeBSD I  
wouldn't mind using with Net instead.

Thanks.

--

-- 
Shawn W.
shawnw <at> speakeasy.org
Permalink | Reply | 3 comments |
headers
Martin Husemann | 7 Jun 2007 22:37
Picon

Re: Load average and trying -current

On Thu, Jun 07, 2007 at 12:11:08PM -0700, Shawn W. wrote:
> load average when idle is consistently in the 0.08-0.10 range.  
> Looking at top, [ioflush] is consistently at the top of CPU-usage. 

This is not sparc64 specific. The syncer wakes up periodically and
looks for work - apparently it gets sampled often enough as "runnable"
so it adds to the load average. I'm not sure if we should worry about it,
or even work around it for cosmetic reasons.

> Also, since while 3.1 is the latest release, it seems to be based on  
> a many-years-old version of the development tree, I'm thinking about  
> updating to a 4.0 beta (If I can find a recent one compiled for  
> sparc64) or a -current snapshot (They're not the same thing, right?  

Yes, they are not the same thing.

You can find snapshots on 

   ftp.netbsd.org:/pub/NetBSD/NetBSD-daily/netbsd-4/*/iso

or

   ftp.netbsd.org:/pub/NetBSD/NetBSD-daily/HEAD/*/iso

You can find information about the versioning here:

   http://www.netbsd.org/Releases/release-map.html

One concrete difference between the 4.0 branch and -current right now is the
new threading in -current. 4.0 will still have the SA based one (though many
(Continue reading)

Permalink | Reply | 1 comment |
headers
Shawn W. | 8 Jun 2007 09:01
Picon

Re: Load average and trying -current

On Jun 7, 2007, at 1:37 PM, Martin Husemann wrote:

> On Thu, Jun 07, 2007 at 12:11:08PM -0700, Shawn W. wrote:
>> load average when idle is consistently in the 0.08-0.10 range.
>> Looking at top, [ioflush] is consistently at the top of CPU-usage.
>
> This is not sparc64 specific. The syncer wakes up periodically and
> looks for work - apparently it gets sampled often enough as "runnable"
> so it adds to the load average. I'm not sure if we should worry  
> about it,
> or even work around it for cosmetic reasons.
>

As long as it's harmless, I'll stop worrying about it.

> You can find information about the versioning here:
>
>    http://www.netbsd.org/Releases/release-map.html
>

Ooo. I don't know how I missed that, but the timeline and chart  
answered a lot of questions about how the various releases relate to - 
current..

> One concrete difference between the 4.0 branch and -current right  
> now is the
> new threading in -current. 4.0 will still have the SA based one  
> (though many
> bugs have been fixed).
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Doran | 8 Jun 2007 10:13
Picon

Re: Load average and trying -current

Hi Shawn,

On Thu, Jun 07, 2007 at 12:11:08PM -0700, Shawn W. wrote:

> I have an Ultra 5 with a 270mhz UltraSparc IIi running NetBSD 3.1,  
> that usually sits around running dhcpd and hosting a ssh login. Its  
> load average when idle is consistently in the 0.08-0.10 range.  
> Looking at top, [ioflush] is consistently at the top of CPU-usage.  
> I'm used to other operating systems having a load average of 0 when  
> idle like that. Any idea what's happening?

The load average calculation has been broken for a long time, but it's
fixed in -current. The fix may still be merged into what will become 
NetBSD 4.

> Also, since while 3.1 is the latest release, it seems to be based on  
> a many-years-old version of the development tree, I'm thinking about  
> updating to a 4.0 beta (If I can find a recent one compiled for  
> sparc64) or a -current snapshot (They're not the same thing, right?  

No, NetBSD 4 was branched from -current some months ago and is in the
process of being released. I don't know of an ETA yet but it will be
some time soon. -current is in a continuous state of development and
is not guaranteed to be stable.

> Trying to find out any information about what'll be in future  
> releases and how -current relates to 4.0 on the netbsd web page was  
> frustrating) so I can play with the latest and greatest -- in  
> particular, hardware accelerated GL, since my Ultra 5 has an ATI Mach  
> 64 card (I don't think I'd /use/ it since I usually don't have a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Ross | 11 Jun 2007 16:20

Problems netbooting a sparc64


   I have a DP ultrasparc enterprise 2 that I thought I'd bring up to  
current and poke around the SMP code.  I have booted both sparc's and  
sparc64's diskless in the past, but I don't do it often.

   I was reading through all of the documentation at www.netbsd.org,  
dated though some of it is, and I think I have it mostly working.   
The problem I believe I'm having is that it's taking the hme in the  
machine too long to negotiate the link with my cisco switch.  I've  
seen this sort of thing happen before with Ciscos.

   When I type "boot net", I can watch the console on the cisco  
switch, see the link flap, then it's about 40-45 seconds after that  
before the rarpd on the server noted getting a packet.  I don't know  
how often the OFW sends packets, but I'd guess it's at least 30  
seconds before traffic will pass through the cisco, maybe more like  
40.  Then, I'm getting the ofb loaded (via tftp):

 >> NetBSD/sparc64 OpenFirmware Boot, Revision 1.10
 >> (cross <at> host.built.on, Say Jun  9 02:28:56 EDT 2007)

  ...and then after about 25-30 seconds, it reports:

bootp: no reply
Using BOOTPARAMS protocol: ip address: AA.BB.CC.DD

   But, this won't work.  It won't be able to find the server or root  
path, since that's all in the dhcpd.conf on my DHCP server.

   Anyone know if there's a way to make the OFW bootloader (in -
(Continue reading)

Permalink | Reply | 12 comments |
headers
Julian Coleman | 11 Jun 2007 17:20
Picon

Re: Problems netbooting a sparc64

>   Thanks...  I'm going to see if I can make the cisco stupider or  
> something.  :-)

At a guess, the cisco runs spanning tree by default on all its interfaces.
There will be a 30 second delay after the link changes to up before the port
goes into the forwarding state, by which time the Sun has timed out (the link
must be changing down then up during the boot process).  You can make the
cisco not do this by disabling the spanning tree forwarding delay on that
port:

  conf t
  int f0/x	# relevant interface here
  spanning-tree portfast
  end
  wr

J

--

-- 
  My other computer also runs NetBSD    /        Sailing at Newbiggin
        http://www.netbsd.org/        /   http://www.newbigginsailingclub.org/
Permalink | Reply | 7 comments |
headers
Chris Ross | 11 Jun 2007 17:28

Re: Problems netbooting a sparc64


On Jun 11, 2007, at 11:20 AM, Julian Coleman wrote:
> At a guess, the cisco runs spanning tree by default on all its  
> interfaces.
> There will be a 30 second delay after the link changes to up before  
> the port
> goes into the forwarding state, by which time the Sun has timed out  
> (the link
> must be changing down then up during the boot process).

   Ahh!  Excellent.  Thank you.  I was looking for a way to disable  
spanning-tree, but "no spanning-tree" didn't work, and I didn't  
interpret "portfast" as the way to effectively disable that  
behavior.  Thank you very much for your assistance.

   It's booting up the kernel, and the kernel is able to mount the  
root filesystem (which required another flap and DHCP, of course).   
Thanks!

   Now, would booting a GENERIC.MP kernel give me anything of  
value?  ;-)  Is there anything useful I could provide to that effort  
without spending days learning about the hard-core internals of UPA  
and UltraSparc II processors?

                         - Chris
Permalink | Reply | 6 comments |

Gmane