Re: haskell-http-conduit failure on powerpc
On Tue, Jun 04, 2013 at 09:05:37PM +1000, Erik de Castro Lopo wrote:
> Colin Watson wrote:
> > On Tue, Jun 04, 2013 at 08:38:05PM +1000, Erik de Castro Lopo wrote:
> > > Erik de Castro Lopo wrote:
> > > > -- That definitely is function not implemented
> > > > SYS_344(0x5, 0xf7c7e0f0, 0xf7c7e110, 0x800, 0x10a00000) = -1 ENOSYS (Function not implemented)
> > >
> > > >From file /usr/include/powerpc-linux-gnu/asm/unistd.h
> > >
> > > #define __NR_accept4 344
> >
> > That appears to have been added in 2.6.37, and praetorius is 2.6.32. I
> > wonder if we're explicitly using accept4 somewhere based on libc
> > presence or similar?
>
> Isn't it more likely that its libc deciding to call accept4?
Yeah, looks like haskell-network is using the libc accept4 stub and libc
has the wrong idea about which kernel version supports the accept4
syscall on powerpc (it's skewed across architectures). I'm talking with
Adam Conrad about this and he's going to get it fixed.
<cjwatson> Do you have a minute to help out with something that looks like a possible libc bug in Debian? (powerpc, haskell-related; hardly work-urgent but might be interesting)
<infinity> I have a minute to look at it, I might not have the brainpower to understand it.
<cjwatson> So, this is http://lists.debian.org/debian-haskell/2013/06/msg00000.html and thread
<cjwatson> We've tracked it down to an attempt to call the accept4 syscall (344), which was introduced in 2.6.37 AFAICS; the buildd is on 2.6.32
<cjwatson> I'm reasonably sure the binary in question is calling the libc accept4 stub - nm certainly shows that it has a reference to it - so shouldn't libc take care of calling the proper syscall for the kernel version?
<infinity> "The accept4() system call is available starting with Linux 2.6.28"
<cjwatson> I think powerpc was different
<infinity> And that could be the problem, then.
<cjwatson> See Linux 86250b9d
<infinity> I don't suppose we can convince the buildd maintainer to upgrade to wheezy and scream "la la la, can't see you"?
<cjwatson> Which switched from the socketcall multiplexer to making accept4 and friends available directly
<cjwatson> Well, arguably, but libc does say MIN_KERNEL_SUPPORTED=2.6.32 ...
* infinity nods.
<infinity> I'm making with the grepping.
<infinity> Pretty sure that, historically, syscalls have gone in when they go into linux x86, and port maintainers who lag have been left to pick up the pieces.
<infinity> Though, 2.6.28->37 is quite a lag.
<cjwatson> I might be misunderstanding, but that kernel commit seems fairly clear
<cjwatson> It had the facility before then, it was just spelled differently
<infinity> Grr, how do I not have a kernel clone anywhere on my laptop?
<cjwatson> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=86250b9d
<infinity> That would definitely match how you're reading it.
<cjwatson> If you vaguely agree this is a libc bug then I can go ahead and file a Debian bug
<cjwatson> (My actual motivation is that once this gets fixed I can stop having to merge git-annex every five minutes)
<infinity> Right, so powerpc is falling back to the global __ASSUME_ACCEPT4 cause no one ever defined it as different for PPC.
<infinity> I can fix this and push it upstream (and double-check some of those other syscalls too), but it won't be in the next upload, I think aurel is already spinning that one for a critical kfreebsd fuckup.
<cjwatson> OK. Do you want the bug for an audit trail or shall I not bother?
<infinity> If there isn't already a glibc bug filed for it, I don't much care if you file one.
<cjwatson> Doesn't seem to be, no.
<infinity> Anyhow, I'm not on the haskell list, feel free to followup with a copy-and-paste of the above so people know it's being looked at.
So a fix for this is in progress, but, of the four active powerpc
buildds, only praetorius is running 2.6.32, and the rest are on 3.2.
I've CCed the powerpc buildd admins; I don't suppose it would be
possible to upgrade praetorius?
Thanks,
--
Colin Watson [cjwatson@debian.org]
Reply to: