Re: HPPA and Squeeze

2009-07-13 Thread Carlos O'Donell
On Sun, Jul 12, 2009 at 10:52 AM, Carlos
O'Donellcar...@systemhalted.org wrote:
 I'm building my own set of patches for debian-glibc, I'll tell you
 what my results are when I finish today.

I had to restart the build last night, and it's building right now. I
should have test results within 2 hours.

I have trimmed debian-release from the CC.

Thanks.

Cheers,
Carlos.


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



Re: HPPA and Squeeze

2009-07-12 Thread Aurelien Jarno
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 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 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...
 
 
  BTW, Carlos, could you please send me the latest version of your
  patches, so that we can actually do the switch with version 2.10?
 
 
 The latest patches are now up.
 
 Core glibc patch:
 http://www.parisc-linux.org/~carlos/2009-06-20-glibc-hppa-nptl.diff
 
 Ports glibc patch:
 http://www.parisc-linux.org/~carlos/2009-06-20-glibc-ports-hppa-nptl.diff
 
 No regressions in the testsuite for hppa-linux-gnu.
 

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 
linuxthreads build:
| Encountered regressions that don't match expected failures:
| tst-cancelx20.out, Error 1
| tst-cancelx21.out, Error 1
| tst-cancelx4.out, Error 1
| tst-cancelx5.out, Error 1
| tst-cleanupx4.out, Error 1
| tst-cputimer1.out, Error 1
| tst-cputimer2.out, Error 1
| tst-cputimer3.out, Error 1
| tst-mqueue3.out, Error 1
| tststatic2.out, Error 1
| tststatic.out, Error 1
| tst-timer4.out, Error 1
| tst-timer5.out, Error 1
| tst-tls9-static.out, Error 1

Is it something expected?

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


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



Re: HPPA and Squeeze

2009-07-12 Thread Carlos O'Donell
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
 linuxthreads build:
 | Encountered regressions that don't match expected failures:
 | tst-cancelx20.out, Error 1
 | tst-cancelx21.out, Error 1
 | tst-cancelx4.out, Error 1
 | tst-cancelx5.out, Error 1
 | tst-cleanupx4.out, Error 1

These are expected regressions

 | tst-cputimer1.out, Error 1
 | tst-cputimer2.out, Error 1
 | tst-cputimer3.out, Error 1
 | tst-mqueue3.out, Error 1

So are these.

 | tststatic2.out, Error 1
 | tststatic.out, Error 1

These are not.

 | tst-timer4.out, Error 1
 | tst-timer5.out, Error 1

These are.

 | tst-tls9-static.out, Error 1

This is not.

I'm building my own set of patches for debian-glibc, I'll tell you
what my results are when I finish today.

Cheers,
Carlos.


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



Re: HPPA and Squeeze

2009-07-07 Thread Carlos O'Donell
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            : Duet W2
 hversion              : 0x5dd0
 sversion              : 0x0491
 I-cache                 : 768 KB
 D-cache                   : 1536 KB (WB, direct mapped)
 ITLB entries              : 240
 DTLB entries              : 240 - shared with ITLB
 bogomips                  : 1495.04
 software id               : 2001606322

This is very similar to my own box. In frustration I've started
installing a buildd on my own a500. I might as well run a buildd to
load the machine and see if any of the reported package FTBS crop up.

Cheers,
Carlos.


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



Re: HPPA and Squeeze

2009-07-07 Thread James Bottomley
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 reproduce it with a UP 64-bit kernel on your C3750 to
  discount the L2 problems.
 
 Googling, I see Grant had trouble with RCU_TORTURE_TEST=y.  Probably,
 I should test current kernel to see if the problem is still present.
 
 I guess you are referring to this change:
 http://fossplanet.com/linux.debian.devel.kernel.cvs/thread-4378354-r7141-patches/
 
 I'm thinking we must be missing a flush...  Maybe in clear_user_page
 as for copy_user_page?

Clear user page is very clever and doesn't need a flush.  What it does
is clear the page through the users cache rather than the kernel's ...
what it actually does is place zeros in the cache above the physical
page, so the user can only access the zeros ... they eventually get
cleaned back to the page as the cache empties.

 Do the problematic debian buildd machines have pa8800/pa8900 processors?

No boxes outside of the cupertino test ring and a few giveaways (you,
kyle and t-bone, I think) have pa88/8900 cpus.

 My sense is that some change (probably to the core memory management
 code) made the coherence issue worse post 2.6.22.x.

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.

James



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



Re: HPPA and Squeeze

2009-07-07 Thread John David Anglin
 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 terminated by a null tag:

  while (dyn-d_tag != DT_NULL)
  {
 ...
  }

However, the core dump doesn't show a null tag before the STRTAB tag
that caused the segmentation fault.

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


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



Re: HPPA and Squeeze

2009-07-07 Thread Carlos O'Donell
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
 there should be data?  Yes, it does sound like a caching issue.

 Yes.  The loop is terminated by a null tag:

  while (dyn-d_tag != DT_NULL)
      {
         ...
      }

 However, the core dump doesn't show a null tag before the STRTAB tag
 that caused the segmentation fault.

Do you mean after the STRTAB tag? I assume the library on-disk has a
DT_NULL, otherwise it would always fail.

Cheers,
Carlos.


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



Re: HPPA and Squeeze

2009-07-07 Thread Carlos O'Donell
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
 the value loaded from memory somehow got corrupted.  Another possibility
 would be the mmap operation wasn't complete when the memory was examined
 by the dynamic loader.  When the core dump was done, the operation was
 complete.

 I think it's less likely that a cache issue affected the memory used by
 the dynamic loader (l_info field) as the data before and after in the
 map seemed reasonable.

 The fact PA8700 processors are also experiencing similar problems
 would seem to suggest that this isn't a PA8800 L2 issue unless we have
 multiple problems.

 I think we need to try running a recent kernel on gsyprf11 for a while
 to see if we can capture a similar event.

This rang a bell...

In glibc/elf/rtld.c we have this:

  /* Partly clean the `bootstrap_map' structure up.  Don't use
 `memset' since it might not be built in or inlined and we cannot
 make function calls at this point.  Use '__builtin_memset' if we
 know it is available.  We do not have to clear the memory if we
 do not have to use the temporary bootstrap_map.  Global variables
 are initialized to zero by default.  */
#ifndef DONT_USE_BOOTSTRAP_MAP
# ifdef HAVE_BUILTIN_MEMSET
  __builtin_memset (bootstrap_map.l_info, '\0', sizeof (bootstrap_map.l_info));
# else
  for (size_t cnt = 0;
   cnt  sizeof (bootstrap_map.l_info) / sizeof (bootstrap_map.l_info[0]);
   ++cnt)
bootstrap_map.l_info[cnt] = 0;
# endif

On hppa we don't have builtin memset (probably one of the few arches),
so we fall back on this weird loop which I always thought was wrong.

I was seeing problems with l_info having garbage in it, so I had a
local hack which cleared the entire bootstrap_map.

Did your l_info come from the bootstrap_map?

Cheers,
Carlos.


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



Re: HPPA and Squeeze

2009-07-07 Thread John David Anglin
 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, or possibly
  the value loaded from memory somehow got corrupted. =A0Another possibilit=
 y
  would be the mmap operation wasn't complete when the memory was examined
  by the dynamic loader. =A0When the core dump was done, the operation was
  complete.
 
  I think it's less likely that a cache issue affected the memory used by
  the dynamic loader (l_info field) as the data before and after in the
  map seemed reasonable.
 
  The fact PA8700 processors are also experiencing similar problems
  would seem to suggest that this isn't a PA8800 L2 issue unless we have
  multiple problems.
 
  I think we need to try running a recent kernel on gsyprf11 for a while
  to see if we can capture a similar event.
 
 This rang a bell...
 
 In glibc/elf/rtld.c we have this:
 
   /* Partly clean the `bootstrap_map' structure up.  Don't use
  `memset' since it might not be built in or inlined and we cannot
  make function calls at this point.  Use '__builtin_memset' if we
  know it is available.  We do not have to clear the memory if we
  do not have to use the temporary bootstrap_map.  Global variables
  are initialized to zero by default.  */
 #ifndef DONT_USE_BOOTSTRAP_MAP
 # ifdef HAVE_BUILTIN_MEMSET
   __builtin_memset (bootstrap_map.l_info, '\0', sizeof (bootstrap_map.l_inf=
 o));
 # else
   for (size_t cnt =3D 0;
cnt  sizeof (bootstrap_map.l_info) / sizeof (bootstrap_map.l_info[0=
 ]);
++cnt)
 bootstrap_map.l_info[cnt] =3D 0;
 # endif
 
 On hppa we don't have builtin memset (probably one of the few arches),
 so we fall back on this weird loop which I always thought was wrong.
 
 I was seeing problems with l_info having garbage in it, so I had a
 local hack which cleared the entire bootstrap_map.
 
 Did your l_info come from the bootstrap_map?

No.  The l_info fields for the dynamic loader and libncurses.so.5
had already been processed.  The segv occurred processing the needed
entry for libdl.so.2.  The code was processing the needed entries
for /bin/sh.

The cause of the corruption that you observed is not obvious to
me.

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


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



Re: HPPA and Squeeze

2009-07-06 Thread John David Anglin
  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.  While I know the problem is present in the PCH file, I
  haven't been able to figure out how wrong data gets in the file.

 There are some limitations on hppa if a file is both opened for reading 
 (via read()) and written to via a mmap'ed mapping. This came up a few 
 years ago.
 
 Does gcc do this?

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
memory.  In theory, it could be brought back to a different location
but this would require a fairly complex set of relocations.

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


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



Re: HPPA and Squeeze

2009-07-06 Thread Carlos O'Donell
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
 memory.  In theory, it could be brought back to a different location
 but this would require a fairly complex set of relocations.

GCC does not read() and write to the mmap()'d file.

The dynamic loader uses MAP_DENYWRITE to avoid writing into the mmap()'d memory.

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.

What we need to do here is create a test case.

I tried this:

1. cp /lib/libc.so.6 original.so
2. cp /lib/libc.so.6 map.so
3. gcc -O2 -g -o test-mmap test-mmap.c
4. while true; do ./test-mmap ./original.so ./map.so; done;

The test mmap's a file and compares it to the original, aborting if
the comparison fails. I've yet to see it abort on my a500, and I've
run 20-30 instances of the test simultaneously. Then again I don't see
any serious segv's like others do (2.6.26-1-parisc64-smp).

What might be a better testcase?

Cheers,
Carlos.
#include stdio.h
#include stdlib.h
#include sys/mman.h /* mmap */
#include sys/types.h /* open */
#include sys/stat.h /* open */
#include fcntl.h /* open */
#include unistd.h /* lseek */

#define BMAX 4096

int 
main (int argc, char **argv)
{
  void *mappref;
  int fd, fdc;
  off_t maplength, index, j;
  char *original = argv[1], *copy = argv[2];
  char buf[BMAX], *mbuf;
  ssize_t ret;
  /* Open original file to compute size. We open the original
 file to simulate having the fd open before mmap as the
 dynamic loader does.  */
  fd = open (original, O_RDONLY);
  if (fd == -1)
{
  perror (open);
  abort ();
}
  maplength = lseek (fd, 0, SEEK_END);
  if (fd == -1)
{
  perror (lseek);
  abort ();
}
  /* Now mmap the open file. */
  mappref = mmap ((void *)mappref, 
		  maplength, 
		  PROT_READ | PROT_EXEC, 
		  MAP_PRIVATE | MAP_DENYWRITE | MAP_FILE, 
		  fd, 
		  0);
  if (mappref == (void *)-1)
{
  perror (mmap);
  abort ();
}
  mbuf = (char *)mappref;
  /* Compare mmap to copy. */
  fdc = open (copy, O_RDONLY);
  if (fdc == -1)
{
  perror (open #2);
  abort ();
}
  for (index = 0; index  maplength; index += BMAX)
{
  ret = read (fdc, buf[0], BMAX);
  if ((ret != BMAX)  (ret == -1))
{
	  perror (read);
	  abort ();
}
  for (j = 0; ((j  BMAX)  ((index + j)  maplength)); j++)
{
	  if (mbuf[index + j] != buf[j])
	{
	  fprintf(stderr, Mismatch at %ld, read %d, expected %d\n, 
			index + j, (unsigned int)mbuf[index + j], (unsigned int)buf[j]);
	  abort ();
	}
	  if (DEBUG)
	printf (Match at %ld, read %d, expected %d\n,
			index + j, (unsigned int)mbuf[index + j], (unsigned int)buf[j]);
}
}
  return 0;
}



Re: HPPA and Squeeze

2009-07-06 Thread John David Anglin
 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 to a certain extent.  However, there are large portions
of code and initialized data that it doesn't touch.  I don't think
that I've ever seen an invalid instruction fault.  So, I'm not fully
convinced that we understand the cause of these segvs.

As far as I can tell, the mmap'd data appears correct (at least as
far as what was recorded in the core file).  What is wrong is the
l_info field in the linker map.  Prior to failing on processing
libdl.so.2, it had successfully processed itself and libncurses.so.5
(see NEEDED entries for /bin/sh).  There isn't a lot that happens
between mmap'ing the file and the access to the STRTAB entry in
the l_info field.  The NEEDED entry at l_info[1] seems ok in the
dump.

I doubt this is a TLB issue as the data is a long way from page
boundaries.  Possibly, there is a cache line issue in the mmap'd
file, or as I suggested before a race condition and the file isn't
fully mapped when the mmap call returns.  In any case, the extraction
of the dynamic data failed after doing the first NEEDED entry.

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.

 What we need to do here is create a test case.
 
 I tried this:
 
 1. cp /lib/libc.so.6 original.so
 2. cp /lib/libc.so.6 map.so
 3. gcc -O2 -g -o test-mmap test-mmap.c
 4. while true; do ./test-mmap ./original.so ./map.so; done;
 
 The test mmap's a file and compares it to the original, aborting if
 the comparison fails. I've yet to see it abort on my a500, and I've
 run 20-30 instances of the test simultaneously. Then again I don't see
 any serious segv's like others do (2.6.26-1-parisc64-smp).
 
 What might be a better testcase?

