Bug#1067197: xserver-xorg-video-nouveau ftbfs

[Helge Deller]

Source: xserver-xorg-video-nouveau
Version: 1:1.0.17-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: del...@debian.org

Failure can be seen on hppa architecture, but I assume it will show up on armel 
too:

https://buildd.debian.org/status/fetch.php?pkg=xserver-xorg-video-nouveau=hppa=1%3A1.0.17-3=1710537593=0

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../src -I.. -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/xorg 
-fvisibility=hidden -I/usr/include/pixman-1 -I/usr/include/X11/dri -I/usr/include/libdrm 
-I/usr/include/libdrm -I/usr/include/libdrm/nouveau -I/usr/include/libdrm -g -O2 
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
-Wformat -Werror=format-security -Wall -I/usr/include/xorg -fvisibility=hidden 
-I/usr/include/pixman-1 -I/usr/include/X11/dri -I/usr/include/libdrm -c 
../../src/nv_shadow.c  -fPIC -DPIC -o .libs/nv_shadow.o
../../src/nv_driver.c: In function ‘NVScreenInit’:
../../src/nv_driver.c:1451:23: error: implicit declaration of function 
‘wfbScreenInit’; did you mean ‘fbScreenInit’? 
[-Werror=implicit-function-declaration]
 1451 | ret = wfbScreenInit(pScreen, FBStart, pScrn->virtualX,
  |   ^
  |   fbScreenInit
cc1: some warnings being treated as errors
make[3]: *** [Makefile:674: nv_driver.lo] Error 1

Bug#1065973: kmod: FTBFS due to time64 transition

[Helge Deller]

The patch below builds for me on the hppa platform.
Testcases needs verifying on physical hardware though.

Helge


diff -up ./testsuite/path.c.org ./testsuite/path.c
--- ./testsuite/path.c.org  2024-03-13 07:01:04.610222544 +
+++ ./testsuite/path.c  2024-03-13 07:11:16.630339502 +
@@ -15,9 +15,14 @@
  * License along with this library; if not, see .
  */
 
+#if !defined(_TIME_BITS) || _TIME_BITS != 64
+#define NEED_WRAPPER
 /* We unset _FILE_OFFSET_BITS here so we can override both stat and stat64 on
  * 32-bit architectures and forward each to the right libc function */
 #undef _FILE_OFFSET_BITS
+#else
+#undef NEED_WRAPPER
+#endif
 
 #include 
 #include 
@@ -191,6 +196,7 @@ TS_EXPORT int prefix ## stat ## suffix (
return _fn(ver, p, st); \
 }
 
+#ifdef NEED_WRAPPER
 WRAP_1ARG(DIR*, NULL, opendir);
 WRAP_1ARG(int, -1, chdir);
 
@@ -212,3 +218,4 @@ WRAP_VERSTAT(__lx,);
 WRAP_VERSTAT(__x,64);
 WRAP_VERSTAT(__lx,64);
 #endif
+#endif
diff -up ./tools/depmod.c.org ./tools/depmod.c
--- ./tools/depmod.c.org2024-03-13 06:56:13.616085242 +
+++ ./tools/depmod.c2024-03-13 07:13:11.417610532 +
@@ -2613,8 +2613,8 @@ static int depmod_output(struct depmod *
int mode = 0644;
int fd;
 
-   snprintf(tmp, sizeof(tmp), "%s.%i.%li.%li", itr->name, 
getpid(),
-   tv.tv_usec, tv.tv_sec);
+   snprintf(tmp, sizeof(tmp), "%s.%i.%lli.%lli", 
itr->name, getpid(),
+   (long long)tv.tv_usec, (long 
long)tv.tv_sec);
fd = openat(dfd, tmp, flags, mode);
if (fd < 0) {
ERR("openat(%s, %s, %o, %o): %m\n",

Bug#1026204: tar FTBFS on armel, armhf, i386, hppa, powerpc and sparc64

[Helge Deller]

On Tue, 31 Jan 2023 18:27:27 +0100 Andreas Henriksson  wrote:

> 
> export DEB_BUILD_MAINT_OPTIONS = future=+lfs
> export DEB_CFLAGS_MAINT_APPEND = -Wall -Wno-analyzer-null-argument

Might be useful to add a comment here saying:

# Workaround gnulib issue: The below three lines can be dropped once tar >= 
1.35 is used.
> ifneq ($(shell dpkg-architecture -qDEB_TARGET_ARCH_BITS),64)
> export DEB_CPPFLAGS_MAINT_APPEND = -D_TIME_BITS=64
> endif


Just for your info:
I opened this ticket:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030159.
which asks for a "future=+time64" option, which was accepted.
So, in future, just adding "future=+time64" avoids the "ifneq" check above.


I assume you also have no idea how to use src:gnulib when building tar
(or maybe it's just too complicated change)?
(The problem should already be fixed in the version of src:gnulib we
have in debian...)


I don't know. Sorry.


Will you go ahead and upload this Helge?


I'd prefer if some "tar" maintainer would do that...

Helge

Bug#1026204: tar FTBFS on armel, armhf, i386, hppa, powerpc and sparc64

[Helge Deller]

Hi David & Andreas,

On 1/28/23 12:10, David Prévot wrote:

Le Wed, Jan 18, 2023 at 01:24:37AM +0100, Helge Deller a écrit :

On Sat, 14 Jan 2023 20:38:38 +0100 Andreas Henriksson  wrote:

Here's a slightly different patch to implement basically the same thing


Unfortunately, even if both patches allow me to build tar on i386, they
also both lead to an FTBFS on amd64.


That's right. glibc headers used by configure complains then that _TIME_BITS=64 
can only be
used if FILE_OFFSET_BITS=64 is defined too (which isn't the case on amd64
as it's not needed there).

So, please use this hunk instead. It compiles for me on amd64 and 32-bit hppa.

export DEB_BUILD_MAINT_OPTIONS = future=+lfs
export DEB_CFLAGS_MAINT_APPEND = -Wall -Wno-analyzer-null-argument
ifneq ($(shell dpkg-architecture -qDEB_TARGET_ARCH_BITS),64)
export DEB_CPPFLAGS_MAINT_APPEND = -D_TIME_BITS=64
endif

DPKG_EXPORT_BUILDFLAGS = 1
include /usr/share/dpkg/buildflags.mk
---
Helge

Bug#1026204: tar FTBFS on armel, armhf, i386, hppa, powerpc and sparc64

[Helge Deller]

On Sat, 14 Jan 2023 20:38:38 +0100 Andreas Henriksson  wrote:

Here's a slightly different patch to implement basically the same thing


Yes, I like this patch better too.

Helge

Bug#1024653: git: FTBFS on s390x due to test failure, incorrect /proc/cpuinfo parsing

[Helge Deller]

The same bug happens on hppa and sparc architecture as well, as can be seen in 
those logs:
https://buildd.debian.org/status/fetch.php?pkg=git=hppa=1%3A2.39.0-1=1670883297=0
https://buildd.debian.org/status/fetch.php?pkg=git=sparc64=1%3A2.39.0-1=1670887934=0

Isn't there a better way to get the number of processors
in perl?
According to
https://stackoverflow.com/questions/4586405/how-to-get-the-number-of-cpus-in-linux-using-c
I like the idea of using the:
getNumCpus method of Sys::CpuAffinity

even fixing this line in chainlint.pl:
do { local @ARGV='/proc/cpuinfo'; return scalar(grep(/^processor[\s\d]*:/, 
<>)); } if -r '/proc/cpuinfo';
to never return 0, but at minimum "1" would work.

Helge

Bug#919857: klibc crashes on hppa

[Helge Deller]

Package: klibc
Version: 2.0.5-1
Severity: critical

The new klibc package (2.0.5-1) leads to crashes and an unbootable system.
Version 2.0.4-15 was working ok.

Output is as shown below.
I haven't had time yet to analyze what exactly is wrong in the new version.
Any idea what to test or where to look would be good.
Helge

Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... done.
[   58.612345] 117 (fstype): Uhuuh, elf segment at 0001 requested 
but the memory is mapped already
Segmentation fault
[   58.746281] 121 (fstype): Uhuuh, elf segment at 0001 requested 
but the memory is mapped already
Segmentation fault
[   58.799789] 124 (fstype): Uhuuh, elf segment at 0001 requested 
but the memory is mapped already
Segmentation fault
Begin: Will now check root file system ... fsck from util-linux 2.33.1
[/sbin/fsck.ext4 (1) -- /dev/sdb3] fsck.ext4 -a -C0 /dev/sdb3
ROOT300: clean, 139523/17039360 files, 15570025/68157440 blocks
done.
[   59.841124] EXT4-fs (sdb3): mounted filesystem with ordered data mode. Opts: 
(null)
done.
Begin: Running /scripts/local-bottom ... done.
Begin: Running /scripts/init-bottom ... [   60.171403] 138 (nuke): Uhuuh, elf 
segment at 0001 requested but the memory is mapped already
Segmentation fault
done.
[   60.228447] 140 (run-init): Uhuuh, elf segment at 0001 requested 
but the memory is mapped already
Segmentation fault
Target filesystem doesn't have requested /sbin/init.
[   60.243239] 141 (run-init): Uhuuh, elf segment at 0001 requested 
but the memory is mapped already
Segmentation fault
[   60.257792] 142 (run-init): Uhuuh, elf segment at 0001 requested 
but the memory is mapped already
Segmentation fault
[   60.272482] 143 (run-init): Uhuuh, elf segment at 0001 requested 
but the memory is mapped already
Segmentation fault
[   60.287150] 144 (run-init): Uhuuh, elf segment at 0001 requested 
but the memory is mapped already
Segmentation fault
[   60.301670] 145 (run-init): Uhuuh, elf segment at 0001 requested 
but the memory is mapped already
Segmentation fault
chvt: can't open console

Bug#851792: palo ships binary in the sources

[Helge Deller]

> On 21.01.2017 10:50, Christoph Biedl wrote:
>> However, after applying palo builds on amd64 and produces an iplboot of
>> the same size but with partially different content. Helge, might want to
>> burn one your boxes trying out? :-)

Thanks! Seems to work fine (with minor modification).
I did some more changes and pushed v1.97 to the git upstream tree.
Want to try again?
-> https://git.kernel.org/cgit/linux/kernel/git/deller/palo.git/

If it works somebody needs to upload a new palo to the debian buildds.
I don't have those rights.

Helge

Bug#851792: palo ships binary in the sources

[Helge Deller]

On 21.01.2017 10:50, Christoph Biedl wrote:
> Helge Deller wrote...
> 
>> On 18.01.2017 20:40, Adrian Bunk wrote:
>>> Package: palo
>> ...
>>> If palo should continue to be available on non-hppa machines,
>>> a (binary-all) package that uses gcc-hppa-linux-gnu for building
>>> might be an option.
>>
>> I'll check if it's possile. May take some time.
> 
> As my hppa machine still suffers from systemd's assertion failure[0], I
> cannot test the result of the changes attached below, or compare with
> the result of a build on native hardware.
> [0] https://lists.debian.org/debian-hppa/2014/09/msg00025.html

We have long time ago fixed the systemd issues. If you update kernel
and glibc you won't see those problems any longer. systemd now works
on hppa. The step to "jump over to a working systemd" while upgrading
the packages may be hard though... I think a normal update to debian
latest unstable should work.
 
> However, after applying palo builds on amd64 and produces an iplboot of
> the same size but with partially different content. Helge, might want to
> burn one your boxes trying out? :-)

Thanks for the patches.
I'll try soon.

Helge

Bug#851792: palo ships binary in the sources

[Helge Deller]

On 18.01.2017 20:40, Adrian Bunk wrote:
> Package: palo
...
> If palo should continue to be available on non-hppa machines,
> a (binary-all) package that uses gcc-hppa-linux-gnu for building
> might be an option.

I'll check if it's possile. May take some time.

Helge

Bug#769105: dietlibc: [PATCH] fix error codes and signals on hppa architecture

[Helge Deller]

Package: dietlibc
Version: 0.33~cvs20120325
Severity: critical
Tags: patch

Can you please apply this patch for the next upload of dietlibc?

It adjusts (for the hppa architecture only):

- EWOULDBLOCK is now same as EAGAIN, see upstream kernel commit (since kernel 
3.14):
  
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f5a408d53edef3af07ac7697b8bc54a755628450

- adjusts SIGSTKFLT, SIGXCPU, SIGXFSZ and SIGRTMIN to our new scheme, see Linux 
kernel upstream commit:
  
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1f25df2eff5b25f52c139d3ff31bc883eee9a0ab

Thanks,
Helge
diff -up ./include/errno.h.org ./include/errno.h
--- ./include/errno.h.org	2014-11-11 11:01:32.500997002 +0100
+++ ./include/errno.h	2014-11-11 11:02:33.356987381 +0100
@@ -550,7 +550,7 @@
 
 #define	EALREADY	244	/* Operation already in progress */
 #define	EINPROGRESS	245	/* Operation now in progress */
-#define	EWOULDBLOCK	246	/* Operation would block (Linux returns EAGAIN) */
+#define	EWOULDBLOCK	EAGAIN	/* Operation would block (Linux returns EAGAIN) */
 #define	ENOTEMPTY	247	/* Directory not empty */
 #define	ENAMETOOLONG	248	/* File name too long */
 #define	ELOOP		249	/* Too many symbolic links encountered */
diff -up ./include/signal.h.org ./include/signal.h
--- ./include/signal.h.org	2014-11-11 11:04:33.988968598 +0100
+++ ./include/signal.h	2014-11-11 11:14:17.980881783 +0100
@@ -97,9 +97,9 @@ __BEGIN_DECLS
 #define SIGXCPU		30
 #define SIGXFSZ		31
 #elif defined(__hppa__)
-#define SIGEMT		 7
+#define SIGSTKFLT	 7
 #define SIGBUS		10
-#define SIGSYS		12
+#define SIGXCPU		12
 #define SIGUSR1		16
 #define SIGUSR2		17
 #define SIGCHLD		18
@@ -114,12 +114,10 @@ __BEGIN_DECLS
 #define SIGTTIN		27
 #define SIGTTOU		28
 #define SIGURG		29
-#define SIGLOST		30
+#define SIGXFSZ		30
 #define SIGUNUSED	31
-#define SIGRESERVE	SIGUNUSE
-#define SIGXCPU		33
-#define SIGXFSZ		34
-#define SIGSTKFLT	36
+#define SIGRESERVE	SIGUNUSED
+#define SIGSYS		31
 
 #else
 #error signal layout not yet known
@@ -129,12 +127,8 @@ __BEGIN_DECLS
 #define SIGPOLL		SIGIO
 
 /* These should not be considered constants from userland.  */
-#ifdef __hppa__
-#define SIGRTMIN	37
-#else
 #define SIGLOST		SIGPWR
 #define SIGRTMIN	32
-#endif
 #define SIGRTMAX	(_NSIG-1)
 
 /* SA_FLAGS values: */

Bug#730903: mutrace FTBFS on hppa

[Helge Deller]

Same problem happens on hppa architecture.

Full build log is here:
http://buildd.debian-ports.org/status/fetch.php?pkg=mutracearch=hppaver=0.2.0-2stamp=1394830489

  CC   libmutrace_backtrace_symbols_la-backtrace-symbols.lo
backtrace-symbols.c:53:23: fatal error: libiberty.h: No such file or directory
 #include libiberty.h
   ^
compilation terminated.
make[2]: *** [libmutrace_backtrace_symbols_la-backtrace-symbols.lo] Error 1


The libiberty.h is provided by libiberty-dev and installed in 
/usr/include/libiberty/libiberty.h. 

Helge


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#561203: threads and fork on machine with VIPT-WB cache

[Helge Deller]

On 04/02/2010 09:35 PM, John David Anglin wrote:
 On Fri, 02 Apr 2010, NIIBE Yutaka wrote:
 
 NIIBE Yutaka wrote:
 To have same semantics as other archs, I think that VIPT-WB cache
 machine should have cache flush at ptep_set_wrprotect, so that memory
 of the page has up-to-date data.  Yes, it will be huge performance
 impact for fork.  But I don't find any good solution other than this
 yet.

 I think we could do something like (only for VIPT-WB cache machine):

 -static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned 
 long 
 address, pte_t *ptep)

 +static inline void ptep_set_wrprotect(struct vm_area_struct *vma, 
 struct 
 mm_struct *mm, unsigned long addr, pte_t *ptep)
  {
  pte_t old_pte = *ptep;
 +if (atomic_read(mm-mm_users)  1)
 +flush_cache_page(vma, addr, pte_pfn(old_pte));
  set_pte_at(mm, addr, ptep, pte_wrprotect(old_pte));
  }
 
 I tested the hack below on two machines currently running 2.6.33.2
 UP kernels.  The change seems to fix Debian #561203 (minifail bug)!
 Thus, I definitely think you are on the right track.  I'll continue
 to test.
 
 I suspect the same issue is present for SMP kernels.

Hi Dave,

I tested your patch today on one of my machines with plain kernel 2.6.33 
(32bit, SMP, B2000 I think).
Sadly I still did see the minifail bug.

Are you sure, that the patch fixed this bug for you?

Helge

do_page_fault() pid=21470 command='minifail3' type=6 address=0x0003
do_page_fault() pid=7986 command='minifail3' type=6 address=0x0003  
   
do_page_fault() pid=19952 command='minifail3' type=6 address=0x0003 
   
do_page_fault() pid=13549 command='minifail3' type=6 address=0x0003
do_page_fault() pid=21862 command='minifail3' type=6 address=0x0003
do_page_fault() pid=4615 command='minifail3' type=6 address=0x0003
do_page_fault() pid=17336 command='minifail3' type=6 address=0x0003
do_page_fault() pid=21986 command='minifail3' type=6 address=0x0003
do_page_fault() pid=2157 command='minifail3' type=15 address=0x00dc
do_page_fault() pid=23886 command='minifail3' type=6 address=0x0003
do_page_fault() pid=2681 command='minifail3' type=6 address=0x0003
do_page_fault() pid=3229 command='minifail3' type=15 address=0x00ec
do_page_fault() pid=26095 command='minifail3' type=6 address=0x0003
do_page_fault() pid=20722 command='minifail3' type=6 address=0x0003
do_page_fault() pid=19912 command='minifail3' type=15 address=0x00ec
...
pagealloc: memory corruption
7db0c780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
7db0c790: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
7db0c7a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
7db0c7b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
Backtrace:
 [1011ec14] show_stack+0x18/0x28
 [10117ba0] dump_stack+0x1c/0x2c
 [101c6594] kernel_map_pages+0x2a0/0x2b8
 [1019e6c8] get_page_from_freelist+0x3d4/0x614
 [1019ea3c] __alloc_pages_nodemask+0x134/0x610
 [101b1d20] do_wp_page+0x268/0xac0
 [101b3b34] handle_mm_fault+0x4d4/0x7c4
 [1011d854] do_page_fault+0x1f8/0x2fc
 [1011f450] handle_interruption+0xec/0x730
 [10103078] intr_check_sig+0x0/0x34
...
do_page_fault() pid=13414 command='minifail3' type=15 address=0x00dc
do_page_fault() pid=22776 command='minifail3' type=15 address=0x
do_page_fault() pid=26290 command='minifail3' type=15 address=0x00ec
do_page_fault() pid=1399 command='minifail3' type=6 address=0x0003
do_page_fault() pid=16130 command='minifail3' type=6 address=0x0003
do_page_fault() pid=26401 command='minifail3' type=6 address=0x0003
do_page_fault() pid=3383 command='minifail3' type=6 address=0x0003
do_page_fault() pid=3400 command='minifail3' type=15 address=0x0004
do_page_fault() pid=18659 command='minifail3' type=6 address=0x0003
do_page_fault() pid=3730 command='minifail3' type=6 address=0x0003
do_page_fault() pid=28828 command='minifail3' type=6 address=0x0003



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#561203: FTBFS [hppa] - pthread_create() (QThread) + fork() = crash

[Helge Deller]

 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-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#561203: FTBFS [hppa] - pthread_create() (QThread) + fork() = crash

[Helge Deller]

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-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#561203: FTBFS [hppa] - pthread_create() (QThread) + fork() = crash

[Helge Deller]

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-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#539215: grave or important ?

[Helge Deller]

Hmm...
I just marked this bug grave, but I'm not sure if it should be important 
instead. Please advise...

Fact is, that the hppa 2.6.26-2 kernel, as it's currently available, has a 
major bug, which can easily hang and DOS the full machine under various loads. 
I can reproduce this bug with my testcases. Given the fact that some people 
consider the hppa port (and the debian build servers) not very stable, I think 
it's important to fix this issue as soon as possible.

Helge
-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#478717: kernel patch for ruby1.9 kernel crashes

[Helge Deller]

This Linux kernel patch solves the issue:
http://permalink.gmane.org/gmane.linux.ports.parisc/1028

Patch in parisc git tree:
http://git.kernel.org/?p=linux/kernel/git/kyle/parisc-2.6.git;a=commitdiff;h=378fe7c4cc619b561409206605c723c05358edac;hp=6c4dfa8f8bcf032137aacb3640d7dd9d75b2b607



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#478717: [PATCH] fix ruby1.9 kernel crashes on hppa when compiling

[Helge Deller]

I could reproduce the kernel crashes when compiling ruby1.9 on hppa,
even with kernel 2.6.28-rc8.

My current analysis showed, that the miniruby process creates a
memory protection ID trap when trying to push back the results of the
poll() syscall to userspace. This means, that (sometimes) when the
kernel calls __put_user() in fs/select.c:do_sys_poll() it suddenly
access some kind of invalid memory and creates a data protection ID fault.

My assumption is, that the linuxthreads implementation on hppa is still
buggy (or it's another still hidden kernel bug).

Nevertheless, the attached patch below fixes the kernel crashes at least.
This means, that you can compile ruby1.9 and run miniruby as often as
you want. The patch will make it possible to kill the miniruby process
and makes further debugging of the problem possible.

The patch applies to kernel 2.6.28-rc8, but should similar apply to
older kernel versions (e.g. 2.6.26) as well.

I'm not sure yet, if this will be the final version of the patch and
I'll continue to try find the real cause of the problem of course...

Any feedback and testing results very much welcome.

Helge

Patch is
Signed-off-by: Helge Deller del...@gmx.de
diff --git a/arch/parisc/kernel/traps.c b/arch/parisc/kernel/traps.c
index 4c771cd..70eabfe 100644
--- a/arch/parisc/kernel/traps.c
+++ b/arch/parisc/kernel/traps.c
@@ -43,6 +43,8 @@
 
 #include ../math-emu/math-emu.h	/* for handle_fpe() */
 
+DECLARE_PER_CPU(struct exception_data, exception_data);
+
 #define PRINT_USER_FAULTS /* (turn this on if you want user faults to be */
 			  /*  dumped to the console via printk)  */
 
@@ -745,6 +747,41 @@ void handle_interruption(int code, struct pt_regs *regs)
 		/* Fall Through */
 	case 27: 
 		/* Data memory protection ID trap */
+		if (code == 27  !user_mode(regs)) {
+			const struct exception_table_entry *fix;
+
+			/* mostly copied from:
+ 			   arch/parisc/mm/fault.c:do_page_fault()
+			 */
+			fix = search_exception_tables(regs-iaoq[0]);
+			printk(KERN_CRIT BUG: Kernel Data memory protection ID
+ trap at %p (%pS), fix=%p\n,
+(void*)regs-iaoq[0], (void*)regs-iaoq[0], fix);
+			if (fix) {
+struct exception_data *d;
+
+d = __get_cpu_var(exception_data);
+d-fault_ip = regs-iaoq[0];
+d-fault_space = regs-isr;
+d-fault_addr = regs-ior;
+
+regs-iaoq[0] = ((fix-fixup)  ~3);
+
+/*
+ * NOTE: In some cases the faulting instruction
+ * may be in the delay slot of a branch. We
+ * don't want to take the branch, so we don't
+ * increment iaoq[1], instead we set it to be
+ * iaoq[0]+4, and clear the B bit in the PSW
+ */
+
+regs-iaoq[1] = regs-iaoq[0] + 4;
+regs-gr[0] = ~PSW_B; /* IPSW in gr[0] */
+
+return;
+			}
+		}
+
 		die_if_kernel(Protection id trap, regs, code);
 		si.si_code = SEGV_MAPERR;
 		si.si_signo = SIGSEGV;

Bug#492778: *context

[Helge Deller]

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]

Bug#459567: [RFC] Patch for glibc getcontext()/makecontext()/setcontext()/swapcontext()

[Helge Deller]

Proposed patch to glibc posted here, waiting for feedback.
http://permalink.gmane.org/gmane.linux.ports.parisc/524

(It fixed this bug for me, after I rebuilt pth-2.0.7 with the *context() 
implementation).



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#475767: [Fwd: Re: kde4libs vs qt4]

[Helge Deller]

This should really fix the bug...
---BeginMessage---

Hello Sune,

Sune Vuorela wrote:

I now hacked a bit and got stuff working on one of those cluster machines.
http://svn.debian.org/wsvn/pkg-kde/trunk/packages/qt4-
x11/debian/patches/72_generic_arch_atomic_header_fix.diff?op=filerev=0sc=0

This isn't the real solution though.

Qt4 has arch specific code for most archs (and a generic arch mostly used 
for bootstrapping of Qt), but no arch for linux/hppa, so we use the generic 
arch here.


The real solution involves some hppa assembler (which is way out of my 
league). There is a patch in the package by lamont about patching the hpux 
code, but I couldn't get taht to work with my quick tests.


Attached are the basic pieces which should get it working with the 
qt4-x11_4.4.0-3 source package. My machine is still compiling, but it 
seems OK so far...


First of all, I reused the parisc architecture code from the Trolls.
hppa and parisc are the same architectures, so why introduce something 
new? Furthermore the Qt code base has lots of #ifdef QT_ARCH_PARISC, 
e.g. in src/corelib/thread/qbasicatomic.h, which would need to be 
duplicated for hppa.
The nice effect is, that this way the parisc-atomic-headers will be used 
instead of the generic-locking-headers and it should fix a lot of 
following problems, e.g. with KDE.


This piece makes configure detect hppa as a parisc-architecture:

diff -up ./debian/patches/07_trust_dpkg-arch_over_uname-m.diff.org 
./debian/patches/07_trust_dpkg-arch_over_uname-m.diff
--- ./debian/patches/07_trust_dpkg-arch_over_uname-m.diff.org	2008-06-11 
23:34:12.0 +0200
+++ ./debian/patches/07_trust_dpkg-arch_over_uname-m.diff	2008-06-11 
23:34:23.0 +0200

@@ -22,7 +22,7 @@ Reported to trolltech as N180631 - and t
 +  UNAME_MACHINE=armv5tel
 +  ;;
 +  hppa)
-+  UNAME_MACHINE=parisc64
++  UNAME_MACHINE=parisc
 +  ;;
 +  hurd-i386)
 +  UNAME_MACHINE=i686-AT386


Not sure if it's needed, but it doesn't hurts either:
(I had some problems on my machine, that the Qt configure tests could 
not detect the endianess.)


diff -up ./debian/rules.org ./debian/rules
--- ./debian/rules.org  2008-06-10 23:50:44.0 +0200
+++ ./debian/rules  2008-06-11 23:36:26.0 +0200
@@ -65,6 +65,8 @@ ifeq ($(DEB_HOST_ARCH),hppa)
echo Please update kernel and test again ; \
exit 5 ; \
fi
+
+   EXTRA_CONFIGURE_OPTS += -v -big-endian
 endif

# Create mkspecs/glibc-g++ from mkspecs/linux-g++, needed by 
GNU/kFreeBSD



And this part replaces the debian patch 70_hppa_ldcw_fix.diff.
Maybe you could name this one 71_hppa_ldcw_fix.diff and add it to the 
to-be-applied patches list?
Benefit of my version is, that the q_ldcw() assembler statement will be 
inlined any will perform better than a call to an external funtion.


diff -up ./src/corelib/arch/parisc/arch.pri.org 
./src/corelib/arch/parisc/arch.pri
--- ./src/corelib/arch/parisc/arch.pri.org	2008-04-28 15:11:18.0 
+0200

+++ ./src/corelib/arch/parisc/arch.pri  2008-06-10 00:19:10.0 +0200
@@ -1,5 +1,7 @@
 #
 # HP PA-RISC architecture
 #
