FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Kernel

 
 
LinkBack Thread Tools
 
Old 11-10-2011, 02:35 PM
Marco d'Itri
 
Default Bug#647825: udevd: unable to receive ctrl connection: Function not implemented

clone 647825 -1
block 647825 by -1
thanks

On Nov 10, Émeric Maschino <emeric.maschino@gmail.com> 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 you are the
first person to install wheezy on ia64.

> Is it thus a kernel-related issued rather than an udev one?
Other architectures have it and I am not going to revert this change
again, so this will have to be fixed in the kernel.
I would like to know from the kernel people which conflicts I need to
add to the udev package.

--
ciao,
Marco
 
Old 11-10-2011, 03:01 PM
Ben Hutchings
 
Default Bug#647825: udevd: unable to receive ctrl connection: Function not implemented

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 <emeric.maschino@gmail.com> 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 you are the
> first person to install wheezy on ia64.

That seems entirely plausible.

> > Is it thus a kernel-related issued rather than an udev one?
> Other architectures have it and I am not going to revert this change
> again, so this will have to be fixed in the kernel.
> 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, like we did for armel (#625752).

Ben.

--
Ben Hutchings
You can't have everything. Where would you put it?
 
Old 11-10-2011, 03:03 PM
Marco d'Itri
 
Default Bug#647825: udevd: unable to receive ctrl connection: Function not implemented

On Nov 10, Ben Hutchings <ben@decadent.org.uk> 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, like we did for armel (#625752).
I know, but udev already has per-architecture conflicts to help upgrades.
A backport is a good idea, or upgrades will be very painful.

--
ciao,
Marco
 
Old 11-10-2011, 03:19 PM
Ben Hutchings
 
Default Bug#647825: udevd: unable to receive ctrl connection: Function not implemented

On Thu, 2011-11-10 at 16:01 +0000, 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 <emeric.maschino@gmail.com> 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 you are the
> > first person to install wheezy on ia64.
>
> That seems entirely plausible.
>
> > > Is it thus a kernel-related issued rather than an udev one?
> > Other architectures have it and I am not going to revert this change
> > again, so this will have to be fixed in the kernel.
> > 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, like we did for armel (#625752).

I think we need this, which applies cleanly to the current kernel
version in squeeze:

commit 9ab87644393d789b950ba984fa360f45c4df02e5
Author: Arnd Bergmann <arnd@arndb.de>
Date: Thu Dec 10 22:10:31 2009 +0100

asm-generic: add sys_accept4 to unistd.h

Can someone test that the attached patch is sufficient to make the new
udev work on ia64? (See the instructions at
<kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official>.)

Ben.

--
Ben Hutchings
You can't have everything. Where would you put it?
 
Old 11-11-2011, 12:00 AM
Ben Hutchings
 
Default Bug#647825: udevd: unable to receive ctrl connection: Function not implemented

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 <arnd@arndb.de>
> > Date: Thu Dec 10 22:10:31 2009 +0100
> >
> > asm-generic: add sys_accept4 to unistd.h
> >
> > Can someone test that the attached patch is sufficient to make the new
> > udev work on ia64? (See the instructions at
> > <kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official>.)
>
> Since current kernel 3.0.0+39 in Wheezy cannot be installed due to the
> initramfs-tools 0.99 issue, I tried to apply the patch to "last
> working in Wheezy" 2.6.38+34 kernel. Patch was rejected as
> include/asm-generic/unistd.h in 2.6.38+34 already has __NR_accept4
> defined to 242.

Sorry, I assumed that ia64 must have accept4() in the current upstream
version (3.1) and we only needed to worry about squeeze. So I wrongly
thought that patch must have been the change that added it to ia64.

> I know nothing about kernel development, And nothing about ia64
> architecture. However, looking at various kernel commits in order to
> understand how accept4 support was added for other architectures, and
> also looking at how accept() is currently defined for ia64, I ended up
> modifying the following files (patches against Wheezy 2.6.38+34
> kernel, in attached):
>
> --- a/arch/ia64/include/asm/unistd.h 2011-03-15 02:20:32.000000000 +0100
> +++ b/arch/ia64/include/asm/unistd.h 2011-11-10 21:27:31.000000000 +0100
> @@ -315,11 +315,12 @@
> #define __NR_fanotify_init 1323
> #define __NR_fanotify_mark 1324
> #define __NR_prlimit64 1325
> +#define __NR_accept4 1326
>
> #ifdef __KERNEL__
>
>
> -#define NR_syscalls 302 /* length of syscall table */
> +#define NR_syscalls 303 /* length of syscall table */
>
> /*
> * The following defines stop scripts/checksyscalls.sh from complaining about
>
>
> --- a/arch/ia64/kernel/entry.S 2011-03-15 02:20:32.000000000 +0100
> +++ b/arch/ia64/kernel/entry.S 2011-11-10 21:32:03.000000000 +0100
> @@ -1771,6 +1771,7 @@
> data8 sys_fanotify_init
> data8 sys_fanotify_mark
> data8 sys_prlimit64 // 1325
> + data8 sys_accept4
>
> .org sys_call_table + 8*NR_syscalls // guard against
> failures to increase NR_syscalls
> #endif /* __IA64_ASM_PARAVIRTUALIZED_NATIVE */
>
>

The above changes look reasonable; please send them to
linux-ia64@vger.kernel.org with a signed-off-by line as explained in
Documentation/SubmittingPatches.

> --- a/arch/ia64/kernel/fsys.S 2011-03-15 02:20:32.000000000 +0100
> +++ b/arch/ia64/kernel/fsys.S 2011-11-10 21:34:53.000000000 +0100
> @@ -1042,7 +1042,29 @@
> data8 0 // tee
> data8 0 // vmsplice
> data8 0
> - data8 fsys_getcpu // getcpu // 1304
> + data8 fsys_getcpu // getcpu
> + data8 0 // 1305
> + data8 0
> + data8 0
> + data8 0
> + data8 0
> + data8 0 // 1310
> + data8 0
> + data8 0
> + data8 0
> + data8 0
> + data8 0 // 1315
> + data8 0
> + data8 0
> + data8 0
> + data8 0
> + data8 0 // 1320
> + data8 0
> + data8 0
> + data8 0
> + data8 0
> + data8 0 // 1325
> + data8 0 // accept4 // 1326
>
> // fill in zeros for the remaining entries
> .zero:
>
> For fsys.S, I don't know if adding "data8 0" lines like I did in order
> to match accept4() 1326 define with unistd.h and entry.S is required
> or not. If yes, well, table hasn't been updated from quite some time
> then!

The comment means that the .space directive will add the necessary
trailing zero entries automatically. So you don't need to edit this
file.

> However, even with these patches applied, test_accept4 still report
> that accept4() is not implemented :-(.

Isn't that because it is using the installed header which doesn't define
__NR_accept4?

> What am I still missing?

Don't know can you point to the version of test_accept4 that you are
using? I only found the original version which is explicitly for x86
only.

Ben.

--
Ben Hutchings
The program is absolutely right; therefore, the computer must be wrong.
 
Old 11-11-2011, 03:44 PM
Ben Hutchings
 
Default Bug#647825: udevd: unable to receive ctrl connection: Function not implemented

On Fri, 2011-11-11 at 17:09 +0100, Émeric Maschino wrote:
> 2011/11/11 Ben Hutchings <ben@decadent.org.uk>:
> >> --- a/arch/ia64/include/asm/unistd.h 2011-03-15 02:20:32.000000000 +0100
> >> +++ b/arch/ia64/include/asm/unistd.h 2011-11-10 21:27:31.000000000 +0100
> >> @@ -315,11 +315,12 @@
> >> #define __NR_fanotify_init 1323
> >> #define __NR_fanotify_mark 1324
> >> #define __NR_prlimit64 1325
> >> +#define __NR_accept4 1326
> >>
> >> #ifdef __KERNEL__
> >>
> >>
> >> -#define NR_syscalls 302 /* length of syscall table */
> >> +#define NR_syscalls 303 /* length of syscall table */
> >>
> >> /*
> >> * The following defines stop scripts/checksyscalls.sh from complaining about
> >>
> >>
> >> --- a/arch/ia64/kernel/entry.S 2011-03-15 02:20:32.000000000 +0100
> >> +++ b/arch/ia64/kernel/entry.S 2011-11-10 21:32:03.000000000 +0100
> >> @@ -1771,6 +1771,7 @@
> >> data8 sys_fanotify_init
> >> data8 sys_fanotify_mark
> >> data8 sys_prlimit64 // 1325
> >> + data8 sys_accept4
> >>
> >> .org sys_call_table + 8*NR_syscalls // guard against
> >> failures to increase NR_syscalls
> >> #endif /* __IA64_ASM_PARAVIRTUALIZED_NATIVE */
> >>
> >>
> >
> > The above changes look reasonable; please send them to
> > linux-ia64@vger.kernel.org with a signed-off-by line as explained in
> > Documentation/SubmittingPatches.
>
> OK, will do.
>
> I however imagine that these patches are to be created against current
> linux-3.2-rc1 source tree, right?

Yes.

> One thing that thus worries me is
> that I won't be able to test the resulting kernel, since that the
> initramfs-tools 0.99 issue prevents me from running kernel > 2.6.38.

No it doesn't. The Debian packagaing of new kernel versions depends on
new initramfs-tools, but the upstream code does not.

> >> However, even with these patches applied, test_accept4 still report
> >> that accept4() is not implemented :-(.
> >
> > Isn't that because it is using the installed header which doesn't define
> > __NR_accept4?
> >
> >> What am I still missing?
> >
> > Don't know can you point to the version of test_accept4 that you are
> > using? I only found the original version which is explicitly for x86
> > only.
>
> Sorry Ben, you were CC'ed too lately in the discussion!
>
> I was referring to the test_accept4.c file that I've modified and
> attached in Message #25
> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=647825#25). Here's
> the direct link to get the file:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=25;filename=test_accept4.c;att=1 ;bug=647825

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.

Ben.

--
Ben Hutchings
The program is absolutely right; therefore, the computer must be wrong.
 
Old 11-11-2011, 08:07 PM
Ben Hutchings
 
Default Bug#647825: udevd: unable to receive ctrl connection: Function not implemented

On Fri, Nov 11, 2011 at 07:48:24PM +0100, Émeric Maschino wrote:
> 2011/11/11 Ben Hutchings <ben@decadent.org.uk>:
> > 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()?

That is a little difficult when the system call is not even defined
for an architecture! Until it is rebuilt against the new kernel
header, I assume it will use a fallback implementation that always
fails.

> I've nevertheless modified test_accept.c following your guidelines. I
> also had to rename accept4() to __accept4(), otherwise it will
> conflict with non-static definition of accept4() in
> /usr/include/ia64-linux-gnu/sys/socket.h (isn't this the eglibc
> declaration?)

Right.

> I'm however still getting the error message stating that accept4() is
> not implemented, although I've rebuilt my kernel with the patches and
> booted the system with it:
>
> emeric@longspeak:~/Documents$ ./test_accept4
> =======================================
> Calling accept4(): flags = 0
> accept4(): Function not implemented
[...]

I have no idea why this would still fail; maybe you need to change
something additional in the kernel. Ask the linux-ia64 mailing list.

Ben.

--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111111210728.GT3366@decadent.org.uk">http://lists.debian.org/20111111210728.GT3366@decadent.org.uk
 

Thread Tools




All times are GMT. The time now is 10:27 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org