I typically run my GCC builds with `make -j 4'.  So, there's a mix
of other stuff actively running at any time.

I'll give the testcase a try tonight.

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


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



Re: HPPA and Squeeze

2009-07-06 Thread Kyle McMartin
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 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 the L2 problems.

regards, Kyle


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



Re: HPPA and Squeeze

2009-07-06 Thread John David Anglin
 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 the L2 problems.

Googling, I see Grant had trouble with RCU_TORTURE_TEST=y.  Probably,
I should test current kernel to see if the problem is still present.

I guess you are referring to this change:
http://fossplanet.com/linux.debian.devel.kernel.cvs/thread-4378354-r7141-patches/

I'm thinking we must be missing a flush...  Maybe in clear_user_page
as for copy_user_page?

Do the problematic debian buildd machines have pa8800/pa8900 processors?

My sense is that some change (probably to the core memory management
code) made the coherence issue worse post 2.6.22.x.

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


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



Re: HPPA and Squeeze

2009-07-06 Thread dann frazier
On Mon, Jul 06, 2009 at 09:47:09PM -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 reproduce it with a UP 64-bit kernel on your C3750 to
  discount the L2 problems.
 
 Googling, I see Grant had trouble with RCU_TORTURE_TEST=y.  Probably,
 I should test current kernel to see if the problem is still present.
 
 I guess you are referring to this change:
 http://fossplanet.com/linux.debian.devel.kernel.cvs/thread-4378354-r7141-patches/
 
 I'm thinking we must be missing a flush...  Maybe in clear_user_page
 as for copy_user_page?
 
 Do the problematic debian buildd machines have pa8800/pa8900 processors?

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: Duet W2
hversion  : 0x5dd0
sversion  : 0x0491
I-cache : 768 KB
D-cache   : 1536 KB (WB, direct mapped)
ITLB entries  : 240
DTLB entries  : 240 - shared with ITLB
bogomips  : 1495.04
software id   : 2001606322


 My sense is that some change (probably to the core memory management
 code) made the coherence issue worse post 2.6.22.x.
 
 Dave

-- 
dann frazier


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



Re: HPPA and Squeeze

2009-07-05 Thread Helge Deller

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



Re: HPPA and Squeeze

2009-07-05 Thread Jurij Smakov
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 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.

HPPA folks, can you please convert at least one buildd to a UP
configuration? I have another example of extreme buildd flakiness mentioned
in bug #529485. Adam C Powell IV hazel...@debian.org writes:

  That's too bad.  I saw 6 attempts to do 3.0.0-X of which two passed the
  first try and four failed.  At that rate (1/3), it would take nine
  attempts to have a decent chance of passing both rounds (debug static
  and optimized shared/static).

HPPA is the only arch for which petsc failed to build, and currently this
blocks petsc transition.

Best regards,
-- 
Jurij Smakov   ju...@wooyd.org
Key: http://www.wooyd.org/pgpkey/  KeyID: C99E03CC


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



Re: HPPA and Squeeze

2009-07-05 Thread John David Anglin
 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 /bin/sh
GNU gdb (GDB) 6.8.50.20090510-cvs
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as hppa-unknown-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
(no debugging symbols found)
BFD: Warning: /home/dave/gnu/gcc/objdir/hppa-linux/libjava/core is truncated: 
expected core file size = 196608, found: 118784.
Reading symbols from /lib/ld.so.1...Reading symbols from 
/usr/lib/debug/lib/ld-2.9.so...done.
done.
Loaded symbols for /lib/ld.so.1
Reading symbols from /lib/libncurses.so.5...done.
Loaded symbols for /lib/libncurses.so.5
Reading symbols from /lib/libdl.so.2...Reading symbols from 
/usr/lib/debug/lib/libdl-2.9.so...done.
done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libc.so.6...Reading symbols from 
/usr/lib/debug/lib/libc-2.9.so...done.
done.
Loaded symbols for /lib/libc.so.6
Core was generated by `/bin/sh -c /home/dave/gnu/gcc/gcc/mkinstalldirs `dirname 
gnu/java/locale/Locale'.
Program terminated with signal 11, Segmentation fault.
#0  _dl_map_object_deps (map=0x403d8880, preloads=0x40001398, npreloads=12, 
trace_mode=0, open_mode=0) at dl-deps.c:224
224 dl-deps.c: No such file or directory.
in dl-deps.c
(gdb) bt
#0  _dl_map_object_deps (map=0x403d8880, preloads=0x40001398, npreloads=12, 
trace_mode=0, open_mode=0) at dl-deps.c:224
#1  0x403b9bd4 in dl_main (phdr=0x10034, phnum=value optimized out, 
user_entry=value optimized out) at rtld.c:1780
#2  0x403cb898 in _dl_sysdep_start (start_argptr=value optimized out, 
dl_ma...@0x403d7566: 0x403b8fe4 dl_main) at ../elf/dl-sysdep.c:239
#3  0x403b785c in _dl_start_final (arg=0xbfff2020, info=0xbfff2348)
at rtld.c:332
#4  0x403b7adc in _dl_start (arg=0xbfff2020) at rtld.c:560
#5  0x403b742c in _start () from /lib/ld.so.1
#6  0x403b742c in _start () from /lib/ld.so.1
#7  0x403b742c in _start () from /lib/ld.so.1
#8  0x403b742c in _start () from /lib/ld.so.1
#9  0x403b742c in _start () from /lib/ld.so.1
#10 0x403b742c in _start () from /lib/ld.so.1
#11 0x403b742c in _start () from /lib/ld.so.1
#12 0x403b742c in _start () from /lib/ld.so.1
#13 0x403b742c in _start () from /lib/ld.so.1
#14 0x403b742c in _start () from /lib/ld.so.1
#15 0x403b742c in _start () from /lib/ld.so.1
#16 0x403b742c in _start () from /lib/ld.so.1
^CQuit

For some reason, gdb does terminate the backtrace.  Recent versions
of gdb also complain about core file truncation.  Think the full stack
region is not being dumped.

As with most of the segvs that I have debugged in the past, the problem
occurs in the dynamic loader.

This is the tombstone:

Jul  5 04:07:31 mx3210 kernel: 
Jul  5 04:07:31 mx3210 kernel: do_page_fault() pid=22068 command='sh' type=15 
address=0x0004
Jul  5 04:07:31 mx3210 kernel: Jul  5 04:07:31 mx3210 kernel:  
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
Jul  5 04:07:31 mx3210 kernel: PSW: 0100 Not 
taintedJul  5 04:07:31 mx3210 kernel: r00-03  0004000f 403d76a0 
000
0403c2c23 bfff2ac0
Jul  5 04:07:31 mx3210 kernel: r04-07  403d76a0 000c 000
040001398 403b0dc0
Jul  5 04:07:31 mx3210 kernel: r08-11   0002 000
04e88 bfff2d08
Jul  5 04:07:31 mx3210 kernel: r12-15  4037e4b4 bfff2c48 
403d76a0 0004
Jul  5 04:07:31 mx3210 kernel: r16-19  bfff2c08 bfff2bc8 
bfff2b88 403d76a0
Jul  5 04:07:31 mx3210 kernel: r20-23  bfff2d0f  
40002000 0001
Jul  5 04:07:31 mx3210 kernel: r24-27  000c 40001398 
400013a8 000365e8
Jul  5 04:07:31 mx3210 kernel: r28-31   24242424 
bfff2e00 403c45c3
Jul  5 04:07:31 mx3210 kernel: sr00-03  e800 e800 
 e800
Jul  5 04:07:31 mx3210 kernel: sr04-07  e800 e800 
e800 e800
Jul  5 04:07:31 mx3210 kernel: 
Jul  5 04:07:31 mx3210 kernel:   VZOUICununcqcqcqcqcqcrmunTDVZOUI
Jul  5 04:07:31 mx3210 kernel: FPSR: 
Jul  5 04:07:31 mx3210 kernel: FPER1: 
Jul  5 04:07:31 mx3210 kernel: fr00-03    
 
Jul  5 04:07:31 mx3210 kernel: fr04-07  f000  
ff9c 

Re: HPPA and Squeeze

2009-07-05 Thread John David Anglin
 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 = 0x4e88, l_ns = 0, l_libname = 0x400010dc, l_info = {0x0, 
   0x4029e5fc, 0x0 repeats 74 times}, l_phdr = 0x4029b034, 
   l_entry = 1076477148, l_phnum = 7, l_ldnum = 31, l_searchlist = {
   r_list = 0x0, r_nlist = 0}, l_symbolic_searchlist = {r_list = 0x400010d8, 
   r_nlist = 0}, l_loader = 0x403d8880, l_versions = 0x0, l_nversions = 0, 
   l_nbuckets = 0, l_gnu_bitmask_idxbits = 0, l_gnu_shift = 0, 
   l_gnu_bitmask = 0x0, {l_gnu_buckets = 0x0, l_chain = 0x0}, {
   l_gnu_chain_zero = 0x0, l_buckets = 0x0}, l_direct_opencount = 0, 
   l_type = lt_library, l_relocated = 0, l_init_called = 0, l_global = 0, 
   l_reserved = 1, l_phdr_allocated = 0, l_soname_added = 0, l_faked = 0, 
   l_need_tls_init = 0, l_used = 0, l_auditing = 0, l_audit_any_plt = 0, 
   l_removed = 0, l_contiguous = 1, l_rpath_dirs = {dirs = 0x0, malloced = 0}, 
   l_reloc_result = 0x0, l_versyms = 0x0, l_origin = 0x400010f8 /lib, 
   l_map_start = 1076473856, l_map_end = 1076488476, l_text_end = 1076490240, 
   l_scope_mem = {0x403d89dc, 0x0, 0x0, 0x0}, l_scope_max = 4, 
   l_scope = 0x40001040, l_local_scope = {0x4fe4, 0x0}, l_dev = 536937216, 
   l_ino = 641559, l_runpath_dirs = {dirs = 0x0, malloced = 0}, 
   l_initfini = 0x0, l_reldepsmax = 0, l_reldeps = 0x0, l_feature_1 = 0, 
   l_flags_1 = 0, l_flags = 0, l_idx = 0, l_mach = {fptr_table_len = 0, 
   fptr_table = 0x0}, l_lookup_cache = {sym = 0x0, type_class = 0, 
   value = 0x0, ret = 0x0}, l_tls_initimage = 0x0, l_tls_initimage_size = 0, 
   l_tls_blocksize = 0, l_tls_align = 0, l_tls_firstbyte_offset = 0, 
   l_tls_offset = 0, l_tls_modid = 0, l_relro_addr = 0, l_relro_size = 0, 
   l_serial = 3, l_audit = 0x400010d8}

When I run the command directly under gdb, the info is a different location
and the string table entry is not null:

(gdb) bt
#0  _dl_map_object_deps (map=0x403d8880, preloads=0x40001170, npreloads=12, 
trace_mode=0, open_mode=0) at dl-deps.c:224
#1  0x403b9bd4 in dl_main (phdr=0x10034, phnum=value optimized out, 
user_entry=value optimized out) at rtld.c:1780
#2  0x403cb898 in _dl_sysdep_start (start_argptr=value optimized out, 
dl_ma...@0x403d7566: 0x403b8fe4 dl_main) at ../elf/dl-sysdep.c:239
#3  0x403b785c in _dl_start_final (arg=0xbff01028, info=0xbff01188)
at rtld.c:332
#4  0x403b7adc in _dl_start (arg=0xbff01028) at rtld.c:560

(gdb) p *(*preloads)-l_next
$2 = {l_addr = 1076473856, l_name = 0x4c50 /lib/libdl.so.2, 
  l_ld = 0x4029e5fc, l_next = 0x4ef0, l_prev = 0x49c8, 
  l_real = 0x4c60, l_ns = 0, l_libname = 0x4eb4, l_info = {0x0, 
  0x4029e604, 0x4029e66c, 0x4029e664, 0x4029e634, 0x4029e644, 0x4029e64c, 
  0x4029e684, 0x4029e68c, 0x4029e694, 0x4029e654, 0x4029e65c, 0x4029e614, 
  0x4029e61c, 0x4029e60c, 0x0, 0x0, 0x0, 0x0, 0x0, 0x4029e674, 0x0, 0x0, 
  0x4029e67c, 0x0, 0x4029e624, 0x0, 0x4029e62c, 0x0, 0x0, 0x0, 0x0, 0x0, 
  0x0, 0x4029e6b4, 0x4029e6ac, 0x4029e6a4, 0x4029e69c, 0x0, 0x0, 0x4029e6c4, 
  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x4029e6bc, 
  0x0 repeats 25 times, 0x4029e63c}, l_phdr = 0x4029b034, 
  l_entry = 1076477148, l_phnum = 7, l_ldnum = 31, l_searchlist = {
  r_list = 0x0, r_nlist = 0}, l_symbolic_searchlist = {r_list = 0x4eb0, 
  r_nlist = 0}, l_loader = 0x403d8880, l_versions = 0x0, l_nversions = 0, 
  l_nbuckets = 22, l_gnu_bitmask_idxbits = 3, l_gnu_shift = 7, 
  l_gnu_bitmask = 0x4029b144, {l_gnu_buckets = 0x4029b154, 
  l_chain = 0x4029b154}, {l_gnu_chain_zero = 0x4029b148, 
  l_buckets = 0x4029b148}, l_direct_opencount = 0, l_type = lt_library, 
  l_relocated = 0, l_init_called = 0, l_global = 0, l_reserved = 1, 
  l_phdr_allocated = 0, l_soname_added = 0, l_faked = 0, l_need_tls_init = 0, 
  l_used = 0, l_auditing = 0, l_audit_any_plt = 0, l_removed = 0, 
  l_contiguous = 1, l_rpath_dirs = {dirs = 0x0, malloced = 0}, 
  l_reloc_result = 0x0, l_versyms = 0x0, l_origin = 0x4ed0 /lib, 
  l_map_start = 1076473856, l_map_end = 1076488476, l_text_end = 1076490240, 
  l_scope_mem = {0x403d89dc, 0x0, 0x0, 0x0}, l_scope_max = 4, 
  l_scope = 0x4e18, l_local_scope = {0x4dbc, 0x0}, l_dev = 536937216, 
  l_ino = 641559, l_runpath_dirs = {dirs = 0x0, malloced = 0}, 
  l_initfini = 0x0, l_reldepsmax = 0, l_reldeps = 0x0, l_feature_1 = 0, 
  l_flags_1 = 0, l_flags = 0, l_idx = 0, l_mach = {fptr_table_len = 0, 
  fptr_table = 0x0}, l_lookup_cache = {sym = 0x0, type_class = 0, 
  value = 0x0, ret = 0x0}, l_tls_initimage = 0x0, l_tls_initimage_size = 0, 
  l_tls_blocksize = 0, l_tls_align = 0, l_tls_firstbyte_offset = 0, 
  l_tls_offset = 0, l_tls_modid = 0, l_relro_addr = 0, l_relro_size = 0, 
  l_serial = 3, l_audit = 0x4eb0}

Dave
-- 
J. David Anglin  

Re: HPPA and Squeeze

2009-07-05 Thread John David Anglin
 (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, 
   l_entry = 1076477148, l_phnum = 7, l_ldnum = 31, l_searchlist = {
   r_list = 0x0, r_nlist = 0}, l_symbolic_searchlist = {r_list = 0x400010d8, 
   r_nlist = 0}, l_loader = 0x403d8880, l_versions = 0x0, l_nversions = 0, 
   l_nbuckets = 0, l_gnu_bitmask_idxbits = 0, l_gnu_shift = 0, 
   l_gnu_bitmask = 0x0, {l_gnu_buckets = 0x0, l_chain = 0x0}, {
   l_gnu_chain_zero = 0x0, l_buckets = 0x0}, l_direct_opencount = 0, 
   l_type = lt_library, l_relocated = 0, l_init_called = 0, l_global = 0, 
   l_reserved = 1, l_phdr_allocated = 0, l_soname_added = 0, l_faked = 0, 
   l_need_tls_init = 0, l_used = 0, l_auditing = 0, l_audit_any_plt = 0, 
   l_removed = 0, l_contiguous = 1, l_rpath_dirs = {dirs = 0x0, malloced = 0}, 
   l_reloc_result = 0x0, l_versyms = 0x0, l_origin = 0x400010f8 /lib, 
   l_map_start = 1076473856, l_map_end = 1076488476, l_text_end = 1076490240, 
   l_scope_mem = {0x403d89dc, 0x0, 0x0, 0x0}, l_scope_max = 4, 
   l_scope = 0x40001040, l_local_scope = {0x4fe4, 0x0}, l_dev = 536937216, 
   l_ino = 641559, l_runpath_dirs = {dirs = 0x0, malloced = 0}, 
   l_initfini = 0x0, l_reldepsmax = 0, l_reldeps = 0x0, l_feature_1 = 0, 
   l_flags_1 = 0, l_flags = 0, l_idx = 0, l_mach = {fptr_table_len = 0, 
   fptr_table = 0x0}, l_lookup_cache = {sym = 0x0, type_class = 0, 
   value = 0x0, ret = 0x0}, l_tls_initimage = 0x0, l_tls_initimage_size = 0, 
   l_tls_blocksize = 0, l_tls_align = 0, l_tls_firstbyte_offset = 0, 
   l_tls_offset = 0, l_tls_modid = 0, l_relro_addr = 0, l_relro_size = 0, 
   l_serial = 3, l_audit = 0x400010d8}
 
 (gdb) p (*preloads)-l_next-l_info
 $14 = (Elf32_Dyn *(*)[76]) 0x4ea8
 (gdb) p (*preloads)-l_next-l_info
 $15 = {0x0, 0x4029e5fc, 0x0 repeats 74 times}
 (gdb) p/x 0x4ea8 + 5 * 4
 $17 = 0x4ebc
 
 So, the segmentation fault was caused by a 0x0 in the l_info field of
 the link map for /lib/libdl.so.2.

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 object uses.  */
l-l_map_start = (ElfW(Addr)) __mmap ((void *) mappref, maplength,
  c-prot,
  MAP_COPY|MAP_FILE,
  fd, c-mapoff);

The info data is near the end of the mapped segment.  The l_info field
is initialized by elf_get_dynamic_info from the dynamic data mapped
at l-ld.

I seem to recall that the kernel mmap implementation on hppa is somewhat
unique.

In the above call, mappref is NULL.  The kernel selects the map location.

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


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



Re: HPPA and Squeeze

2009-07-05 Thread Carlos O'Donell
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 object uses.  */
        l-l_map_start = (ElfW(Addr)) __mmap ((void *) mappref, maplength,
                                              c-prot,
                                              MAP_COPY|MAP_FILE,
                                              fd, c-mapoff);

 The info data is near the end of the mapped segment.  The 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 seem to recall that the kernel mmap implementation on hppa is somewhat
 unique.

I don't recall anything, Kyle?

 In the above call, mappref is NULL.  The kernel selects the map location.

Yes, that's probably correct, the loader is letting the kernel choose
the address, at this point we don't care where the library is loaded.

Cheers,
Carlos.


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



Re: HPPA and Squeeze

2009-07-05 Thread John David Anglin
  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 depending on where the map is placed.

  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.  While I know the problem is present in the PCH file, I
haven't been able to figure out how wrong data gets in the file.

  In the above call, mappref is NULL. =A0The kernel selects the map locatio=
 n.
 
 Yes, that's probably correct, the loader is letting the kernel choose
 the address, at this point we don't care where the library is loaded.

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


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



Re: HPPA and Squeeze

2009-07-05 Thread John David Anglin
 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 supposition is that we may not
  be copying the entire segment depending on where the map is placed.
 
 Who is supposed to copy the segment?  The user or the kernel?

As far as I can tell, the kernel is responsible for mapping the segment.
Then, elf_get_dynamic_info processes the mapped data to generate the
l_info field in the link map.

The kernel has control over where the segment is mapped.  In as much
as the dependencies for /bin/sh are processed many times in a GCC
build, I have to think the problem relates to the placement or a
random problem with mmap.  There is a small possibility that the
processing of the data by elf_get_dynamic_info has a problem.

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.  While I know the problem is present in the PCH file, I
  haven't been able to figure out how wrong data gets in the file.
 
 Do you have a bugzilla reference so we can take a look ... also, is this
 likely a tool chain problem or a kernel one?  If it's a kernel one could
 someone provide a description of what they think is going wrong?

The bugzilla reference is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355.

Many of my comments in the PR are wrong.  See comment #47.  At this time,
I know that the data in the PCH file are wrong but I don't know why.  In
any case, I should not have mentioned the PCH bug.  It's probably a tool
chain bug.  The main point of the comment was that the hppa mmap implementation
differs from other implementations (MAP_PRIVATE is not reliable).  So, there
may be other issues.

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


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



Re: HPPA and Squeeze

2009-07-04 Thread Kurt Roeckx
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 with -ffunction-sections
  /usr/bin/ld: libgag/src/libgag.a(FileManager.o)(.text+0x2fc8): cannot 
  handle R_PARISC_PCREL17F for memcpy@@GLIBC_2.2
  /usr/bin/ld: final link failed: Bad value
  collect2: ld returned 1 exit status
 
 I couldn't duplicate the problem with binutils 2.19.1-1 and gcc-4.3
 4.3.3-10, or with my own binutils build on two different systems.
 
 The above shouldn't happen as the text size of FileManager.o is well below
 the size where a 17-bit branch can't reach the stub table.  Possibly, the
 stub table is full.  On the otherhand, the f9bf_memcpy@@GLIBC_2.2+0
 string looks garbled.  So, this may be another form of the SMP memory
 corruption that causes the segvs, particularly if it isn't reproducible
 on the build system.

It actually already failed twice on the same system with the same
error.  I've just let it retry again, we'll see if it fails again.

The log file show this is with:
gcc-4.3 4.3.3-13 / 4.3.3-11
binutils 2.19.1-1


Kurt


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



Re: HPPA and Squeeze

2009-07-04 Thread Kurt Roeckx
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 with -ffunction-sections
   /usr/bin/ld: libgag/src/libgag.a(FileManager.o)(.text+0x2fc8): cannot 
   handle R_PARISC_PCREL17F for memcpy@@GLIBC_2.2
   /usr/bin/ld: final link failed: Bad value
   collect2: ld returned 1 exit status
  
  I couldn't duplicate the problem with binutils 2.19.1-1 and gcc-4.3
  4.3.3-10, or with my own binutils build on two different systems.
  
  The above shouldn't happen as the text size of FileManager.o is well below
  the size where a 17-bit branch can't reach the stub table.  Possibly, the
  stub table is full.  On the otherhand, the f9bf_memcpy@@GLIBC_2.2+0
  string looks garbled.  So, this may be another form of the SMP memory
  corruption that causes the segvs, particularly if it isn't reproducible
  on the build system.
 
 It actually already failed twice on the same system with the same
 error.  I've just let it retry again, we'll see if it fails again.

And it failed again with the same error, on peri now.


Kurt


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



Re: HPPA and Squeeze

2009-07-03 Thread Kurt Roeckx
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: *** [install] Segmentation fault
  acpica-unix | peri | make: *** [install] Segmentation fault
 
 I had those random segfaults in make on paer too, until we switched to the
 UP kernel, at least from what I saw.

Did something change to peri?  I'm currently only seeing them on
penalosa.

Failed logs the past few days:
Jun 22 | wesnoth| penalosa | quilt segfaults
Jun 22 | gitg   | penalosa | quilt segfaults
Jun 23 | zita-convolver | penalosa | quilt segfaults
Jun 25 | autodocksuite  | penalosa | make segfaults
Jun 26 | mpd| penalosa | find segfaults?
Jun 30 | scorched3d | penalosa | make segfaults
Jun 30 | libtext-bibtex-perl| penalosa | make segfaults
Jun 30 | gnome-chemistry-utils  | penalosa | libtool segfaults
Jul 01 | openmsx-catapult   | penalosa | make segfaults
Jul 01 | prima  | penalosa | make segfaults
Jul 01 | fvwm   | penalosa | gcc says as had a segfault
Jul 01 | cherokee   | penalosa | quilt segfaults
Jul 03 | vflib3 | penalosa | make segfaults
Jul 03 | rpy2   | penalosa | make segfaults
Jul 03 | debian-installer-utils | penalosa | make segfaults

On other that looks weird is, all also on penalosa:
- scid, seems to have been stuck in a cp.
- postgresql-8.3, not sure what the error is
- building gnome-system-monitor, openssh-client failed to install
  in it's postinst script calling update-alternatives

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 memcpy@@GLIBC_2.2
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status


Kurt


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



Re: HPPA and Squeeze

2009-07-03 Thread Kurt Roeckx
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.


Kurt


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



Re: HPPA and Squeeze

2009-06-24 Thread Matthias Klose
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 it's wrong to assume we will come with the answers.
 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, time, and materials to.
 +1. dropping hppa as a release architecture was not communicated by the 
 release
 team at all.  I did spend some time to get gcj / default-jdk working on hppa,
 and some money (buying a new disk for a hppa machine) to help this port.  The
 time and the money could have spent better, if d-r would have better
 communicated about their intent.
 
 There are issues with the hppa port where the release team considered
 dropping it since 2005 communicated to the porter list...
 
 hppa is not in a good shape, but there are other architectures which are not
 better (sparc, mips*) from a toolchain point of view. what about these?
 
 I'm not aware of current toolchain issues on sparc and the issues on
 mips* still seem to be manageable, no?

sparc-biarch defaulting to 32bit isn't supported by upstream; there are requests
to move to v9 optimization by default, which requires some work in the compiler.
I don't plan to update this for upcoming GCC versions, and there's no interest
by upstream to help with this kind of setup. You can't buy v8 software for years
now, but afaik all our machines run 64bit kernels. Maybe it's time to
acknowledge this, remove sparc from the list of release architectures and go on
with sparc64?

there are currently binutils issues outstanding, reported upstream. plus the
non-availability of developer machines seems to be an issue. Sadly we don't have
the mips support for squeeze as we had for lenny.

 there are issues pointed out and not addressed like the -dev / -headers 
 packages
  built as binary independent packages just to save disk space, which have an
 impact on slow architectures, and which are not addressed by the release 
 team.
 would the release team mind addressing these real issues, or should we drop
 slow architectures as well?
 
 Well, this Packages issue is clearly a responsability from the FTP Team
 and the Release Team would indeed be very happy to have that resolved.

So it seems to be ok to ignore an issue, if you can work around it? Fine, then
I'll build all compiler front ends from one source again.

  Matthias


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



Re: HPPA and Squeeze

2009-06-21 Thread Carlos O'Donell
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,
 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 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...


 BTW, Carlos, could you please send me the latest version of your
 patches, so that we can actually do the switch with version 2.10?


The latest patches are now up.

Core glibc patch:
http://www.parisc-linux.org/~carlos/2009-06-20-glibc-hppa-nptl.diff

Ports glibc patch:
http://www.parisc-linux.org/~carlos/2009-06-20-glibc-ports-hppa-nptl.diff

No regressions in the testsuite for hppa-linux-gnu.

No failures in my custom testsuite for the transition.

However, the usability testing in a chroot + vnc is showing that some
applications are segfaulting. I've been looking into this today.

Cheers,
Carlos.


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



Re: HPPA and Squeeze

2009-06-20 Thread Kurt Roeckx
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 compiler error since
atleast April 2008.  Logs are at:
https://buildd.debian.org/build.cgi?pkg=netgen;ver=4.4-15;arch=hppa
https://buildd.debian.org/build.cgi?pkg=netgen;arch=hppa


Kurt


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



Re: HPPA and Squeeze

2009-06-20 Thread Kurt Roeckx
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 gets killed after
150 minutes of inactivity.  I assume NPTL will fix this.


Kurt


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



Re: HPPA and Squeeze

2009-06-20 Thread John David Anglin
 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 compiler error since
 atleast April 2008.  Logs are at:
 https://buildd.debian.org/build.cgi?pkg=netgen;ver=4.4-15;arch=hppa
 https://buildd.debian.org/build.cgi?pkg=netgen;arch=hppa

g++ -c -I. -I../libsrc/interface -Iinclude -O2 -I/usr/include/GL 
-I/usr/include/tcl8.4 -I/usr/include/tk8.4 -I/usr/X11R6/include  -DLINUX 
-DOPENGL -DNGSOLVE basiclinalg/cholesky.cpp basiclinalg/calcinverse.cpp 
basiclinalg/vecmat.cpp basiclinalg/bandmatrix.cpp basiclinalg/eigensystem.cpp 
linalg/basevector.cpp linalg/vvector.cpp linalg/basematrix.cpp 
linalg/sparsematrix.cpp linalg/special_matrix.cpp linalg/cg.cpp 
linalg/chebyshev.cpp linalg/eigen.cpp linalg/order.cpp 
linalg/sparsecholesky.cpp linalg/pardisoinverse.cpp linalg/superluinverse.cpp 
linalg/jacobi.cpp linalg/blockjacobi.cpp linalg/commutingAMG.cpp 
ngstd/exception.cpp ngstd/table.cpp ngstd/bitarray.cpp ngstd/flags.cpp 
ngstd/symboltable.cpp ngstd/blockalloc.cpp ngstd/evalfunc.cpp 
ngstd/templates.cpp ngstd/localheap.cpp
linalg/basematrix.cpp: In member function 'void 
ngla::S_BaseMatrixstd::complexdouble 
::_ZTv0_n72_NK4ngla12S_BaseMatrixISt7complexIdEE12MultTransAddES2_RKNS_10BaseVectorERS4_(ngbla::Complex,
 const ngla::BaseVector, ngla::BaseVector) const':
linalg/basematrix.cpp:208: internal compiler error: in expand_expr_addr_expr_1, 
at expr.c:6830
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.3/README.Bugs for instructions.

When an internal compiler error occurs as above, a GCC bug report with
the following information should be filed:

1) failing compiler command,
2) details of the compiler (gcc -v), and
3) the preprocessed source for the failing command.

You can CC me on hppa bugs (danglin at gcc dot gnu dot org).

It takes less than five minutes to generate the above information and
file a bug report.  The preprocessed source is really important as it
is very difficult for others to duplicate the problem otherwise.

In this case, it appears the following assert is triggered.

  /* If the DECL isn't in memory, then the DECL wasn't properly
 marked TREE_ADDRESSABLE, which will be either a front-end
 or a tree optimizer bug.  */
  gcc_assert (MEM_P (result));

There's a fairly high probability that this is a generic bug.

If the bug is a compiler regression, then fixes will applied to all active
branches when available.  Thus, it is useful to know if an earlier compiler
version was able to successfully compile the file.

As things stand, I file more than 90% of hppa compiler bugs based on what
I see in my testing.  However, I'm not trying to build and maintain 10,000
packages.  So, hopefully, the debian build team can help a bit more with
problem reporting.

I recognize that not all bugs are easy to classify.  However, internal
compiler errors are always compiler bugs.

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


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



Re: HPPA and Squeeze

2009-06-20 Thread Kurt Roeckx
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 porting issues specific
   to hppa.
  
  netgen fails to built with an internal compiler error since
  atleast April 2008.  Logs are at:
 
 When an internal compiler error occurs as above, a GCC bug report with
 the following information should be filed:
 
 1) failing compiler command,
 2) details of the compiler (gcc -v), and
 3) the preprocessed source for the failing command.
 
 You can CC me on hppa bugs (danglin at gcc dot gnu dot org).

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 at:
http://gcc.gnu.org/PR40505


 It takes less than five minutes to generate the above information and
 file a bug report.

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.


Kurt


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



Re: HPPA and Squeeze

2009-06-20 Thread Grant Grundler
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 at:
 http://gcc.gnu.org/PR40505

Kurt - thanks for filing the bug.

  It takes less than five minutes to generate the above information and
  file a bug report.
 
 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 bugreport.  

thanks again,
grant


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



Re: HPPA and Squeeze

2009-06-20 Thread John David Anglin
  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 bugreport.  

There's no problem reproducing the ICE.

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 copied to memory.  This doesn't happen in calls
from normal functions because the value gets copied to a stack slot.

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


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



Re: HPPA and Squeeze

2009-06-19 Thread Kurt Roeckx
I take a regular look at various arches why packages are not
correctly built.  hppa is the most annoying arch for me. If you
look at the stats you will notice that it's almost always
the lowest in the stats.  The reason it more or less keeps up is
because I put alot of time in looking at the state of the
packages and that packages get retried alot by the buildd
maintainer.

One of the most annoying things about it is that packages only
get uploaded 2 or 3 times a week.  This has as effect that alot
of packages fail to build because others haven't been uploaded
yet.  Alot of packages are uninstallable, and are basicly waiting
for others to be built/uploaded.  With only 2/3 uploads a week
this means that packages are uninstallable for _weeks_.  By the
time the first reason has been fixed, something else already make
it uninstallable again.  And I guess this is also the reason
the release team always needs to take a look at why something
is uninstallable on hppa.  I can deal with this, but because of
this reason, hppa is a low priority port for me.

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.

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] Segmentation fault


This are probabaly porting issues, they atleast seems to
only affect hppa:
package| error
rt-tests   | PTHREAD_PRIO_INHERIT undeclared (NPTL support?)
insighttoolkit | undefined references
axis   | #531995: Cannot override the final method from ResourceBundle
petsc  | petscvariables: No such file or directory

Logs can be found at
https://buildd.debian.org/build.cgi?arch=hppa;pkg=$package


Kurt

On Fri, Jun 19, 2009 at 08:05:56AM +0200, Luk Claes wrote:
 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 into Lenny even when the
 Debian System Administrators (DSA), package maintainers, release team
 members an others were shouting to drop it. I thought it was unfair to
 drop the port just before the release. They accepted my decision as long
 as I would make it clear that it was a *big* exception not to be taken
 lightly. At the time java support was completely dropped, buildds were
 crashing every other day and support for other programing languages
 looked poor and the port was still using linuxthreads as the latest of
 all ports.
 
 After the release of Lenny there were still not much signs of
 improvement to the reliability of the buildds and the move to ntpl (that
 was going to solve almost all issues the maintainers had) seemed to not
 happen and not going to solve everything. The only surprising
 improvement was the regained java support.
 
 It's quite disturbing in my honest opinion that only after us starting a
 thread like this one that we get to know the status of some of the
 porting efforts and lots of vocal support, but not many visible
 improvements. Instead of making sure that there is visibile improvement
 after that, this pattern seems to repeat itself which is not looking
 very promising. I'm sorry if my and others' frustration is ventilated in
 some of the mails. The issues with the buildds are lasting for years
 already with lots of time spent by DSA and others.
 
 I still hope that the hppa porters can prove us wrong, fix the kernel
 issues (which are the probable cause of the unreliability of the
 buildds), finalise the ntpl move and stay on top of porting issues in
 Debian in the future.
 
 Please let us now focus on improving the status of the hppa port in
 general and the buildds in particular!
 
 Cheers
 
 Luk
 
 
 -- 
 To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 


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



Re: HPPA and Squeeze

2009-06-19 Thread Philipp Kern
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] Segmentation fault

I had those random segfaults in make on paer too, until we switched to the
UP kernel, at least from what I saw.

Sadly it looks that I forgot the buildd upgrade process on paer some days
ago.  The buildd will be back building ASAP.

Kind regards,
Philipp Kern
-- 
 .''`.  Philipp KernDebian Developer