-SOURCES += $$QT_ARCH_CPP/q_ldcw.s \
-  $$QT_ARCH_CPP/qatomic_parisc.cpp
+
+hpux*: SOURCES += $$QT_ARCH_CPP/q_ldcw.s
+
+SOURCES += $$QT_ARCH_CPP/qatomic_parisc.cpp
diff -up ./src/corelib/arch/parisc/qatomic_parisc.cpp.org 
./src/corelib/arch/parisc/qatomic_parisc.cpp
--- ./src/corelib/arch/parisc/qatomic_parisc.cpp.org	2008-06-10 
00:02:32.0 +0200
+++ ./src/corelib/arch/parisc/qatomic_parisc.cpp	2008-06-10 
00:09:54.0 +0200

@@ -72,7 +72,21 @@ static int *align16(int *lock)

 extern C {

+#if defined(Q_OS_LINUX)
+#if defined(__LP64__)
+   #define __LDCW  ldcw,co
+#else
+   #define __LDCW  ldcw
+#endif
+#define q_ldcw(addr) ({\
+   unsigned __ret; \
+   __asm__ __volatile__(__LDCW  0(%1),%0   \
+   : =r (__ret) : r (addr));   \
+   __ret;  \
+   })
+#else /* for HP/UX */
 int q_ldcw(volatile int *addr);
+#endif

 void q_atomic_lock(int *lock)
 {


Full patch attached as well, just in case my mailer breaks the lines.
Could you test it ? Do you need more ?

Best regards,
Helge
diff -up ./debian/patches/07_trust_dpkg-arch_over_uname-m.diff.org ./debian/patches/07_trust_dpkg-arch_over_uname-m.diff
--- ./debian/patches/07_trust_dpkg-arch_over_uname-m.diff.org	2008-06-11 23:34:12.0 +0200
+++ ./debian/patches/07_trust_dpkg-arch_over_uname-m.diff	2008-06-11 23:34:23.0 +0200
@@ -22,7 +22,7 @@ Reported to trolltech as N180631 - and t
 +		UNAME_MACHINE=armv5tel
 +	;;
 +	hppa)
-+		UNAME_MACHINE=parisc64
++		UNAME_MACHINE=parisc
 +	;;
 +	hurd-i386)
 +		UNAME_MACHINE=i686-AT386
diff -up ./debian/rules.org ./debian/rules

Bug#459560: crashes at once on hppa architecture

[Helge Deller]

Package: ant
Version: 1.7.0-3
Severity: grave

ant crashes at once on the hppa architecture if it's called from the command 
line.

Example:
[EMAIL PROTECTED] ~]$ ant
Segmentation fault

the last part of strace gives:
.
brk(0)  = 0x12000
brk(0x33000)= 0x33000
open(/usr/lib/locale/locale-archive, O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=0, st_size=0, ...}) = 0
mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0x438b4000
mmap2(NULL, 1183744, PROT_READ, MAP_PRIVATE, 3, 0x222) = 0x434b4000
close(3)= 0
gettimeofday({1199701873, 548740}, NULL) = 0
rt_sigaction(SIGHUP, {0x4012722a, [], 0}, NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], NULL, 8) = 0
rt_sigaction(SIGPWR, {0x4012722a, ~[], SA_RESTART}, NULL, 8) = 0
rt_sigaction(SIGXCPU, {0x4012722a, ~[], SA_RESTART}, NULL, 8) = 0
open(/proc/stat, O_RDONLY)= 3
read(3, cpu  89099 18209902 2666026 2211..., 4096) = 447
close(3)= 0
sched_getscheduler(25290)   = 0 (SCHED_OTHER)
sched_getparam(25290, { 0 })= 0
open(/proc/self/maps, O_RDONLY)   = 3
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=81920*1024}) = 0
fstat64(3, {st_mode=0, st_size=46673409605649, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x4000b000
read(3, 0001-00011000 r-xp  ..., 1024) = 1024
read(3, .4\n40288000-40289000 rwxp e0..., 1024) = 1024
read(3, 43663000 rwxp 0007a000 08:03 798..., 1024) = 194
close(3)= 0
munmap(0x4000b000, 4096)= 0
mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x4009c000
mmap(0x400ac000, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0x400ac000
mmap(0x400bc000, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0x400bc000
getpid()= 25290
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Process 25290 detached



-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: hppa (parisc)

Kernel: Linux 2.6.24-rc4
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Versions of packages ant depends on:
ii  gij [java-virtual-machine]4:4.2.1-6  The GNU Java bytecode interpreter
ii  gij-4.1 [java1-runtime]   4.1.2-6The GNU Java bytecode interpreter
ii  gij-4.2 [java1-runtime]   4.2.1-5The GNU Java bytecode interpreter
ii  java-gcj-compat   1.0.76-5   Java runtime environment using GIJ
ii  libxerces2-java   2.9.0-1Validating XML parser for Java wit

Versions of packages ant recommends:
ii  ant-gcj   1.7.0-3Java based build tool like make
ii  ant-optional  1.7.0-3Java based build tool like make - 

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#459563: javac / ecj crashes at once at startup on hppa architecture

[Helge Deller]

Package: ecj
Version: 3.3.0+0728-5
Severity: grave


javac / ecj crashes at once at startup on the hppa architecture

Example:

[EMAIL PROTECTED] ~]$ uname -a
Linux ls3545 2.6.24-rc4 #25 Sat Dec 8 12:36:01 CET 2007 parisc GNU/Linux

[EMAIL PROTECTED] ~]$ javac
Segmentation fault


I assume the problem is similiar as for the ant bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;bug=459560


The last lines of a strace shows:
.
brk(0x5ac000)   = 0x5ac000
open(/usr/lib/locale/locale-archive, O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=0, st_size=0, ...}) = 0
mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0x438b4000
mmap2(NULL, 1183744, PROT_READ, MAP_PRIVATE, 3, 0x222) = 0x42cb4000
close(3)= 0
rt_sigaction(SIGPWR, {0x4012722a, ~[], SA_RESTART}, NULL, 8) = 0
rt_sigaction(SIGXCPU, {0x4012722a, ~[], SA_RESTART}, NULL, 8) = 0
open(/proc/stat, O_RDONLY)= 3
read(3, cpu  91477 18209902 2666735 2212..., 4096) = 447
close(3)= 0
sched_getscheduler(25385)   = 0 (SCHED_OTHER)
sched_getparam(25385, { 0 })= 0
open(/proc/self/maps, O_RDONLY)   = 3
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=81920*1024}) = 0
fstat64(3, {st_mode=0, st_size=46673409605649, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x40017000
read(3, 0001-004ee000 r-xp  ..., 1024) = 1024
read(3, lib/libz.so.1.2.3.3\n403b9000-427..., 1024) = 867
close(3)= 0
munmap(0x40017000, 4096)= 0
mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x40017000
mmap(0x40027000, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x4009e000
mmap(0x400ae000, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x400ae000
getpid()= 25385
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Process 25385 detached




-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: hppa (parisc)

Kernel: Linux 2.6.24-rc4
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages ecj depends on:
ii  gij-4.2 4.2.1-5  The GNU Java bytecode interpreter
ii  java-common 0.27 Base of all Java packages
ii  libecj-java 3.3.0+0728-5 Eclipse Java compiler (library)
ii  libgcj8-jar 4.2.1-5  Java runtime library for use with 

Versions of packages ecj recommends:
ii  ecj-gcj 3.3.0+0728-5 standalone version of the Eclipse 

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#459567: dirmngr segfaults on hppa architecture

[Helge Deller]

Package: dirmngr
Version: 1.0.1-2
Severity: grave

dirmngr segfaults at once on hppa architecture

Example:
3545:~# uname -a
Linux ls3545 2.6.24-rc4 #25 Sat Dec 8 12:36:01 CET 2007 parisc GNU/Linux

ls3545:~# dirmngr
dirmngr[28087]: error opening `/root/.gnupg/dirmngr_ldapservers.conf':
No such file or directory
Segmentation fault

strace shows:
.
gettimeofday({1199704348, 771319}, NULL) = 0
rt_sigprocmask(SIG_BLOCK, NULL, ~[KILL STOP], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
open(/root/.gnupg/dirmngr.conf, O_RDONLY|O_LARGEFILE) = -1 ENOENT (No
such file or directory)
open(/root/.gnupg/dirmngr_ldapservers.conf, O_RDONLY|O_LARGEFILE) = -1
ENOENT (No such file or directory)
fstat64(2, {st_mode=0, st_size=46673409605637, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x40008000
getpid()= 28089
write(2, dirmngr[28089]: error opening `/..., 97dirmngr[28089]: error
opening `/root/.gnupg/dirmngr_ldapservers.conf': No such file or
directory
) = 97
rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0
mmap(NULL, 266240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x40009000
gettimeofday({1199704348, 777586}, NULL) = 0
rt_sigprocmask(SIG_BLOCK, [USR1], [], 8) = 0
rt_sigaction(SIGUSR1, {0x406578fa, [], SA_STACK}, {SIG_DFL}, 8) = 0
sigaltstack({ss_sp=0x40009008, ss_flags=0, ss_size=262144}, {ss_sp=0,
ss_flags=SS_DISABLE, ss_size=0}) = 0
getpid()= 28089
kill(28089, SIGUSR1)= 0
rt_sigsuspend(~[USR1])  = -514
--- SIGUSR1 (User defined signal 1) @ 0 (0) ---
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Process 28089 detached



-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: hppa (parisc)

Kernel: Linux 2.6.24-rc4
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages dirmngr depends on:
ii  adduser 3.105add and remove users and groups
ii  libc6   2.7-5GNU C Library: Shared libraries
ii  libgcrypt11 1.4.0-2  LGPL Crypto library - runtime libr
ii  libgpg-error0   1.4-2library for common error values an
ii  libksba81.0.2-1  X.509 and CMS support library
ii  libldap22.1.30.dfsg-13.5 OpenLDAP libraries
ii  libpth202.0.7-9  The GNU Portable Threads
ii  lsb-base3.1-24   Linux Standard Base 3.1 init scrip

dirmngr recommends no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]