named kills raspberry pi

[Brett Wynkoop]

On Thu, 7 Feb 2013 22:30:38 +0000
"Steve O'Hara-Smith" <steve at sohara.org> wrote:

> 	Hi,
> 
> 	As soon as I start named either by rc.d script or directly,
> whether in an ssh session or directly on the video console, with or
> without chroot, my early model 256MB model B pi locks up solid, no
> response on console, all ssh sessions freeze, no response to ping,
> nothing until power cycle. I can build ports all day long, but if I
> start named everything stops dead.
> 
> 	I'm using about a two day old head tree currently but it's
> been happening for several days now since I first tried it. The uboot
> (20130201) and script I use are from
> http://people.freebsd.org/~gonzo/arm/rpi/ with minor changes to the
> script (-j 4 and no pi user) and a kernel config that includes pf and
> altq. I earlier used the older script and uboot with the same results.
> 
> 	Any ideas on how I can coax some more useful detail out of
> this ?
> 

Greeting-

I just started named in base on a build from head as of 5 days ago on
my BeagleBone.  I made no adjustments to any config files, so it is
running listening on localhost and acting as a caching server.  

root at beaglebone:/etc/rc.d # ./named onestart

wrote key file "/var/named/etc/namedb/rndc.key"
Starting named.
root at beaglebone:/etc/rc.d # 
root at beaglebone:/etc/rc.d # ps ax | grep name
16104  -  Is      0:01.41 /usr/sbin/named -t /var/named -u bind
16107  0  R+      0:00.10 grep name
root at beaglebone:/etc/rc.d # 
root at beaglebone:/etc/rc.d # nslookup
> server localhost
Default server: localhost
Address: 127.0.0.1#53
Default server: localhost
Address: ::1#53
> www.isc.org
Server:         localhost
Address:        127.0.0.1#53

Non-authoritative answer:
Name:   www.isc.org
Address: 149.20.64.42
> www.wynn.com
Server:         localhost
Address:        127.0.0.1#53

Non-authoritative answer:
Name:   www.wynn.com
Address: 199.89.147.3
> 


So......it seems to be working on my BeagleBone with 256 Mb.  If you
can give me more information I will see what I can determine by playing
with my Bone.

One thing I might suggest would be building a somewhat more generic
kernel without pf and altq.  My kernel is pretty generic with just some
extra debugging flags included.  I do not think that either pf or altq
should be the problem, but with trouble shooting I always eliminate
variables first.

-Brett

-- 

wynkoop at wynn.com               http://prd4.wynn.com/wynkoop/pgp-keys.txt
917-642-6925
718-717-5435

I would never invade the United States.  There would be a gun behind
every blade of grass.  --Isoroku Yamamoto