: :' :  http://philkern.de Stable Release Manager
`. `'   xmpp:p...@0x539.de Wanna-Build Admin
  `-finger pkern/k...@db.debian.org


signature.asc
Description: Digital signature


Re: HPPA and Squeeze

2009-06-18 Thread Luk Claes
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 will come with the answers.
 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, time, and materials to.
 
 +1. dropping hppa as a release architecture was not communicated by the 
 release
 team at all.  I did spend some time to get gcj / default-jdk working on hppa,
 and some money (buying a new disk for a hppa machine) to help this port.  The
 time and the money could have spent better, if d-r would have better
 communicated about their intent.

There are issues with the hppa port where the release team considered
dropping it since 2005 communicated to the porter list...

 hppa is not in a good shape, but there are other architectures which are not
 better (sparc, mips*) from a toolchain point of view. what about these?

I'm not aware of current toolchain issues on sparc and the issues on
mips* still seem to be manageable, no?

 there are issues pointed out and not addressed like the -dev / -headers 
 packages
  built as binary independent packages just to save disk space, which have an
 impact on slow architectures, and which are not addressed by the release 
 team.
 would the release team mind addressing these real issues, or should we drop
 slow architectures as well?

Well, this Packages issue is clearly a responsability from the FTP Team
and the Release Team would indeed be very happy to have that resolved.

Cheers

Luk


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



Re: HPPA and Squeeze

2009-06-18 Thread Luk Claes
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 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
maintainers and others.

Cheers

Luk


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



Re: HPPA and Squeeze

2009-06-18 Thread Randolph Chung

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
maintainers and others.
  
If you looked at https://buildd.debian.org/stats/graph-big.png  I think 
it is obvious hppa is not *that* broken. hppa is 95% built. That is not 
that bad. Of course, it can be better, but if you looked at this with a 
historical perspective the port is really in a pretty good shape.


If you looked at the status of the toolchain posted to the 
gcc-testresults page: http://gcc.gnu.org/ml/gcc-testresults/2009-06/  
you can see that hppa is one of the better architectures out there. Our 
results are on par with (if not better than) other supported architectures.


IMHO hppa contributed a lot to getting Debian packages (and upstream) 
properly fixed to build properly across many other architectures and 
making it easier for new architectures to get incorporated into Debian. 
It's unfortunate that parisc is no longer a commercially popular 
platform, but why should not affect whether Debian supports it?


It's obvious from the recent exchange that there are still people on the 
hppa team (and other Debian maintainers) that are willing to work on 
this architecture to make things better. Also by many metrics it is 
still very much a working architecture. It's really a shame that 
Debian's considering dropping support for HPPA in Squeeze. Please 
reconsider.


randolph


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



Re: HPPA and Squeeze

2009-06-18 Thread Thibaut VARENE
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 based on some misinformation, and an unclear
 rational.

 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
 maintainers and others.

I'm sorry, but this thread is now over 2 weeks old and we yet have to
see a *rationale* motivating the current decision. Not some claims
about bugs (which we still haven't been pointed at, except for the
ruby one, which we addressed already) affecting the buildds (and that
only you experience). Speaking of which, I'm not aware of any problem
affecting lafayette...

We have given you tangible elements and have answered each and every
questions that have been raised in this thread. The release team, on
the other hand, failed to answer the single question we've been
asking: what's the rationale for dropping parisc?

I joined Debian many years ago because it seemed to me that it had
proper ethics, in particular because decisions were taken
transparently, and were properly - and openly - discussed before
anything final was settled. I too have invested time and money into
the project. I'm extremely disappointed with the handling of the issue
at stake here.

Again, I would like to see a comprehensive rationale for this
decision, so that we can at least try to address the problems at hands
and hope for re-inclusion after squeeze. BTW, can you clarify whether
that would be an option?

Cheers,
T-Bone

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/


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



Re: HPPA and Squeeze

2009-06-18 Thread John David Anglin
 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 nscd.
It causes random problems with uid/gid lookups.  This is just a guess
based on this report:
http://www.nabble.com/Boost-build-failure-on-hppa-td23496708.html

I had problems with sshd and dpkg on my c3750 until I disabled nscd.
It's now running 2.6.30.  It has done a full build and check of GCC
several times, and appears to be stable with this kernel.  This is
with a UP kernel.

With SMP kernels, there's still a problem with random segementation
faults.  These cause application core dumps and are normally logged
in /var/log/debug.  The frequency of these problems vary with kernel
version.

I believe that it should be possible to setup a reliable hppa build
server running a UP kernel.

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


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



Re: HPPA and Squeeze

2009-06-18 Thread Luk Claes
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
 the current decision was based on some misinformation, and an unclear
 rational.
 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
 maintainers and others.
 
 I'm sorry, but this thread is now over 2 weeks old and we yet have to
 see a *rationale* motivating the current decision. Not some claims
 about bugs (which we still haven't been pointed at, except for the
 ruby one, which we addressed already) affecting the buildds (and that
 only you experience). Speaking of which, I'm not aware of any problem
 affecting lafayette...

lafayette is only doing non-sid to make sure we have a buildd that is
not heavy loaded and very probable to be able to build all security and
stable/oldstable updates...

 We have given you tangible elements and have answered each and every
 questions that have been raised in this thread. The release team, on
 the other hand, failed to answer the single question we've been
 asking: what's the rationale for dropping parisc?

Please read again, it's only in the beginning of the mail...

 I joined Debian many years ago because it seemed to me that it had
 proper ethics, in particular because decisions were taken
 transparently, and were properly - and openly - discussed before
 anything final was settled. I too have invested time and money into
 the project. I'm extremely disappointed with the handling of the issue
 at stake here.

I'm very disappointed at the hppa porters attitudes I must say. They
talk a lot, they assumingly work a lot behind the scenes, but they don't
seem to know what issues there are within the project nor is there any
visible progress unless we prod very hard and even then they are more
worried about the way we prod than about proving they are worthy to
support the port and show some real progress...

 Again, I would like to see a comprehensive rationale for this
 decision, so that we can at least try to address the problems at hands
 and hope for re-inclusion after squeeze. BTW, can you clarify whether
 that would be an option?

It's still an option to stay in squeeze like I told before, but we want
a clear sign that the port will be supported throughout the whole
release cycle (which honestly looks more and more like it could be the
case, though I still fail to see why randomly crashing and segfaulting
buildds and decreasing support for programming languages before Lenny
was not seen as critical enough).

Cheers

Luk


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



Re: HPPA and Squeeze

2009-06-18 Thread Luk Claes
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
 maintainers and others.
   
 If you looked at https://buildd.debian.org/stats/graph-big.png  I think
 it is obvious hppa is not *that* broken. hppa is 95% built. That is not
 that bad. Of course, it can be better, but if you looked at this with a
 historical perspective the port is really in a pretty good shape.

As already was explained, the issue is not that builds don't succeed
after multiple tries. The issue is that sometimes multiple tries are
needed and sometimes the buildds crash.

 If you looked at the status of the toolchain posted to the
 gcc-testresults page: http://gcc.gnu.org/ml/gcc-testresults/2009-06/ 
 you can see that hppa is one of the better architectures out there. Our
 results are on par with (if not better than) other supported architectures.

I hope that it will show in the reliability of the buildds and the
general improvement of support for the hppa port.

Cheers

Luk


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



Re: HPPA and Squeeze

2009-06-17 Thread Carlos O'Donell
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,
 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 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...


 BTW, Carlos, could you please send me the latest version of your
 patches, so that we can actually do the switch with version 2.10?

I'm in the middle of a build-test cycle with glibc/glibc-ports git
head. I'll send you the patches before the end of today.

Cheers,
Carlos.


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



Re: HPPA and Squeeze

2009-06-17 Thread Grant Grundler
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 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 uniprocessor kernel right now, and I believe the
  segfaults have mostly gone away (although buildd should chime in if I'm
  not remembering right - they will see more of the machine than I do).
  That being said, if the porters and buildd people are happy to put the
  SMP kernel back on and give him access, DSA have no objection.
 
 Ah - well if paer is running stably, then maybe a less invasive option
 would be to setup duplicate hardware and run a buildd that uploads to
 /dev/null. I have an rp2470 (same hw is paer) we could probably setup
 for that.

I'm all for less invasive/disruptive option and have the HW available.

Dann pointed jsw at me and I'll set jsw up with full remote
access to the HW. jsw said he would setup a buildd on the HW
that I manage. If we can reproduce the problem great. If not,
even better and it will be just a matter of getting the same
kernel (or equivalent) onto paer or other official hppa buildd machine.

thanks!
grant


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



Re: HPPA and Squeeze

2009-06-17 Thread Matthias Klose
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, Neil McGovern wrote:
 Hi,

 As mentioned previously[0], the release team haven't been happy with the
 state of the HPPA port in Debian. After the release team meeting[1], it
 has been decided that unfortunatly HPPA will not be supported for
 Squeeze. This was after careful consideration, and wasn't an easy
 decision.

 This means that ftpmasters will be asked to remove HPPA from testing and
 unstable from the 30th June. It is suggested that HPPA porters may wish
 to consider using debian-ports.org if they wish to continue with the
 port.

 Regards,
 Neil McGovern

 [0] http://lists.debian.org/debian-release/2009/04/msg00299.html
 Carlos O'Donnell asked some questions in response to [0] and I never
 saw any response.  Can an attendee of the above meeting please reply
 this email from Carlos?

 http://lists.debian.org/debian-release/2009/04/msg00303.html
 Note that it's wrong to assume we will come with the answers.
 
 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, time, and materials to.

+1. dropping hppa as a release architecture was not communicated by the release
team at all.  I did spend some time to get gcj / default-jdk working on hppa,
and some money (buying a new disk for a hppa machine) to help this port.  The
time and the money could have spent better, if d-r would have better
communicated about their intent.

hppa is not in a good shape, but there are other architectures which are not
better (sparc, mips*) from a toolchain point of view. what about these?

there are issues pointed out and not addressed like the -dev / -headers packages
 built as binary independent packages just to save disk space, which have an
impact on slow architectures, and which are not addressed by the release team.
would the release team mind addressing these real issues, or should we drop
slow architectures as well?

  Matthias


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



Re: HPPA and Squeeze

2009-06-17 Thread John David Anglin
 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, Neil McGovern wrote:
  Hi,
 
  As mentioned previously[0], the release team haven't been happy with the
  state of the HPPA port in Debian. After the release team meeting[1], it
  has been decided that unfortunatly HPPA will not be supported for
  Squeeze. This was after careful consideration, and wasn't an easy
  decision.
 
  This means that ftpmasters will be asked to remove HPPA from testing and
  unstable from the 30th June. It is suggested that HPPA porters may wish
  to consider using debian-ports.org if they wish to continue with the
  port.
 
  Regards,
  Neil McGovern
 
  [0] http://lists.debian.org/debian-release/2009/04/msg00299.html
  Carlos O'Donnell asked some questions in response to [0] and I never
  saw any response.  Can an attendee of the above meeting please reply
  this email from Carlos?
 
  http://lists.debian.org/debian-release/2009/04/msg00303.html
  Note that it's wrong to assume we will come with the answers.
  
  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, time, and materials to.
 
 +1. dropping hppa as a release architecture was not communicated by the 
 release
 team at all.  I did spend some time to get gcj / default-jdk working on hppa,
 and some money (buying a new disk for a hppa machine) to help this port.  The
 time and the money could have spent better, if d-r would have better
 communicated about their intent.

I totally understand your frustration.  I have spent thousands of hours
supporting hppa.  At my current rate, this would be...

I believe that intent to drop an architecture should be communicated well
in advance of the fact.  Not doing so will alienate the developer and
user communities.

 hppa is not in a good shape, but there are other architectures which are not
 better (sparc, mips*) from a toolchain point of view. what about these?

Sparc still exists as a mainframe architecture.  If you can afford a
high end server, it's probably not that slow.  64 processors, 256 cores,
and 512 threads at 2.52 GHz can't be all that bad ;)

As you know, it takes a lot of effort to keep a tool chain up to date.
If a manufacturer doesn't provide the support that is needed to keep
the tool chain going, then the open source support for it will die.
It can't be done without access to a variety of hardware, and documentation
that may be proprietary.

Mips and arm are primarily embedded architectures.  Unless one of
these manages to achieve market success as a low-end programmable device
running linux, the user community is going to be limited to the developers
working on products using these devices.  The workstation and server
market using mips is dead.

I was able to build up the tools I need for a Linux arm board in a few
days.  Thus, I don't really see the need for Debian to try to maintain
full blown builds and releases for these architectures.  Certainly,
there's a lot applications for linux in board products, but it's very
product specific.

I can understand the desire to trim architectures.  However, it's clear
the current decision was based on some misinformation, and an unclear
rational.

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


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



Re: HPPA and Squeeze

2009-06-16 Thread Lucas Nussbaum
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, time, and materials to.
 
   It's an
  extra bad feeling we get that even the people that do respond when there
  is a request regarding hppa porters don't know what the issues are...
 
 Expecting me to know the state of user space components is a bit silly.
 I'm not a DD. I'm a kernel developer. Specifically IO/Device Drivers.
 
 Carlos does know that state (toolchain/glibc) and he just wanted
 a list of issues that are driving this decision. It's a very reasonable
 question he asked.

[...]

 I can put one (and maybe two) machines on a public IP. Just ask.
 The remote console access will remain behind a fire wall.
 
 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 offer either.

(Stepping in ; I had some HPPA-related issues in one of my packages -
ruby1.9 - so this is based on my experience with that problems)

I think that your email summarizes the problem quite well: there are
several people willing to offer buildd hosting, help after someone else
has investigated the issues, etc.
What debian-hppa currently lacks is someone that is willing to
proactively detect issues (looking at packages that failed to build, for
example), investigate them, and fix them. This can be done cooperating
with the package maintainers, but the HPPA side should take the lead.
The fact that HPPA people are asking the release team what are the
problems you are talking about? clearly shows that this is broken: the
HPPA people should be knowing more than the release team about HPPA
issues.

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.
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


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



Re: HPPA and Squeeze

2009-06-16 Thread Helge Deller

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



Re: HPPA and Squeeze

2009-06-16 Thread Aurelien Jarno
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,
 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 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...


BTW, Carlos, could you please send me the latest version of your
patches, so that we can actually do the switch with version 2.10?

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


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



Re: HPPA and Squeeze

2009-06-16 Thread Grant Grundler
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 offer either.
 
 (Stepping in ; I had some HPPA-related issues in one of my packages -
 ruby1.9 - so this is based on my experience with that problems)
 
 I think that your email summarizes the problem quite well: there are
 several people willing to offer buildd hosting, help after someone else
 has investigated the issues, etc.
 What debian-hppa currently lacks is someone that is willing to
 proactively detect issues (looking at packages that failed to build, for
 example), investigate them, and fix them. This can be done cooperating
 with the package maintainers, but the HPPA side should take the lead.

Yup - this is definitely true. debian-hppa needed alot of prodding to
look at buildd failures.

 The fact that HPPA people are asking the release team what are the
 problems you are talking about? clearly shows that this is broken: the
 HPPA people should be knowing more than the release team about HPPA
 issues.

Generalizing one person's response (mine) to represent the group is wrong.

However I agree the release team has no one who cares about HPPA involved.
And yes, it's up to the release team to track bugs and determine
the viability of a release based on outstanding bugs.

As I said before, I'm ok with NOT having a stable HPPA release.
If someone disagrees, then they need to participate in the release
team and help debian-hppa focus on critical buildd failures. ie generate
the nag mail listing the HPPA-specific issues that need to be resolved.


 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.

This did take a long time to resolve. Helge described the root cause
(ruby did not support LinuxThreads implementation correctly) and
resolution plan (migrate HPPA to NTPL).

No phase of this problem sounds trivial to debug or resolve.
Based on this, I can argue the HPPA response is reasonable even
if is unsatisfactory and frustrating to you (as package maintainer).

Do you have another HPPA specific issue?
Or maybe just remind the list how to find those issues?
(Teach a man to fish...)

thanks,
grant


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



Re: HPPA and Squeeze

2009-06-16 Thread dann frazier
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 HPPA buildd machines
   as well but hasn't heard any response to that offer either.
  
  (Stepping in ; I had some HPPA-related issues in one of my packages -
  ruby1.9 - so this is based on my experience with that problems)
  
  I think that your email summarizes the problem quite well: there are
  several people willing to offer buildd hosting, help after someone else
  has investigated the issues, etc.
  What debian-hppa currently lacks is someone that is willing to
  proactively detect issues (looking at packages that failed to build, for
  example), investigate them, and fix them. This can be done cooperating
  with the package maintainers, but the HPPA side should take the lead.
 
 Yup - this is definitely true. debian-hppa needed alot of prodding to
 look at buildd failures.
 
  The fact that HPPA people are asking the release team what are the
  problems you are talking about? clearly shows that this is broken: the
  HPPA people should be knowing more than the release team about HPPA
  issues.
 
 Generalizing one person's response (mine) to represent the group is wrong.
 
 However I agree the release team has no one who cares about HPPA involved.
 And yes, it's up to the release team to track bugs and determine
 the viability of a release based on outstanding bugs.
 
 As I said before, I'm ok with NOT having a stable HPPA release.
 If someone disagrees, then they need to participate in the release
 team and help debian-hppa focus on critical buildd failures. ie generate
 the nag mail listing the HPPA-specific issues that need to be resolved.
 
 
  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.
 
 This did take a long time to resolve. Helge described the root cause
 (ruby did not support LinuxThreads implementation correctly) and
 resolution plan (migrate HPPA to NTPL).
 
 No phase of this problem sounds trivial to debug or resolve.
 Based on this, I can argue the HPPA response is reasonable even
 if is unsatisfactory and frustrating to you (as package maintainer).
 
 Do you have another HPPA specific issue?
 Or maybe just remind the list how to find those issues?
 (Teach a man to fish...)

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.

-- 
dann frazier


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



Re: HPPA and Squeeze

2009-06-16 Thread Stephen Gran
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 uniprocessor kernel right now, and I believe the
segfaults have mostly gone away (although buildd should chime in if I'm
not remembering right - they will see more of the machine than I do).
That being said, if the porters and buildd people are happy to put the
SMP kernel back on and give him access, DSA have no objection.

Cheers,
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :sg...@debian.org |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature


Re: HPPA and Squeeze

2009-06-16 Thread dann frazier
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 running a dummy buildd on
  another rp2470.
 
 We're running paer on a uniprocessor kernel right now, and I believe the
 segfaults have mostly gone away (although buildd should chime in if I'm
 not remembering right - they will see more of the machine than I do).
 That being said, if the porters and buildd people are happy to put the
 SMP kernel back on and give him access, DSA have no objection.

Ah - well if paer is running stably, then maybe a less invasive option
would be to setup duplicate hardware and run a buildd that uploads to
/dev/null. I have an rp2470 (same hw is paer) we could probably setup
for that.

-- 
dann frazier


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



Re: HPPA and Squeeze

2009-06-16 Thread John David Anglin
 Again, kernel bugs are sometimes hard to find.
 I still think that http://patchwork.kernel.org/patch/28458/ may fix a few.
 The only outstanding bug I still know of is that we sometimes face uid/gid 
 issues.
 This still needs analysis.

Helge suggested yesterday that the uid/gid issue might be a bug in nscd.
I installed 2.6.30 last night and disabled nscd.  I have now run for more
than a day without this issue appearing.  The machine did a full GCC build
and check taking about 24 hours.

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


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



Re: HPPA and Squeeze

2009-06-15 Thread Grant Grundler
On Mon, Jun 08, 2009 at 10:26:06PM +0100, Neil McGovern wrote:
 Firstly, thanks for your mail, apologies that I haven't replied sooner,
 we've had EU and local elections, so I've been busy runnign around with
 leaflets, knocking on doors, kissing babies etc. like any politician. No
 expenses though...

No problem.

 
 On Sat, Jun 06, 2009 at 12:36:01PM -0600, Grant Grundler wrote:
  Carlos O'Donnell asked some questions in response to [0] and I never
  saw any response.  Can an attendee of the above meeting please reply
  this email from Carlos?
  http://lists.debian.org/debian-release/2009/04/msg00303.html
  
 
 I'm not sure what replies you'd like... there's certainly been some
 follow ups to that mail.

The following questions haven't been answered in that thread:
1) Is there a list of different porting efforts?
2) What is considered proper java support? GCJ?

I've commented on the kernel side and it's looking better.
I don't know the status of the HPPA installer.

  I also never got a response to my offer here:
  http://lists.debian.org/debian-release/2009/04/msg00339.html
  
 
 Indeed, and that's worrying. I would have expected a HPPA porter (if
 indeed one still exists) to have replied to that.

Or they already have machines. I'm not a DD and don't aspire to be one.
So these are in the wild from a Debian point of view.

  Quite a few serious hppa specific bugs have been fixed upstream over
  the past 6 months. This is worth revisiting.
  
  Is upstream stable enough for a buildd?  I don't know since I'm not aware
  of any attempts to run a buildd with those kernels.
 
 Neither do we, we're not HPPA porters :)
 We did go through this before with newer kernels, and it didn't help
 FWIW.
 
  Is the answer to that question still germane?
 
 Ish. We still have the issue that you can't actually buy HPPAs any more,
 and various bits and pieces from the Arch Requalification list.

We can buy HPPA. Just not new ones. There are several resellers of
used HPPA gear if someone wants/needs to spend money on it.

Can you list the various bits and pieces specifically?

I can then prod the folks I know who might be able to do something about
if they still feel like it.


 [change of order by me below]
  Also, I'd like to ask HPPA debs be kept in testing staging area,
  just never promoted when the release is cut.  This will let people
  continue using HPPA without having to suffer with the !hppa breakage
  that lives in unstable. 
 
  (that's all I personally care about - I don't care about stable
  releases.)
 
 This is one of the major problems for the port. Testing exists to create
 the next stable release. Essentially, testing *is* the next stable,
 except that it's a little volatile for a number of months... :)

Ok.

  Can we have the minutes for this meeting?
 
 I'm afraid they're not publicly available, but I will be posting a
 mail to d-d-a real-soon-now(tm), apologies for the delays in this, it
 was a rather full meeting.

Given Debian is non-profit and strives to be transperent in it's operations,
this sounds like a digression in that effort.

I'm not on d-d-a. Can you please CC affected ports? (TIA)

cheers,
grant


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



Re: HPPA and Squeeze

2009-06-15 Thread Grant Grundler
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 wrote:
  Hi,
 
  As mentioned previously[0], the release team haven't been happy with the
  state of the HPPA port in Debian. After the release team meeting[1], it
  has been decided that unfortunatly HPPA will not be supported for
  Squeeze. This was after careful consideration, and wasn't an easy
  decision.
 
  This means that ftpmasters will be asked to remove HPPA from testing and
  unstable from the 30th June. It is suggested that HPPA porters may wish
  to consider using debian-ports.org if they wish to continue with the
  port.
 
  Regards,
  Neil McGovern
 
  [0] http://lists.debian.org/debian-release/2009/04/msg00299.html
  
  Carlos O'Donnell asked some questions in response to [0] and I never
  saw any response.  Can an attendee of the above meeting please reply
  this email from Carlos?
 
  http://lists.debian.org/debian-release/2009/04/msg00303.html
 
 Note that it's wrong to assume we will come with the answers.

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, time, and materials to.

  It's an
 extra bad feeling we get that even the people that do respond when there
 is a request regarding hppa porters don't know what the issues are...

Expecting me to know the state of user space components is a bit silly.
I'm not a DD. I'm a kernel developer. Specifically IO/Device Drivers.

Carlos does know that state (toolchain/glibc) and he just wanted
a list of issues that are driving this decision. It's a very reasonable
question he asked.

  I also never got a response to my offer here:
  http://lists.debian.org/debian-release/2009/04/msg00339.html
 
 There was some discussion with DSA and they didn't seem willing to take
 the offer as it would be very restricted regarding access and control
 (too strongly firewalled if I remember correctly) for our administrators.

I can put one (and maybe two) machines on a public IP. Just ask.
The remote console access will remain behind a fire wall.

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 offer either.

 It's rather strange that you did not get any feedback in
 that regard.

Agred. Maybe the problems that need to be resolved aren't technical ones.

In any case, responding to some of the above with specific concerns
should continue this constructive dialog.

 
  And my response again to this question posted in [0]:
  * The machines that host the buildds still seem to have a very
  unreliable kernel. Is there any update on this?
 
 It looks like the amount of random crashes has decreased and the amount
 of random segfaults has increased, though does not look promising after
 more than 2 years already of random issues like this.

The buildd is seeing issues most other HPPA users (including me) are
not seeing. That makes the problems quite a bit harder to resolve.

Last time I tried to set up a buildd was rather painful and exceeded
the amount of time I was willing to invest (vs contributing to other
kernel issues). This was more than 2 years ago and I'm willing to
try again IFF someone can tell me what impact that would have on
the Debian cabal that seems to be running things.

  Is upstream stable enough for a buildd?  I don't know since I'm not aware
  of any attempts to run a buildd with those kernels.
 
 Rather recent kernels have been tried and like said above seem to behave
 better, but still very much subpar.

Have bugs been filed for those issues that HPPA folks can look at?
How can I find them?

  Is the answer to that question still germane?
  If so, I'm willing to setup a local buildd and try it. But I will need
  more time and some commitment that if it works, hppa remain in testing
  release (that's all I personally care about - I don't care about stable
  releases.)
 
 That's not how it works. testing is the preparation for the next stable
 release, so staying in testing means fixing any important outstanding
 porting issue and most importantly the random crashes and segfaults,
 actively making sure there are no important issues with the hppa port
 within Debian and committing to support the next stable release.

Ok. Sounds like Helge is ok with unstable and I'll try switching to
unstable instead of testing. 


  Can we have the minutes for this meeting?
 
 No, I didn't even get the chance myself to read them. A summary of the
 minutes will be posted as usual in the next 'Bits from the 

Re: HPPA and Squeeze

2009-06-15 Thread Helge Deller

On 06/15/2009 06:26 PM, Grant Grundler wrote:

On Mon, Jun 08, 2009 at 10:26:06PM +0100, Neil McGovern wrote:

Firstly, thanks for your mail, apologies that I haven't replied sooner,
we've had EU and local elections, so I've been busy runnign around with
leaflets, knocking on doors, kissing babies etc. like any politician. No
expenses though...


No problem.


On Sat, Jun 06, 2009 at 12:36:01PM -0600, Grant Grundler wrote:

Carlos O'Donnell asked some questions in response to [0] and I never
saw any response.  Can an attendee of the above meeting please reply
this email from Carlos?
 http://lists.debian.org/debian-release/2009/04/msg00303.html


I'm not sure what replies you'd like... there's certainly been some
follow ups to that mail.


The following questions haven't been answered in that thread:
1) Is there a list of different porting efforts?
2) What is considered proper java support? GCJ?

I've commented on the kernel side and it's looking better.
I don't know the status of the HPPA installer.


The HPPA installer should be OK:
http://www.mail-archive.com/debian-hppa@lists.debian.org/msg06298.html

Helge


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



Re: HPPA and Squeeze

2009-06-14 Thread dann frazier
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 unstable seem to trip over issues that we
  don't see elsewhere.
 
 Workload more to the point.

Yes, workload is what I meant.

 Almost all my parisc boxen have been
 running BOINC for years and never puked on it. I'm quite convinced the
 issues buildds are suffering are much less random than people believe.
 It's more likely that they are very uncommon corner cases.
 
 FWIW, afaik lafayette - the autobuilder I recently provided - seems
 to be running mostly fine. And as far as I (as the local admin) am
 concerned, I believe my response time to problems (such as when the
 first hardware that was committed to this autobuilder failed beyond
 salvation and had to be entirely replaced) is acceptable. Let me know
 if that weren't true ;-)
 
 HTH
 T-Bone
 

-- 
dann frazier


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



Re: HPPA and Squeeze

2009-06-12 Thread Luk Claes
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 happy with the
 state of the HPPA port in Debian. After the release team meeting[1], it
 has been decided that unfortunatly HPPA will not be supported for
 Squeeze. This was after careful consideration, and wasn't an easy
 decision.

 This means that ftpmasters will be asked to remove HPPA from testing and
 unstable from the 30th June. It is suggested that HPPA porters may wish
 to consider using debian-ports.org if they wish to continue with the
 port.

 Regards,
 Neil McGovern

 [0] http://lists.debian.org/debian-release/2009/04/msg00299.html
 
 Carlos O'Donnell asked some questions in response to [0] and I never
 saw any response.  Can an attendee of the above meeting please reply
 this email from Carlos?

 http://lists.debian.org/debian-release/2009/04/msg00303.html

Note that it's wrong to assume we will come with the answers. It's an
extra bad feeling we get that even the people that do respond when there
is a request regarding hppa porters don't know what the issues are...

 I also never got a response to my offer here:
 http://lists.debian.org/debian-release/2009/04/msg00339.html

There was some discussion with DSA and they didn't seem willing to take
the offer as it would be very restricted regarding access and control
(too strongly firewalled if I remember correctly) for our
administrators. It's rather strange that you did not get any feedback in
that regard.

 And my response again to this question posted in [0]:
 * The machines that host the buildds still seem to have a very
 unreliable kernel. Is there any update on this?

It looks like the amount of random crashes has decreased and the amount
of random segfaults has increased, though does not look promising after
more than 2 years already of random issues like this.

 Is upstream stable enough for a buildd?  I don't know since I'm not aware
 of any attempts to run a buildd with those kernels.

Rather recent kernels have been tried and like said above seem to behave
better, but still very much subpar.

 Is the answer to that question still germane?
 If so, I'm willing to setup a local buildd and try it. But I will need
 more time and some commitment that if it works, hppa remain in testing
 release (that's all I personally care about - I don't care about stable
 releases.)

That's not how it works. testing is the preparation for the next stable
release, so staying in testing means fixing any important outstanding
porting issue and most importantly the random crashes and segfaults,
actively making sure there are no important issues with the hppa port
within Debian and committing to support the next stable release.

 Can we have the minutes for this meeting?

No, I didn't even get the chance myself to read them. A summary of the
minutes will be posted as usual in the next 'Bits from the Release Team'
though.

 Also, I'd like to ask HPPA debs be kept in testing staging area,
 just never promoted when the release is cut.  This will let people
 continue using HPPA without having to suffer with the !hppa breakage
 that lives in unstable.

This will get DSA, maintainers, release team and others keep being
frustrated that hppa issues are making their work harder and will only
be tolerated if there will finally be a clear commitment from the hppa
porters to deal with any present and future important porting issue in a
reasonable time frame.

The main problem we have with hppa is that important porter issues are
not dealt with in a reasonable time frame. The random crashes and
segfaults are lasting for years already!

Note that we do *NOT* intend to drop hppa from unstable, it being
mentioned at all was an unfortunate sign of the deep frustration of some...

Cheers

Luk

Debian Release Manager


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



Re: HPPA and Squeeze

2009-06-12 Thread Bart Schelstraete
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
with the hppa version.


Just to say that I'm personally not so unhappy with deb hppa, and that not
everything is bad.


B

On Fri, Jun 12, 2009 at 8:49 AM, Luk Claes l...@debian.org wrote:


 The main problem we have with hppa is that important porter issues are
 not dealt with in a reasonable time frame. The random crashes and
 segfaults are lasting for years already!

 Note that we do *NOT* intend to drop hppa from unstable, it being
 mentioned at all was an unfortunate sign of the deep frustration of some...


-- 
Schelstraete Bart
http://www.schelstraete.org
b...@schelstraete.org
Sent from Brussels, Brx, Belgium
Mae West http://www.brainyquote.com/quotes/authors/m/mae_west.html  - I
like restraint, if it doesn't go too far.


Re: HPPA and Squeeze

2009-06-12 Thread Bart Schelstraete
 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 with the hppa version.


 Just to say that I'm personally not so unhappy with deb hppa, and
that not everything is bad.


 B

 On Fri, Jun 12, 2009 at 8:49 AM, Luk Claes l...@debian.org wrote:

 The main problem we have with hppa is that important porter issues are
 not dealt with in a reasonable time frame. The random crashes and
 segfaults are lasting for years already!

 Note that we do *NOT* intend to drop hppa from unstable, it being
 mentioned at all was an unfortunate sign of the deep frustration of some...


 --
 Schelstraete Bart
 http://www.schelstraete.org
 b...@schelstraete.org
 Sent from Brussels, Brx, Belgium
 Mae West  - I like restraint, if it doesn't go too far.


--
Schelstraete Bart
http://www.schelstraete.org
b...@schelstraete.org
Sent from Brussels, Brx, Belgium
Erma Bombeck  - Never have more children than you have car windows.


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



Re: HPPA and Squeeze

2009-06-12 Thread Geoff
On Friday 12 June 2009 17:55, 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 need to say that I had a lot more crashes with the x86 version
 then with the hppa version.


  Just to say that I'm personally not so unhappy with deb hppa, and
 that not everything is bad.


  B
snipped

I agree with Bart. My C3700 is a very reliable HPPA box indeed. Currently it's 
been up for 21 days, the only thing that usually brings it down is a mains 
power failure. It is about as reliable as the Mandrake/Celeron box I used up 
until 18 months ago.

Cheers, Geoff.


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



Re: HPPA and Squeeze

2009-06-12 Thread James Bottomley
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 need to say that I had a lot more crashes with the x86 version
 then with the hppa version.

It seems to be related to what machine you actually have.  I run a B180
as my network gateway, handling firewall, web,
postfix/postgrey/spamassassin at quite a high volume on a domain.  I
also used to run it with a PCMCIA wireless card just for chuckles and
grins (although I stopped that two years ago when I got a linksys).  It
runs debian testing and has been completely stable.  I only reboot it
for updates and in the seven or so years I've been doing this, I haven't
had any segfaults or crashes ... have to say I only started using debian
kernels on it for the last four or so years, because there used to be
big problems with the ones they built.

  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, so can't verify.

James



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



Re: HPPA and Squeeze

2009-06-09 Thread Thomas Bogendoerfer
On Tue, Jun 09, 2009 at 10:29:54AM +0100, Neil McGovern wrote:
 However, I didn't mean it as a 'you must be able to get these from HP'.
 You can't find them on ebay (for the three days I looked), and this
 would indicate that it's unlikely that there's going to be sufficient
 new porters to make this work.

your ebay is broken.

A simple search for C3750 (an quite fast parisc workstation) on ebay.de
gives me four hits for complete systems. And there are other workstations
and servers on ebay.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea.[ RFC1925, 2.3 ]


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



Re: HPPA and Squeeze

2009-06-09 Thread Aioanei Rares

Neil McGovern wrote:

On Tue, Jun 09, 2009 at 01:44:27AM +0200, Thibaut VARENE wrote:
  

Ish. We still have the issue that you can't actually buy HPPAs any more,
  

When did being a marketed platform become a criteria for inclusion?
Is Debian the new Ubuntu? :-P




Well, back in 2005...
http://lists.debian.org/debian-devel-announce/2005/03/msg00012.html

However, I didn't mean it as a 'you must be able to get these from HP'.
You can't find them on ebay (for the three days I looked), and this
would indicate that it's unlikely that there's going to be sufficient
new porters to make this work.

  


www.gall.de and some more others

Failing this, could we please have a detailed rationale for the
decision?



It'll be in the d-d-a post, or linked from the post :)

Hope this helps,
Neil
  



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



Re: HPPA and Squeeze

2009-06-09 Thread John David Anglin
  Well, back in 2005...
  http://lists.debian.org/debian-devel-announce/2005/03/msg00012.html
 
  However, I didn't mean it as a 'you must be able to get these from HP'.
  You can't find them on ebay (for the three days I looked), and this
  would indicate that it's unlikely that there's going to be sufficient
  new porters to make this work.
 

 
 www.gall.de and some more others

And in the US,
http://www.cypress-tech.com/
http://www.more-computers.com/

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


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



Re: HPPA and Squeeze

2009-06-09 Thread Helge Deller
Hi Sune, all,

Sune Vuorela wrote:
 On 2009-06-08, Thibaut VARENE vare...@debian.org wrote:
 Failing this, could we please have a detailed rationale for the
 decision?
 
 I'm not in any way involved with the decision, but I support it.
 
 I have in the past had some issues with some of the packages I
 (co)-maintain in debian on hppa, and I have in the past spent much more
 time on those packages on hppa than its userbase deserve. And I'm not a
 hppa porter.

Yes, there have been issues.

 I personally don't mind that we in debian supports many architectures,
 but it should mainly be the porters who are responsible for fixing
 architecture weirdnesses, not the package maintainers.

Sure.
 
 I have really missed this from the hppa porters. It might be that hppa
 porters don't care for Qt on hppa. It might be that hppa porters don't
 care for KDE on hppa. 

I think that's not fair.
I'm a big KDE and Qt fan and when you reported the issues, I stepped in.

You had problems with the locking functions in Qt. I did sent you
fixes for that to fix it in the qt code base.
This was one of the threads:  
http://www.mail-archive.com/debian-hppa@lists.debian.org/msg05888.html
I have to admit, that I didn't checked if you integrated them yet, but since I 
didn't heard back, I expected you did.

Then, as a next step we stepped up to fix those Qt locking functions
at the place where they really needed to be fixed in the end, which is the gcc 
as atomic locking builtins.
Even this was integrated upstream:
http://permalink.gmane.org/gmane.comp.gcc.patches/166978

 But. As long as hppa is a release architecture in
 Debian, we have to have it working. And I have expected more help than I
 actually got.
 
 There has in the past 6-8 month been random segfaults of
 anything from make over moc to dpkg on the hppa buildds making it hard
 to get stuff built. It doesn't seem like anyone have actually worked on
 this, except the buildd admin giving the packages back and next time
 they succeeded.

Sometimes finding kernel bugs isn't easy.
I wouldn't be astonished, if this patch fixes those issues:
http://patchwork.kernel.org/patch/28458/
It still is on discussion on the hppa-kernel-list.

 It seems that the buildd's have issues with actually being on line, and
 it can take 1-3 days for the buildd admins to actually notice this.
 
 Up to the lenny release there was the you can crash a hppa machine by
 building ruby-issue, where the suggested solution was Let's not ship
 ruby and instead let anyone with a account crash our boxes.

The kernel crash was finally fixed by:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c61c25eb02757ecf697015ef4ae3675c5e114e2e
 
 And in general, I have the impression that random unexplainable
 failures is just too common for hppa to actually be able to support it
 in debian. And I also have the impression that the porters think that
 random unexplainable failures is fully acceptable.

No, it's not.
Again, kernel bugs are sometimes hard to find.
I still think that http://patchwork.kernel.org/patch/28458/ may fix a few.
The only outstanding bug I still know of is that we sometimes face uid/gid 
issues.
This still needs analysis.

All that said, personally I'm currently really happy about the hppa unstable 
port.
I'm regularly compiling some really big closed-source application on this 
platform
and gcc-3.4 and gij-4.4 are doing a really good thing. Furthermore, the already 
started
migration to NPTL (from linuxthreads) is great, from which I expect even better 
results.
For me hppa unstable is currently in such a good shape in which it hasn't been 
up to now.
So, dropping it now at _this_ _stage_ from unstable would be really sad after 
such a long 
(and imho sucessful) way.

Best regards,
Helge


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



Re: HPPA and Squeeze

2009-06-08 Thread Neil McGovern
Firstly, thanks for your mail, apologies that I haven't replied sooner,
we've had EU and local elections, so I've been busy runnign around with
leaflets, knocking on doors, kissing babies etc. like any politician. No
expenses though...

On Sat, Jun 06, 2009 at 12:36:01PM -0600, Grant Grundler wrote:
 Carlos O'Donnell asked some questions in response to [0] and I never
 saw any response.  Can an attendee of the above meeting please reply
 this email from Carlos?
 http://lists.debian.org/debian-release/2009/04/msg00303.html
 

I'm not sure what replies you'd like... there's certainly been some
follow ups to that mail.

 I also never got a response to my offer here:
 http://lists.debian.org/debian-release/2009/04/msg00339.html
 

Indeed, and that's worrying. I would have expected a HPPA porter (if
indeed one still exists) to have replied to that.

 Quite a few serious hppa specific bugs have been fixed upstream over
 the past 6 months. This is worth revisiting.
 
 Is upstream stable enough for a buildd?  I don't know since I'm not aware
 of any attempts to run a buildd with those kernels.
 

Neither do we, we're not HPPA porters :)
We did go through this before with newer kernels, and it didn't help
FWIW.

 Is the answer to that question still germane?

Ish. We still have the issue that you can't actually buy HPPAs any more,
and various bits and pieces from the Arch Requalification list.

[change of order by me below]
 Also, I'd like to ask HPPA debs be kept in testing staging area,
 just never promoted when the release is cut.  This will let people
 continue using HPPA without having to suffer with the !hppa breakage
 that lives in unstable. 

 (that's all I personally care about - I don't care about stable
 releases.)

This is one of the major problems for the port. Testing exists to create
the next stable release. Essentially, testing *is* the next stable,
except that it's a little volatile for a number of months... :)

 Can we have the minutes for this meeting?

I'm afraid they're not publicly available, but I will be posting a
mail to d-d-a real-soon-now(tm), apologies for the delays in this, it
was a rather full meeting.

Hope this helps,
Neil
-- 
A. Because it breaks the logical sequence of discussion
Q. Why is top posting bad?
gpg key - http://www.halon.org.uk/pubkey.txt ; the.earth.li A40F862E


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



Re: HPPA and Squeeze

2009-06-06 Thread Grant Grundler
+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 happy with the
 state of the HPPA port in Debian. After the release team meeting[1], it
 has been decided that unfortunatly HPPA will not be supported for
 Squeeze. This was after careful consideration, and wasn't an easy
 decision.
 
 This means that ftpmasters will be asked to remove HPPA from testing and
 unstable from the 30th June. It is suggested that HPPA porters may wish
 to consider using debian-ports.org if they wish to continue with the
 port.
 
 Regards,
 Neil McGovern
 
 [0] http://lists.debian.org/debian-release/2009/04/msg00299.html

Carlos O'Donnell asked some questions in response to [0] and I never
saw any response.  Can an attendee of the above meeting please reply
this email from Carlos?
http://lists.debian.org/debian-release/2009/04/msg00303.html

I also never got a response to my offer here:
http://lists.debian.org/debian-release/2009/04/msg00339.html


And my response again to this question posted in [0]:
 * The machines that host the buildds still seem to have a very
 unreliable kernel. Is there any update on this?

Quite a few serious hppa specific bugs have been fixed upstream over
the past 6 months. This is worth revisiting.

Is upstream stable enough for a buildd?  I don't know since I'm not aware
of any attempts to run a buildd with those kernels.

Is the answer to that question still germane?
If so, I'm willing to setup a local buildd and try it. But I will need
more time and some commitment that if it works, hppa remain in testing
release (that's all I personally care about - I don't care about stable
releases.)


 [1] http://lists.debian.org/debian-project/2009/05/msg00080.html

Can we have the minutes for this meeting?

Also, I'd like to ask HPPA debs be kept in testing staging area,
just never promoted when the release is cut.  This will let people
continue using HPPA without having to suffer with the !hppa breakage
that lives in unstable.

thanks,
grant


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



Re: HPPA and Squeeze

2009-06-03 Thread Thibaut VARENE
On Tue, Jun 2, 2009 at 4:07 PM, Neil McGovern ne...@debian.org wrote:
 Hi,

 As mentioned previously[0], the release team haven't been happy with the
 state of the HPPA port in Debian. After the release team meeting[1], it
 has been decided that unfortunatly HPPA will not be supported for
 Squeeze. This was after careful consideration, and wasn't an easy
 decision.

I don't question that. To make things as transparent as they should
be, could you elaborate on the grounds for that decision?

I think it'd be nice if those were publicly stated so that if people
raise eyebrows / want to help, they know exactly what's wrong.

Thanks

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/


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



Re: HPPA and Squeeze

2009-06-02 Thread Neil McGovern
On Tue, Jun 02, 2009 at 03:07:35PM +0100, Neil McGovern wrote:
 This means that ftpmasters will be asked to remove HPPA from testing and
 unstable from the 30th June. It is suggested that HPPA porters may wish
 to consider using debian-ports.org if they wish to continue with the
 port.
 

Erk, apologies for a couple of points in the above text which should
have been made clearer:
* HPPA will be removed from testing at that point. It's up to the FTP
  Masters to decide what to do with unstable.
* s/consider using/consider asking/ - I certainly didn't want to give
  the impression that I was trying to force anything on the admins!

Thanks,
Neil


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