From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jeff Sickel <jas@corpus-callosum.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Message-Id: <F6F0518F-4AB9-478B-967F-72E50802FFDD@corpus-callosum.com>
Date: Tue, 13 May 2014 13:31:51 -0500
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
Subject: [9fans] arm fun
Topicbox-Message-UUID: e6316eb6-ead8-11e9-9d60-3106f5b1d025

I may be one of the few with a still surviving Kirkwood dreamplugs,
though that could be tentative as who knows how long the hardware will
last.  After the thing was running relatively well for a long
period of time, I finally got around to changing some http settings,
rebuilt userland, and prepared to finally get some http requests
handled correctly.

Now, unfortunately, many processes don=92t live so long.  The first
I noticed was httpd that would respond a few times, until:

	none            96    0:00   0:00     1436K Semacqui httpd

	dream% chmod +w /proc/96/mem
	dream% acid 96
	/proc/96/text:arm plan 9 executable
	/sys/lib/acid/port
	/sys/lib/acid/arm
	acid: stk()
	semacquire()+0xc /sys/src/libc/9syscall/semacquire.s:6
	lock(l=3D0x31208)+0x20 /sys/src/libc/port/lock.c:10
	plock()+0x8 /sys/src/libc/port/malloc.c:80
	poolalloc(p=3D0x35a4c,n=3D0x2c)+0xc =
/sys/src/libc/port/pool.c:1223
	mallocz(size=3D0x24,clr=3D0x1)+0x18 =
/sys/src/libc/port/malloc.c:221
	getnetconninfo(fd=3D0xffffffff,dir=3D0x5ffffeb4)+0x78 =
/sys/src/libc/9sys/getnetconninfo.c:59
	dolisten(address=3D0xd1704)+0x134 =
/sys/src/cmd/ip/httpd/httpd.c:291
	main(argc=3D0x0,argv=3D0x5fffff74)+0x1c0 =
/sys/src/cmd/ip/httpd/httpd.c:138
	_main+0x28 /sys/src/libc/arm/main9.s:19
	acid:=20



When I=92d try and kill it, there=92d be a likely chance that rc
would also get the same Semacquire deadlock.  This can also be seen
using broke to try and prune dead dns processes:

	dream% acid 158
	/proc/158/text:arm plan 9 executable
	/sys/lib/acid/port
	/sys/lib/acid/arm
	acid: stk()
	semacquire()+0xc /sys/src/libc/9syscall/semacquire.s:6
	lock(l=3D0x17104)+0x20 /sys/src/libc/port/lock.c:10
	plock()+0x8 /sys/src/libc/port/malloc.c:80
	poolalloc(p=3D0x18a8c,n=3D0x10)+0xc =
/sys/src/libc/port/pool.c:1223
	mallocz(size=3D0x8,clr=3D0x1)+0x18 =
/sys/src/libc/port/malloc.c:221
	Malloc()+0x8 /sys/src/cmd/rc/plan9.c:624
	emalloc(n=3D0x8)+0x4 /sys/src/cmd/rc/subr.c:9
	newword(wd=3D0x18e4e,next=3D0x202d0)+0x8 =
/sys/src/cmd/rc/exec.c:33
	pushword(wd=3D0x18e4e)+0x40 /sys/src/cmd/rc/exec.c:44
	execforkexec()+0x34 /sys/src/cmd/rc/havefork.c:223
	Xsimple()+0x170 /sys/src/cmd/rc/simple.c:62
	main(argv=3D0x5fffff94,argc=3D0x2)+0x320 =
/sys/src/cmd/rc/exec.c:184
	_main+0x28 /sys/src/libc/arm/main9.s:19
	acid:=20



That all said, it could be the hardware about to finally die: reverting
all the userland and kernels back to an earlier version still shows the
same error.

But if it isn=92t about to die, I=92d like to solve this problem and =
figure
out how to put the nvram onto the fat32 usbdisk and get it to boot using
that.

-jas