Bug#1036459: pre-unblock: palo/2.23
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Control: affects -1 src:palo This pre-unblock request is to get a decision from the Bookworm release team if I'm allowed to upload the palo 2.23 bug-fix version. - palo is a bootloader for the PA-RISC (hppa) architecture, comparable to lilo or grub on x86. - hppa is NOT a release architecture, and the palo package does NOT affect any of the release architectures (palo can be used on x86 to generate an ISO image for hppa though) - the new palo version has some important bootloader fixes for specific parisc machines - it would be nice to get OK here, as even if hppa is not a release architecture, we plan to build bookworm-install CD's for hppa in debian-ports and it would be nice to have latest palo bootloader available in the bookworm release, else people will install bookworm/parisc and have an old/buggy bootloader. Ok to upload/unblock palo/2.23 ? Thanks, Helge
Re: The (uncalled for) toolchain maintainers roll call for stretch
Hi Matthias, On 10.09.2016 00:48, Matthias Klose wrote: > While the Debian Release team has some citation about the quality of the > toolchain on their status page, it is not one of the release criteria > documented > by the release team. I'd like to document the status how I do understand it > for > some of the toolchains available in Debian. > Java/OpenJDK > > > For the stretch release openjdk-8 will be fine as the default java > implementation. For buster, gcj (to be removed in GCC 7) won't be available > anymore, and we'll end up with architectures without a java implementation. > At > the same time I'd like to consider to stop providing OpenJDK zero builds, > leaving powerpc and mips* without a java implementation as well (currently not > building for openjdk-9). armhf (not armel) and s390x have Hotspot ports > underway. Can you explain the reason why you consider stopping OpenJDK zero builds? I'm asking, because on hppa we currently use gcj and we don't have any OpenJDK port yet. My hope was to fix at some point in future the old existing OpenJDK zero port patches to get some newer JDK even if it's slower. With your intention to stop zero builds, we probably won't have any JDK at all... Thanks, Helge
Re: Roll call for porters of architectures in sid and testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I am not currently a porter but I would like to be one for the architecture parisc/hppa. I currently have lots of parisc hardware (5 workstations and 4 servers), all currently running debian unstable from our own debian repository at www.parisc-linux.org. My involvement for debian-parisc so far: - - I was one of the initiators of parisc-linux port back in 1999. - - I have continuous worked on the ports since then. - - I'm currently one of the two official linux kernel maintainers for the parisc port at kernel.org. - - I've fixed quite some debian bugs reported for parisc in the past, including locking functions in gcc, KDE fixes, udev fixes and many more. - - I do have a strong linux developer background (C/C++, Assembler) and was formerly a developer at a major linux distributor. - - I'm maintaining the parisc-linux website and wikis. I am not a DD/DM but would like to become one. At last, I would be happy if parisc could become again a supported platform in the debian-ports repositories for the lifetime of Jessie. parisc was dropped with debian squeeze, because there were quite some stability issues with the Linux kernel at that time. Currently, upstream kernel 3.10 (stable) and kernel 3.11 do work reliable on all major machines. -- Helge Deller On 09/01/2013 09:33 AM, Niels Thykier wrote: > Hi, > > As we announced in [LAST-BITS], we would like to get a better idea of > that status of the ports, to make an informed decision about which > port can be released with jessie. One of the steps is to get an > overview of which of the porters are (still) active for each > port. Once the results from the role-call are in, we will request > other information about the status of the ports. In the meantime, feel > free to update and collect info about the ports in the Debian wiki[WIKI]. > > If you are (or intend to become) an active porter for the lifetime of > jessie, then please send a signed email explaining your involvement in > the port to the Release Team before > 1st of October 2013. Please explain the level of your involvement in > the port. > > Feel free to use the following template as your reply: > > """ > Hi, > > I am an active porter for the following architectures and I intend > to continue this for the lifetime of the jessie release: > > For , I > - test (most|all) packages on this architecture > - fix toolchain issues > - triage arch-specific bugs > - fix arch-related bugs > - maintain buildds > - ... > > > > > """ > > Niels, on behalf of the release team > > [LAST-BITS] > http://lists.debian.org/debian-devel-announce/2013/08/msg6.html > > [WIKI] https://wiki.debian.org/ArchiveQualification/Jessie > > > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSKPXJAAoJEIfJwVG1Hjhk1BsH/3nhr6HjGwpGnc6NnQxV3KA2 95LNye6Fi7aOh5NWGrjn8c3fmyJcoHdQFAMOIIulGZW6gLAeu1cX9Y16OAzMKP/H LTCvq0Q8yzl/U75+NKgz9rdozsXds43rmuyBJIZdypGXKjWEIkRz/ISzOL4+hdqh W+HoYWG/fqCsdhJMiUIIUQ7BW6kadJmoi3L5dZBBwLD9bHLY6lCIT4JEdDXKZrQ9 NPIYhEDfCIJl4yS982Q76SwqEkCYG84f0Egez66ADuazCjqGWkrI6EBzOeDvgV26 wdfekcU/Wx3LcFDBnd8clMG/MdmxxQu7c915Uv23DejD0QWVUlimFSTfWI8v59k= =htC/ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5228f5c9.3050...@gmx.de
Re: open issues with the hppa port
On 10/07/2009 02:43 PM, Andreas Barth wrote: * Andreas Barth (a...@not.so.argh.org) [090816 13:24]: * Andreas Barth (a...@not.so.argh.org) [090730 16:51]: As from release team point of view, it is necessary that there is a plan how hppa can and will return in the forseeable future to normal mode of operation, i.e. there are not many issues with e.g. architecture specific build failures. I have seen some activity from your side. Thank you for that. However, it would be really good if we could get some written down plan with maximum amount of time it takes till we are in normale operation mode. Things have become better, I'd like to thank you for that. Full ACK ! Carlos, you did an outstanding job! There are still more issues with hppa popping up than with other architectures, but the general direction looks promising. For this reason, we have decided that we try to avoid the additional burden of packages getting out of sync, and keep hppa in our list of "normal supported architectures" at this time. We are only able to keep it this way if the good work continues, the switch to ntpl happens etc etc - I definitly hope it will work out well. That's great. Thanks Andreas! Helge -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: open issues with the hppa port
On 07/30/2009 07:44 PM, John David Anglin wrote: On Thu, Jul 30, 2009 at 10:50 AM, Andreas Barth wrote: You know your porters mailing list best, but I want to highlight some of the issues: http://lists.debian.org/debian-hppa/2009/07/msg2.html I can't comment on this issue. I hope Dave can? Over the past few weeks, I have been testing 2.6.30.y on three different platforms (c3750, rp3440 and A500-7X). I have run identical 32 and 64-bit kernels on the c3750. To the base system, I have applied a collected set of patches. Except for the typo change recently posted to the parisc linux list, all the changes are now in 2.6.31. With the exception of nscd, I have had no segfault problems with 2.6.30.y on the c3750. However, the same is not true for the rp3440 and A500-7X. The rp3440 is worse than the A500-7X, but application segfaults occured very quickly running SMP kernels building GCC (usually in our old friend the dynamic loader). The A500-7X (gsyprf11) is now back running a modified SMP version of 2.6.19.22. Last change was the U bit fix. It has now run eight days without any obvious segfaults. 2.6.19.22 with the above changes is not segfault free on the rp3440. However, it is better than any other SMP build on this processor. I am currently running a UP build of 2.6.30.3 on the rp3440. It is not segfault free, but I can usually get through a GCC build without a fault. So, even with a UP kernel, we still get cache corruption on this machine. I wonder if it is possible to turn L2 off. I had hoped that the U bit fix would help. However, its effect is not dramatic. When rebooting the rp3440, it would sometimes report memory errors in the system hardware log. Similarly, the display attached to the VisEG on the c3750 would sometimes get noisy. Resetting the display mode at boot would cure this. Another effect was for cpus to mysteriously get disabled. I suspect that the kernel was sometimes accidently writing to the control memory for these devices. These problems may be fixed or reduced with the U bit fix. In summary, the segfault problem is still there and a major issue, particularly with SMP kernels. Without a testcase that consistently triggers the problem, it's almost impossible to debug what's going wrong. glob2 built for me, so the build failure was probably caused by cache corruption. Dave Dave, thanks for this very good summary! I just want to mention my thoughts on this issue. I see the point, that Debian needs a stable and reliable build server. But just saying, that the whole parisc port is unstable due to a few problematic servers is imho wrong. My 4 machines (715/64, B160L, Tadpole parisc laptop and a C3000) are absolutely stable. The debian kernel is stable on those machines and even survives big compilation tests. That said, in my opinion and given my machines, parisc IS a stable platform. So, if we have stability problems on the most important machines, which are the debian build servers, then maybe some thoughts should be given to replace those machines by slower but at least stable machines, like e.g. a C3000 ? That way, debian can continue to be built and we can concentrate on fixing the remaining issues. Helge PS: Sadly I don't have neither a SMP machine nor one of the problematic boxes. So, I'm currently not very much of a help to fix those issues (unless someone sends me such a problematic box :-)) -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On 07/05/2009 01:34 AM, John David Anglin wrote: On Fri, Jul 03, 2009 at 09:28:00PM +0200, Philipp Kern wrote: On Fri, Jul 03, 2009 at 08:57:56PM +0200, Kurt Roeckx wrote: Did something change to peri? I'm currently only seeing them on penalosa. UP kernel, maybe? Both peri and penalosa run 2.6.29-2-parisc64-smp and from what I can tell run on identical hardware. I tried a SMP kernel (2.6.30.1 with the patch set posted earlier) on my rp34404. Fired up a GCC build. It didn't take more than a few minutes to trigger a couple of segvs in /bin/sh. On the other hand, I ran a UP version of 2.6.30 for more than a week without any major problems. So, instead of just complaining, wouldn't it be useful if someone with root access would install a UP kernel (and disable nscd) for the time being on the build servers? That way we all would avoid debian build problems and could concentrate on solving the issues with the SMP kernel itself. In the meantime, all (IMHO) major kernel patches have now been included in Linus' 2.6.31-rc2 kernel and I plan to backport and send them to the stable-kernel team for inclusion into 2.6.29 and 2.6.30 stable kernel series. Helge -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On 06/16/2009 08:25 AM, Lucas Nussbaum wrote: On 15/06/09 at 11:31 -0600, Grant Grundler wrote: PS: if you want an HPPA-specific issue to play with, http://experimental.debian.net/fetch.php?&pkg=ruby1.9&ver=1.9.0.1-5&arch=hppa&stamp=1213563978&file=log&as=raw might be a good candidate. In reality it's not (any longer) a hppa specific bug. It's a bug in ruby. Ruby just relies on NPTL specific behaviour of threads and as such plays mad on LinuxThreads, which we still have active on hppa. The good thing is, that the NPTL switch-over was started by Carlos, so I expect that this should be fixed when NPTL hits unstable... Helge -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Please give back ruby1.9/1.9.0.2-9 on hppa and alpha
dann frazier wrote:
> On Mon, Feb 02, 2009 at 07:04:48PM +0100, Lucas Nussbaum wrote:
>> ruby1.9 still fails to build on hppa and alpha.
>>
>> On hppa, it's caused by a kernel bug, which was partially fixed (at
>> least the kernel doesn't panic() anymore). Since the issue is related to
>> threading, it is possible that retrying could make it build
>> successfully.
>
> fyi, I've retried it numerous times on both buildds with no
> luck. We're not crashing the buildd anymore - thanks to Helge's fix -
The kudos belong to James Bottomley btw. I did debugging and testing,
but James gave me the final hint to the solution then...
> but the build hangs indefinitely. I've no objection to it being
> retried again of course (and I'm not the buildd admin anyway) - I just
> want to set your expectations.
I tried a few times now to find the bug. I'm not sure if it's really due to
a) a kernel bug (probably)
b) the fact that hppa still uses Linuxthreads (although Dann mentioned
in another mail that he saw similar problems with another server which
used NPTL instead of Linuxthreads)
c) wrong pthread coding in ruby1.9
If it's due to a) (kernel bug), then it's hard to find and track down.
I concentrated on b) and c) for now. LT uses a few signals to synchronize the
threads, and ruby plays some small but bad games with signals in it's code, e.g.
rb_disable_interrupt() and rb_enable_interrupt() in signal.c.
With the attached patch/hack below I tried to work around possible LT-related
cornercases
in ruby1.9, but the issue stays the same: "make test" will make the ruby
testsuite hang in the "test_thread.rb" test. It seems some thread is waiting
for a signal which will not arrive, since the other thread is a zombie
already
Anyway, it would be nice if someone with ruby knowledge could reduce
the testsuite, so that it will be easier to reproduce the bug. I'm a little
lost at this stage. Now since the hppa kernel doesn't crash any longer, building
such a testcase should be much easier to create.
Helge
--- ./signal.c.org 2009-02-05 11:16:23.0 +0100
+++ ./signal.c 2009-02-05 20:52:38.0 +0100
@@ -36,6 +36,46 @@
# endif
#endif
+/* ruby1.9 is a multithreaded program.
+ Nevertheless, ruby1.9 uses sigprocmask() which has unspecified
+ behaviour in a multi-threaded process (see man page!).
+ */
+static void ruby_generate_sigprocmask(int how, sigset_t *mask, sigset_t *oldset)
+{
+ /* make sure that ruby does not block the Linuxthreads
+ signals */
+ if (how == SIG_BLOCK) {
+ sigdelset(mask, __SIGRTMIN);
+ sigdelset(mask, __SIGRTMIN+1);
+ sigdelset(mask, __SIGRTMIN+2);
+ } else if (how == SIG_SETMASK) {
+ sigaddset(mask, __SIGRTMIN);
+ sigaddset(mask, __SIGRTMIN+1);
+ sigaddset(mask, __SIGRTMIN+2);
+ } else { // SIG_UNBLOCK
+ sigaddset(mask, __SIGRTMIN);
+ sigaddset(mask, __SIGRTMIN+1);
+ sigaddset(mask, __SIGRTMIN+2);
+ }
+}
+
+static int ruby_pthread_sigprocmask(int how, sigset_t *mask, sigset_t *oldset)
+{
+ ruby_generate_sigprocmask(how, mask, oldset);
+ return pthread_sigmask(how,mask,oldset);
+}
+
+static int ruby_sigprocmask(int how, sigset_t *mask, sigset_t *oldset)
+{
+#if 0
+ return ruby_pthread_sigprocmask(how, mask, oldset);
+#else
+ ruby_generate_sigprocmask(how, mask, oldset);
+ /* XXX: ruby should not use sigprocmask(). */
+ return sigprocmask(how,mask,oldset);
+#endif
+}
+
static const struct signals {
const char *signm;
int signo;
@@ -430,7 +470,6 @@ static sighandler_t
ruby_signal(int signum, sighandler_t handler)
{
struct sigaction sigact, old;
-
#if 0
rb_trap_accept_nativethreads[signum] = 0;
#endif
@@ -448,6 +487,10 @@ ruby_signal(int signum, sighandler_t han
if (signum == SIGCHLD && handler == SIG_IGN)
sigact.sa_flags |= SA_NOCLDWAIT;
#endif
+
+//printf("signal: %d (%d), %p\n", signum, __SIGRTMIN, handler);
+if (signum >= __SIGRTMIN && signum <= __SIGRTMIN+2)
+ return NULL;
sigaction(signum, &sigact, &old);
return old.sa_handler;
}
@@ -505,7 +548,7 @@ rb_disable_interrupt(void)
sigfillset(&mask);
sigdelset(&mask, SIGVTALRM);
sigdelset(&mask, SIGSEGV);
-pthread_sigmask(SIG_SETMASK, &mask, NULL);
+ruby_pthread_sigprocmask(SIG_SETMASK, &mask, NULL);
#endif
}
@@ -515,7 +558,7 @@ rb_enable_interrupt(void)
#ifndef _WIN32
sigset_t mask;
sigemptyset(&mask);
-pthread_sigmask(SIG_SETMASK, &mask, NULL);
+ruby_pthread_sigprocmask(SIG_SETMASK, &mask, NULL);
#endif
}
@@ -852,7 +895,7 @@ trap_ensure(struct trap_arg *arg)
{
/* enable interrupt */
#ifdef HAVE_SIGPROCMASK
-sigprocmask(SIG_SETMASK, &arg->mask, NULL);
+ruby_sigprocmask(SIG_SETMASK, &arg->mask, NULL);
#else
sigsetmask(arg->mask);
#endif
@@ -866,7 +909,7 @@ rb_trap_restore_mask(void)
{
#if USE_TRAP_MASK
# ifdef HAVE_SIGPROCMASK
-sigprocmask(SIG_SETMASK, &trap_last_mask, NULL);
+ruby_sigprocmask(SIG_SETMASK, &trap_last_mask, NULL);
# else
sigsetmask(trap_last_mask);
# endif
@@ -931,7
Re: HPPA and lenny (ruby1.9 build problems)
dann frazier wrote:
> On Tue, Jan 06, 2009 at 12:46:34AM +0100, Helge Deller wrote:
>> CC: linux-paric mailing list
>>
>> Peter Palfrader wrote:
>>> On Mon, 05 Jan 2009, dann frazier wrote:
>>>
>>>> On Tue, Dec 23, 2008 at 11:43:22AM +0100, Helge Deller wrote:
>>>>> Peter Palfrader wrote:
>>>>>> Helge Deller schrieb am Dienstag, dem 23. Dezember 2008:
>>>>>>
>>>>>>> Patch in parisc git tree:
>>>>>>> http://git.kernel.org/?p=linux/kernel/git/kyle/parisc-2.6.git;a=commitdiff;h=378fe7c4cc619b561409206605c723c05358edac;hp=6c4dfa8f8bcf032137aacb3640d7dd9d75b2b607
>>>>>> So just using an SMP kernel should also work?
>>>>> Probably yes, since some other developers tried initially to reproduce
>>>>> the problem, but they couldn't (as it seems they were running on newer
>>>>> SMP machines). But I don't have a SMP server which is why I can't test
>>>>> myself...
>>>> Unfortunately, it looks like we're still having problems on the
>>>> buildds w/ 2.6.26 SMP kernels:
>>>>
>>>> http://buildd.debian.org/build.php?&pkg=ruby1.9&ver=1.9.0.2-9&arch=hppa&file=log
>>>>
>>>> The build doesn't take the system down, but does still hang
>>>> indefinitely while running miniruby - though the hang location varies.
>>>>
>>>> I'll prepare a UP kernel for one of the buildds w/ the
>>>> up-optimization-removal patch just to see if it improves things. I
>>>> don't see why it would, other than it seemed to solve the problem on
>>>> my test box when I first tested the patch.
>> It seemed to fix the problem for me as well.
>
> fyi, I tested w/ a 2.6.26 32-bit UP kernel w/ the
> up-optimization-removal patch, and received another hang:
>
> http://buildd.debian.org/fetch.cgi?pkg=ruby1.9;ver=1.9.0.2-9;arch=hppa;stamp=1231212073
Yes, that's the same I can reproduce here as well.
It's AFAICS not the ProtectionID trap kernel bug any longer, which is good :-)
>> In principle looking at the logs it looks more like a userspace bugs
>> due to threading functions.
>> Anyway, I'll try to reproduce it here as well.
>> FWIW, I had some additional irq locking code in load_context(), maybe
>> this helps...?
>
> I'd be happy to test it if you can point me to a changeset.
Sorry, nothing yet.
As it does not seem to be related to the Protection ID trap, they are probably
useless anyway.
Overall, this is what I see when running dpkg-buildpackage for ruby1.9:
test_load.rb .
test_exception.rb
test_thread.rb .
r...@c3000:~/cvs/ruby/ruby1.9-1.9.0.2# ps -efww
root 15817 15815 0 13:36 pts/000:00:00 /usr/bin/perl
/usr/bin/dpkg-buildpackage
root 25673 3 0 14:56 pts/000:00:00
/mnt/sdb4/cvs/ruby/ruby1.9-1.9.0.2/miniruby
-I/mnt/sdb4/cvs/ruby/ruby1.9-1.9.0.2/lib
-I/mnt/sdb4/cvs/ruby/ruby1.9-1.9.0.2/.ext/common -I./-
-r/mnt/sdb4/cvs/ruby/ruby1.9-1.9.0.2/ext/purelib.rb -W0 bootstraptest.tmp.rb
root 25676 25673 0 14:56 pts/000:00:00 [miniruby]
root 25892 2014 0 17:16 pts/100:00:00 ps -efwww
root 29832 15817 0 14:46 pts/000:00:00 /usr/bin/make -f debian/rules
binary
root 32188 29832 0 14:55 pts/000:00:00 make test
root 3 32188 0 14:55 pts/000:00:00 ./miniruby -I./lib
-I.ext/common -I./- -r./ext/purelib.rb ./bootstraptest/runner.rb
--ruby=./miniruby -I./lib -I.ext/common -I./- -r./ext/purelib.rb -q
root 32223 3 0 14:55 pts/000:00:00 ./miniruby -I./lib
-I.ext/common -I./- -r./ext/purelib.rb ./bootstraptest/runner.rb
--ruby=./miniruby -I./lib -I.ext/common -I./- -r./ext/purelib.rb -q
root 32224 32223 0 14:55 pts/000:00:00 ./miniruby -I./lib
-I.ext/common -I./- -r./ext/purelib.rb ./bootstraptest/runner.rb
--ruby=./miniruby -I./lib -I.ext/common -I./- -r./ext/purelib.rb -q
r...@c3000:~/cvs/ruby/ruby1.9-1.9.0.2# strace -p 3
Process 3 attached - interrupt to quit
_newselect(7, [6], NULL, NULL, NULL^C
Process 3 detached
r...@c3000:~/cvs/ruby/ruby1.9-1.9.0.2# strace -p 32223
Process 32223 attached - interrupt to quit
restart_syscall(<... resuming interrupted call ...>) = 0
getppid() = 3
poll([{fd=3, events=POLLIN}], 1, 2000) = 0 (Timeout)
getppid() = 3
poll([{fd=3, events=POLLIN}], 1, 2000^C
Process 32223 detached
r...@c3000:~/cvs/ruby/ruby1.9-1.9.0.2# strace -p 32224
Process 32224 attached - interrupt to quit
nanosleep({0, 1000}, {0, 7191145}) = 0
nanosleep({0, 1000}, {0, 7191145}) = 0
nanosleep({0, 1000}, {0, 71911
Re: HPPA and lenny (ruby1.9 build problems)
CC: linux-paric mailing list Peter Palfrader wrote: > On Mon, 05 Jan 2009, dann frazier wrote: > >> On Tue, Dec 23, 2008 at 11:43:22AM +0100, Helge Deller wrote: >>> Peter Palfrader wrote: >>>> Helge Deller schrieb am Dienstag, dem 23. Dezember 2008: >>>> >>>>> Patch in parisc git tree: >>>>> http://git.kernel.org/?p=linux/kernel/git/kyle/parisc-2.6.git;a=commitdiff;h=378fe7c4cc619b561409206605c723c05358edac;hp=6c4dfa8f8bcf032137aacb3640d7dd9d75b2b607 >>>> So just using an SMP kernel should also work? >>> Probably yes, since some other developers tried initially to reproduce >>> the problem, but they couldn't (as it seems they were running on newer >>> SMP machines). But I don't have a SMP server which is why I can't test >>> myself... >> Unfortunately, it looks like we're still having problems on the >> buildds w/ 2.6.26 SMP kernels: >> >> http://buildd.debian.org/build.php?&pkg=ruby1.9&ver=1.9.0.2-9&arch=hppa&file=log >> >> The build doesn't take the system down, but does still hang >> indefinitely while running miniruby - though the hang location varies. >> >> I'll prepare a UP kernel for one of the buildds w/ the >> up-optimization-removal patch just to see if it improves things. I >> don't see why it would, other than it seemed to solve the problem on >> my test box when I first tested the patch. It seemed to fix the problem for me as well. In principle looking at the logs it looks more like a userspace bugs due to threading functions. Anyway, I'll try to reproduce it here as well. FWIW, I had some additional irq locking code in load_context(), maybe this helps...? > Yeah, penalosa got stuck again today, this was on the console: Does panalosa has the patched kernel (same one as the one on peri) ? The protection ID traps shouldn't happen any longer, and from the buildd logs on peri it does seem like that the ProtID traps don't happen there. Helge > ... > [18255061.952000] > > [18255240.024000] install (pid 15737): Protection id trap (code 27) at > 4038d203 > > [18255240.116000] Backtrace: > > [18255240.148000] > > [18255258.72] dpkg-deb (pid 15897): Protection id trap (code 27) at > > 4035defb > > [18255258.812000] Backtrace: > > [18255258.844000] > > [18260696.284000] dpkg-deb (pid 13540): Protection id trap (code 27) at > > 00026f1b > > [18260696.376000] Backtrace: > > [18260696.408000] > > [18289955.716000] [ cut here ] > > [18289955.776000] kernel BUG at fs/inode.c:262! I think this bug is unrelated to the ruby1.9 issue. > [18289955.824000] > > [18289955.848000] YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI > > [18289955.908000] PSW: 1100 Tainted: G D > > [18289955.988000] r00-03 00ff0804ff0f 401e7888 401e78a4 > a7d1d750 > > [18289956.084000] r04-07 405c9660 a7d1d750 404a5d40 > 00012db86400 > > [18289956.184000] r08-11 f000 00017800 000dc2f7 > 00012f871828 > > [18289956.284000] r12-15 7f9d7000 000e7d58 81a4 > 0001 > > [18289956.384000] r16-19 000ad800 000ad800 000f4648 > 40501e4c > > [18289956.48] r20-23 080f 080f 00012e623b40 > > > [18289956
Re: HPPA and lenny
Peter Palfrader wrote: > Helge Deller schrieb am Dienstag, dem 23. Dezember 2008: > >> Patch in parisc git tree: >> http://git.kernel.org/?p=linux/kernel/git/kyle/parisc-2.6.git;a=commitdiff;h=378fe7c4cc619b561409206605c723c05358edac;hp=6c4dfa8f8bcf032137aacb3640d7dd9d75b2b607 > > So just using an SMP kernel should also work? Probably yes, since some other developers tried initially to reproduce the problem, but they couldn't (as it seems they were running on newer SMP machines). But I don't have a SMP server which is why I can't test myself... Helge -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: HPPA and lenny
dann frazier wrote: > On Wed, Dec 17, 2008 at 11:08:59PM +0100, Helge Deller wrote: >> dann frazier wrote: >>> On Mon, Dec 15, 2008 at 08:30:25PM +0100, Peter Palfrader wrote: >>>> Helge Deller schrieb am Montag, dem 15. Dezember 2008: >>>> >>>>> Matt Taggart wrote: >>>>>> The real problem is that no one is fixing hppa kernel problems. I don't >>>>>> see >>>>>> much point in keeping the archive up to date if nobody is working on >>>>>> fixing >>>>>> the kernel (not currently and I suspect not in the future either). This >>>>>> has >>>>>> been stated on the debian-hppa list several times over a long period and >>>>>> in >>>>>> that time no one (AFAIK) has stepped up to work on it. >>>>> Matt, >>>>> >>>>> We have done quite some bugfixing in the last weeks and upstream >>>>> 2.6.28-rcX works pretty well now. >>>> What does that mean for the lenny 2.6.26 kernel? >>> Well, obviously when there's a fix upstream we will look at >>> backporting this into 2.6.26. >> I've just posted a short analysis of the problem and a proposed kernel >> patch in: >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=478717#118 >> >> It fixes the kernel crashes for me and should help to do further >> analysis without crashing the running linux kernel. >> >> The patch (and the problem) needs further discussion on parisc-linux >> kernel mailing list though... > > Thanks Helge! Just in case its relevant to your investigation, note > that this is also an issue when using a pure NPTL environment. Just wanted to give a short update - After quite some debugging by various parisc kernel developers, it seems that buggy TLB flushing code was causing the ruby1.9 build failures / kernel crashes and we developed a workaround for now: 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 I assume this patch solves quite some other issues which were seen as well. It would be really nice, if this (preliminary) patch could be included in the debian parisc kernel soon... I'll update bugzilla 478717 as well. Helge -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: HPPA and lenny
dann frazier wrote: > On Mon, Dec 15, 2008 at 08:30:25PM +0100, Peter Palfrader wrote: >> Helge Deller schrieb am Montag, dem 15. Dezember 2008: >> >>> Matt Taggart wrote: >>>> The real problem is that no one is fixing hppa kernel problems. I don't >>>> see >>>> much point in keeping the archive up to date if nobody is working on >>>> fixing >>>> the kernel (not currently and I suspect not in the future either). This >>>> has >>>> been stated on the debian-hppa list several times over a long period and >>>> in >>>> that time no one (AFAIK) has stepped up to work on it. >>> Matt, >>> >>> We have done quite some bugfixing in the last weeks and upstream >>> 2.6.28-rcX works pretty well now. >> What does that mean for the lenny 2.6.26 kernel? > > Well, obviously when there's a fix upstream we will look at > backporting this into 2.6.26. I've just posted a short analysis of the problem and a proposed kernel patch in: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=478717#118 It fixes the kernel crashes for me and should help to do further analysis without crashing the running linux kernel. The patch (and the problem) needs further discussion on parisc-linux kernel mailing list though... Helge -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: HPPA and lenny
Matt Taggart wrote: > The real problem is that no one is fixing hppa kernel problems. I don't see > much point in keeping the archive up to date if nobody is working on fixing > the kernel (not currently and I suspect not in the future either). This has > been stated on the debian-hppa list several times over a long period and in > that time no one (AFAIK) has stepped up to work on it. Matt, We have done quite some bugfixing in the last weeks and upstream 2.6.28-rcX works pretty well now. The only problem I'm facing personally right now, is that the kernel might hang on a spinlock (network/cache-flushing) when I compile a special (commercial) application on hppa. I assume this is the same bug which happens with the compilation of ruby. I'll test tonight and I've already some ideas on how to track this bug. That said, I agree that things are not 100% perfect, but it isn't as bad either... Helge -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: hppa in lenny? (Was: Freeze exceptions related to libdb-ruby)
dann frazier wrote:
On Sun, Aug 17, 2008 at 01:14:01AM +0200, Helge Deller wrote:
Adeodato Sim?? wrote:
I just looked into ruby19 on hppa.
The makecontext()/setcontext()/switchcontext() functions which went into
libc-ports recently [*2] will not help here.
Instead, I think only when at some point the glibc on hppa switches to
NPTL, ruby could work.
hey Helge!
fyi, John Wright and I have had a buildd running w/ an NPTL glibc for
a while, and we're not having any better luck with ruby1.9 builds -
they seem to fail just as before ('miniruby' spinning indefinitely).
In general, I haven't noticed any better or worse behavior between
linuxthread/NPTL buildds.
Hi Dan,
Thanks for testing it! That's interesting. It was always my assumption,
that NPTL would fix a few problems. If this is not the case, then it's
time to look into the glibc/linuxthreads/NPTL coding again. I'll try to
find some time this week to analyze that, but sadly debugging
thread-issues is not easy nor really funny :-(
Helge
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hppa in lenny? (Was: Freeze exceptions related to libdb-ruby)
Adeodato Simó wrote: * Lucas Nussbaum [Sat, 16 Aug 2008 14:10:16 -0300]: ruby1.9 is broken on hppa: 1.9.0.1, that previously built fine (it's in the archive) exhibits the same problems as 1.9.0.2 and 1.9.0.3. I spent hours trying to do the hppa porters' work by investigating the ruby1.9 build failure, with no success (and no help from the hppa porters, except giving me access to an hppa machine, since hppa doesn't have any developer-accessible machine maintained by DSA). In [1], the state of hppa was already raised, and, while no real conclusion has been drawn from this thread, it seems that, while most people involved on hppa find it very sad (which I agree with), the right thing to do is to drop hppa from the list of official archs for lenny, since it's unlikely to be a "good" stable arch. So far, I haven't heard any official position from the release team about that, hppa has certainly had trouble during this release cycle. However, it's been mostly reduced to a small set of packages, and since (a) it has not been the kind of brekage that prevents the release team from doing their job (alpha buildd outages eg. have been more painful), and (b) the architecture is not generally broken, it was decided not to use /our/ veto power to kick it out of lenny. (No decision taken for lenny+1 in either direction, though.) I realize the ruby1.9 situation is frustrating, but I don't think it's fair to drop hppa from lenny because of it. I don't think your "it's unlikely to be a 'good' stable arch" is true either. Otoh, it's really commendable, and I mean it, that you decided to spend your time towards having it fixed, rather than just kill ruby1.9 on hppa as I suggested (which is, tbh, what I would've done in your position). It really sucks that no hppa person is available to help, but my opinion is that's still more valuable to release with hppa without ruby1.9 there, than to drop hppa completely. So, what I would like from a release POV is to wait at most for this glibc -14 upload with context-fu on hppa that somebody somewhere said could fix the issue, I just looked into ruby19 on hppa. The makecontext()/setcontext()/switchcontext() functions which went into libc-ports recently [*2] will not help here. Instead, I think only when at some point the glibc on hppa switches to NPTL, ruby could work. [*2] http://permalink.gmane.org/gmane.comp.lib.glibc.cvs/25637 > and if it persists, to kill ruby1.9 on hppa so that we get that part of the archive on a releseable state. Probably the best idea, unless my hand-built (and partly buggy) ruby19 binaries on http://gsyprf10.external.hp.com/~deller/ruby/ may help (see my other mail on the debian-hppa list). [1] http://lists.debian.org/debian-hppa/2008/07/msg00044.html Cheers, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hppa release status
CC'ed: parisc-linux kernel development list Andreas Barth wrote: during the upload of python2.5, the build failed on hppa due to stalls in the test suite, see http://bugs.debian.org/483042 and http://buildd.debian.org/fetch.cgi?&pkg=python2.5&ver=2.5.2-5&arch=hppa&stamp=1211583145&file=log (Matthias "fixed" that bug by disabling the testsuite, not something that makes us happy.) After that happened, we asked on #parisc if someone could take a look, and we were told that linuxthreads is currently unmaintained for hppa, and the issue could only be fixed by moving to nptl and we need to do an (incompatible) abi change in glibc. Such a change would be really unfortunate, and we hope that every other roads have been evaluated first (like trying to understand why python on linuxthreads fails on hppa but not on e.g. kfreebsd). We also would like to be sure that ntpl is really better than linuxthreads for python2.5 before a transition. My personal feeling is, that a switch to NPTL is probably the best solution. Even if this involves a abi change. Maybe experts on NPTL could comment here? In addition to the python2.5 issue, there are two other issues that are quite concerning: * a problem with ruby1.9 which likely is kernel related #478717. Hmm.. * dirmngr that segfaults, likely because of some signalstack issues #459567. Yes, we need to implement makecontext()/getcontext() in glibc. We've seen no porter activity on those bugs yet. I'd volunteer to try on thedirmngr/makecontext() issue. (At least as far as my time permits). On further discussing that within the release team, we noticed that the Qualification page on http://wiki.debian.org/hppaLennyReleaseRecertification is not really complete, e.g. it says: | The installer is being maintained by ... and it's currently working | effectively. Successful installation reports are available at: ... It would really be great (read: it is necessary) that the Qualification Page is filled with the missing information, and that we actually have enough porters for hppa. I've added myself there in a few items. I'd be willing to look into issues with the installer, but not being a active debian developer I'd need help from a debian guy if necessary. So, with respect to the python2.5 issue, what now? At the technical side, best of course would be if linuxthreads would continue to work at least enough for lenny, this was the case for a few years already, it should be able to survive a few months more, and python2.5 can build with the test-suite on hppa. Of course not breaking the API during a linuxthreads -> NPTL switch would be even better. I can't comment on that. If really you see no other option than switching to NPTL, even at the current unfortunate moment, the only way how this could be done in a timely fashion would be to exempt hppa from the list of architectures our testing migration scripts look at for updateness and non-breakness. Then upload glibc ASAP, and schedule an archive-wide binNMU campaign. Of course, this demands enough buildd power, and wanna-build access by (some of) the porters (or whatever else you consider appropriate). Moreover it needs quite a lot of time to track that closely, which the Release Team probably won't have on its own, so we will need hppa buildd-admin and hppa porters time, a lot. After the transition is done (and we can only hope it is in time for lenny), hppa could be added back to the normal architectures. Downside of this is of course that in case hppa is slower than lenny, lenny would be released without hppa. which would be sad... Of course, we also need plans for the ruby and dirmngr issues. Yes. So, after that long mail, what's your take on this? How do we continue? Any other comments? Helge -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
