Request for 64k binaries

General
1

I bought last week a Zyxel NAS540 which uses a kernel with 64k pages. Now, after some days of investigating how I can run own software on the NAS (the NAS itself is open for access from outside), I found out that

  • it was really a bad idea setting kernel size from 4k to 64k because it breaks the compatibility with many many many ready build software packages
  • it wasn’t a manufacture / device specific problem. There are some other manufactures (maybe they all using a kernel provided by the board manufacture), WD for example, having the same issue with newer firmware versions.

It would nice, if the offical binary build would be supplemented with a build for ARM/64k. Another discussion related to that topic could also found here: https://github.com/syncthing/syncthing/issues/928

I love syncthing, use it intensivly and would be happy, when I could it bring easy to my NAS.

1 Like
2

Someone needs to contribute the required build steps, then I have nothing against adding it.

3

If i’m not totaly wrong, the version for ARM with 64k kernel page size need only the compile flag -ldflags "-R 65536" (See also https://github.com/syncthing/syncthing/issues/928#issuecomment-122450539).

That is the only difference to the “regular” ARM version. All other thing could be the same. If a version with that flags is compiled, send me the package / link and can give you the feedback it is working.

4

Ok, see if this works:

https://nym.se/t/syncthing-linux-arm-v0.12.0-beta0+50-g0ca39f6-dirty-64k-noupgrade.tar.gz

(That filename is a bit of a mouthful…)

(Automatic upgrades is going to require a hack or two to work, as that version “thinks” it’s a normal ARM build so would upgrade to that and then break.)

(You probably don’t want to run that dev build for real, but check if the build works.)

5

Thank you for the really fast response!

Basically your binary runs on the NAS with 64k page size kernel. But there are some error messages:

[monitor] 16:18:37 INFO: Starting syncthing
[VUFJZ] 16:18:37 INFO: syncthing v0.12.0-beta0+50-g0ca39f6-dirty "Beryllium Bedbug" (go1.5 linux-arm default) jb@syno 2015-09-01 09:48:45 UTC
[VUFJZ] 16:18:37 INFO: My ID: VUFJZWO-S5JJRJO-TFQVE5M-5HDXDDV-NIBS3L2-KNTU2G3-HRV77Q2-LR3OCQI
[VUFJZ] 16:18:37 INFO: Database block cache capacity 8192 KiB
fatal error: runtime: cannot map pages in arena address space
[monitor] 16:18:37 WARNING: Panic detected, writing to "/opt/home/root/.config/syncthing/panic-20150901-161837.log"
[monitor] 16:18:37 WARNING: Please check for existing issues with similar panic message at https://github.com/syncthing/syncthing/issues/
[monitor] 16:18:37 WARNING: If no issue with similar panic message exists, please create a new issue with the panic log attached
[monitor] 16:18:37 INFO: Syncthing exited: exit status 2
[monitor] 16:18:38 INFO: Starting syncthing
[monitor] 16:18:38 INFO: Signal 2 received; exiting

The log file:

[VUFJZ] 16:18:37 INFO: syncthing v0.12.0-beta0+50-g0ca39f6-dirty "Beryllium Bedbug" (go1.5 linux-arm default) jb@syno 2015-09-01 09:48:45 UTC
[VUFJZ] 16:18:37 INFO: My ID: VUFJZWO-S5JJRJO-TFQVE5M-5HDXDDV-NIBS3L2-KNTU2G3-HRV77Q2-LR3OCQI
[VUFJZ] 16:18:37 INFO: Database block cache capacity 8192 KiB
...
Panic at 2015-09-01T16:18:37Z
fatal error: runtime: cannot map pages in arena address space

runtime stack:
runtime.throw(0x6433d0, 0x30)
        /usr/local/go/src/runtime/panic.go:527 +0x78
runtime.sysMap(0xa01000, 0x1000, 0x11200001, 0x99d340)
        /usr/local/go/src/runtime/mem_linux.go:157 +0x180
runtime.mHeap_MapSpans(0x98b248, 0x11600000)
        /usr/local/go/src/runtime/mheap.go:314 +0xc8
runtime.mHeap_SysAlloc(0x98b248, 0x400000, 0x11100100)
        /usr/local/go/src/runtime/malloc.go:425 +0x198
runtime.mHeap_Grow(0x98b248, 0x200, 0x0)
        /usr/local/go/src/runtime/mheap.go:628 +0x68
runtime.mHeap_AllocSpanLocked(0x98b248, 0x200, 0x0)
        /usr/local/go/src/runtime/mheap.go:532 +0x6c8
runtime.mHeap_Alloc_m(0x98b248, 0x200, 0x0, 0x4e201, 0x987084)
        /usr/local/go/src/runtime/mheap.go:425 +0x23c
runtime.mHeap_Alloc.func1()
        /usr/local/go/src/runtime/mheap.go:484 +0x40
runtime.systemstack(0x7ec3fba8)
        /usr/local/go/src/runtime/asm_arm.s:256 +0xa8
runtime.mHeap_Alloc(0x98b248, 0x200, 0x0, 0x101, 0x0)
        /usr/local/go/src/runtime/mheap.go:485 +0x58
runtime.largeAlloc(0x400000, 0x1, 0x10b000e0)
        /usr/local/go/src/runtime/malloc.go:745 +0xb4
runtime.mallocgc.func3()
        /usr/local/go/src/runtime/malloc.go:634 +0x34
runtime.systemstack(0x987280)
        /usr/local/go/src/runtime/asm_arm.s:242 +0x80
runtime.mstart()
        /usr/local/go/src/runtime/proc1.go:674

goroutine 1 [running]:
runtime.systemstack_switch()
        /usr/local/go/src/runtime/asm_arm.s:187 +0x4 fp=0x10c1e55c sp=0x10c1e558
runtime.mallocgc(0x400000, 0x4bc5d0, 0x1, 0x1)
        /usr/local/go/src/runtime/malloc.go:635 +0x9e8 fp=0x10c1e5c8 sp=0x10c1e55c
runtime.newarray(0x4bc5d0, 0x400000, 0x43ce18)
        /usr/local/go/src/runtime/malloc.go:777 +0xe4 fp=0x10c1e5e8 sp=0x10c1e5c8
runtime.makeslice(0x4b2da8, 0x0, 0x0, 0x400000, 0x0, 0x0, 0x0, 0x0)
        /usr/local/go/src/runtime/slice.go:32 +0x1d8 fp=0x10c1e610 sp=0x10c1e5e8
github.com/syndtr/goleveldb/leveldb/memdb.New(0x32cf0470, 0x10bfa5c0, 0x400000, 0x10c1e6c8)
        /Users/jb/src/github.com/syncthing/syncthing/Godeps/_workspace/src/github.com/syndtr/goleveldb/leveldb/memdb/memdb.go:466 +0xa8 fp=0x10c1e660 sp=0x10c1e610
github.com/syndtr/goleveldb/leveldb.(*DB).newMem(0x10c03180, 0x0, 0x0, 0x0, 0x0)
        /Users/jb/src/github.com/syncthing/syncthing/Godeps/_workspace/src/github.com/syndtr/goleveldb/leveldb/db_state.go:125 +0x528 fp=0x10c1e6d8 sp=0x10c1e660
github.com/syndtr/goleveldb/leveldb.(*DB).recoverJournal(0x10c03180, 0x0, 0x0)
        /Users/jb/src/github.com/syncthing/syncthing/Godeps/_workspace/src/github.com/syndtr/goleveldb/leveldb/db.go:609 +0x1130 fp=0x10c1e940 sp=0x10c1e6d8
github.com/syndtr/goleveldb/leveldb.openDB(0x10c72c40, 0x0, 0x0, 0x0)
        /Users/jb/src/github.com/syncthing/syncthing/Godeps/_workspace/src/github.com/syndtr/goleveldb/leveldb/db.go:122 +0x914 fp=0x10c1ea2c sp=0x10c1e940
github.com/syndtr/goleveldb/leveldb.Open(0x32cf0208, 0x10cb4900, 0x10cb22c0, 0x0, 0x0, 0x0)
        /Users/jb/src/github.com/syncthing/syncthing/Godeps/_workspace/src/github.com/syndtr/goleveldb/leveldb/db.go:194 +0x16c fp=0x10c1ea54 sp=0x10c1ea2c
github.com/syndtr/goleveldb/leveldb.OpenFile(0x10b19540, 0x31, 0x10cb22c0, 0x0, 0x0, 0x0)
        /Users/jb/src/github.com/syncthing/syncthing/Godeps/_workspace/src/github.com/syndtr/goleveldb/leveldb/db.go:216 +0x80 fp=0x10c1ea80 sp=0x10c1ea54
main.syncthingMain()
        /Users/jb/src/github.com/syncthing/syncthing/cmd/syncthing/main.go:595 +0x15c4 fp=0x10c1f808 sp=0x10c1ea80
main.main()
        /Users/jb/src/github.com/syncthing/syncthing/cmd/syncthing/main.go:385 +0x238c fp=0x10c1ff94 sp=0x10c1f808
runtime.main()
        /usr/local/go/src/runtime/proc.go:111 +0x2b4 fp=0x10c1ffbc sp=0x10c1ff94
runtime.goexit()
        /usr/local/go/src/runtime/asm_arm.s:1036 +0x4 fp=0x10c1ffbc sp=0x10c1ffbc

goroutine 6 [syscall]:
os/signal.loop()
        /usr/local/go/src/os/signal/signal_unix.go:22 +0x14
created by os/signal.init.1
        /usr/local/go/src/os/signal/signal_unix.go:28 +0x30

goroutine 7 [chan receive]:
main.trackCPUUsage()
        /Users/jb/src/github.com/syncthing/syncthing/cmd/syncthing/gui_unix.go:24 +0x108
created by main.init.3
        /Users/jb/src/github.com/syncthing/syncthing/cmd/syncthing/gui_unix.go:17 +0x24

goroutine 8 [select]:
github.com/thejerf/suture.(*Supervisor).Serve(0x10b7c100)
        /Users/jb/src/github.com/syncthing/syncthing/Godeps/_workspace/src/github.com/thejerf/suture/suture.go:432 +0xcec
created by github.com/thejerf/suture.(*Supervisor).ServeBackground
        /Users/jb/src/github.com/syncthing/syncthing/Godeps/_workspace/src/github.com/thejerf/suture/suture.go:394 +0x2c

goroutine 9 [select]:
github.com/syncthing/syncthing/lib/events.(*Subscription).Poll(0x10b0fae0, 0xf8475800, 0xd, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
        /Users/jb/src/github.com/syncthing/syncthing/lib/events/events.go:201 +0x3d4
github.com/syncthing/syncthing/lib/events.(*BufferedSubscription).pollingLoop(0x10b10a20)
        /Users/jb/src/github.com/syncthing/syncthing/lib/events/events.go:239 +0x38
created by github.com/syncthing/syncthing/lib/events.NewBufferedSubscription
        /Users/jb/src/github.com/syncthing/syncthing/lib/events/events.go:233 +0x268

goroutine 18 [select]:
github.com/syndtr/goleveldb/leveldb/util.(*BufferPool).drain(0x10cb2420)
        /Users/jb/src/github.com/syncthing/syncthing/Godeps/_workspace/src/github.com/syndtr/goleveldb/leveldb/util/buffer_pool.go:206 +0x260
created by github.com/syndtr/goleveldb/leveldb/util.NewBufferPool
        /Users/jb/src/github.com/syncthing/syncthing/Godeps/_workspace/src/github.com/syndtr/goleveldb/leveldb/util/buffer_pool.go:237 +0x258

No idea it’s maybe a result because 0.12.0 is beta. There are also some small changes posted on the linked thread in my initial post (-> https://github.com/syncthing/syncthing/issues/928#issuecomment-71466208), maybe that changes are also necessary!?

6

Looks like it’s running out of memory. Maybe those patches are necessary, indeed.

If they are, they don’t apply to the current compiler. It seems more likely this is a genuine out-of-memory that isn’t really related to the page size thing? (Other than the fact that larger pages probably means we use more memory.)

7

Is there a way, apply that changes into regular release (e.g. with if-conditions for specific compile parameters) so syncthing can build “normal”?

I tested some older precompiled syncthing versions and they run without any problems so I assume that this small changes could be all what is necessary. If you could build me the current stable with that modifications, I could would give you a feedback if all is running fine.

8

@calhm: Could you support me maybe with a link / how-to how I can implement a cross-compile/toolchain environment so I can compile syncthing for ARM with 64k kernel page size support? A other user and I currently fails with compiling go … but I also read, cross compile with go should be very easy (what currently it isn’t because of missing clear documentation).

I would test syncthing is running with the modification and if it does, i would try to contribute a patch which let compile syncthing with 4k and 64k systems.

9

Just check build.go, or check xgo or any other project. It’s just a matter or setting a few env vars and bootstrapping.

10

With Go 1.5, cross compilation is fairly trivial. Just install it and follow the build instructions. If the source is in the right place, you can basically

$ cd ~/src/github.com/syncthing/syncthing
$ go get -d ./cmd/syncthing # downloads dependencies
$ GOOS=linux GOARCH=arm go build -v -ldflags "-R 65536" ./cmd/syncthing

and experiment from there.

Just make sure you get the basics for Go right, which is basically $GOPATH and having the source in the right place as above.

If you build the old v0.11 branch, you need to check out an older version of the protocol repo as well, or use the “real” build process (described on the page linked above) to use the included dependencies.

11

Jakob, thank you very much! This small instruction helps me, compiling a version from syncthing for ARM really easy. I’ll checkout modification and how I can create a patch which works for 4k and 64k page size kernels and report here then again!

1 Like
12

Okay … I overlooked that the modification in the posted thread match the Go source code itself and not only relates to Syncthing. I’m going to try the modification go’s into the offical Go sources so 64k applications can compile without much effort.

Edit: Get current stable (0.11.23) and got error during compiling with your instruction:

_/public/src/github.com/syncthing/cmd/syncthing
# _/public/src/github.com/syncthing/cmd/syncthing
cmd/syncthing/connections.go:181: too many arguments in call to s.model.AddConnection
cmd/syncthing/connections.go:257: multiple-value discoverer.Lookup() in single-value context
cmd/syncthing/main.go:901: not enough arguments in call to discover.NewDiscoverer

If i go the way with go run build.go build i got the same:

go build -ldflags -w -X main.Version=v0.11.23 -X main.BuildStamp=1441311194 -X main.BuildUser=root -X main.BuildHost=leonard -X main.BuildEnv=default ./cmd/syncthing
# _/public/src/github.com/syncthing/cmd/syncthing
cmd/syncthing/connections.go:181: too many arguments in call to s.model.AddConnection
cmd/syncthing/connections.go:257: multiple-value discoverer.Lookup() in single-value context
cmd/syncthing/main.go:901: not enough arguments in call to discover.NewDiscoverer
exit status 2
exit status 1

Something wrong in the build process or with syncthing src? Current syncting git checkout builds but doesn’t work without errors on ARM/64k :-/

13

Go run build.go clean

14

Done but same again …

15

Make sure you have a clean checkout of the code (git status), and delete everything in $GOPATH/pkg, and Godeps/_workspace/pkg

16

Delete everything, uninstall and install go 1.5 but always the same … Source is the tar.gz file from syncthing start page.

Try it with taged 0.12 beta bring another error:

# _/public/src/github.com/syncthing/cmd/syncthing
cmd/syncthing/connections.go:146: c.ConnType undefined (type model.IntermediateConnection has no field or method ConnType)
cmd/syncthing/connections.go:197: c.ConnType undefined (type model.IntermediateConnection has no field or method ConnType)
cmd/syncthing/connections.go:208: c.ConnType undefined (type model.IntermediateConnection has no field or method ConnType)
cmd/syncthing/connections.go:211: c.ConnType undefined (type model.IntermediateConnection has no field or method ConnType)
cmd/syncthing/connections.go:222: c.ConnType undefined (type model.IntermediateConnection has no field or method ConnType)
cmd/syncthing/connections.go:224: c.ConnType undefined (type model.IntermediateConnection has no field or method ConnType)
cmd/syncthing/connections.go:293: undefined: model.ConnectionTypeBasicDial
cmd/syncthing/connections_tcp.go:102: undefined: model.ConnectionTypeBasicAccept

Up to date checkout (git clone https://github.com/syncthing/syncthing) compiles without any errors. Now … I think, I’ll set up tomorrow a fresh build environment with ubuntu or debian. Currently I use opensuse but opensuse isn’t not always a good decision for compiling stuff …

Maybe, if it doesn’t make too much work for you, you could compile 0.11.23 with

GOOS=linux GOARCH=arm GOARM=7 go build -v -ldflags "-R 65536" ./cmd/syncthing
17

I am on holiday on a phone, but I think it’s the same thing calmh compiled for you. You should download an official release (0.11.x) and not some random checkout which might be broken at any point in time. Also you are building the wrong way, you should build via the scripts provided (modify build.go) or via godep (godep go build …), because you are not using the vendored dependencies which is the cause of your errors.

18

I already tried it with official release but I will change the build environment. Would/could not exclude the possibility that the reason is. I’ll report then again.

Have a nice holiday :smile:

19

I got a 64k page syncthing for arm 7 running. The problem is that it panics and dumps out.

If I had to take a guess, I bet that the memory requirements for synchting are higher than I have available.

Panic segment below:

[6DYME] 14:44:12 INFO: Database block cache capacity 16284 KiB
...
Panic at 2015-09-14T14:44:12-05:00
fatal error: runtime: cannot map pages in arena address space

runtime stack:
runtime.throw(0x65e6e0, 0x30)
        /home/osboxes/go/src/runtime/panic.go:527 +0x78
runtime.sysMap(0xb01000, 0x1000, 0x11300001, 0x9ce258)
        /home/osboxes/go/src/runtime/mem_linux.go:157 +0x180
runtime.mHeap_MapSpans(0x9bbf80, 0x11700000)
        /home/osboxes/go/src/runtime/mheap.go:314 +0xc8
runtime.mHeap_SysAlloc(0x9bbf80, 0x400000, 0xae448)
        /home/osboxes/go/src/runtime/malloc.go:425 +0x198
runtime.mHeap_Grow(0x9bbf80, 0x200, 0x0)
        /home/osboxes/go/src/runtime/mheap.go:628 +0x68
runtime.mHeap_AllocSpanLocked(0x9bbf80, 0x200, 0x0)
        /home/osboxes/go/src/runtime/mheap.go:532 +0x6c8
runtime.mHeap_Alloc_m(0x9bbf80, 0x200, 0x0, 0x9b7701, 0x9c0438)
        /home/osboxes/go/src/runtime/mheap.go:425 +0x248
runtime.mHeap_Alloc.func1()
        /home/osboxes/go/src/runtime/mheap.go:484 +0x40
runtime.systemstack(0xbee3fcf8)
        /home/osboxes/go/src/runtime/asm_arm.s:256 +0xa8
runtime.mHeap_Alloc(0x9bbf80, 0x200, 0x0, 0xa0101, 0x9c2570)
        /home/osboxes/go/src/runtime/mheap.go:485 +0x58
runtime.largeAlloc(0x400000, 0x1, 0x2d)
        /home/osboxes/go/src/runtime/malloc.go:745 +0xb4
runtime.mallocgc.func3()
        /home/osboxes/go/src/runtime/malloc.go:634 +0x34
runtime.systemstack(0x9b77a0)
        /home/osboxes/go/src/runtime/asm_arm.s:242 +0x80
runtime.mstart()
        /home/osboxes/go/src/runtime/proc1.go:674
20

Yeah, this generally means out of memory in a 32bit build…