Hi, Bottom line: Docker works reliably on powerpc 440fpu 32 bit using gccgo as the compiler. We will likely soon start working on powerpc e6500 in 32bit mode.
After a fix in the structures used by the epoll system calls, the problem disappeared. I assume the problem was a starvation similar to https://github.com/moby/moby/issues/39461 We had to correct the used system call numbers for the fstat system call family, for sendfile, fadvise, ftruncate, truncate and fcntl. We also had to fix the alignment of some of the structures used by these functions and for the EpollEvent structure (ie. the generator did not always generate correct structures). The fix for EpollEvent also fixed the I/O starvation problem. It remains unclear why the generator did not generate correct structures. We updated the post processor mkpost.go to fix the structures (alignment + member names), but did not look further into the underlying problem. Hugo On Thu, Jul 9, 2020 at 10:08 AM Hugo Cornelis <[email protected]> wrote: > > > On Fri, Jul 3, 2020 at 9:36 PM Ian Lance Taylor <[email protected]> wrote: > >> That looks like the process is writing to a pipe that nothing is reading >> from. >> > > Yes, that is correct. The question is: why doesn't the reader read from > the pipe? And why does it suddenly start reading when the Docker daemon > process is terminated? > > At first I would believe this to be a starvation problem, but our > investigation is still inconclusive. > > Here is what we know about the reader process / goroutine: > > - It is a goroutine that becomes active when Docker terminates. > > - This same goroutine gets stuck at io.CopyBuffer(epollConsole, in, *bp) > before Docker terminates. During this time the writer writes 18778 > characters (and then gets stuck). > > - All the configurations we tested, gave this or similar behaviour. > However the behaviour is slightly timing dependent, ie. inserting logging > statements may result in small changes to this behaviour. > > > During the last few days of investigation we found one race in containerd > and several bugs in our system call bindings for ppc (Ftruncate, Truncate, > Fstatfs, Statfs, Lstat). > > We have fixed these, but the problem with the reader not reading / blocked > I/O persists. > > It may be a case of starvation, or a race, or something else. > > More investigation is required. We are now looking further into the > system call bindings, debugging the code of Docker and its tools, and the > gccgo runtime. > > Thanks for your reply. > > Hugo > > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAARrXCSWbTLZ0QEWpuENEHUJaE_Bj5qcuMKGMkvHkyghBFZTqQ%40mail.gmail.com.
