Re: [9fans] arm fun

Re: [9fans] arm fun

[Erik Quanstrom]

[-- Attachment #1: Type: text/plain, Size: 389 bytes --]

the lock is in the bss.  maybe the wrong page gets accessed after fork.

Charles Forsyth <charles.forsyth@gmail.com> wrote:

>I've got one of those that was fine last time I tried it. I'll try it in the morning.
>
>I wonder whether the change of lock to use semacquire instead of tas doesn't work well on the (that) ARM.
>
>It seems a strange coincidence that it always fails there.
>
>
>

[-- Attachment #2: Type: text/html, Size: 591 bytes --]

Re: [9fans] arm fun

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 256 bytes --]

I've got one of those that was fine last time I tried it. I'll try it in
the morning.
I wonder whether the change of lock to use semacquire instead of tas
doesn't work well on the (that) ARM.
It seems a strange coincidence that it always fails there.

[-- Attachment #2: Type: text/html, Size: 448 bytes --]

Re: [9fans] arm fun

[erik quanstrom]

> 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: 

image cache strikes again?

- erik

[9fans] arm fun

[Jeff Sickel]

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