Bug#986222: Acknowledgement (glibc: Fix O_NONBLOCK value on hppa architecture)
This looks like a duplicate of #981650, which can't be fixed right now due to the freeze. Merging the bugs. Thanks for merging the bugs! Does the freeze is relevant for non-released architectures like hppa as well? I'm asking, because for hppa it would be very good if this gets fixed before the release Helge
Bug#986222: Acknowledgement (glibc: Fix O_NONBLOCK value on hppa architecture)
The attached second patch is needed too.
It corrects hppa EFD_NONBLOCK, IN_NONBLOCK, SFD_NONBLOCK and TFD_NONBLOCK
defines.
From: John David Anglin
Date: Fri, 19 Feb 2021 17:08:47 + (+)
Subject: Correct hppa EFD_NONBLOCK, IN_NONBLOCK, SFD_NONBLOCK and TFD_NONBLOCK defines.
X-Git-Url: https://sourceware.org/git/?p=glibc.git;a=commitdiff_plain;h=96b8038f12dd5fc5620a1213b79eb3a8342e846a;hp=044e603b698093cf48f6e6229e0b66acf05227e4
Correct hppa EFD_NONBLOCK, IN_NONBLOCK, SFD_NONBLOCK and TFD_NONBLOCK defines.
---
diff --git a/sysdeps/unix/sysv/linux/hppa/bits/eventfd.h b/sysdeps/unix/sysv/linux/hppa/bits/eventfd.h
index e692b44c56..c1a46a16b0 100644
--- a/sysdeps/unix/sysv/linux/hppa/bits/eventfd.h
+++ b/sysdeps/unix/sysv/linux/hppa/bits/eventfd.h
@@ -26,6 +26,6 @@ enum
#define EFD_SEMAPHORE EFD_SEMAPHORE
EFD_CLOEXEC = 01000,
#define EFD_CLOEXEC EFD_CLOEXEC
-EFD_NONBLOCK = 0024 /* HPUX has separate NDELAY & NONBLOCK */
+EFD_NONBLOCK = 0020
#define EFD_NONBLOCK EFD_NONBLOCK
};
diff --git a/sysdeps/unix/sysv/linux/hppa/bits/inotify.h b/sysdeps/unix/sysv/linux/hppa/bits/inotify.h
index f6cf97e8a7..a69a4a88d9 100644
--- a/sysdeps/unix/sysv/linux/hppa/bits/inotify.h
+++ b/sysdeps/unix/sysv/linux/hppa/bits/inotify.h
@@ -24,6 +24,6 @@ enum
{
IN_CLOEXEC = 01000,
#define IN_CLOEXEC IN_CLOEXEC
-IN_NONBLOCK = 00024 /* HPUX has separate NDELAY & NONBLOCK */
+IN_NONBLOCK = 00020
#define IN_NONBLOCK IN_NONBLOCK
};
diff --git a/sysdeps/unix/sysv/linux/hppa/bits/signalfd.h b/sysdeps/unix/sysv/linux/hppa/bits/signalfd.h
index dd4ba77cc8..18568a9f1d 100644
--- a/sysdeps/unix/sysv/linux/hppa/bits/signalfd.h
+++ b/sysdeps/unix/sysv/linux/hppa/bits/signalfd.h
@@ -24,6 +24,6 @@ enum
{
SFD_CLOEXEC = 01000,
#define SFD_CLOEXEC SFD_CLOEXEC
-SFD_NONBLOCK = 0024 /* HPUX has separate NDELAY & NONBLOCK */
+SFD_NONBLOCK = 0020
#define SFD_NONBLOCK SFD_NONBLOCK
};
diff --git a/sysdeps/unix/sysv/linux/hppa/bits/timerfd.h b/sysdeps/unix/sysv/linux/hppa/bits/timerfd.h
index f64502477a..9d7f228995 100644
--- a/sysdeps/unix/sysv/linux/hppa/bits/timerfd.h
+++ b/sysdeps/unix/sysv/linux/hppa/bits/timerfd.h
@@ -24,6 +24,6 @@ enum
{
TFD_CLOEXEC = 01000,
#define TFD_CLOEXEC TFD_CLOEXEC
-TFD_NONBLOCK = 00024 /* HPUX has separate NDELAY & NONBLOCK */
+TFD_NONBLOCK = 00020
#define TFD_NONBLOCK TFD_NONBLOCK
};
Bug#986222: glibc: Fix O_NONBLOCK value on hppa architecture
Package: glibc Version: 2.31-11 Tags: hppa, patch Please apply the attached patch which removes obsolete defines on the hppa architecture for old HPUX support from fcntl.h. The most important part is changing O_NONBLOCK to just be one bit. The patch is already committed upstream in glibc-2.33, but we would need it in the current debian/sid glibc-2.31 too. All other projects have been fixed already too (Linux kernel, dietlibc, qemu, ...). Thanks, Helge From: John David Anglin Date: Fri, 13 Nov 2020 16:42:11 + (+) Subject: Remove obsolete defines for HPUX support from fcntl.h and update O_NONBLOCK. X-Git-Tag: glibc-2.33~298 X-Git-Url: https://sourceware.org/git/?p=glibc.git;a=commitdiff_plain;h=a24f414ba11a7acdf3c5ccec3fb327fc72166556;hp=01bd62517cc242ae503aaa7002e9e94551803e4d Remove obsolete defines for HPUX support from fcntl.h and update O_NONBLOCK. --- diff --git a/sysdeps/unix/sysv/linux/hppa/bits/fcntl.h b/sysdeps/unix/sysv/linux/hppa/bits/fcntl.h index 294d3b5191..47686099a7 100644 --- a/sysdeps/unix/sysv/linux/hppa/bits/fcntl.h +++ b/sysdeps/unix/sysv/linux/hppa/bits/fcntl.h @@ -24,14 +24,11 @@ #define O_EXCL 2000 /* not fcntl */ #define O_NOCTTY 0040 /* not fcntl */ #define O_APPEND 0010 -#define O_NONBLOCK 0024 /* HPUX has separate NDELAY & NONBLOCK */ +#define O_NONBLOCK 0020 #define __O_DSYNC 0100 -#define __O_RSYNC 0200 /* HPUX only */ #define __O_SYNC 0010 #define O_SYNC (__O_SYNC|__O_DSYNC) -#define O_BLKSEEK 0100 /* HPUX only */ - #define __O_DIRECTORY 1 /* Must be a directory. */ #define __O_NOFOLLOW 00200 /* Do not follow links. */ #define __O_CLOEXEC 01000 /* Set close_on_exec. */
Re: glibc 2.22 testsuite issues on hppa
On 08.03.2016 19:07, Aurelien Jarno wrote: > Dear HPPA porters, Hi Aurelien, > The glibc testsuite in version 2.22 which has been uploaded to sid 2 > days ago fails to pass on both phantom and sibaris build daemons. Thanks for the notice! > There seems to be 3 failures that are regressions compared to glibc > 2.21: > > FAIL: debug/backtrace-tst > FAIL: nptl/tst-cancel9 > FAIL: nptl/tst-cancelx9 > > These tests have not been modified between glibc 2.21 and glibc 2.22. In > addition they are not listed in the expected failures list upstream [1]. > Note that the compiler has been changed from gcc 4.9 to gcc 5, this > might explain the failures, especially the first one. I think thread cancellation does has problems. Anyway, maybe Dave wants to take a look at those...? > In addition libio/tst-atime fails on sibaris only. It might be a > regression, but it is more likely a misconfiguration of the build > daemon, with the build parition mounted with the noatime option. Both machines run the same kernel and builds are on SSD drives with ext4. Both have the build directories mounted with relatime mount option. So, it's strange. > Can someone please investigate the issues? Sure, we will look into it. Thanks, Helge > Thanks, > Aurelien > > [1] https://sourceware.org/glibc/wiki/Release/2.22 >
Bug#809776: glibc: Please add patch to support HUGE PAGES on hppa
Package: glibc Version: 2.21-6 Tags: patch Can you please add this patch: https://sourceware.org/bugzilla/attachment.cgi?id=8811 to the next upload of debian glibc? It adds some defines for HUGE PAGE support for the hppa/parisc architecture, and it has been accepted upstream and committed into glibc master for 2.22. References: * glibc bugzilla entry (with patch and upstream commit): https://sourceware.org/bugzilla/show_bug.cgi?id=19285 Thanks, Helge
Bug#766605: glibc patch for hppa architecture
Source: glibc Version: 2.19-11 Severity: important Tags: patch Dear debian glibc maintainers, Can you please apply this hppa-arch-specific patch to debian glibc and keep it until you upgrade to sources of glibc 2.21 ? Main reason for this patch is to make it possible to use systemd on hppa. Without this patch people who will by mistake install systemd (e.g. because of dependencies) will render their machines unbootable. The patch breaks the ABI on hppa, but in a way which will not affect people, because it changes the signals which are usually not used. This has been tested by installing and booting mixtures of glibc and kernel with corresponding patches. I'll send in a bug report with patch for debian kernel shortly too. Upstream Linux kernel commit is 1f25df2eff5b25f52c139d3ff31bc883eee9a0ab http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1f25df2eff5b25f52c139d3ff31bc883eee9a0abutm_source=anzwix Upstream glibc commit is: https://sourceware.org/git/?p=glibc.git;a=commit;h=13d845549e41823e6658122dcf268154bcbbcfde I've adjusted the attached patch (only changes path names) so that it applies to debian's glibc 2.19 To better understand what we fix here, the glibc changelog description of Carlos is probably best (copied in here): This is a conscious ABI break for hppa. We find ourselves unable to run systemd because it expects SIGRTMIN+29 signals to be available and with hppa starting at 37 that exceeds the 64 signals available. It is arguable that the systemd code could compact their signal usage (the have a gap and don't check SIGRTMAX to see if they are over). However, that would require pursuing this upstream with systemd. The least work option is to make hppa more like other arches. The best option is to free up 3 signals for use with SIGXCPU, SIGXFSZ and SIGSTKFLT, and move those below 31. We make SIGSYS equal to SIGUNUSED as is expected. We remove SIGEMT and SIGLOST as HPUX signal we won't ever use. With that change we match all other machines. Given that these signals are so esoteric, testing by other users building minimal systems from scratch showed no problems. In fact Tcl fails to build if you make SIGEMT == SIGABRT, so we just removed SIGEMT (they use a large switch statement in C to handle signals, and I don't think it's valid to assume they will all have distinct values to fit into a switch). Committed as the only solution we possibly have here. Signed-off-by: Carlos O'Donell car...@systemhalted.org Signed-off-by: Helge Deller del...@gmx.de From 13d845549e41823e6658122dcf268154bcbbcfde Mon Sep 17 00:00:00 2001 From: Carlos O'Donell car...@redhat.com Date: Thu, 23 Oct 2014 23:14:12 -0400 Subject: [PATCH] hppa: Make __SIGRTMIN 32 (ABI break). In the Linux kernel version 3.17 the signal numbers were rearranged in order to make hppa like every other arch. Previously we started __SIGRTMIN at 37, and that meant several pieces of important software, including systemd, would fail to build. To support systemd we removed SIGEMT and SIGLOST, and rearranged the others according to expected values. This is technically an ABI incompatible change, but because zero applications use SIGSTKFLT, SIGXCPU, SIGXFSZ and SIGSYS nothing broke. Nothing uses SIGEMT and SIGLOST, and they were present for HPUX compatibility which is no longer supported. Thus because nothing breaks we don't do any compatibility work here. Upstream kernel commit is 1f25df2eff5b25f52c139d3ff31bc883eee9a0ab. Signed-off-by: Carlos O'Donell car...@systemhalted.org Signed-off-by: Helge Deller del...@gmx.de 2014-10-23 Carlos O'Donell car...@systemhalted.org Helge Deller del...@gmx.de [BZ #17508] * sysdeps/unix/sysv/linux/hppa/bits/signum.h: Remove SIGEMT. Define SIGSTKFLT as 7. Define SIGSYS as 31. Define SIGXCPU as 12. Remove SIGLOST. Define SIGXFSZ as 30. Define __SIGRTMIN as 32. --- diff -up ./ports/sysdeps/unix/sysv/linux/hppa/bits/signum.h.org ./ports/sysdeps/unix/sysv/linux/hppa/bits/signum.h --- ./ports/sysdeps/unix/sysv/linux/hppa/bits/signum.h.org 2014-10-24 12:47:51.039590372 +0200 +++ ./ports/sysdeps/unix/sysv/linux/hppa/bits/signum.h 2014-10-24 12:47:59.707589170 +0200 @@ -36,12 +36,12 @@ #define SIGTRAP 5 /* Trace trap (POSIX). */ #define SIGABRT 6 /* Abort (ANSI). */ #define SIGIOT 6 /* IOT trap (4.2 BSD). */ -#define SIGEMT 7 +#define SIGSTKFLT 7 /* Stack fault. */ #define SIGFPE 8 /* Floating-point exception (ANSI). */ #define SIGKILL 9 /* Kill, unblockable (POSIX). */ #define SIGBUS 10 /* BUS error (4.2 BSD). */ #define SIGSEGV 11 /* Segmentation violation (ANSI). */ -#define SIGSYS 12 /* Bad system call. */ +#define SIGXCPU 12 /* CPU limit exceeded (4.2 BSD). */ #define SIGPIPE 13 /* Broken pipe (POSIX). */ #define SIGALRM 14 /* Alarm clock (POSIX). */ #define SIGTERM 15 /* Termination (ANSI). */ @@ -61,11 +61,9 @@ #define SIGTTIN 27 /* Background read from tty (POSIX). */ #define SIGTTOU 28 /* Background write to tty
Bug#766605: Acknowledgement (glibc patch for hppa architecture)
The corresponding debian Linux kernel bug report is: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766635 -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/544a64f3.9040...@gmx.de
Bug#741243: [PATCH] localedef fix on hppa architecture
Hello Aurelien, On 05/08/2014 01:06 AM, Aurelien Jarno wrote: could you please add this patch temporarily to the debian eglibc sources? I don't really understand why changing the alignment from 4MB to 4kB will make the file mmapped at the same location. It's due to how the mmap logic was developed in glibc. Current logic will round the map-address up to the next SHMLBA alignment which may be wrong on parisc since the platform has specific hardware cache constraints which renders shared mappings then possibly not being in sync between different CPUs. Anyway, in that case instead of modifying a generic file common to all architecture, you should create a ports/sysdeps/hppa/libc-mmap.h with the HPPA specific value. True. Now that patch local-shmlba.diff from bug #725508 has been applied, is this patch still needed? That's correct. This patch here is not needed any longer then. You can just close this bug report (or mark it as duplicate of #725508). Thanks! Helge -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/536b301c.6080...@gmx.de
Bug#741243: [PATCH] localedef fix on hppa architecture
Package: eglibc Version: 2.18-4 Severity: important Tags: patch This command: localedef -i de_DE -c -f ISO-8859-1 -A /usr/share/locale/locale.alias de_DE fails on the hppa architecture because localedef wants to remap the locale file at another location than what it was given originally. This fails on hppa, because each file must be mapped so that the same byte in a file is mapped at offset modulo SHMLBA-1. Otherwise you will get a EINVAL error from mmap(). Dear Debian maintainer, could you please add this patch temporarily to the debian eglibc sources? It will take me quite some time to discuss the best approach to fix it upstream, but in the meantime it would be nice if the debian eglibc package will not show this problem on hppa. Thanks, Helge References: * Linux kernel patch: https://lkml.org/lkml/2013/12/10/148 * Mail thread: http://www.spinics.net/lists/linux-parisc/msg05236.html * not directly related: Debian bug 725508: hppa patches for eglibc (generic eglibc patches for hppa)diff -up ./sysdeps/generic/libc-mmap.h.org ./sysdeps/generic/libc-mmap.h --- ./sysdeps/generic/libc-mmap.h.org 2014-03-10 11:51:24.0 +0100 +++ ./sysdeps/generic/libc-mmap.h 2014-03-10 11:53:37.0 +0100 @@ -21,6 +21,11 @@ /* Using MAP_FIXED with mmap sometimes requires larger alignment. */ #include sys/shm.h +#ifdef __hppa__ +/* On parisc you can only remap at the same address (modulo SHMLBA-1) */ +#define MAP_FIXED_ALIGNMENT 4096 +#else #define MAP_FIXED_ALIGNMENT SHMLBA +#endif #endif
Bug#725508: hppa patches for eglibc
Any chance that those patches can be applied to eglibc? I'm asking, because we have done really great progress on the hppa port, e.g. - we have 7 buildd servers online (on 4 physical servers): http://unstable.buildd.net/index-hppa.html - the unstable branch mostly up-to-date, with more than 9400 packages built: http://buildd.debian-ports.org/stats/ - Linux kernel up-to-date and maintained upstream - gcc and glibc maintained upstream - debian-installer nearly finished. - ... That said, it would be really nice if you could apply it. It would really help us. Thanks, Helge -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/530268cb.2050...@gmx.de
Bug#561203: FTBFS [hppa] - pthread_create() (QThread) + fork() = crash
It seems libc6 2.10.2-3 fixed the problem. I cannot reproduce the bug with both test cases above any more. As far as I can tell from the changelog, rebuild with gcc-4.4 helped. I will close this bug once a couple of KDE packages get built on hppa successfully. Hello Modestas, libc6-2.10.2-3 made it much, *much* better (I'm not sure yet why!!). But I can still reproduce the bug on my system with your testcases. It's just much harder to reproduce it, but it still happens. So, it's not fixed yet, it just happens much less often. I'm continuing to look into this issue, but at least we have some progress... Helge -- Preisknaller: GMX DSL Flatrate für nur 16,99 Euro/mtl.! http://portal.gmx.net/de/go/dsl02 -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561203: FTBFS [hppa] - pthread_create() (QThread) + fork() = crash
On 12/27/2009 04:38 PM, Carlos O'Donell wrote: On Sun, Dec 27, 2009 at 9:47 AM, Luk Claesl...@debian.org wrote: What's the status of this bug? It's holding the KDE transition which is blocking the Xorg and python transitions... I'm working on this bug. The current status is under investigation. I don't have a good idea of what is going on or why it's crashing. I could reproduce this bug as well and will continue to debug as soon as I return back from christmas family visits. My current analysis/assumption is: I assumed, that the NPTL userspace implementation is correct and in this case I only see a difference in how the clone() syscall is called from pthread_create() and fork(). fork() always worked, while pthread_create() sometimes failed. pthread_create() uses clone(child_stack=0x4088d040, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x4108c4e8, tls=0x4108c900, child_tidptr=0x4108c4e8), while fork() uses clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x40002028) So, maybe the kernel implementation of clone() misses some cache flush instructions for the newly created child in the pthread_create() case... ? That said... I still need some more time for testing... Helge -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561203: FTBFS [hppa] - pthread_create() (QThread) + fork() = crash
On 12/22/2009 08:54 PM, Modestas Vainius wrote: when investigating this issue further, I determined that fork() following pthread_create() sometimes makes the application crash. In order to reproduce, build attached minifail.cpp with: $ g++ -I/usr/include/qt4 -lQtCore minifail.cpp -o minifail -O0 -g (pipe()/read()/write() are only used to sync parent with child after fork(), they are irrelevant for the problem). Thanks! Good testcase! I could verify all problems you reported (segfaults and hangs). Kernel 2.6.33-rc1-32bit, UP-machine, c3000. Helge -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#492778: *context
the patch was accepted and committed upstream: http://sourceware.org/ml/glibc-cvs/2008-q3/msg00272.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [parisc-linux] Re: NPTL for hppa-linux is not backwards compatible with Linuxthreads.
On Monday 19 February 2007, Jeff Bailey wrote: On 19/02/07, Aurelien Jarno [EMAIL PROTECTED] wrote: if the breakage is just in pthreads, i dont think the libc ABI needs to be bumped, just the pthread one ? libc provides look ahead stub functions for pthreads, so it shouldnt be affected by the breakage you've mentioned with static lock initializers ... libpthread.so.0 - libpthread.so.1 While it's definetly Ubuntu and Debian's problem, not upstream's, libpthread is bundled in the libc6 package. Bumping just the libpthread version will make packaging hard for those distros. If there are other ABI breaking moves that need to be done that would cause a bump from libc6, doing them now would help sidestep the problem. Well I am thinking in splitting out libpthread.so.X from the libc6 package if the ABI breakage is confirmed. This is still a very complicated transition, but I think far less packages are affected. Well, the ABI breakage is confirmed. I just remember people siting some other corner case problems with the ABI they wanted to change. Now would be a great time to change it all over if we need to do this. Maybe relevant: - [parisc-linux] [PATCH] fix up our compat semaphore operations http://lists.parisc-linux.org/pipermail/parisc-linux/2007-January/031125.html - [parisc-linux] 64-bit long double support. http://lists.parisc-linux.org/pipermail/parisc-linux/2006-November/030629.html - [parisc-linux] [patch] Remove magic constant from gas/tc-hppa.c Jeff Bailey http://lists.parisc-linux.org/pipermail/parisc-linux/2006-October/030417.html - [parisc-linux] Re: Looking at vfprintf.c and alloca. http://lists.parisc-linux.org/pipermail/parisc-linux/2006-July/029607.html (make possible to get ELF64 later?) - [parisc-linux] Close to mainline for hppa-linux TLS. http://lists.parisc-linux.org/pipermail/parisc-linux/2006-May/029171.html - [parisc-linux] [RFC] using 64bit wide registers with 32bit kernel http://lists.parisc-linux.org/pipermail/parisc-linux/2006-May/029050.html - Bug#364231: [parisc-linux] Re: Bug#364231: exception catching http://lists.parisc-linux.org/pipermail/parisc-linux/2006-May/028953.html (passing complex types) - [parisc-linux] ELF ABI Documents http://lists.parisc-linux.org/pipermail/parisc-linux/2006-April/028803.html (ELF64 ABI?) I am a bit busy right now, but I think we should put our transition ideas (at least for Debian, and probably Ubuntu) on a wiki, for example http://wiki.debian.org/HppaNptlTransition Sounds good. I've added doko to the cc: list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [parisc-linux] J5600 Video
On Thursday 08 February 2007, Max Grabert wrote: On 07/02/07, Michael Greene [EMAIL PROTECTED] wrote: I have my old J5600 recompiled and running with 2.6.19.1 kernel. I put an old Voodoo3 2000 rev 1 in the secondary pci slot and it is recognized by the system (not compiled in the kernel just lspci). Is there any trick to getting it to work with linux in the J5600 before I waste time trying? At one time I was trying to use a Voodoo3 3000 in a C3000, but I was unsuccessful (linux fb wouldn't initialise/turn on the display, and the native XFree86 driver would crash the machine). That was about 2 years ago I think, and some things have changed since then ... you might even be successful today. Just try and find out :-) I think you will fail. If I remember correctly Vodoo3 needs the on-board i386 Graphics-BIOS to get into a useful state which can be used by vodoo fbdev driver. Vodoo1 or Vodoo2 do work as framebuffer devices though. Helge -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc nptl failure baseline update.
tst-timer4.out :
clock_gettime returned timespec = { 1170787417, 996313000 }
clock_getres returned timespec = { 0, 4000250 }
Unknown.
Linux hake 2.6.19.2 #2 Thu Feb 1 19:58:15 EST 2007 parisc PA8600 (PCX-W+)
I don't know this test, but it might be fixed with a newer Linux kernel,
which includes those patches:
[GENERIC_TIME patchset for parisc]:
http://git.parisc-linux.org/?p=linux-2.6.git;a=commit;h=b6de83b58b8b07f057deacdef8a95b6c32d1c4e6
[disable cr16 clocksource when multiple CPUs are online]:
http://git.parisc-linux.org/?p=linux-2.6.git;a=commit;h=f70a979c843e4610edfb2a316648fe8ae8718f69
Helge
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc nptl failure baseline update.
Carlos O'Donell wrote: On 2/6/07, Matthew Wilcox [EMAIL PROTECTED] wrote: On Mon, Feb 05, 2007 at 10:13:01PM -0500, Carlos O'Donell wrote: make[2]: *** [/libc-tls-nptl/io/tst-fstatat.out] Error 1 make[2]: *** [/libc-tls-nptl/io/tst-futimesat.out] Error 1 make[2]: *** [/libc-tls-nptl/io/tst-renameat.out] Error 1 make[2]: *** [/libc-tls-nptl/io/tst-fchmodat.out] Error 1 make[2]: *** [/libc-tls-nptl/io/tst-symlinkat.out] Error 1 make[2]: *** [/libc-tls-nptl/io/tst-linkat.out] Error 1 make[2]: *** [/libc-tls-nptl/io/tst-mkdirat.out] Error 1 make[2]: *** [/libc-tls-nptl/io/tst-mkfifoat.out] Error 1 I guess we need to hook up the *at syscalls. Helge hooked them up already? This build uses an old header set and doesn't detect the *at functions. The fallbacks have likely never been tested, and as always... are rotten and don't work properly. TIF_RESTORE_SIGMASK support ? I think the honour goes to Kyle: http://git.parisc-linux.org/?p=linux-2.6.git;a=commitdiff;h=eeb14f5d284eacfa939153302dadfb7dc134ff9e;hp=dc914919be25ee5e98df90558c591d76d4b231d4 Helge -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405411: glibc clone() call buggy on HPPA
Package: libc6 Architecture: hppa Source: glibc Version: 2.3.6.ds1-9 Maintainer: GNU Libc Maintainers debian-glibc@lists.debian.org The current libc6 (2.3.6.dsl-9) on the HPPA (PARISC) architecture has two bugs in the clone() function. The first bug is, that it does not check the input variables for correctness. The second bug is, that the child process crashes when it call return 0. Both bugs are already fixed upstream in glibc CVS sources in a similiar way, but the current debian package (which is based on an older glibc source) still has the bug. Due to my current web-mailer I can't attach the patch to this bug report. Instead it would be great if the patch can be taken from this mail/thread on the parisc-linux development list: http://lists.parisc-linux.org/pipermail/parisc-linux/2007-January/031039.html Thanks, Helge -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405411: Patch attached
patch for parisc/hppa arcitecture is attached here now... --- glibc-2.3.6.ds1/build-tree/glibc-2.3.6/debian/sysdeps/unix/sysv/linux/hppa/clone.S.org 2006-12-29 08:49:25.0 +0100 +++ glibc-2.3.6.ds1/build-tree/glibc-2.3.6/debian/sysdeps/unix/sysv/linux/hppa/clone.S 2007-01-01 19:53:00.0 +0100 @@ -32,6 +32,11 @@ ENTRY(__clone) /* FIXME: I have no idea how profiling works on hppa. */ + /* Save the PIC register. */ +#ifdef PIC + stw %r19,-32(%sr0, %sp) /* parent */ +#endif + /* Sanity check arguments. */ comib,= 0,%arg0,.Lerror/* no NULL function pointers */ ldi -EINVAL,%ret0 @@ -41,10 +46,8 @@ /* Save the fn ptr and arg on the new stack. */ stwm%arg0,64(%arg1) stw %arg3,-60(%arg1) - - /* Save the PIC register. */ #ifdef PIC - stw %r19,-32(%sr0, %sp) /* parent */ + stw %r19,-32(%arg1) /* save PIC on child's stack */ #endif /* Do the system call */ @@ -88,6 +91,11 @@ bl $$dyncall,%r31 copy%r31,%rp + /* Restore PIC register for exit() */ +#ifdef PIC + ldw -32(%sr0, %sp), %r19/* parent */ +#endif + bl _exit,%rp copy%ret0,%arg0
