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’t 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=0x31208)+0x20 /sys/src/libc/port/lock.c:10
plock()+0x8 /sys/src/libc/port/malloc.c:80
poolalloc(p=0x35a4c,n=0x2c)+0xc /sys/src/libc/port/pool.c:1223
mallocz(size=0x24,clr=0x1)+0x18 /sys/src/libc/port/malloc.c:221
getnetconninfo(fd=0xffffffff,dir=0x5ffffeb4)+0x78
/sys/src/libc/9sys/getnetconninfo.c:59
dolisten(address=0xd1704)+0x134 /sys/src/cmd/ip/httpd/httpd.c:291
main(argc=0x0,argv=0x5fffff74)+0x1c0 /sys/src/cmd/ip/httpd/httpd.c:138
_main+0x28 /sys/src/libc/arm/main9.s:19
acid:
When I’d try and kill it, there’d 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=0x17104)+0x20 /sys/src/libc/port/lock.c:10
plock()+0x8 /sys/src/libc/port/malloc.c:80
poolalloc(p=0x18a8c,n=0x10)+0xc /sys/src/libc/port/pool.c:1223
mallocz(size=0x8,clr=0x1)+0x18 /sys/src/libc/port/malloc.c:221
Malloc()+0x8 /sys/src/cmd/rc/plan9.c:624
emalloc(n=0x8)+0x4 /sys/src/cmd/rc/subr.c:9
newword(wd=0x18e4e,next=0x202d0)+0x8 /sys/src/cmd/rc/exec.c:33
pushword(wd=0x18e4e)+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=0x5fffff94,argc=0x2)+0x320 /sys/src/cmd/rc/exec.c:184
_main+0x28 /sys/src/libc/arm/main9.s:19
acid:
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’t about to die, I’d 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
