Re: Bug#647825: udevd[XXX]: unable to receive ctrl connection: Function not implemented
2011/11/10 Ben Hutchings <ben@decadent.org.uk>:
>> > 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.99 bug prevents from installing kernel > 2.6.38
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638068) and Wheezy
currently ships with 3.0.0. Unfortunately, I didn't get life signs
recently about this initramfs-tools issue :-(
The only way to run Wheezy is upgrading from Squeeze, but several packages.
> 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.
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 */
--- 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!
However, even with these patches applied, test_accept4 still report
that accept4() is not implemented :-(.
What am I still missing?
Émeric
--- 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 */
--- 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:
Reply to: