for a while yet, to
give you a chance to decide whether you'd like to try and produce an
hppa/squeeze release and, if so, how you'd like to do that (e.g. by
talking to debian-ports or ftp-master).
Regards,
Adam
for the Release Team
[1] http://lists.debian.org/debian-hppa/2010/08/msg00064.html
On Sun, Jun 21, 2009 at 06:55:21PM -0400, Carlos O'Donell wrote:
On Tue, Jun 16, 2009 at 3:13 PM, Aurelien Jarnoaurel...@aurel32.net wrote:
On Tue, Jun 16, 2009 at 09:08:37PM +0200, Helge Deller wrote:
On 06/16/2009 08:25 AM, Lucas Nussbaum wrote:
On 15/06/09 at 11:31 -0600, Grant Grundler
On Sun, Jul 12, 2009 at 8:30 AM, Aurelien Jarnoaurel...@aurel32.net wrote:
I have just included these patches in the eglibc-2.10 branch of our SVN,
though currently the linuxthreads version is still built by default.
I got the following regressions in the NPTL build compared to the
On Mon, Jul 6, 2009 at 10:43 PM, dann frazierda...@dannf.org wrote:
da...@penalosa:~$ cat /proc/cpuinfo
processor : 0
cpu family : PA-RISC 2.0
cpu : PA8700 (PCX-W2)
cpu MHz : 750.00
model : 9000/785/J6700
model name :
On Mon, 2009-07-06 at 17:43 -0400, Kyle McMartin wrote:
On Mon, Jul 06, 2009 at 02:45:37PM -0400, John David Anglin wrote:
I have to think that this has something to do with the machine
being a rp3440 (large memory and cache). I have never seen this
on my c3750 with 32-bit UP kernel.
On Mon, 2009-07-06 at 21:47 -0400, John David Anglin wrote:
If I remember correctly, there's still some issues with the L2 cache on
pa8800 that we haven't quite bothered to work out yet, since it's good
enough for now. James probably knows more. It would be interesting to
see if you could
So if I characterise the problem you think you're seeing: on mmap of a
file at a memory location to be determined by the kernel, a sequential
set of reads of the mapped location eventually turns up a zero where
there should be data? Yes, it does sound like a caching issue.
Yes. The loop is
On Tue, Jul 7, 2009 at 12:21 PM, John David
Anglind...@hiauly1.hia.nrc.ca wrote:
So if I characterise the problem you think you're seeing: on mmap of a
file at a memory location to be determined by the kernel, a sequential
set of reads of the mapped location eventually turns up a zero where
On Tue, 07 Jul 2009, Carlos O'Donell wrote:
On Tue, Jul 7, 2009 at 12:21 PM, John David
Anglind...@hiauly1.hia.nrc.ca wrote:
So if I characterise the problem you think you're seeing: on mmap of a
file at a memory location to be determined by the kernel, a sequential
set of reads of the
On Tue, Jul 7, 2009 at 6:07 PM, John David
Anglind...@hiauly1.hia.nrc.ca wrote:
I would guess that the loop terminated early because the l_info array
is all zeros except for the first NEEDED entry. It appears correct. The
loop might have terminated early because of a cache issue, or possibly
On Tue, Jul 7, 2009 at 6:07 PM, John David
Anglind...@hiauly1.hia.nrc.ca wrote:
I would guess that the loop terminated early because the l_info array
is all zeros except for the first NEEDED entry. =A0It appears correct. =
=A0The
loop might have terminated early because of a cache issue,
I seem to recall that the kernel mmap implementation on hppa is somewhat
unique.
I don't recall anything, Kyle?
This came up with respect to the GCC PCH implementation for parisc. See
comments in host-hpux.h. At the moment, we do have a PCH related bug.
See PR
On Mon, Jul 6, 2009 at 9:28 AM, John David
Anglind...@hiauly1.hia.nrc.ca wrote:
Not that I am aware of. The situation is essentially the reverse of
the above. Data is written from a region of memory. Then, in another
instance of gcc, it needs to be mmap'ed back to the same location in
I will reiterate my point here that the dynamic linker the first user
of mmap in a newly started process, and the first program to read and
process data from the mmap'd files. Therefore the dynamic linker is
always the first to suffer if a mapped region of memory is not
correct.
That is true
On Mon, Jul 06, 2009 at 02:45:37PM -0400, John David Anglin wrote:
I have to think that this has something to do with the machine
being a rp3440 (large memory and cache). I have never seen this
on my c3750 with 32-bit UP kernel. Also, this was with a 64-bit
UP kernel.
If I remember
If I remember correctly, there's still some issues with the L2 cache on
pa8800 that we haven't quite bothered to work out yet, since it's good
enough for now. James probably knows more. It would be interesting to
see if you could reproduce it with a UP 64-bit kernel on your C3750 to
discount
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
On Sun, Jul 05, 2009 at 11:06:52AM +0200, Helge Deller wrote:
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
That way we all would avoid debian build problems and could concentrate
on solving the issues with the SMP kernel itself.
The problem actually may be present in UP kernels. I had a segv this
morning building GCC with a UP 2.6.30.1:
ad...@mx3210:~/gnu/gcc/objdir/hppa-linux/libjava$ gdb -c core
Register $r10 contains the address of the next link map:
(gdb) p (*preloads)-l_next
$10 = (struct link_map *) 0x4e88
(gdb) p *(*preloads)-l_next
$11 = {l_addr = 1076473856, l_name = 0x4e78 /lib/libdl.so.2,
l_ld = 0x4029e5fc, l_next = 0x40001118, l_prev = 0x4bf0,
l_real =
(gdb) p *(*preloads)-l_next
$11 = {l_addr = 1076473856, l_name = 0x4e78 /lib/libdl.so.2,
l_ld = 0x4029e5fc, l_next = 0x40001118, l_prev = 0x4bf0,
l_real = 0x4e88, l_ns = 0, l_libname = 0x400010dc, l_info = {0x0,
0x4029e5fc, 0x0 repeats 74 times}, l_phdr = 0x4029b034,
On Sun, Jul 5, 2009 at 1:19 PM, John David
Anglind...@hiauly1.hia.nrc.ca wrote:
Carlos, what do you think?
I think the dynamic linker is always the first to touch the mmap'd
file and therefore the most likely to fail if something is wrong in
our VM layer.
Cheers,
Carlos.
--
To UNSUBSCRIBE,
On Sun, Jul 5, 2009 at 7:07 PM, John David
Anglind...@hiauly1.hia.nrc.ca wrote:
After staring at the dynamic loader code for a while, I think the following
mmap call in dl-load.c doesn't correctly map the info data for
/lib/libdl.so.2.
/* Remember which part of the address space this
The info data is near the end of the mapped segment. =A0The l_info field
is initialized by elf_get_dynamic_info from the dynamic data mapped
at l-ld.
Why do you think this is wrong?
I don't know about the specifics. My supposition is that we may not
be copying the entire segment
On Sun, 2009-07-05 at 20:17 -0400, John David Anglin wrote:
The info data is near the end of the mapped segment. =A0The l_info field
is initialized by elf_get_dynamic_info from the dynamic data mapped
at l-ld.
Why do you think this is wrong?
I don't know about the specifics. My
On Sun, 2009-07-05 at 20:17 -0400, John David Anglin wrote:
The info data is near the end of the mapped segment. =A0The l_info field
is initialized by elf_get_dynamic_info from the dynamic data mapped
at l-ld.
Why do you think this is wrong?
I don't know about the
On Sun, Jul 5, 2009 at 1:19 PM, John David
Anglind...@hiauly1.hia.nrc.ca wrote:
Carlos, what do you think?
I think the dynamic linker is always the first to touch the mmap'd
file and therefore the most likely to fail if something is wrong in
our VM layer.
From the core dump, this is the
I seem to recall that the kernel mmap implementation on hppa is somewhat
unique.
I don't recall anything, Kyle?
This came up with respect to the GCC PCH implementation for parisc. See
comments in host-hpux.h. At the moment, we do have a PCH related bug.
See PR 39355.
And then there is glob2 that fails with:
/usr/bin/ld: libgag/src/libgag.a(FileManager.o)(.text+0x2fc8): cannot reach
f9bf_memcpy@@GLIBC_2.2+0, recompile with -ffunction-sections
/usr/bin/ld: libgag/src/libgag.a(FileManager.o)(.text+0x2fc8): cannot handle
R_PARISC_PCREL17F for
On Sat, Jul 04, 2009 at 11:03:01PM +0200, Kurt Roeckx wrote:
On Sat, Jul 04, 2009 at 03:52:16PM -0400, John David Anglin wrote:
And then there is glob2 that fails with:
/usr/bin/ld: libgag/src/libgag.a(FileManager.o)(.text+0x2fc8): cannot
reach f9bf_memcpy@@GLIBC_2.2+0, recompile
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
On Fri, Jun 19, 2009 at 05:43:24PM +0200, Philipp Kern wrote:
On Fri, Jun 19, 2009 at 05:15:26PM +0200, Kurt Roeckx wrote:
Here is a list of packages that failed to build because of instability
on the buildds today:
package | buildd | error
qgit| penalosa | make: ***
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?
Kind regards,
Philipp Kern
--
.''`. Philipp KernDebian Developer
: :' : http://philkern.de
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
On Thu, 2009-06-25 at 10:10 +0200, Matthias Klose wrote:
Mike Hommey schrieb:
On Thu, Jun 25, 2009 at 01:32:09AM +0200, Matthias Klose wrote:
Luk Claes schrieb:
Matthias Klose wrote:
Grant Grundler schrieb:
On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote:
Grant Grundler
Mike Hommey schrieb:
On Thu, Jun 25, 2009 at 01:32:09AM +0200, Matthias Klose wrote:
Luk Claes schrieb:
Matthias Klose wrote:
Grant Grundler schrieb:
On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote:
Grant Grundler wrote:
On Tue, Jun 02, 2009 at 03:07:35PM +0100, Neil McGovern
Luk Claes schrieb:
Matthias Klose wrote:
Grant Grundler schrieb:
On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote:
Grant Grundler wrote:
On Tue, Jun 02, 2009 at 03:07:35PM +0100, Neil McGovern wrote:
http://lists.debian.org/debian-release/2009/04/msg00303.html
Note that
On Thu, Jun 25, 2009 at 01:32:09AM +0200, Matthias Klose wrote:
Luk Claes schrieb:
Matthias Klose wrote:
Grant Grundler schrieb:
On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote:
Grant Grundler wrote:
On Tue, Jun 02, 2009 at 03:07:35PM +0100, Neil McGovern wrote:
On Tue, Jun 16, 2009 at 3:13 PM, Aurelien Jarnoaurel...@aurel32.net wrote:
On Tue, Jun 16, 2009 at 09:08:37PM +0200, Helge Deller wrote:
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,
On Fri, Jun 19, 2009 at 05:15:26PM +0200, Kurt Roeckx wrote:
So it's my understanding that the porters have no idea about the
problems. So I will start to mail you about problems as soon
as I see them and they look like porting issues specific
to hppa.
netgen fails to built with an internal
On Fri, Jun 19, 2009 at 05:15:26PM +0200, Kurt Roeckx wrote:
So it's my understanding that the porters have no idea about the
problems. So I will start to mail you about problems as soon
as I see them and they look like porting issues specific
to hppa.
Ruby1.9 hangs in test_thread.rb and
On Sat, Jun 20, 2009 at 4:39 PM, Kurt Roeckxk...@roeckx.be wrote:
On Fri, Jun 19, 2009 at 05:15:26PM +0200, Kurt Roeckx wrote:
So it's my understanding that the porters have no idea about the
problems. So I will start to mail you about problems as soon
as I see them and they look like porting
On Fri, Jun 19, 2009 at 05:15:26PM +0200, Kurt Roeckx wrote:
So it's my understanding that the porters have no idea about the
problems. So I will start to mail you about problems as soon
as I see them and they look like porting issues specific
to hppa.
netgen fails to built with an
On Sat, Jun 20, 2009 at 12:02:54PM -0400, John David Anglin wrote:
On Fri, Jun 19, 2009 at 05:15:26PM +0200, Kurt Roeckx wrote:
So it's my understanding that the porters have no idea about the
problems. So I will start to mail you about problems as soon
as I see them and they look like
On Sat, Jun 20, 2009 at 07:48:38PM +0200, Kurt Roeckx wrote:
...
I know how to file gcc bugs. I've just filed one. I didn't
have time to try and reduce the testcase, and I can't try
different versions of g++ yet. I've asked to have different
versions installed on paer.
The bug report is
I've never been able to file any (non-automated) bug report in
5 minutes. And if you don't even have direct access to the
hardware it takes longer.
I agree. I'm trying to build netgen here too and if the ICE is easy to
reproduce, can make that available to danglin and add to the
On Fri, Jun 19, 2009 at 05:15:26PM +0200, Kurt Roeckx wrote:
Here is a list of packages that failed to build because of instability
on the buildds today:
package | buildd | error
qgit| penalosa | make: *** [install] Segmentation fault
acpica-unix | peri | make: ***
On Sat, Jun 20, 2009 at 06:25:20PM -0400, John David Anglin wrote:
I've never been able to file any (non-automated) bug report in
5 minutes. And if you don't even have direct access to the
hardware it takes longer.
I agree. I'm trying to build netgen here too and if the ICE is easy
I've pretty much localized the problem. It's a GCC middle-end bug.
The problem is in passing a complex double from a thunk. The hppa
specification says that values larger than 64 bits are passed by
reference in the 32-bit runtime. However, the value is in a pair
of registers and not
Hmm...
It's right that some of my comments are rather harsh, though you must
know that I'm not speaking from a personal perspective.
Personally (and as Release Manager), I would be very happy to have a
good working hppa port for Squeeze and beyond.
I made sure that the hppa port was included
not speaking from a personal perspective.
Personally (and as Release Manager), I would be very happy to have a
good working hppa port for Squeeze and beyond.
I made sure that the hppa port was included into Lenny even when the
Debian System Administrators (DSA), package maintainers, release team
On Fri, Jun 19, 2009 at 05:15:26PM +0200, Kurt Roeckx wrote:
Here is a list of packages that failed to build because of instability
on the buildds today:
package | buildd | error
qgit| penalosa | make: *** [install] Segmentation fault
acpica-unix | peri | make: *** [install]
Matthias Klose wrote:
Grant Grundler schrieb:
On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote:
Grant Grundler wrote:
On Tue, Jun 02, 2009 at 03:07:35PM +0100, Neil McGovern wrote:
http://lists.debian.org/debian-release/2009/04/msg00303.html
Note that it's wrong to assume we
John David Anglin wrote:
Grant Grundler schrieb:
On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote:
Grant Grundler wrote:
I can understand the desire to trim architectures. However, it's clear
the current decision was based on some misinformation, and an unclear
rational.
There is
considering dropping support for HPPA in Squeeze. Please
reconsider.
randolph
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
On Thu, Jun 18, 2009 at 8:33 AM, Luk Claesl...@debian.org wrote:
John David Anglin wrote:
Grant Grundler schrieb:
On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote:
Grant Grundler wrote:
I can understand the desire to trim architectures. However, it's clear
the current decision was
It's very easy to tell there is nothing wrong when you don't have to
deal with unreliable build daemons, endless discussions but no visible
progress (except for java support) and complaints from DSA, package
maintainers and others.
The problem with the build daemons may be a buggy version of
Thibaut VARENE wrote:
On Thu, Jun 18, 2009 at 8:33 AM, Luk Claesl...@debian.org wrote:
John David Anglin wrote:
Grant Grundler schrieb:
On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote:
Grant Grundler wrote:
I can understand the desire to trim architectures. However, it's clear
Randolph Chung wrote:
Luk,
There is no desire to trim working architectures.
It's very easy to tell there is nothing wrong when you don't have to
deal with unreliable build daemons, endless discussions but no visible
progress (except for java support) and complaints from DSA, package
On Tue, Jun 16, 2009 at 3:13 PM, Aurelien Jarnoaurel...@aurel32.net wrote:
On Tue, Jun 16, 2009 at 09:08:37PM +0200, Helge Deller wrote:
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,
On Tue, Jun 16, 2009 at 05:13:44PM -0600, dann frazier wrote:
On Wed, Jun 17, 2009 at 12:01:31AM +0100, Stephen Gran wrote:
This one time, at band camp, dann frazier said:
Are we still having random segfaults on paer? If so - that's be a good
one to resolve. Not sure if DSA would be
Grant Grundler schrieb:
On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote:
Grant Grundler wrote:
+linux-parisc (hppa kernel, compiler and !debian tech forum)
Neil,
thanks for the summary. I know this is an unpleasant business in general.
On Tue, Jun 02, 2009 at 03:07:35PM +0100,
Grant Grundler schrieb:
On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote:
Grant Grundler wrote:
+linux-parisc (hppa kernel, compiler and !debian tech forum)
Neil,
thanks for the summary. I know this is an unpleasant business in general.
On Tue, Jun 02, 2009 at 03:07:35PM
On 15/06/09 at 11:31 -0600, Grant Grundler wrote:
I was expecting a summary of specific issues from an organization
that claims to operate transperently. The hand waving is easy. But
doesn't resolve problems and doesn't meet my expectation of an open
organization that I've donated money,
On Tue, Jun 16, 2009 at 09:08:37PM +0200, Helge Deller wrote:
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,
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.9ver=1.9.0.1-5arch=hppastamp=1213563978file=logas=raw
might be a good candidate.
In reality
On Tue, Jun 16, 2009 at 08:25:31AM +0200, Lucas Nussbaum wrote:
...
BTW, that firewall was reviewed and approved by Lamont (a pretty well
known DD and buildd maintainer).
Thibaut Varene (who is a DD) has offered to host HPPA buildd machines
as well but hasn't heard any response to that
On Tue, Jun 16, 2009 at 02:50:27PM -0600, Grant Grundler wrote:
On Tue, Jun 16, 2009 at 08:25:31AM +0200, Lucas Nussbaum wrote:
...
BTW, that firewall was reviewed and approved by Lamont (a pretty well
known DD and buildd maintainer).
Thibaut Varene (who is a DD) has offered to host
This one time, at band camp, dann frazier said:
Are we still having random segfaults on paer? If so - that's be a good
one to resolve. Not sure if DSA would be willing to grant (heh) you
access to that box, or if we should try running a dummy buildd on
another rp2470.
We're running paer on a
On Wed, Jun 17, 2009 at 12:01:31AM +0100, Stephen Gran wrote:
This one time, at band camp, dann frazier said:
Are we still having random segfaults on paer? If so - that's be a good
one to resolve. Not sure if DSA would be willing to grant (heh) you
access to that box, or if we should try
On Fri, Jun 12, 2009 at 08:49:26AM +0200, Luk Claes wrote:
Grant Grundler wrote:
+linux-parisc (hppa kernel, compiler and !debian tech forum)
Neil,
thanks for the summary. I know this is an unpleasant business in general.
On Tue, Jun 02, 2009 at 03:07:35PM +0100, Neil McGovern
On Sun, Jun 14, 2009 at 08:29:14PM +0200, Thibaut VARENE wrote:
On Fri, Jun 12, 2009 at 5:35 PM, dann frazierda...@dannf.org wrote:
On Fri, Jun 12, 2009 at 09:16:25AM -0500, James Bottomley wrote:
It seems to be related to what machine you actually have.
And the load - buildds for
On Fri, Jun 12, 2009 at 5:35 PM, dann frazierda...@dannf.org wrote:
On Fri, Jun 12, 2009 at 09:16:25AM -0500, James Bottomley wrote:
It seems to be related to what machine you actually have.
And the load - buildds for unstable seem to trip over issues that we
don't see elsewhere.
Workload
dann frazier wrote:
On Fri, Jun 12, 2009 at 09:16:25AM -0500, James Bottomley wrote:
Just to say that I'm personally not so unhappy with deb hppa, and
that not everything is bad.
I think the main class of problem machines are anything with SMP ...
unfortunately, I don't have one,
Grant Grundler wrote:
+linux-parisc (hppa kernel, compiler and !debian tech forum)
Neil,
thanks for the summary. I know this is an unpleasant business in general.
On Tue, Jun 02, 2009 at 03:07:35PM +0100, Neil McGovern wrote:
Hi,
As mentioned previously[0], the release team haven't been
Hello all,
Everybody is talking about the 'random crashes' and 'segfaults' in the HPPA
version.
Over here I'm using the hppa on a small HP-UX workstation, and that has an
uptime of 542 days!.
So it's not that unstable.
I even need to say that I had a lot more crashes with the x86 version then
Hello all,
Everybody is talking about the 'random crashes' and 'segfaults' in
the HPPA version.
Over here I'm using the hppa on a small HP-UX workstation, and that
has an uptime of 542 days!.
So it's not that unstable.
I even need to say that I had a lot more crashes with the x86 version
On Fri, 2009-06-12 at 09:55 +0200, Bart Schelstraete wrote:
Hello all,
Everybody is talking about the 'random crashes' and 'segfaults' in
the HPPA version.
Over here I'm using the hppa on a small HP-UX workstation, and that
has an uptime of 542 days!.
So it's not that unstable.
I even
On Fri, Jun 12, 2009 at 09:16:25AM -0500, James Bottomley wrote:
On Fri, 2009-06-12 at 09:55 +0200, Bart Schelstraete wrote:
Hello all,
Everybody is talking about the 'random crashes' and 'segfaults' in
the HPPA version.
Over here I'm using the hppa on a small HP-UX workstation, and
79 matches
Mail list logo
