2011/11/11 Ben Hutchings :
> On Fri, Nov 11, 2011 at 07:48:24PM +0100, Émeric Maschino wrote:
>> 2011/11/11 Ben Hutchings :
>> Isn't Wheezy eglibc 2.13-21 supposed to already implement accept4()?
>
> That is a little difficult when the system call is not even defined
> for an architecture! Until i
On Fri, Nov 11, 2011 at 07:48:24PM +0100, Émeric Maschino wrote:
> 2011/11/11 Ben Hutchings :
> > That version just calls the libc implementation of accept4(), which
> > won't work until libc is rebuilt. You need to define __NR_accept4 and
> > call syscall(__NR_accept4, ...) in the test program in
2011/11/11 Ben Hutchings :
> That version just calls the libc implementation of accept4(), which
> won't work until libc is rebuilt. You need to define __NR_accept4 and
> call syscall(__NR_accept4, ...) in the test program instead.
Isn't Wheezy eglibc 2.13-21 supposed to already implement accept4
On Fri, 2011-11-11 at 17:09 +0100, Émeric Maschino wrote:
> 2011/11/11 Ben Hutchings :
> >> --- a/arch/ia64/include/asm/unistd.h2011-03-15 02:20:32.0 +0100
> >> +++ b/arch/ia64/include/asm/unistd.h2011-11-10 21:27:31.0 +0100
> >> @@ -315,11 +315,12 @@
> >> #define __NR_fano
2011/11/11 Ben Hutchings :
>> --- a/arch/ia64/include/asm/unistd.h 2011-03-15 02:20:32.0 +0100
>> +++ b/arch/ia64/include/asm/unistd.h 2011-11-10 21:27:31.0 +0100
>> @@ -315,11 +315,12 @@
>> #define __NR_fanotify_init 1323
>> #define __NR_fanotify_mark
On Fri, 2011-11-11 at 00:05 +0100, Émeric Maschino wrote:
[...]
> > I think we need this, which applies cleanly to the current kernel
> > version in squeeze:
> >
> > commit 9ab87644393d789b950ba984fa360f45c4df02e5
> > Author: Arnd Bergmann
> > Date: Thu Dec 10 22:10:31 2009 +0100
> >
> >asm-
2011/11/10 Ben Hutchings :
>> > But I do not understand why nobody else noticed this, unless you are the
>> > first person to install wheezy on ia64.
>>
>> That seems entirely plausible.
Definitely since:
- netinst Wheezy CD-ROM is unbootable on ia64 (although Squeeze was fine)
- initramfs-tools 0
On Thu, 2011-11-10 at 16:01 +, Ben Hutchings wrote:
> On Thu, 2011-11-10 at 16:35 +0100, Marco d'Itri wrote:
> > clone 647825 -1
> > block 647825 by -1
> > thanks
> >
> > On Nov 10, Émeric Maschino wrote:
> >
> > > Well, it seems that the problem isn't in fact that SOCK_CLOEXEC isn't
> > > i
On Nov 10, Ben Hutchings wrote:
> > I would like to know from the kernel people which conflicts I need to
> > add to the udev package.
> Don't bother; there's no reasonable way to write conflicts against
> kernel versions. We can backport sys_accept4 plumbing for ia64 to
> squeeze if necessary,
On Thu, 2011-11-10 at 16:35 +0100, Marco d'Itri wrote:
> clone 647825 -1
> block 647825 by -1
> thanks
>
> On Nov 10, Émeric Maschino wrote:
>
> > Well, it seems that the problem isn't in fact that SOCK_CLOEXEC isn't
> > implemented on ia64, but simply that sys_accept4() isn't implemented,
> > r
clone 647825 -1
block 647825 by -1
thanks
On Nov 10, Émeric Maschino wrote:
> Well, it seems that the problem isn't in fact that SOCK_CLOEXEC isn't
> implemented on ia64, but simply that sys_accept4() isn't implemented,
> right?
Right.
But I do not understand why nobody else noticed this, unless
Marco,
Adapting test_accept4.c from de11defebf7677fb7ee91d9b089b78786fbb
(modified source file attached), I'm getting:
emeric@longspeak:~$ ./test_accept4
===
accept4(): Function not implemented
===
accept4(): Function not
On Nov 07, Émeric Maschino wrote:
> It seems that SOCK_CLOEXEC is thus correctly defined, don't you think so?
Yes, but this does not mean that it is also implemented.
> Is there a way to check for "SOCK_CLOEXEC symbol" in the currently
> running kernel? This should give a definitive answer regar
Hello Marco,
2011/11/6 Marco d'Itri :
> On Nov 06, Émeric Maschino wrote:
>
>> Starting with udev 170 (well, IIRC!), console is flooded at startup with:
>> udevd[XXX]: unable to receive ctrl connection: Function not implemented
> Your lacks support for SOCK_CLOEXEC on accept, why?
Well,
On Nov 06, Émeric Maschino wrote:
> Starting with udev 170 (well, IIRC!), console is flooded at startup with:
> udevd[XXX]: unable to receive ctrl connection: Function not implemented
Your lacks support for SOCK_CLOEXEC on accept, why?
It is supposed to be available since 2.6.27.
Does the ol
Package: udev
Version: 172-1
Severity: important
Hello,
Starting with udev 170 (well, IIRC!), console is flooded at startup with:
udevd[XXX]: unable to receive ctrl connection: Function not implemented
where XXX is a number (PID?).
And system takes ~3 min. to get login prompt.
Last udev v
16 matches
Mail list logo
