open issues with the hppa port

[Andreas Barth]

Hi,

there are some issues in the hppa port that currently let us doubt whether
we should continue to carry on that port to next stable. Apart the fact
that hppa is no longer buyable as new, there are quite a few technical
issues.

You know your porters mailing list best, but I want to highlight some of
the issues:
http://lists.debian.org/debian-hppa/2009/07/msg00002.html
http://lists.debian.org/debian-hppa/2009/07/msg00050.html
http://lists.debian.org/debian-hppa/2009/07/msg00053.html

As from release team point of view, it is necessary that there is a plan
how hppa can and will return in the forseeable future to normal mode of
operation, i.e. there are not many issues with e.g. architecture specific
build failures.

I'd welcome your feedback with a list of open current issues and how and
when they will be resolved. It would be good to have that feedback before
end of August to avoid the necessity to treat the hppa port as broken in
regard to our testing migration scripts.



Cheers,
Andi
for the Debian Release Team


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Carlos O'Donell-2]

On Thu, Jul 30, 2009 at 10:50 AM, Andreas Barth<aba@...> wrote:
> You know your porters mailing list best, but I want to highlight some of
> the issues:
> http://lists.debian.org/debian-hppa/2009/07/msg00002.html

I can't comment on this issue. I hope Dave can?

> http://lists.debian.org/debian-hppa/2009/07/msg00050.html

Issue:
* When do we enable NPTL for HPPA?

Answer:
* When usability testing is done.

Done:
* Built eglibc deb with NPTL enabled.
* Setup test chroot.
* Installed eglibc deb into chroot.

In progress:
* More complex applications fail under the new glibc.
* Debug failing application.

Timeline:
* Two weeks at the very least.

> http://lists.debian.org/debian-hppa/2009/07/msg00053.html

Issue:
* guile-gnome-platform testsuite fails.

Answer:
* libtool's la loader is not functioning correctly.

Done:
* Initial triage and narrowing of bug down to libtool la loading problem.

In progress:
* Building a test case for libtool's libltdl.so to prove it is broken.

Timeline:
* One week, though this changes if libtool appears to be not at fault.

Cheers,
Carlos.


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[John David Anglin-4]

> On Thu, Jul 30, 2009 at 10:50 AM, Andreas Barth<aba@...> wrote:
> > You know your porters mailing list best, but I want to highlight some of
> > the issues:
> > http://lists.debian.org/debian-hppa/2009/07/msg00002.html
>
> I can't comment on this issue. I hope Dave can?

Over the past few weeks, I have been testing 2.6.30.y on three different
platforms (c3750, rp3440 and A500-7X).  I have run identical 32 and 64-bit
kernels on the c3750.

To the base system, I have applied a collected set of patches.  Except
for the typo change recently posted to the parisc linux list, all the
changes are now in 2.6.31.

With the exception of nscd, I have had no segfault problems with 2.6.30.y
on the c3750.

However, the same is not true for the rp3440 and A500-7X.  The rp3440
is worse than the A500-7X, but application segfaults occured very quickly
running SMP kernels building GCC (usually in our old friend the dynamic
loader).

The A500-7X (gsyprf11) is now back running a modified SMP version of
2.6.19.22.  Last change was the U bit fix.  It has now run eight days
without any obvious segfaults.

2.6.19.22 with the above changes is not segfault free on the rp3440.
However, it is better than any other SMP build on this processor.

I am currently running a UP build of 2.6.30.3 on the rp3440.  It is
not segfault free, but I can usually get through a GCC build without
a fault.  So, even with a UP kernel, we still get cache corruption
on this machine.  I wonder if it is possible to turn L2 off.

I had hoped that the U bit fix would help.  However, its effect is
not dramatic.  When rebooting the rp3440, it would sometimes report
memory errors in the system hardware log.  Similarly, the display
attached to the VisEG on the c3750 would sometimes get noisy.
Resetting the display mode at boot would cure this.  Another effect
was for cpus to mysteriously get disabled.  I suspect that
the kernel was sometimes accidently writing to the control memory
for these devices.  These problems may be fixed or reduced with
the U bit fix.

In summary, the segfault problem is still there and a major issue,
particularly with SMP kernels.  Without a testcase that consistently
triggers the problem, it's almost impossible to debug what's going
wrong.

glob2 built for me, so the build failure was probably caused by cache
corruption.

Dave
--
J. David Anglin                                  dave.anglin@...
National Research Council of Canada              [phone] (FAX: [phone])


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Carlos O'Donell-2]

On Thu, Jul 30, 2009 at 1:44 PM, John David
Anglin<dave@...> wrote:
>> On Thu, Jul 30, 2009 at 10:50 AM, Andreas Barth<aba@...> wrote:
>> > You know your porters mailing list best, but I want to highlight some of
>> > the issues:
>> > http://lists.debian.org/debian-hppa/2009/07/msg00002.html
>>
>> I can't comment on this issue. I hope Dave can?
>
> glob2 built for me, so the build failure was probably caused by cache
> corruption.

In your opinion, what is the most stable kernel configuration that
should be run on the buildds?

Cheers,
Carlos.


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[dann frazier]

On Thu, Jul 30, 2009 at 01:44:03PM -0400, John David Anglin wrote:

> > On Thu, Jul 30, 2009 at 10:50 AM, Andreas Barth<aba@...> wrote:
> > > You know your porters mailing list best, but I want to highlight some of
> > > the issues:
> > > http://lists.debian.org/debian-hppa/2009/07/msg00002.html
> >
> > I can't comment on this issue. I hope Dave can?
>
> Over the past few weeks, I have been testing 2.6.30.y on three different
> platforms (c3750, rp3440 and A500-7X).  I have run identical 32 and 64-bit
> kernels on the c3750.
>
> To the base system, I have applied a collected set of patches.  Except
> for the typo change recently posted to the parisc linux list, all the
> changes are now in 2.6.31.

Thanks Dave.

If you can point me to these changesets, I can get them into the
2.6.30 kernel in sid so that we can start getting wider testing
sooner.

--
dann frazier


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[John David Anglin-4]

On Thu, 30 Jul 2009, Carlos O'Donell wrote:

> In your opinion, what is the most stable kernel configuration that
> should be run on the buildds?

If the buildd has to run a SMP kernel, then 2.6.22.19 as patched for gsyprf11.
There is a minor issue wrt setting the RTC at startup, but it can be worked
around.
   
The main problem is 2.6.22.19 is too old.  However, I think the relevant
kernel packages can be installed.
     
If the buildd can run a UP kernel, then 2.6.30.y is fine.  There are some
issues on pa8800/pa8900 machines, but all kernels have issues on these
machines as far as I know.

I attached my patch collection for 2.6.30.3 as it stands.  Most of the
changes could be backported to 2.6.29.

Dave
--
J. David Anglin                                  dave.anglin@...
National Research Council of Canada              [phone] (FAX: [phone])

diff --git a/arch/parisc/include/asm/atomic.h b/arch/parisc/include/asm/atomic.h
index ada3e53..7d5ebf1 100644
--- a/arch/parisc/include/asm/atomic.h
+++ b/arch/parisc/include/asm/atomic.h
@@ -222,13 +222,13 @@ static __inline__ int atomic_add_unless(atomic_t *v, int a, int u)
 
 #define atomic_inc_not_zero(v) atomic_add_unless((v), 1, 0)
 
-#define atomic_add(i,v) ((void)(__atomic_add_return( ((int)(i)),(v))))
-#define atomic_sub(i,v) ((void)(__atomic_add_return(-((int)(i)),(v))))
+#define atomic_add(i,v) ((void)(__atomic_add_return( (i),(v))))
+#define atomic_sub(i,v) ((void)(__atomic_add_return(-(i),(v))))
 #define atomic_inc(v) ((void)(__atomic_add_return(   1,(v))))
 #define atomic_dec(v) ((void)(__atomic_add_return(  -1,(v))))
 
-#define atomic_add_return(i,v) (__atomic_add_return( ((int)(i)),(v)))
-#define atomic_sub_return(i,v) (__atomic_add_return(-((int)(i)),(v)))
+#define atomic_add_return(i,v) (__atomic_add_return( (i),(v)))
+#define atomic_sub_return(i,v) (__atomic_add_return(-(i),(v)))
 #define atomic_inc_return(v) (__atomic_add_return(   1,(v)))
 #define atomic_dec_return(v) (__atomic_add_return(  -1,(v)))
 
diff --git a/arch/parisc/include/asm/dma.h b/arch/parisc/include/asm/dma.h
index 31ad0f0..f7a18f9 100644
--- a/arch/parisc/include/asm/dma.h
+++ b/arch/parisc/include/asm/dma.h
@@ -1,5 +1,4 @@
-/* $Id: dma.h,v 1.2 1999/04/27 00:46:18 deller Exp $
- * linux/include/asm/dma.h: Defines for using and allocating dma channels.
+/* asm/dma.h: Defines for using and allocating dma channels.
  * Written by Hennus Bergman, 1992.
  * High DMA channel support & info by Hannu Savolainen
  * and John Boyd, Nov. 1992.
diff --git a/arch/parisc/include/asm/system.h b/arch/parisc/include/asm/system.h
index ee80c92..d91357b 100644
--- a/arch/parisc/include/asm/system.h
+++ b/arch/parisc/include/asm/system.h
@@ -168,8 +168,8 @@ static inline void set_eiem(unsigned long val)
 /* LDCW, the only atomic read-write operation PA-RISC has. *sigh*.  */
 #define __ldcw(a) ({ \
  unsigned __ret; \
- __asm__ __volatile__(__LDCW " 0(%1),%0" \
- : "=r" (__ret) : "r" (a)); \
+ __asm__ __volatile__(__LDCW " 0(%2),%0" \
+ : "=r" (__ret), "+m" (*(a)) : "r" (a)); \
  __ret; \
 })
 
diff --git a/arch/parisc/include/asm/tlbflush.h b/arch/parisc/include/asm/tlbflush.h
index 1f6fd4f..217588e 100644
--- a/arch/parisc/include/asm/tlbflush.h
+++ b/arch/parisc/include/asm/tlbflush.h
@@ -18,8 +18,8 @@
  */
 extern spinlock_t pa_tlb_lock;
 
-#define purge_tlb_start(x) spin_lock(&pa_tlb_lock)
-#define purge_tlb_end(x) spin_unlock(&pa_tlb_lock)
+#define purge_tlb_start(flags) spin_lock_irqsave(&pa_tlb_lock, flags)
+#define purge_tlb_end(flags) spin_unlock_irqrestore(&pa_tlb_lock, flags)
 
 extern void flush_tlb_all(void);
 extern void flush_tlb_all_local(void *);
@@ -64,13 +64,14 @@ static inline void flush_tlb_page(struct vm_area_struct *vma,
  unsigned long addr)
 {
  /* For one page, it's not worth testing the split_tlb variable */
+ unsigned long flags;
 
  mb();
  mtsp(vma->vm_mm->context,1);
- purge_tlb_start();
+ purge_tlb_start(flags);
  pdtlb(addr);
  pitlb(addr);
- purge_tlb_end();
+ purge_tlb_end(flags);
 }
 
 void __flush_tlb_range(unsigned long sid,
diff --git a/arch/parisc/include/asm/unistd.h b/arch/parisc/include/asm/unistd.h
index ef26b00..a3c3419 100644
--- a/arch/parisc/include/asm/unistd.h
+++ b/arch/parisc/include/asm/unistd.h
@@ -807,8 +807,10 @@
 #define __NR_dup3 (__NR_Linux + 312)
 #define __NR_pipe2 (__NR_Linux + 313)
 #define __NR_inotify_init1 (__NR_Linux + 314)
+#define __NR_preadv (__NR_Linux + 315)
+#define __NR_pwritev (__NR_Linux + 316)
 
-#define __NR_Linux_syscalls (__NR_inotify_init1 + 1)
+#define __NR_Linux_syscalls (__NR_pwritev + 1)
 
 
 #define __IGNORE_select /* newselect */
diff --git a/arch/parisc/kernel/cache.c b/arch/parisc/kernel/cache.c
index 837530e..57b3908 100644
--- a/arch/parisc/kernel/cache.c
+++ b/arch/parisc/kernel/cache.c
@@ -1,5 +1,4 @@
-/* $Id: cache.c,v 1.4 2000/01/25 00:11:38 prumpf Exp $
- *
+/*
  * This file is subject to the terms and conditions of the GNU General Public
  * License.  See the file "COPYING" in the main directory of this archive
  * for more details.
@@ -400,10 +399,11 @@ void clear_user_page_asm(void *page, unsigned long vaddr)
 {
  /* This function is implemented in assembly in pacache.S */
  extern void __clear_user_page_asm(void *page, unsigned long vaddr);
+ unsigned long flags;
 
- purge_tlb_start();
+ purge_tlb_start(flags);
  __clear_user_page_asm(page, vaddr);
- purge_tlb_end();
+ purge_tlb_end(flags);
 }
 
 #define FLUSH_THRESHOLD 0x80000 /* 0.5MB */
@@ -444,20 +444,22 @@ extern void clear_user_page_asm(void *page, unsigned long vaddr);
 
 void clear_user_page(void *page, unsigned long vaddr, struct page *pg)
 {
+ unsigned long flags;
  purge_kernel_dcache_page((unsigned long)page);
- purge_tlb_start();
+ purge_tlb_start(flags);
  pdtlb_kernel(page);
- purge_tlb_end();
+ purge_tlb_end(flags);
  clear_user_page_asm(page, vaddr);
 }
 EXPORT_SYMBOL(clear_user_page);
 
 void flush_kernel_dcache_page_addr(void *addr)
 {
+ unsigned long flags;
  flush_kernel_dcache_page_asm(addr);
- purge_tlb_start();
+ purge_tlb_start(flags);
  pdtlb_kernel(addr);
- purge_tlb_end();
+ purge_tlb_end(flags);
 }
 EXPORT_SYMBOL(flush_kernel_dcache_page_addr);
 
@@ -490,8 +492,9 @@ void __flush_tlb_range(unsigned long sid, unsigned long start,
  if (npages >= 512)  /* 2MB of space: arbitrary, should be tuned */
  flush_tlb_all();
  else {
+ unsigned long flags;
  mtsp(sid, 1);
- purge_tlb_start();
+ purge_tlb_start(flags);
  if (split_tlb) {
  while (npages--) {
  pdtlb(start);
@@ -504,7 +507,7 @@ void __flush_tlb_range(unsigned long sid, unsigned long start,
  start += PAGE_SIZE;
  }
  }
- purge_tlb_end();
+ purge_tlb_end(flags);
  }
 }
 
diff --git a/arch/parisc/kernel/entry.S b/arch/parisc/kernel/entry.S
index ae3e70c..e552e54 100644
--- a/arch/parisc/kernel/entry.S
+++ b/arch/parisc/kernel/entry.S
@@ -553,7 +553,7 @@
  * on most of those machines only handles cache transactions.
  */
  extrd,u,*= \pte,_PAGE_NO_CACHE_BIT+32,1,%r0
- depi 1,12,1,\prot
+ depdi 1,12,1,\prot
 
  /* Drop prot bits and convert to page addr for iitlbt and idtlbt */
  convert_for_tlb_insert20 \pte
diff --git a/arch/parisc/kernel/inventory.c b/arch/parisc/kernel/inventory.c
index bd1f7f1..bb3195b 100644
--- a/arch/parisc/kernel/inventory.c
+++ b/arch/parisc/kernel/inventory.c
@@ -170,23 +170,27 @@ static void __init pagezero_memconfig(void)
 static int __init
 pat_query_module(ulong pcell_loc, ulong mod_index)
 {
- pdc_pat_cell_mod_maddr_block_t pa_pdc_cell;
+ pdc_pat_cell_mod_maddr_block_t *pa_pdc_cell;
  unsigned long bytecnt;
  unsigned long temp; /* 64-bit scratch value */
  long status; /* PDC return value status */
  struct parisc_device *dev;
 
+ pa_pdc_cell = kmalloc(sizeof (*pa_pdc_cell), GFP_KERNEL);
+ if (!pa_pdc_cell)
+ panic("couldn't allocate memory for PDC_PAT_CELL!");
+
  /* return cell module (PA or Processor view) */
  status = pdc_pat_cell_module(&bytecnt, pcell_loc, mod_index,
-     PA_VIEW, &pa_pdc_cell);
+     PA_VIEW, pa_pdc_cell);
 
  if (status != PDC_OK) {
  /* no more cell modules or error */
  return status;
  }
 
- temp = pa_pdc_cell.cba;
- dev = alloc_pa_dev(PAT_GET_CBA(temp), &pa_pdc_cell.mod_path);
+ temp = pa_pdc_cell->cba;
+ dev = alloc_pa_dev(PAT_GET_CBA(temp), &(pa_pdc_cell->mod_path));
  if (!dev) {
  return PDC_OK;
  }
@@ -203,8 +207,8 @@ pat_query_module(ulong pcell_loc, ulong mod_index)
 
  /* save generic info returned from the call */
  /* REVISIT: who is the consumer of this? not sure yet... */
- dev->mod_info = pa_pdc_cell.mod_info; /* pass to PAT_GET_ENTITY() */
- dev->pmod_loc = pa_pdc_cell.mod_location;
+ dev->mod_info = pa_pdc_cell->mod_info; /* pass to PAT_GET_ENTITY() */
+ dev->pmod_loc = pa_pdc_cell->mod_location;
 
  register_parisc_device(dev); /* advertise device */
 
@@ -216,14 +220,14 @@ pat_query_module(ulong pcell_loc, ulong mod_index)
 
  case PAT_ENTITY_PROC:
  printk(KERN_DEBUG "PAT_ENTITY_PROC: id_eid 0x%lx\n",
- pa_pdc_cell.mod[0]);
+ pa_pdc_cell->mod[0]);
  break;
 
  case PAT_ENTITY_MEM:
  printk(KERN_DEBUG
  "PAT_ENTITY_MEM: amount 0x%lx min_gni_base 0x%lx min_gni_len 0x%lx\n",
- pa_pdc_cell.mod[0], pa_pdc_cell.mod[1],
- pa_pdc_cell.mod[2]);
+ pa_pdc_cell->mod[0], pa_pdc_cell->mod[1],
+ pa_pdc_cell->mod[2]);
  break;
  case PAT_ENTITY_CA:
  printk(KERN_DEBUG "PAT_ENTITY_CA: %ld\n", pcell_loc);
@@ -243,23 +247,26 @@ pat_query_module(ulong pcell_loc, ulong mod_index)
  print_ranges:
  pdc_pat_cell_module(&bytecnt, pcell_loc, mod_index,
     IO_VIEW, &io_pdc_cell);
- printk(KERN_DEBUG "ranges %ld\n", pa_pdc_cell.mod[1]);
- for (i = 0; i < pa_pdc_cell.mod[1]; i++) {
+ printk(KERN_DEBUG "ranges %ld\n", pa_pdc_cell->mod[1]);
+ for (i = 0; i < pa_pdc_cell->mod[1]; i++) {
  printk(KERN_DEBUG
  "  PA_VIEW %ld: 0x%016lx 0x%016lx 0x%016lx\n",
- i, pa_pdc_cell.mod[2 + i * 3], /* type */
- pa_pdc_cell.mod[3 + i * 3], /* start */
- pa_pdc_cell.mod[4 + i * 3]); /* finish (ie end) */
+ i, pa_pdc_cell->mod[2 + i * 3], /* type */
+ pa_pdc_cell->mod[3 + i * 3], /* start */
+ pa_pdc_cell->mod[4 + i * 3]); /* finish (ie end) */
  printk(KERN_DEBUG
  "  IO_VIEW %ld: 0x%016lx 0x%016lx 0x%016lx\n",
- i, io_pdc_cell.mod[2 + i * 3], /* type */
- io_pdc_cell.mod[3 + i * 3], /* start */
- io_pdc_cell.mod[4 + i * 3]); /* finish (ie end) */
+ i, io_pdc_cell->mod[2 + i * 3], /* type */
+ io_pdc_cell->mod[3 + i * 3], /* start */
+ io_pdc_cell->mod[4 + i * 3]); /* finish (ie end) */
  }
  printk(KERN_DEBUG "\n");
  break;
  }
 #endif /* DEBUG_PAT */
+
+ kfree(pa_pdc_cell);
+
  return PDC_OK;
 }
 
diff --git a/arch/parisc/kernel/irq.c b/arch/parisc/kernel/irq.c
index 4ea4229..5dc6cc1 100644
--- a/arch/parisc/kernel/irq.c
+++ b/arch/parisc/kernel/irq.c
@@ -120,7 +120,7 @@ int cpu_check_affinity(unsigned int irq, const struct cpumask *dest)
  if (CHECK_IRQ_PER_CPU(irq)) {
  /* Bad linux design decision.  The mask has already
  * been set; we must reset it */
- cpumask_setall(&irq_desc[irq].affinity);
+ cpumask_setall(irq_desc[irq].affinity);
  return -EINVAL;
  }
 
@@ -138,11 +138,11 @@ static void cpu_set_affinity_irq(unsigned int irq, const struct cpumask *dest)
  if (cpu_dest < 0)
  return;
 
- cpumask_copy(&irq_desc[irq].affinity, dest);
+ cpumask_copy(irq_desc[irq].affinity, dest);
 }
 #endif
 
-static struct hw_interrupt_type cpu_interrupt_type = {
+static struct irq_chip cpu_interrupt_type = {
  .typename = "CPU",
  .startup = cpu_startup_irq,
  .shutdown = cpu_disable_irq,
@@ -297,7 +297,7 @@ int txn_alloc_irq(unsigned int bits_wide)
 unsigned long txn_affinity_addr(unsigned int irq, int cpu)
 {
 #ifdef CONFIG_SMP
- cpumask_copy(&irq_desc[irq].affinity, cpumask_of(cpu));
+ cpumask_copy(irq_desc[irq].affinity, cpumask_of(cpu));
 #endif
 
  return per_cpu(cpu_data, cpu).txn_addr;
@@ -354,7 +354,7 @@ void do_cpu_irq_mask(struct pt_regs *regs)
  irq = eirr_to_irq(eirr_val);
 
 #ifdef CONFIG_SMP
- cpumask_copy(&dest, &irq_desc[irq].affinity);
+ cpumask_copy(&dest, irq_desc[irq].affinity);
  if (CHECK_IRQ_PER_CPU(irq_desc[irq].status) &&
     !cpu_isset(smp_processor_id(), dest)) {
  int cpu = first_cpu(dest);
diff --git a/arch/parisc/kernel/pci-dma.c b/arch/parisc/kernel/pci-dma.c
index 7d927ea..b8ec5a0 100644
--- a/arch/parisc/kernel/pci-dma.c
+++ b/arch/parisc/kernel/pci-dma.c
@@ -90,12 +90,13 @@ static inline int map_pte_uncached(pte_t * pte,
  if (end > PMD_SIZE)
  end = PMD_SIZE;
  do {
+ unsigned long flags;
  if (!pte_none(*pte))
  printk(KERN_ERR "map_pte_uncached: page already exists\n");
  set_pte(pte, __mk_pte(*paddr_ptr, PAGE_KERNEL_UNC));
- purge_tlb_start();
+ purge_tlb_start(flags);
  pdtlb_kernel(orig_vaddr);
- purge_tlb_end();
+ purge_tlb_end(flags);
  vaddr += PAGE_SIZE;
  orig_vaddr += PAGE_SIZE;
  (*paddr_ptr) += PAGE_SIZE;
@@ -168,11 +169,12 @@ static inline void unmap_uncached_pte(pmd_t * pmd, unsigned long vaddr,
  if (end > PMD_SIZE)
  end = PMD_SIZE;
  do {
+ unsigned long flags;
  pte_t page = *pte;
  pte_clear(&init_mm, vaddr, pte);
- purge_tlb_start();
+ purge_tlb_start(flags);
  pdtlb_kernel(orig_vaddr);
- purge_tlb_end();
+ purge_tlb_end(flags);
  vaddr += PAGE_SIZE;
  orig_vaddr += PAGE_SIZE;
  pte++;
diff --git a/arch/parisc/kernel/pci.c b/arch/parisc/kernel/pci.c
index 6936386..f7064ab 100644
--- a/arch/parisc/kernel/pci.c
+++ b/arch/parisc/kernel/pci.c
@@ -1,5 +1,4 @@
-/* $Id: pci.c,v 1.6 2000/01/29 00:12:05 grundler Exp $
- *
+/*
  * This file is subject to the terms and conditions of the GNU General Public
  * License.  See the file "COPYING" in the main directory of this archive
  * for more details.
diff --git a/arch/parisc/kernel/processor.c b/arch/parisc/kernel/processor.c
index e09d0f7..c8fb61e 100644
--- a/arch/parisc/kernel/processor.c
+++ b/arch/parisc/kernel/processor.c
@@ -1,5 +1,4 @@
-/*    $Id: processor.c,v 1.1 2002/07/20 16:27:06 rhirst Exp $
- *
+/*
  *    Initial setup-routines for HP 9000 based hardware.
  *
  *    Copyright (C) 1991, 1992, 1995  Linus Torvalds
@@ -121,22 +120,28 @@ static int __cpuinit processor_probe(struct parisc_device *dev)
  if (is_pdc_pat()) {
  ulong status;
  unsigned long bytecnt;
-        pdc_pat_cell_mod_maddr_block_t pa_pdc_cell;
+        pdc_pat_cell_mod_maddr_block_t *pa_pdc_cell;
 #undef USE_PAT_CPUID
 #ifdef USE_PAT_CPUID
  struct pdc_pat_cpu_num cpu_info;
 #endif
 
+ pa_pdc_cell = kmalloc(sizeof (*pa_pdc_cell), GFP_KERNEL);
+ if (!pa_pdc_cell)
+ panic("couldn't allocate memory for PDC_PAT_CELL!");
+
  status = pdc_pat_cell_module(&bytecnt, dev->pcell_loc,
- dev->mod_index, PA_VIEW, &pa_pdc_cell);
+ dev->mod_index, PA_VIEW, pa_pdc_cell);
 
  BUG_ON(PDC_OK != status);
 
  /* verify it's the same as what do_pat_inventory() found */
- BUG_ON(dev->mod_info != pa_pdc_cell.mod_info);
- BUG_ON(dev->pmod_loc != pa_pdc_cell.mod_location);
+ BUG_ON(dev->mod_info != pa_pdc_cell->mod_info);
+ BUG_ON(dev->pmod_loc != pa_pdc_cell->mod_location);
+
+ txn_addr = pa_pdc_cell->mod[0];   /* id_eid for IO sapic */
 
- txn_addr = pa_pdc_cell.mod[0];   /* id_eid for IO sapic */
+ kfree(pa_pdc_cell);
 
 #ifdef USE_PAT_CPUID
 /* We need contiguous numbers for cpuid. Firmware's notion
diff --git a/arch/parisc/kernel/setup.c b/arch/parisc/kernel/setup.c
index 82131ca..cb71f3d 100644
--- a/arch/parisc/kernel/setup.c
+++ b/arch/parisc/kernel/setup.c
@@ -1,5 +1,4 @@
-/*    $Id: setup.c,v 1.8 2000/02/02 04:42:38 prumpf Exp $
- *
+/*
  *    Initial setup-routines for HP 9000 based hardware.
  *
  *    Copyright (C) 1991, 1992, 1995  Linus Torvalds
diff --git a/arch/parisc/kernel/sys_parisc32.c b/arch/parisc/kernel/sys_parisc32.c
index 0838155..7488cfd 100644
--- a/arch/parisc/kernel/sys_parisc32.c
+++ b/arch/parisc/kernel/sys_parisc32.c
@@ -179,68 +179,6 @@ asmlinkage long sys32_sched_rr_get_interval(pid_t pid,
  return ret;
 }
 
-/*** copied from mips64 ***/
-/*
- * Ooo, nasty.  We need here to frob 32-bit unsigned longs to
- * 64-bit unsigned longs.
- */
-
-static inline int
-get_fd_set32(unsigned long n, u32 *ufdset, unsigned long *fdset)
-{
- n = (n + 8*sizeof(u32) - 1) / (8*sizeof(u32));
- if (ufdset) {
- unsigned long odd;
-
- if (!access_ok(VERIFY_WRITE, ufdset, n*sizeof(u32)))
- return -EFAULT;
-
- odd = n & 1UL;
- n &= ~1UL;
- while (n) {
- unsigned long h, l;
- __get_user(l, ufdset);
- __get_user(h, ufdset+1);
- ufdset += 2;
- *fdset++ = h << 32 | l;
- n -= 2;
- }
- if (odd)
- __get_user(*fdset, ufdset);
- } else {
- /* Tricky, must clear full unsigned long in the
- * kernel fdset at the end, this makes sure that
- * actually happens.
- */
- memset(fdset, 0, ((n + 1) & ~1)*sizeof(u32));
- }
- return 0;
-}
-
-static inline void
-set_fd_set32(unsigned long n, u32 *ufdset, unsigned long *fdset)
-{
- unsigned long odd;
- n = (n + 8*sizeof(u32) - 1) / (8*sizeof(u32));
-
- if (!ufdset)
- return;
-
- odd = n & 1UL;
- n &= ~1UL;
- while (n) {
- unsigned long h, l;
- l = *fdset++;
- h = l >> 32;
- __put_user(l, ufdset);
- __put_user(h, ufdset+1);
- ufdset += 2;
- n -= 2;
- }
- if (odd)
- __put_user(*fdset, ufdset);
-}
-
 struct msgbuf32 {
     int mtype;
     char mtext[1];
diff --git a/arch/parisc/kernel/syscall_table.S b/arch/parisc/kernel/syscall_table.S
index 03b9a01..6a62961 100644
--- a/arch/parisc/kernel/syscall_table.S
+++ b/arch/parisc/kernel/syscall_table.S
@@ -413,6 +413,8 @@
  ENTRY_SAME(dup3)
  ENTRY_SAME(pipe2)
  ENTRY_SAME(inotify_init1)
+ ENTRY_COMP(preadv)
+ ENTRY_COMP(pwritev)
 
  /* Nothing yet */
 
diff --git a/arch/parisc/kernel/time.c b/arch/parisc/kernel/time.c
index d4dd056..a79c6f9 100644
--- a/arch/parisc/kernel/time.c
+++ b/arch/parisc/kernel/time.c
@@ -56,9 +56,9 @@ static unsigned long clocktick __read_mostly; /* timer cycles per tick */
  */
 irqreturn_t __irq_entry timer_interrupt(int irq, void *dev_id)
 {
- unsigned long now;
+ unsigned long now, now2;
  unsigned long next_tick;
- unsigned long cycles_elapsed, ticks_elapsed;
+ unsigned long cycles_elapsed, ticks_elapsed = 1;
  unsigned long cycles_remainder;
  unsigned int cpu = smp_processor_id();
  struct cpuinfo_parisc *cpuinfo = &per_cpu(cpu_data, cpu);
@@ -71,44 +71,24 @@ irqreturn_t __irq_entry timer_interrupt(int irq, void *dev_id)
  /* Initialize next_tick to the expected tick time. */
  next_tick = cpuinfo->it_value;
 
- /* Get current interval timer.
- * CR16 reads as 64 bits in CPU wide mode.
- * CR16 reads as 32 bits in CPU narrow mode.
- */
+ /* Get current cycle counter (Control Register 16). */
  now = mfctl(16);
 
  cycles_elapsed = now - next_tick;
 
- if ((cycles_elapsed >> 5) < cpt) {
+ if ((cycles_elapsed >> 6) < cpt) {
  /* use "cheap" math (add/subtract) instead
  * of the more expensive div/mul method
  */
  cycles_remainder = cycles_elapsed;
- ticks_elapsed = 1;
  while (cycles_remainder > cpt) {
  cycles_remainder -= cpt;
  ticks_elapsed++;
  }
  } else {
+ /* TODO: Reduce this to one fdiv op */
  cycles_remainder = cycles_elapsed % cpt;
- ticks_elapsed = 1 + cycles_elapsed / cpt;
- }
-
- /* Can we differentiate between "early CR16" (aka Scenario 1) and
- * "long delay" (aka Scenario 3)? I don't think so.
- *
- * We expected timer_interrupt to be delivered at least a few hundred
- * cycles after the IT fires. But it's arbitrary how much time passes
- * before we call it "late". I've picked one second.
- */
- if (unlikely(ticks_elapsed > HZ)) {
- /* Scenario 3: very long delay?  bad in any case */
- printk (KERN_CRIT "timer_interrupt(CPU %d): delayed!"
- " cycles %lX rem %lX "
- " next/now %lX/%lX\n",
- cpu,
- cycles_elapsed, cycles_remainder,
- next_tick, now );
+ ticks_elapsed += cycles_elapsed / cpt;
  }
 
  /* convert from "division remainder" to "remainder of clock tick" */
@@ -122,18 +102,56 @@ irqreturn_t __irq_entry timer_interrupt(int irq, void *dev_id)
 
  cpuinfo->it_value = next_tick;
 
- /* Skip one clocktick on purpose if we are likely to miss next_tick.
- * We want to avoid the new next_tick being less than CR16.
- * If that happened, itimer wouldn't fire until CR16 wrapped.
- * We'll catch the tick we missed on the tick after that.
+ /* Program the IT when to deliver the next interrupt.
+ * Only bottom 32-bits of next_tick are writable in CR16!
  */
- if (!(cycles_remainder >> 13))
- next_tick += cpt;
-
- /* Program the IT when to deliver the next interrupt. */
- /* Only bottom 32-bits of next_tick are written to cr16.  */
  mtctl(next_tick, 16);
 
+ /* Skip one clocktick on purpose if we missed next_tick.
+ * The new CR16 must be "later" than current CR16 otherwise
+ * itimer would not fire until CR16 wrapped - e.g 4 seconds
+ * later on a 1Ghz processor. We'll account for the missed
+ * tick on the next timer interrupt.
+ *
+ * "next_tick - now" will always give the difference regardless
+ * if one or the other wrapped. If "now" is "bigger" we'll end up
+ * with a very large unsigned number.
+ */
+ now2 = mfctl(16);
+ if (next_tick - now2 > cpt)
+ mtctl(next_tick+cpt, 16);
+
+#if 1
+/*
+ * GGG: DEBUG code for how many cycles programming CR16 used.
+ */
+ if (unlikely(now2 - now > 0x3000)) /* 12K cycles */
+ printk (KERN_CRIT "timer_interrupt(CPU %d): SLOW! 0x%lx cycles!"
+ " cyc %lX rem %lX "
+ " next/now %lX/%lX\n",
+ cpu, now2 - now, cycles_elapsed, cycles_remainder,
+ next_tick, now );
+#endif
+
+ /* Can we differentiate between "early CR16" (aka Scenario 1) and
+ * "long delay" (aka Scenario 3)? I don't think so.
+ *
+ * Timer_interrupt will be delivered at least a few hundred cycles
+ * after the IT fires. But it's arbitrary how much time passes
+ * before we call it "late". I've picked one second.
+ *
+ * It's important NO printk's are between reading CR16 and
+ * setting up the next value. May introduce huge variance.
+ */
+ if (unlikely(ticks_elapsed > HZ)) {
+ /* Scenario 3: very long delay?  bad in any case */
+ printk (KERN_CRIT "timer_interrupt(CPU %d): delayed!"
+ " cycles %lX rem %lX "
+ " next/now %lX/%lX\n",
+ cpu,
+ cycles_elapsed, cycles_remainder,
+ next_tick, now );
+ }
 
  /* Done mucking with unreliable delivery of interrupts.
  * Go do system house keeping.
@@ -173,7 +191,7 @@ EXPORT_SYMBOL(profile_pc);
 
 /* clock source code */
 
-static cycle_t read_cr16(void)
+static cycle_t read_cr16(struct clocksource *cs)
 {
  return get_cycles();
 }
diff --git a/arch/parisc/lib/checksum.c b/arch/parisc/lib/checksum.c
index 462696d..ae66d31 100644
--- a/arch/parisc/lib/checksum.c
+++ b/arch/parisc/lib/checksum.c
@@ -13,8 +13,6 @@
  * modify it under the terms of the GNU General Public License
  * as published by the Free Software Foundation; either version
  * 2 of the License, or (at your option) any later version.
- *
- * $Id: checksum.c,v 1.3 1997/12/01 17:57:34 ralf Exp $
  */
 #include <linux/module.h>
 #include <linux/types.h>
diff --git a/arch/parisc/lib/memcpy.c b/arch/parisc/lib/memcpy.c
index bbda909..abf41f4 100644
--- a/arch/parisc/lib/memcpy.c
+++ b/arch/parisc/lib/memcpy.c
@@ -405,7 +405,7 @@ byte_copy:
 
 unaligned_copy:
  /* possibly we are aligned on a word, but not on a double... */
- if (likely(t1 & (sizeof(unsigned int)-1)) == 0) {
+ if (likely((t1 & (sizeof(unsigned int)-1)) == 0)) {
  t2 = src & (sizeof(unsigned int) - 1);
 
  if (unlikely(t2 != 0)) {
diff --git a/arch/parisc/math-emu/decode_exc.c b/arch/parisc/math-emu/decode_exc.c
index 66c8a9f..3ca1c61 100644
--- a/arch/parisc/math-emu/decode_exc.c
+++ b/arch/parisc/math-emu/decode_exc.c
@@ -40,7 +40,7 @@
  * END_DESC
 */
 
-
+#include <linux/kernel.h>
 #include "float.h"
 #include "sgl_float.h"
 #include "dbl_float.h"
diff --git a/arch/parisc/mm/fault.c b/arch/parisc/mm/fault.c
index 92c7fa4..d617e79 100644
--- a/arch/parisc/mm/fault.c
+++ b/arch/parisc/mm/fault.c
@@ -1,5 +1,4 @@
-/* $Id: fault.c,v 1.5 2000/01/26 16:20:29 jsm Exp $
- *
+/*
  * This file is subject to the terms and conditions of the GNU General Public
  * License.  See the file "COPYING" in the main directory of this archive
  * for more details.
diff --git a/arch/parisc/mm/init.c b/arch/parisc/mm/init.c
index 4356ceb..b0831d9 100644
--- a/arch/parisc/mm/init.c
+++ b/arch/parisc/mm/init.c
@@ -370,34 +370,22 @@ static void __init setup_bootmem(void)
 
 void free_initmem(void)
 {
- unsigned long addr, init_begin, init_end;
-
- printk(KERN_INFO "Freeing unused kernel memory: ");
+ unsigned long addr;
+ unsigned long init_begin = (unsigned long)__init_begin;
+ unsigned long init_end = (unsigned long)__init_end;
 
 #ifdef CONFIG_DEBUG_KERNEL
  /* Attempt to catch anyone trying to execute code here
  * by filling the page with BRK insns.
- *
- * If we disable interrupts for all CPUs, then IPI stops working.
- * Kinda breaks the global cache flushing.
  */
- local_irq_disable();
-
- memset(__init_begin, 0x00,
- (unsigned long)__init_end - (unsigned long)__init_begin);
-
- flush_data_cache();
- asm volatile("sync" : : );
- flush_icache_range((unsigned long)__init_begin, (unsigned long)__init_end);
- asm volatile("sync" : : );
-
- local_irq_enable();
+ memset((void *)init_begin, 0x00, init_end - init_begin);
+ flush_icache_range(init_begin, init_end);
 #endif
 
  /* align __init_begin and __init_end to page size,
    ignoring linker script where we might have tried to save RAM */
- init_begin = PAGE_ALIGN((unsigned long)(__init_begin));
- init_end   = PAGE_ALIGN((unsigned long)(__init_end));
+ init_begin = PAGE_ALIGN(init_begin);
+ init_end = PAGE_ALIGN(init_end);
  for (addr = init_begin; addr < init_end; addr += PAGE_SIZE) {
  ClearPageReserved(virt_to_page(addr));
  init_page_count(virt_to_page(addr));
@@ -409,7 +397,8 @@ void free_initmem(void)
  /* set up a new led state on systems shipped LED State panel */
  pdc_chassis_send_status(PDC_CHASSIS_DIRECT_BCOMPLETE);
 
- printk("%luk freed\n", (init_end - init_begin) >> 10);
+ printk(KERN_INFO "Freeing unused kernel memory: %luk freed\n",
+ (init_end - init_begin) >> 10);
 }
 
 
diff --git a/drivers/parisc/ccio-dma.c b/drivers/parisc/ccio-dma.c
index 5d610cb..0f0e0b9 100644
--- a/drivers/parisc/ccio-dma.c
+++ b/drivers/parisc/ccio-dma.c
@@ -1134,7 +1134,7 @@ static const struct file_operations ccio_proc_bitmap_fops = {
  .llseek = seq_lseek,
  .release = single_release,
 };
-#endif
+#endif /* CONFIG_PROC_FS */
 
 /**
  * ccio_find_ioc - Find the ioc in the ioc_list
@@ -1568,14 +1568,15 @@ static int __init ccio_probe(struct parisc_device *dev)
  /* if this fails, no I/O cards will work, so may as well bug */
  BUG_ON(dev->dev.platform_data == NULL);
  HBA_DATA(dev->dev.platform_data)->iommu = ioc;
-
+
+#ifdef CONFIG_PROC_FS
  if (ioc_count == 0) {
  proc_create(MODULE_NAME, 0, proc_runway_root,
     &ccio_proc_info_fops);
  proc_create(MODULE_NAME"-bitmap", 0, proc_runway_root,
     &ccio_proc_bitmap_fops);
  }
-
+#endif
  ioc_count++;
 
  parisc_has_iommu();
diff --git a/drivers/parisc/dino.c b/drivers/parisc/dino.c
index 52ae0b1..c590974 100644
--- a/drivers/parisc/dino.c
+++ b/drivers/parisc/dino.c
@@ -353,7 +353,7 @@ static unsigned int dino_startup_irq(unsigned int irq)
  return 0;
 }
 
-static struct hw_interrupt_type dino_interrupt_type = {
+static struct irq_chip dino_interrupt_type = {
  .typename = "GSC-PCI",
  .startup = dino_startup_irq,
  .shutdown = dino_disable_irq,
@@ -1019,22 +1019,22 @@ static int __init dino_probe(struct parisc_device *dev)
  ** It's not used to avoid chicken/egg problems
  ** with configuration accessor functions.
  */
- bus = pci_scan_bus_parented(&dev->dev, dino_current_bus,
-    &dino_cfg_ops, NULL);
+ dino_dev->hba.hba_bus = bus = pci_scan_bus_parented(&dev->dev,
+ dino_current_bus, &dino_cfg_ops, NULL);
+
  if(bus) {
- pci_bus_add_devices(bus);
  /* This code *depends* on scanning being single threaded
  * if it isn't, this global bus number count will fail
  */
  dino_current_bus = bus->subordinate + 1;
  pci_bus_assign_resources(bus);
+ pci_bus_add_devices(bus);
  } else {
- printk(KERN_ERR "ERROR: failed to scan PCI bus on %s (probably duplicate bus number %d)\n",
+ printk(KERN_ERR "ERROR: failed to scan PCI bus on %s (duplicate bus number %d?)\n",
        dev_name(&dev->dev), dino_current_bus);
  /* increment the bus number in case of duplicates */
  dino_current_bus++;
  }
- dino_dev->hba.hba_bus = bus;
  return 0;
 }
 
diff --git a/drivers/parisc/eisa.c b/drivers/parisc/eisa.c
index f415fdd..eb079d6 100644
--- a/drivers/parisc/eisa.c
+++ b/drivers/parisc/eisa.c
@@ -188,7 +188,7 @@ static unsigned int eisa_startup_irq(unsigned int irq)
  return 0;
 }
 
-static struct hw_interrupt_type eisa_interrupt_type = {
+static struct irq_chip eisa_interrupt_type = {
  .typename = "EISA",
  .startup = eisa_startup_irq,
  .shutdown = eisa_disable_irq,
diff --git a/drivers/parisc/gsc.c b/drivers/parisc/gsc.c
index d336329..647adc9 100644
--- a/drivers/parisc/gsc.c
+++ b/drivers/parisc/gsc.c
@@ -148,7 +148,7 @@ static unsigned int gsc_asic_startup_irq(unsigned int irq)
  return 0;
 }
 
-static struct hw_interrupt_type gsc_asic_interrupt_type = {
+static struct irq_chip gsc_asic_interrupt_type = {
  .typename = "GSC-ASIC",
  .startup = gsc_asic_startup_irq,
  .shutdown = gsc_asic_disable_irq,
@@ -158,7 +158,7 @@ static struct hw_interrupt_type gsc_asic_interrupt_type = {
  .end = no_end_irq,
 };
 
-int gsc_assign_irq(struct hw_interrupt_type *type, void *data)
+int gsc_assign_irq(struct irq_chip *type, void *data)
 {
  static int irq = GSC_IRQ_BASE;
  struct irq_desc *desc;
diff --git a/drivers/parisc/gsc.h b/drivers/parisc/gsc.h
index 762a1ba..b9d7bfb 100644
--- a/drivers/parisc/gsc.h
+++ b/drivers/parisc/gsc.h
@@ -38,7 +38,7 @@ struct gsc_asic {
 int gsc_common_setup(struct parisc_device *parent, struct gsc_asic *gsc_asic);
 int gsc_alloc_irq(struct gsc_irq *dev); /* dev needs an irq */
 int gsc_claim_irq(struct gsc_irq *dev, int irq); /* dev needs this irq */
-int gsc_assign_irq(struct hw_interrupt_type *type, void *data);
+int gsc_assign_irq(struct irq_chip *type, void *data);
 int gsc_find_local_irq(unsigned int irq, int *global_irq, int limit);
 void gsc_fixup_irqs(struct parisc_device *parent, void *ctrl,
  void (*choose)(struct parisc_device *child, void *ctrl));
diff --git a/drivers/parisc/iosapic.c b/drivers/parisc/iosapic.c
index 73348c4..230a5a4 100644
--- a/drivers/parisc/iosapic.c
+++ b/drivers/parisc/iosapic.c
@@ -727,7 +727,7 @@ static void iosapic_set_affinity_irq(unsigned int irq,
 }
 #endif
 
-static struct hw_interrupt_type iosapic_interrupt_type = {
+static struct irq_chip iosapic_interrupt_type = {
  .typename = "IO-SAPIC-level",
  .startup = iosapic_startup_irq,
  .shutdown = iosapic_disable_irq,
diff --git a/drivers/parisc/lba_pci.c b/drivers/parisc/lba_pci.c
index 59fbbf1..da75cd4 100644
--- a/drivers/parisc/lba_pci.c
+++ b/drivers/parisc/lba_pci.c
@@ -980,28 +980,38 @@ static void
 lba_pat_resources(struct parisc_device *pa_dev, struct lba_device *lba_dev)
 {
  unsigned long bytecnt;
- pdc_pat_cell_mod_maddr_block_t pa_pdc_cell; /* PA_VIEW */
- pdc_pat_cell_mod_maddr_block_t io_pdc_cell; /* IO_VIEW */
  long io_count;
  long status; /* PDC return status */
  long pa_count;
+ pdc_pat_cell_mod_maddr_block_t *pa_pdc_cell;    /* PA_VIEW */
+ pdc_pat_cell_mod_maddr_block_t *io_pdc_cell;    /* IO_VIEW */
  int i;
 
+ pa_pdc_cell = kzalloc(sizeof(pdc_pat_cell_mod_maddr_block_t), GFP_KERNEL);
+ if (!pa_pdc_cell)
+ return;
+
+ io_pdc_cell = kzalloc(sizeof(pdc_pat_cell_mod_maddr_block_t), GFP_KERNEL);
+ if (!io_pdc_cell) {
+ kfree(pa_pdc_cell);
+ return;
+ }
+
  /* return cell module (IO view) */
  status = pdc_pat_cell_module(&bytecnt, pa_dev->pcell_loc, pa_dev->mod_index,
- PA_VIEW, & pa_pdc_cell);
- pa_count = pa_pdc_cell.mod[1];
+ PA_VIEW, pa_pdc_cell);
+ pa_count = pa_pdc_cell->mod[1];
 
  status |= pdc_pat_cell_module(&bytecnt, pa_dev->pcell_loc, pa_dev->mod_index,
- IO_VIEW, &io_pdc_cell);
- io_count = io_pdc_cell.mod[1];
+ IO_VIEW, io_pdc_cell);
+ io_count = io_pdc_cell->mod[1];
 
  /* We've already done this once for device discovery...*/
  if (status != PDC_OK) {
  panic("pdc_pat_cell_module() call failed for LBA!\n");
  }
 
- if (PAT_GET_ENTITY(pa_pdc_cell.mod_info) != PAT_ENTITY_LBA) {
+ if (PAT_GET_ENTITY(pa_pdc_cell->mod_info) != PAT_ENTITY_LBA) {
  panic("pdc_pat_cell_module() entity returned != PAT_ENTITY_LBA!\n");
  }
 
@@ -1016,8 +1026,8 @@ lba_pat_resources(struct parisc_device *pa_dev, struct lba_device *lba_dev)
  } *p, *io;
  struct resource *r;
 
- p = (void *) &(pa_pdc_cell.mod[2+i*3]);
- io = (void *) &(io_pdc_cell.mod[2+i*3]);
+ p = (void *) &(pa_pdc_cell->mod[2+i*3]);
+ io = (void *) &(io_pdc_cell->mod[2+i*3]);
 
  /* Convert the PAT range data to PCI "struct resource" */
  switch(p->type & 0xff) {
@@ -1096,6 +1106,9 @@ lba_pat_resources(struct parisc_device *pa_dev, struct lba_device *lba_dev)
  break;
  }
  }
+
+ kfree(pa_pdc_cell);
+ kfree(io_pdc_cell);
 }
 #else
 /* keep compiler from complaining about missing declarations */
@@ -1509,10 +1522,6 @@ lba_driver_probe(struct parisc_device *dev)
  lba_bus = lba_dev->hba.hba_bus =
  pci_scan_bus_parented(&dev->dev, lba_dev->hba.bus_num.start,
  cfg_ops, NULL);
- if (lba_bus) {
- lba_next_bus = lba_bus->subordinate + 1;
- pci_bus_add_devices(lba_bus);
- }
 
  /* This is in lieu of calling pci_assign_unassigned_resources() */
  if (is_pdc_pat()) {
@@ -1533,7 +1542,6 @@ lba_driver_probe(struct parisc_device *dev)
  }
  pci_enable_bridges(lba_bus);
 
-
  /*
  ** Once PCI register ops has walked the bus, access to config
  ** space is restricted. Avoids master aborts on config cycles.
@@ -1543,6 +1551,11 @@ lba_driver_probe(struct parisc_device *dev)
  lba_dev->flags |= LBA_FLAG_SKIP_PROBE;
  }
 
+ if (lba_bus) {
+ lba_next_bus = lba_bus->subordinate + 1;
+ pci_bus_add_devices(lba_bus);
+ }
+
  /* Whew! Finally done! Tell services we got this one covered. */
  return 0;
 }
diff --git a/drivers/parisc/sba_iommu.c b/drivers/parisc/sba_iommu.c
index e5999c4..4b62b89 100644
--- a/drivers/parisc/sba_iommu.c
+++ b/drivers/parisc/sba_iommu.c
@@ -2057,6 +2057,7 @@ void sba_directed_lmmio(struct parisc_device *pci_hba, struct resource *r)
  r->start = (base & ~1UL) | PCI_F_EXTEND;
  size = ~ READ_REG32(reg + LMMIO_DIRECT0_MASK);
  r->end = r->start + size;
+ r->flags = IORESOURCE_MEM;
  }
 }
 
@@ -2093,4 +2094,5 @@ void sba_distributed_lmmio(struct parisc_device *pci_hba, struct resource *r )
  size = (~READ_REG32(sba->sba_hpa + LMMIO_DIST_MASK)) / ROPES_PER_IOC;
  r->start += rope * (size + 1); /* adjust base for this rope */
  r->end = r->start + size;
+ r->flags = IORESOURCE_MEM;
 }
diff --git a/drivers/parisc/superio.c b/drivers/parisc/superio.c
index 33e5ade..675f04e 100644
--- a/drivers/parisc/superio.c
+++ b/drivers/parisc/superio.c
@@ -325,7 +325,7 @@ static unsigned int superio_startup_irq(unsigned int irq)
  return 0;
 }
 
-static struct hw_interrupt_type superio_interrupt_type = {
+static struct irq_chip superio_interrupt_type = {
  .typename = SUPERIO,
  .startup = superio_startup_irq,
  .shutdown = superio_disable_irq,
@@ -434,8 +434,8 @@ static void __init superio_parport_init(void)
  0 /*base_hi*/,
  PAR_IRQ,
  PARPORT_DMA_NONE /* dma */,
- NULL /*struct pci_dev* */),
- 0 /* shared irq flags */ )
+ NULL /*struct pci_dev* */,
+ 0 /* shared irq flags */))
 
  printk(KERN_WARNING PFX "Probing parallel port failed.\n");
 #endif /* CONFIG_PARPORT_PC */
diff --git a/drivers/scsi/zalon.c b/drivers/scsi/zalon.c
index 97f3158..27e84e4 100644
--- a/drivers/scsi/zalon.c
+++ b/drivers/scsi/zalon.c
@@ -134,7 +134,7 @@ zalon_probe(struct parisc_device *dev)
 
  host = ncr_attach(&zalon7xx_template, unit, &device);
  if (!host)
- goto fail;
+ return -ENODEV;
 
  if (request_irq(dev->irq, ncr53c8xx_intr, IRQF_SHARED, "zalon", host)) {
   dev_printk(KERN_ERR, &dev->dev, "irq problem with %d, detaching\n ",
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 0048f11..9eecbc0 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -616,6 +616,8 @@ config FB_STI
  select FB_CFB_FILLRECT
  select FB_CFB_COPYAREA
  select FB_CFB_IMAGEBLIT
+ select STI_CONSOLE
+ select VT
  default y
  ---help---
   STI refers to the HP "Standard Text Interface" which is a set of

[Helge Deller-3]

On 07/30/2009 07:44 PM, John David Anglin wrote:

>> On Thu, Jul 30, 2009 at 10:50 AM, Andreas Barth<aba@...>  wrote:
>>> You know your porters mailing list best, but I want to highlight some of
>>> the issues:
>>> http://lists.debian.org/debian-hppa/2009/07/msg00002.html
>> I can't comment on this issue. I hope Dave can?
>
> Over the past few weeks, I have been testing 2.6.30.y on three different
> platforms (c3750, rp3440 and A500-7X).  I have run identical 32 and 64-bit
> kernels on the c3750.
>
> To the base system, I have applied a collected set of patches.  Except
> for the typo change recently posted to the parisc linux list, all the
> changes are now in 2.6.31.
>
> With the exception of nscd, I have had no segfault problems with 2.6.30.y
> on the c3750.
>
> However, the same is not true for the rp3440 and A500-7X.  The rp3440
> is worse than the A500-7X, but application segfaults occured very quickly
> running SMP kernels building GCC (usually in our old friend the dynamic
> loader).
>
> The A500-7X (gsyprf11) is now back running a modified SMP version of
> 2.6.19.22.  Last change was the U bit fix.  It has now run eight days
> without any obvious segfaults.
>
> 2.6.19.22 with the above changes is not segfault free on the rp3440.
> However, it is better than any other SMP build on this processor.
>
> I am currently running a UP build of 2.6.30.3 on the rp3440.  It is
> not segfault free, but I can usually get through a GCC build without
> a fault.  So, even with a UP kernel, we still get cache corruption
> on this machine.  I wonder if it is possible to turn L2 off.
>
> I had hoped that the U bit fix would help.  However, its effect is
> not dramatic.  When rebooting the rp3440, it would sometimes report
> memory errors in the system hardware log.  Similarly, the display
> attached to the VisEG on the c3750 would sometimes get noisy.
> Resetting the display mode at boot would cure this.  Another effect
> was for cpus to mysteriously get disabled.  I suspect that
> the kernel was sometimes accidently writing to the control memory
> for these devices.  These problems may be fixed or reduced with
> the U bit fix.
>
> In summary, the segfault problem is still there and a major issue,
> particularly with SMP kernels.  Without a testcase that consistently
> triggers the problem, it's almost impossible to debug what's going
> wrong.
>
> glob2 built for me, so the build failure was probably caused by cache
> corruption.
>
> Dave

Dave, thanks for this very good summary!

I just want to mention my thoughts on this issue.

I see the point, that Debian needs a stable and reliable build server.
But just saying, that the whole parisc port is unstable due to a few
problematic servers is imho wrong.
My 4 machines (715/64, B160L, Tadpole parisc laptop and a C3000)  are absolutely
stable. The debian kernel is stable on those machines and even survives
big compilation tests.
That said, in my opinion and given my machines, parisc IS a stable platform.

So, if we have stability problems on the most important machines,
which are the debian build servers, then maybe some thoughts should be
given to replace those machines by slower but at least stable machines,
like e.g. a C3000 ?

That way, debian can continue to be built and we can concentrate on fixing
the remaining issues.

Helge

PS: Sadly I don't have neither a SMP machine nor one of the problematic boxes.
So, I'm currently not very much of a help to fix those issues (unless someone
sends me such a problematic box :-))


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andreas Barth]

* Helge Deller (deller@...) [090731 23:32]:
> So, if we have stability problems on the most important machines,
> which are the debian build servers, then maybe some thoughts should be
> given to replace those machines by slower but at least stable machines,
> like e.g. a C3000 ?

We need to have fast and reliable machines. One of the reasons for
fast is that we want to be able to build an security update for any
package in a resonable time frame. It is no longer acceptable that we
need to wait more than 5 days for a single architecture till we can
upload (we had that with m68k) - I'm not sure how much slower these
machines are, but for sure hppa isn't the fastest port anyways.
(Another reason is that we want to keep up with at maximum 2 buildds,
to reduce admin overhead.)

Doing a stable release means also that we need to be able to support
the architecture for at least 3 years starting from the next stable
release on. Depending on when that will happen, that is 4-5 years from
now.


Any architecture (that isn't parisc related anymore) has more or less
4 stages:

First the architecture comes up fresh (e.g. currently kfreebsd*), so
we have a lot of porting issues. Fast machines are sometimes not too
often, as there are only development boards available etc. For the
very first steps, we often have an seperate archive till the
architecture is stable enough to be integrated.

Then the architecture is stable, we have fast machines, good tool
coverage (e.g. currently amd64), it's easy to buy a machine. Most of
our architectures should be in this stage.

Then, at some point, the hardware is no longer available new, but the
architecture is still usefull to people. We slowly notice that more
and more issues happen. There will be a point in time when the effort
to support the architecture in stable outweights the bonus of still
running the architecture. There will be a time when we cannot do
stable releases anymore. If we cannot do new stable releases anymore,
we cannot host porter machines anymore, so the architecture will need
to go away from unstable after security support for the last stable
release is ended. At the end of that stage, an own archive might be
helpfull as well.

Then the final stage: There are neither porters nor useable hardware
left anymore. End.


Any architecture will be in the final stage at some point in time.
E.g. we already EOLed support for the 80386-cpu, as well as for the
old arm port.

As far as I can see, hppa is currently in the third stage: The
hardware isn't available as new anymore, but the port is still usefull
to people.

I haven't made up my mind yet whether it is better to include hppa in
the next stable release or not. If we notice that the issues that we
have will be fixed / worked around, then the answer to the question is
easy. If we notice that probably we won't have working buildds
available then the answer is ... well, not easy but obvious.

I notice that quite many people are working on / using hppa. However,
there are issues which we have for quite some time, e.g. the switch to
nptl. When I looked first at hppa during my time in Debian (I don't
know when that was, but quite some time ago), I think we already had
the "we will switch to nptl soon, most issues will disappear with
that". I'm happy if the switch happens. But we cannot wait forever if
this is the precondition for supporting hppa with squeeze.


Currently, the state is quite ambigous. The german saying for that is
"zum sterben zu viel, zum leben zu wenig", means: not really stable
enough to support it, but not really broken enough to remove it. We
need to leave that state that just causes pain on all sides.

I would like to reach consensus with the porters how we can leave that
state, and to which direction. That's one of the reasons why I asked
for a plan to reach the state of "hppa is a normal stable
architecture". A proposal of such a plan with (maximum) timeframes
will allow us to either agree that this doesn't work (e.g. takes way
too long for DSA or the security team, or way too less time left for
the porters), or - and that's of course the hope - have a buy-in from
all on the plan and get hppa back in the "it's stable" yard. Also we
can see what preconditions are necessary, e.g. "we need a problematic
machine for porter $name" or "new hosting for machine $name needed" or
whatever.

The important thing on planing that is also to have a common
understanding and common expectations. After the proposal of such a
plan, anyone who has issues can review if his issues are there. If
not, we can discuss if the issue is worth being mentioned there. That
makes sure for the porters that after the review it is quite unlikly
that existing issues will pop up quite late in time.



Cheers,
Andi


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[John David Anglin-4]

>> In summary, the segfault problem is still there and a major issue,
>> particularly with SMP kernels.  Without a testcase that consistently
>> triggers the problem, it's almost impossible to debug what's going
>> wrong.

I have updated and attached my patch set for 2.6.30.4.  So, changes
are now in 2.6.30.4.

UP 2.6.30.4 kernel on c3750 continues to run without segfaults.  It is a
32-bit kernel built with Debian 4.3.2-1.1.

I updated to gcc-4.4-hppa64 4.4.0-5 for 64-bit kernel builds.

Although this may be premature, the segfaults previously seen with
64-bit UP 2.6.30.y kernels on rp3440 (pa8800) may be gone.  I have
my fingers crossed.

The problems with SMP kernels are not resolved with 2.6.30.4.  However,
the nature of the segfaults seems to have changed.  They are more
consistent.  With a SMP 2.6.30.4 kernel on A500-7X, I got through
a full GCC build of 4.5, but there are a whole bunch of segfaults
running xgcc.  They are all the same:

Core was generated by `/home/dave/gcc-4.5/objdir/gcc/xgcc b~ca110042.o /home/dave/gcc-4.5/objdir/gcc/a'.
Program terminated with signal 11, Segmentation fault.
[New process 25845]
#0  0x4034ffb8 in do_lookup_x (new_hash=258356064, old_hash=0xfdfe8b08,
    ref=0x10a9c, result=0xfdfe8b18, scope=0x403689dc, i=0, flags=1, skip=0x0)
    at do-lookup.h:54
54 do-lookup.h: No such file or directory.
        in do-lookup.h
(gdb) bt
#0  0x4034ffb8 in do_lookup_x (new_hash=258356064, old_hash=0xfdfe8b08,
    ref=0x10a9c, result=0xfdfe8b18, scope=0x403689dc, i=0, flags=1, skip=0x0)
    at do-lookup.h:54
#1  0x4035042c in _dl_lookup_symbol_x (undef_name=0x10b18 "execv",
    undef_map=0x40368880, ref=0xfdfe8a48, symbol_scope=0x40368a38,
    version=0x40000f60, type_class=1, flags=1, skip_map=0x0) at dl-lookup.c:340
#2  0x40354320 in _dl_fixup (l=0x40368880, reloc_offset=<value optimized out>)
    at dl-runtime.c:108
#3  0x4035a8fc in _dl_runtime_resolve () from /lib/ld.so.1
#4  0x00029abc in pex_unix_exec_child (obj=0x53e90, flags=1,
    executable=0x53e18 "/home/dave/gcc-4.5/objdir/gcc/collect2", argv=0x539a0,
    env=0x0, in=0, out=1, errdes=2, toclose=-1, errmsg=0xfdfe8888,
    err=0xfdfe8708) at ../../gcc/libiberty/pex-unix.c:462
#5  0x00028ea8 in pex_run_in_environment (obj=0x53e90, flags=1,
    executable=0x53e18 "/home/dave/gcc-4.5/objdir/gcc/collect2", argv=0x539a0,
    env=0x0, orig_outname=0x0, errname=0x0, err=0xfdfe8708)
    at ../../gcc/libiberty/pex-common.c:531
#6  0x00029070 in pex_run (obj=0x10b18, flags=258356064,
    executable=0xfdfe8b08 "????", argv=0x10a9c, orig_outname=0x0, errname=0x0,
    err=0xfdfe8708) at ../../gcc/libiberty/pex-common.c:531
#7  0x0001557c in execute () at ../../gcc/gcc/gcc.c:1469
#8  0x0001fa24 in main (argc=62, argv=0xfdfe8024) at ../../gcc/gcc/gcc.c:1469
(gdb) p/x $pc
$1 = 0x4034ffb8
(gdb) disass 0x4034ffa8 0x4034ffc8
Dump of assembler code from 0x4034ffa8 to 0x4034ffc8:
0x4034ffa8 <do_lookup_x+192>: cmpb,= r7,r21,0x4034ffc0 <do_lookup_x+216>
0x4034ffac <do_lookup_x+196>: stw r21,-a4(sp)
0x4034ffb0 <do_lookup_x+200>: ldw -94(sp),ret0
0x4034ffb4 <do_lookup_x+204>: bb,< ret0,1e,0x40350020 <do_lookup_x+312>
0x4034ffb8 <do_lookup_x+208>: ldw 194(r21),r20
0x4034ffbc <do_lookup_x+212>: bb,>=,n r20,e,0x40350038 <do_lookup_x+336>
0x4034ffc0 <do_lookup_x+216>: ldo 1(r3),r3
0x4034ffc4 <do_lookup_x+220>: cmpb,<< r3,r6,0x4034ff98 <do_lookup_x+176>
End of assembler dump.
(gdb) p/x $r21
$2 = 0x1

The dumps that I looked at all had segfaults looking up "execv".

The was also a hang in the gcc testsuite where it appears expect missed
or wasn't sent a signal.  Possibly, this is related to the above.

Carlos, what do you think?

Dave
--
J. David Anglin                                  dave.anglin@...
National Research Council of Canada              [phone] (FAX: [phone])

diff --git a/arch/parisc/include/asm/atomic.h b/arch/parisc/include/asm/atomic.h
index ada3e53..7d5ebf1 100644
--- a/arch/parisc/include/asm/atomic.h
+++ b/arch/parisc/include/asm/atomic.h
@@ -222,13 +222,13 @@ static __inline__ int atomic_add_unless(atomic_t *v, int a, int u)
 
 #define atomic_inc_not_zero(v) atomic_add_unless((v), 1, 0)
 
-#define atomic_add(i,v) ((void)(__atomic_add_return( ((int)(i)),(v))))
-#define atomic_sub(i,v) ((void)(__atomic_add_return(-((int)(i)),(v))))
+#define atomic_add(i,v) ((void)(__atomic_add_return( (i),(v))))
+#define atomic_sub(i,v) ((void)(__atomic_add_return(-(i),(v))))
 #define atomic_inc(v) ((void)(__atomic_add_return(   1,(v))))
 #define atomic_dec(v) ((void)(__atomic_add_return(  -1,(v))))
 
-#define atomic_add_return(i,v) (__atomic_add_return( ((int)(i)),(v)))
-#define atomic_sub_return(i,v) (__atomic_add_return(-((int)(i)),(v)))
+#define atomic_add_return(i,v) (__atomic_add_return( (i),(v)))
+#define atomic_sub_return(i,v) (__atomic_add_return(-(i),(v)))
 #define atomic_inc_return(v) (__atomic_add_return(   1,(v)))
 #define atomic_dec_return(v) (__atomic_add_return(  -1,(v)))
 
diff --git a/arch/parisc/include/asm/dma.h b/arch/parisc/include/asm/dma.h
index 31ad0f0..f7a18f9 100644
--- a/arch/parisc/include/asm/dma.h
+++ b/arch/parisc/include/asm/dma.h
@@ -1,5 +1,4 @@
-/* $Id: dma.h,v 1.2 1999/04/27 00:46:18 deller Exp $
- * linux/include/asm/dma.h: Defines for using and allocating dma channels.
+/* asm/dma.h: Defines for using and allocating dma channels.
  * Written by Hennus Bergman, 1992.
  * High DMA channel support & info by Hannu Savolainen
  * and John Boyd, Nov. 1992.
diff --git a/arch/parisc/include/asm/unistd.h b/arch/parisc/include/asm/unistd.h
index ef26b00..a3c3419 100644
--- a/arch/parisc/include/asm/unistd.h
+++ b/arch/parisc/include/asm/unistd.h
@@ -807,8 +807,10 @@
 #define __NR_dup3 (__NR_Linux + 312)
 #define __NR_pipe2 (__NR_Linux + 313)
 #define __NR_inotify_init1 (__NR_Linux + 314)
+#define __NR_preadv (__NR_Linux + 315)
+#define __NR_pwritev (__NR_Linux + 316)
 
-#define __NR_Linux_syscalls (__NR_inotify_init1 + 1)
+#define __NR_Linux_syscalls (__NR_pwritev + 1)
 
 
 #define __IGNORE_select /* newselect */
diff --git a/arch/parisc/kernel/entry.S b/arch/parisc/kernel/entry.S
index ae3e70c..e552e54 100644
--- a/arch/parisc/kernel/entry.S
+++ b/arch/parisc/kernel/entry.S
@@ -553,7 +553,7 @@
  * on most of those machines only handles cache transactions.
  */
  extrd,u,*= \pte,_PAGE_NO_CACHE_BIT+32,1,%r0
- depi 1,12,1,\prot
+ depdi 1,12,1,\prot
 
  /* Drop prot bits and convert to page addr for iitlbt and idtlbt */
  convert_for_tlb_insert20 \pte
diff --git a/arch/parisc/kernel/inventory.c b/arch/parisc/kernel/inventory.c
index bd1f7f1..bb3195b 100644
--- a/arch/parisc/kernel/inventory.c
+++ b/arch/parisc/kernel/inventory.c
@@ -170,23 +170,27 @@ static void __init pagezero_memconfig(void)
 static int __init
 pat_query_module(ulong pcell_loc, ulong mod_index)
 {
- pdc_pat_cell_mod_maddr_block_t pa_pdc_cell;
+ pdc_pat_cell_mod_maddr_block_t *pa_pdc_cell;
  unsigned long bytecnt;
  unsigned long temp; /* 64-bit scratch value */
  long status; /* PDC return value status */
  struct parisc_device *dev;
 
+ pa_pdc_cell = kmalloc(sizeof (*pa_pdc_cell), GFP_KERNEL);
+ if (!pa_pdc_cell)
+ panic("couldn't allocate memory for PDC_PAT_CELL!");
+
  /* return cell module (PA or Processor view) */
  status = pdc_pat_cell_module(&bytecnt, pcell_loc, mod_index,
-     PA_VIEW, &pa_pdc_cell);
+     PA_VIEW, pa_pdc_cell);
 
  if (status != PDC_OK) {
  /* no more cell modules or error */
  return status;
  }
 
- temp = pa_pdc_cell.cba;
- dev = alloc_pa_dev(PAT_GET_CBA(temp), &pa_pdc_cell.mod_path);
+ temp = pa_pdc_cell->cba;
+ dev = alloc_pa_dev(PAT_GET_CBA(temp), &(pa_pdc_cell->mod_path));
  if (!dev) {
  return PDC_OK;
  }
@@ -203,8 +207,8 @@ pat_query_module(ulong pcell_loc, ulong mod_index)
 
  /* save generic info returned from the call */
  /* REVISIT: who is the consumer of this? not sure yet... */
- dev->mod_info = pa_pdc_cell.mod_info; /* pass to PAT_GET_ENTITY() */
- dev->pmod_loc = pa_pdc_cell.mod_location;
+ dev->mod_info = pa_pdc_cell->mod_info; /* pass to PAT_GET_ENTITY() */
+ dev->pmod_loc = pa_pdc_cell->mod_location;
 
  register_parisc_device(dev); /* advertise device */
 
@@ -216,14 +220,14 @@ pat_query_module(ulong pcell_loc, ulong mod_index)
 
  case PAT_ENTITY_PROC:
  printk(KERN_DEBUG "PAT_ENTITY_PROC: id_eid 0x%lx\n",
- pa_pdc_cell.mod[0]);
+ pa_pdc_cell->mod[0]);
  break;
 
  case PAT_ENTITY_MEM:
  printk(KERN_DEBUG
  "PAT_ENTITY_MEM: amount 0x%lx min_gni_base 0x%lx min_gni_len 0x%lx\n",
- pa_pdc_cell.mod[0], pa_pdc_cell.mod[1],
- pa_pdc_cell.mod[2]);
+ pa_pdc_cell->mod[0], pa_pdc_cell->mod[1],
+ pa_pdc_cell->mod[2]);
  break;
  case PAT_ENTITY_CA:
  printk(KERN_DEBUG "PAT_ENTITY_CA: %ld\n", pcell_loc);
@@ -243,23 +247,26 @@ pat_query_module(ulong pcell_loc, ulong mod_index)
  print_ranges:
  pdc_pat_cell_module(&bytecnt, pcell_loc, mod_index,
     IO_VIEW, &io_pdc_cell);
- printk(KERN_DEBUG "ranges %ld\n", pa_pdc_cell.mod[1]);
- for (i = 0; i < pa_pdc_cell.mod[1]; i++) {
+ printk(KERN_DEBUG "ranges %ld\n", pa_pdc_cell->mod[1]);
+ for (i = 0; i < pa_pdc_cell->mod[1]; i++) {
  printk(KERN_DEBUG
  "  PA_VIEW %ld: 0x%016lx 0x%016lx 0x%016lx\n",
- i, pa_pdc_cell.mod[2 + i * 3], /* type */
- pa_pdc_cell.mod[3 + i * 3], /* start */
- pa_pdc_cell.mod[4 + i * 3]); /* finish (ie end) */
+ i, pa_pdc_cell->mod[2 + i * 3], /* type */
+ pa_pdc_cell->mod[3 + i * 3], /* start */
+ pa_pdc_cell->mod[4 + i * 3]); /* finish (ie end) */
  printk(KERN_DEBUG
  "  IO_VIEW %ld: 0x%016lx 0x%016lx 0x%016lx\n",
- i, io_pdc_cell.mod[2 + i * 3], /* type */
- io_pdc_cell.mod[3 + i * 3], /* start */
- io_pdc_cell.mod[4 + i * 3]); /* finish (ie end) */
+ i, io_pdc_cell->mod[2 + i * 3], /* type */
+ io_pdc_cell->mod[3 + i * 3], /* start */
+ io_pdc_cell->mod[4 + i * 3]); /* finish (ie end) */
  }
  printk(KERN_DEBUG "\n");
  break;
  }
 #endif /* DEBUG_PAT */
+
+ kfree(pa_pdc_cell);
+
  return PDC_OK;
 }
 
diff --git a/arch/parisc/kernel/irq.c b/arch/parisc/kernel/irq.c
index 4ea4229..5dc6cc1 100644
--- a/arch/parisc/kernel/irq.c
+++ b/arch/parisc/kernel/irq.c
@@ -120,7 +120,7 @@ int cpu_check_affinity(unsigned int irq, const struct cpumask *dest)
  if (CHECK_IRQ_PER_CPU(irq)) {
  /* Bad linux design decision.  The mask has already
  * been set; we must reset it */
- cpumask_setall(&irq_desc[irq].affinity);
+ cpumask_setall(irq_desc[irq].affinity);
  return -EINVAL;
  }
 
@@ -138,11 +138,11 @@ static void cpu_set_affinity_irq(unsigned int irq, const struct cpumask *dest)
  if (cpu_dest < 0)
  return;
 
- cpumask_copy(&irq_desc[irq].affinity, dest);
+ cpumask_copy(irq_desc[irq].affinity, dest);
 }
 #endif
 
-static struct hw_interrupt_type cpu_interrupt_type = {
+static struct irq_chip cpu_interrupt_type = {
  .typename = "CPU",
  .startup = cpu_startup_irq,
  .shutdown = cpu_disable_irq,
@@ -297,7 +297,7 @@ int txn_alloc_irq(unsigned int bits_wide)
 unsigned long txn_affinity_addr(unsigned int irq, int cpu)
 {
 #ifdef CONFIG_SMP
- cpumask_copy(&irq_desc[irq].affinity, cpumask_of(cpu));
+ cpumask_copy(irq_desc[irq].affinity, cpumask_of(cpu));
 #endif
 
  return per_cpu(cpu_data, cpu).txn_addr;
@@ -354,7 +354,7 @@ void do_cpu_irq_mask(struct pt_regs *regs)
  irq = eirr_to_irq(eirr_val);
 
 #ifdef CONFIG_SMP
- cpumask_copy(&dest, &irq_desc[irq].affinity);
+ cpumask_copy(&dest, irq_desc[irq].affinity);
  if (CHECK_IRQ_PER_CPU(irq_desc[irq].status) &&
     !cpu_isset(smp_processor_id(), dest)) {
  int cpu = first_cpu(dest);
diff --git a/arch/parisc/kernel/module.c b/arch/parisc/kernel/module.c
index ecd1c50..88989cb 100644
--- a/arch/parisc/kernel/module.c
+++ b/arch/parisc/kernel/module.c
@@ -86,8 +86,12 @@
  * the bottom of the table, which has a maximum signed displacement of
  * 0x3fff; however, since we're only going forward, this becomes
  * 0x1fff, and thus, since each GOT entry is 8 bytes long we can have
- * at most 1023 entries */
-#define MAX_GOTS 1023
+ * at most 1023 entries.
+ * To overcome this 14bit displacement with some kernel modules, we'll
+ * use instead the unusal 16bit displacement method (see reassemble_16a)
+ * which gives us a maximum positive displacement of 0x7fff, and as such
+ * allows us to allocate up to 4095 GOT entries. */
+#define MAX_GOTS 4095
 
 /* three functions to determine where in the module core
  * or init pieces the location is */
@@ -145,12 +149,40 @@ struct stub_entry {
 /* The reassemble_* functions prepare an immediate value for
    insertion into an opcode. pa-risc uses all sorts of weird bitfields
    in the instruction to hold the value.  */
+static inline int sign_unext (int x, int len)
+{
+ int len_ones;
+
+ len_ones = (1 << len) - 1;
+ return x & len_ones;
+}
+
+static inline int low_sign_unext(int x, int len)
+{
+ int sign, temp;
+
+ sign = (x >> (len-1)) & 1;
+ temp = sign_unext (x, len-1);
+ return (temp << 1) | sign;
+}
+
 static inline int reassemble_14(int as14)
 {
  return (((as14 & 0x1fff) << 1) |
  ((as14 & 0x2000) >> 13));
 }
 
+static inline int reassemble_16a(int as16)
+{
+ int s, t;
+
+ /* Unusual 16-bit encoding, for wide mode only.  */
+ t = (as16 << 1) & 0xffff;
+ s = (as16 & 0x8000);
+ return (t ^ s ^ (s >> 1)) | (s >> 15);
+}
+
+
 static inline int reassemble_17(int as17)
 {
  return (((as17 & 0x10000) >> 16) |
@@ -409,6 +441,7 @@ static Elf_Addr get_stub(struct module *me, unsigned long value, long addend,
  enum elf_stub_type stub_type, Elf_Addr loc0, unsigned int targetsec)
 {
  struct stub_entry *stub;
+ int d;
 
  /* initialize stub_offset to point in front of the section */
  if (!me->arch.section[targetsec].stub_offset) {
@@ -462,12 +495,19 @@ static Elf_Addr get_stub(struct module *me, unsigned long value, long addend,
  */
  switch (stub_type) {
  case ELF_STUB_GOT:
- stub->insns[0] = 0x537b0000; /* ldd 0(%dp),%dp */
+ d = get_got(me, value, addend);
+ if (d <= 15) {
+ /* Format 5 */
+ stub->insns[0] = 0x0f6010db; /* ldd 0(%dp),%dp */
+ stub->insns[0] |= low_sign_unext(d, 5) << 16;
+ } else {
+ /* Format 3 */
+ stub->insns[0] = 0x537b0000; /* ldd 0(%dp),%dp */
+ stub->insns[0] |= reassemble_16a(d);
+ }
  stub->insns[1] = 0x53610020; /* ldd 10(%dp),%r1 */
  stub->insns[2] = 0xe820d000; /* bve (%r1) */
  stub->insns[3] = 0x537b0030; /* ldd 18(%dp),%dp */
-
- stub->insns[0] |= reassemble_14(get_got(me, value, addend) & 0x3fff);
  break;
  case ELF_STUB_MILLI:
  stub->insns[0] = 0x20200000; /* ldil 0,%r1 */
diff --git a/arch/parisc/kernel/pci.c b/arch/parisc/kernel/pci.c
index 6936386..f7064ab 100644
--- a/arch/parisc/kernel/pci.c
+++ b/arch/parisc/kernel/pci.c
@@ -1,5 +1,4 @@
-/* $Id: pci.c,v 1.6 2000/01/29 00:12:05 grundler Exp $
- *
+/*
  * This file is subject to the terms and conditions of the GNU General Public
  * License.  See the file "COPYING" in the main directory of this archive
  * for more details.
diff --git a/arch/parisc/kernel/processor.c b/arch/parisc/kernel/processor.c
index e09d0f7..c8fb61e 100644
--- a/arch/parisc/kernel/processor.c
+++ b/arch/parisc/kernel/processor.c
@@ -1,5 +1,4 @@
-/*    $Id: processor.c,v 1.1 2002/07/20 16:27:06 rhirst Exp $
- *
+/*
  *    Initial setup-routines for HP 9000 based hardware.
  *
  *    Copyright (C) 1991, 1992, 1995  Linus Torvalds
@@ -121,22 +120,28 @@ static int __cpuinit processor_probe(struct parisc_device *dev)
  if (is_pdc_pat()) {
  ulong status;
  unsigned long bytecnt;
-        pdc_pat_cell_mod_maddr_block_t pa_pdc_cell;
+        pdc_pat_cell_mod_maddr_block_t *pa_pdc_cell;
 #undef USE_PAT_CPUID
 #ifdef USE_PAT_CPUID
  struct pdc_pat_cpu_num cpu_info;
 #endif
 
+ pa_pdc_cell = kmalloc(sizeof (*pa_pdc_cell), GFP_KERNEL);
+ if (!pa_pdc_cell)
+ panic("couldn't allocate memory for PDC_PAT_CELL!");
+
  status = pdc_pat_cell_module(&bytecnt, dev->pcell_loc,
- dev->mod_index, PA_VIEW, &pa_pdc_cell);
+ dev->mod_index, PA_VIEW, pa_pdc_cell);
 
  BUG_ON(PDC_OK != status);
 
  /* verify it's the same as what do_pat_inventory() found */
- BUG_ON(dev->mod_info != pa_pdc_cell.mod_info);
- BUG_ON(dev->pmod_loc != pa_pdc_cell.mod_location);
+ BUG_ON(dev->mod_info != pa_pdc_cell->mod_info);
+ BUG_ON(dev->pmod_loc != pa_pdc_cell->mod_location);
+
+ txn_addr = pa_pdc_cell->mod[0];   /* id_eid for IO sapic */
 
- txn_addr = pa_pdc_cell.mod[0];   /* id_eid for IO sapic */
+ kfree(pa_pdc_cell);
 
 #ifdef USE_PAT_CPUID
 /* We need contiguous numbers for cpuid. Firmware's notion
diff --git a/arch/parisc/kernel/setup.c b/arch/parisc/kernel/setup.c
index 82131ca..cb71f3d 100644
--- a/arch/parisc/kernel/setup.c
+++ b/arch/parisc/kernel/setup.c
@@ -1,5 +1,4 @@
-/*    $Id: setup.c,v 1.8 2000/02/02 04:42:38 prumpf Exp $
- *
+/*
  *    Initial setup-routines for HP 9000 based hardware.
  *
  *    Copyright (C) 1991, 1992, 1995  Linus Torvalds
diff --git a/arch/parisc/kernel/sys_parisc32.c b/arch/parisc/kernel/sys_parisc32.c
index 0838155..7488cfd 100644
--- a/arch/parisc/kernel/sys_parisc32.c
+++ b/arch/parisc/kernel/sys_parisc32.c
@@ -179,68 +179,6 @@ asmlinkage long sys32_sched_rr_get_interval(pid_t pid,
  return ret;
 }
 
-/*** copied from mips64 ***/
-/*
- * Ooo, nasty.  We need here to frob 32-bit unsigned longs to
- * 64-bit unsigned longs.
- */
-
-static inline int
-get_fd_set32(unsigned long n, u32 *ufdset, unsigned long *fdset)
-{
- n = (n + 8*sizeof(u32) - 1) / (8*sizeof(u32));
- if (ufdset) {
- unsigned long odd;
-
- if (!access_ok(VERIFY_WRITE, ufdset, n*sizeof(u32)))
- return -EFAULT;
-
- odd = n & 1UL;
- n &= ~1UL;
- while (n) {
- unsigned long h, l;
- __get_user(l, ufdset);
- __get_user(h, ufdset+1);
- ufdset += 2;
- *fdset++ = h << 32 | l;
- n -= 2;
- }
- if (odd)
- __get_user(*fdset, ufdset);
- } else {
- /* Tricky, must clear full unsigned long in the
- * kernel fdset at the end, this makes sure that
- * actually happens.
- */
- memset(fdset, 0, ((n + 1) & ~1)*sizeof(u32));
- }
- return 0;
-}
-
-static inline void
-set_fd_set32(unsigned long n, u32 *ufdset, unsigned long *fdset)
-{
- unsigned long odd;
- n = (n + 8*sizeof(u32) - 1) / (8*sizeof(u32));
-
- if (!ufdset)
- return;
-
- odd = n & 1UL;
- n &= ~1UL;
- while (n) {
- unsigned long h, l;
- l = *fdset++;
- h = l >> 32;
- __put_user(l, ufdset);
- __put_user(h, ufdset+1);
- ufdset += 2;
- n -= 2;
- }
- if (odd)
- __put_user(*fdset, ufdset);
-}
-
 struct msgbuf32 {
     int mtype;
     char mtext[1];
diff --git a/arch/parisc/kernel/syscall_table.S b/arch/parisc/kernel/syscall_table.S
index 03b9a01..6a62961 100644
--- a/arch/parisc/kernel/syscall_table.S
+++ b/arch/parisc/kernel/syscall_table.S
@@ -413,6 +413,8 @@
  ENTRY_SAME(dup3)
  ENTRY_SAME(pipe2)
  ENTRY_SAME(inotify_init1)
+ ENTRY_COMP(preadv)
+ ENTRY_COMP(pwritev)
 
  /* Nothing yet */
 
diff --git a/arch/parisc/kernel/time.c b/arch/parisc/kernel/time.c
index d4dd056..a79c6f9 100644
--- a/arch/parisc/kernel/time.c
+++ b/arch/parisc/kernel/time.c
@@ -56,9 +56,9 @@ static unsigned long clocktick __read_mostly; /* timer cycles per tick */
  */
 irqreturn_t __irq_entry timer_interrupt(int irq, void *dev_id)
 {
- unsigned long now;
+ unsigned long now, now2;
  unsigned long next_tick;
- unsigned long cycles_elapsed, ticks_elapsed;
+ unsigned long cycles_elapsed, ticks_elapsed = 1;
  unsigned long cycles_remainder;
  unsigned int cpu = smp_processor_id();
  struct cpuinfo_parisc *cpuinfo = &per_cpu(cpu_data, cpu);
@@ -71,44 +71,24 @@ irqreturn_t __irq_entry timer_interrupt(int irq, void *dev_id)
  /* Initialize next_tick to the expected tick time. */
  next_tick = cpuinfo->it_value;
 
- /* Get current interval timer.
- * CR16 reads as 64 bits in CPU wide mode.
- * CR16 reads as 32 bits in CPU narrow mode.
- */
+ /* Get current cycle counter (Control Register 16). */
  now = mfctl(16);
 
  cycles_elapsed = now - next_tick;
 
- if ((cycles_elapsed >> 5) < cpt) {
+ if ((cycles_elapsed >> 6) < cpt) {
  /* use "cheap" math (add/subtract) instead
  * of the more expensive div/mul method
  */
  cycles_remainder = cycles_elapsed;
- ticks_elapsed = 1;
  while (cycles_remainder > cpt) {
  cycles_remainder -= cpt;
  ticks_elapsed++;
  }
  } else {
+ /* TODO: Reduce this to one fdiv op */
  cycles_remainder = cycles_elapsed % cpt;
- ticks_elapsed = 1 + cycles_elapsed / cpt;
- }
-
- /* Can we differentiate between "early CR16" (aka Scenario 1) and
- * "long delay" (aka Scenario 3)? I don't think so.
- *
- * We expected timer_interrupt to be delivered at least a few hundred
- * cycles after the IT fires. But it's arbitrary how much time passes
- * before we call it "late". I've picked one second.
- */
- if (unlikely(ticks_elapsed > HZ)) {
- /* Scenario 3: very long delay?  bad in any case */
- printk (KERN_CRIT "timer_interrupt(CPU %d): delayed!"
- " cycles %lX rem %lX "
- " next/now %lX/%lX\n",
- cpu,
- cycles_elapsed, cycles_remainder,
- next_tick, now );
+ ticks_elapsed += cycles_elapsed / cpt;
  }
 
  /* convert from "division remainder" to "remainder of clock tick" */
@@ -122,18 +102,56 @@ irqreturn_t __irq_entry timer_interrupt(int irq, void *dev_id)
 
  cpuinfo->it_value = next_tick;
 
- /* Skip one clocktick on purpose if we are likely to miss next_tick.
- * We want to avoid the new next_tick being less than CR16.
- * If that happened, itimer wouldn't fire until CR16 wrapped.
- * We'll catch the tick we missed on the tick after that.
+ /* Program the IT when to deliver the next interrupt.
+ * Only bottom 32-bits of next_tick are writable in CR16!
  */
- if (!(cycles_remainder >> 13))
- next_tick += cpt;
-
- /* Program the IT when to deliver the next interrupt. */
- /* Only bottom 32-bits of next_tick are written to cr16.  */
  mtctl(next_tick, 16);
 
+ /* Skip one clocktick on purpose if we missed next_tick.
+ * The new CR16 must be "later" than current CR16 otherwise
+ * itimer would not fire until CR16 wrapped - e.g 4 seconds
+ * later on a 1Ghz processor. We'll account for the missed
+ * tick on the next timer interrupt.
+ *
+ * "next_tick - now" will always give the difference regardless
+ * if one or the other wrapped. If "now" is "bigger" we'll end up
+ * with a very large unsigned number.
+ */
+ now2 = mfctl(16);
+ if (next_tick - now2 > cpt)
+ mtctl(next_tick+cpt, 16);
+
+#if 1
+/*
+ * GGG: DEBUG code for how many cycles programming CR16 used.
+ */
+ if (unlikely(now2 - now > 0x3000)) /* 12K cycles */
+ printk (KERN_CRIT "timer_interrupt(CPU %d): SLOW! 0x%lx cycles!"
+ " cyc %lX rem %lX "
+ " next/now %lX/%lX\n",
+ cpu, now2 - now, cycles_elapsed, cycles_remainder,
+ next_tick, now );
+#endif
+
+ /* Can we differentiate between "early CR16" (aka Scenario 1) and
+ * "long delay" (aka Scenario 3)? I don't think so.
+ *
+ * Timer_interrupt will be delivered at least a few hundred cycles
+ * after the IT fires. But it's arbitrary how much time passes
+ * before we call it "late". I've picked one second.
+ *
+ * It's important NO printk's are between reading CR16 and
+ * setting up the next value. May introduce huge variance.
+ */
+ if (unlikely(ticks_elapsed > HZ)) {
+ /* Scenario 3: very long delay?  bad in any case */
+ printk (KERN_CRIT "timer_interrupt(CPU %d): delayed!"
+ " cycles %lX rem %lX "
+ " next/now %lX/%lX\n",
+ cpu,
+ cycles_elapsed, cycles_remainder,
+ next_tick, now );
+ }
 
  /* Done mucking with unreliable delivery of interrupts.
  * Go do system house keeping.
@@ -173,7 +191,7 @@ EXPORT_SYMBOL(profile_pc);
 
 /* clock source code */
 
-static cycle_t read_cr16(void)
+static cycle_t read_cr16(struct clocksource *cs)
 {
  return get_cycles();
 }
diff --git a/arch/parisc/lib/checksum.c b/arch/parisc/lib/checksum.c
index 462696d..ae66d31 100644
--- a/arch/parisc/lib/checksum.c
+++ b/arch/parisc/lib/checksum.c
@@ -13,8 +13,6 @@
  * modify it under the terms of the GNU General Public License
  * as published by the Free Software Foundation; either version
  * 2 of the License, or (at your option) any later version.
- *
- * $Id: checksum.c,v 1.3 1997/12/01 17:57:34 ralf Exp $
  */
 #include <linux/module.h>
 #include <linux/types.h>
diff --git a/arch/parisc/lib/memcpy.c b/arch/parisc/lib/memcpy.c
index bbda909..abf41f4 100644
--- a/arch/parisc/lib/memcpy.c
+++ b/arch/parisc/lib/memcpy.c
@@ -405,7 +405,7 @@ byte_copy:
 
 unaligned_copy:
  /* possibly we are aligned on a word, but not on a double... */
- if (likely(t1 & (sizeof(unsigned int)-1)) == 0) {
+ if (likely((t1 & (sizeof(unsigned int)-1)) == 0)) {
  t2 = src & (sizeof(unsigned int) - 1);
 
  if (unlikely(t2 != 0)) {
diff --git a/arch/parisc/math-emu/decode_exc.c b/arch/parisc/math-emu/decode_exc.c
index 66c8a9f..3ca1c61 100644
--- a/arch/parisc/math-emu/decode_exc.c
+++ b/arch/parisc/math-emu/decode_exc.c
@@ -40,7 +40,7 @@
  * END_DESC
 */
 
-
+#include <linux/kernel.h>
 #include "float.h"
 #include "sgl_float.h"
 #include "dbl_float.h"
diff --git a/arch/parisc/mm/fault.c b/arch/parisc/mm/fault.c
index 92c7fa4..d617e79 100644
--- a/arch/parisc/mm/fault.c
+++ b/arch/parisc/mm/fault.c
@@ -1,5 +1,4 @@
-/* $Id: fault.c,v 1.5 2000/01/26 16:20:29 jsm Exp $
- *
+/*
  * This file is subject to the terms and conditions of the GNU General Public
  * License.  See the file "COPYING" in the main directory of this archive
  * for more details.
diff --git a/arch/parisc/mm/init.c b/arch/parisc/mm/init.c
index 4356ceb..b0831d9 100644
--- a/arch/parisc/mm/init.c
+++ b/arch/parisc/mm/init.c
@@ -370,34 +370,22 @@ static void __init setup_bootmem(void)
 
 void free_initmem(void)
 {
- unsigned long addr, init_begin, init_end;
-
- printk(KERN_INFO "Freeing unused kernel memory: ");
+ unsigned long addr;
+ unsigned long init_begin = (unsigned long)__init_begin;
+ unsigned long init_end = (unsigned long)__init_end;
 
 #ifdef CONFIG_DEBUG_KERNEL
  /* Attempt to catch anyone trying to execute code here
  * by filling the page with BRK insns.
- *
- * If we disable interrupts for all CPUs, then IPI stops working.
- * Kinda breaks the global cache flushing.
  */
- local_irq_disable();
-
- memset(__init_begin, 0x00,
- (unsigned long)__init_end - (unsigned long)__init_begin);
-
- flush_data_cache();
- asm volatile("sync" : : );
- flush_icache_range((unsigned long)__init_begin, (unsigned long)__init_end);
- asm volatile("sync" : : );
-
- local_irq_enable();
+ memset((void *)init_begin, 0x00, init_end - init_begin);
+ flush_icache_range(init_begin, init_end);
 #endif
 
  /* align __init_begin and __init_end to page size,
    ignoring linker script where we might have tried to save RAM */
- init_begin = PAGE_ALIGN((unsigned long)(__init_begin));
- init_end   = PAGE_ALIGN((unsigned long)(__init_end));
+ init_begin = PAGE_ALIGN(init_begin);
+ init_end = PAGE_ALIGN(init_end);
  for (addr = init_begin; addr < init_end; addr += PAGE_SIZE) {
  ClearPageReserved(virt_to_page(addr));
  init_page_count(virt_to_page(addr));
@@ -409,7 +397,8 @@ void free_initmem(void)
  /* set up a new led state on systems shipped LED State panel */
  pdc_chassis_send_status(PDC_CHASSIS_DIRECT_BCOMPLETE);
 
- printk("%luk freed\n", (init_end - init_begin) >> 10);
+ printk(KERN_INFO "Freeing unused kernel memory: %luk freed\n",
+ (init_end - init_begin) >> 10);
 }
 
 
diff --git a/drivers/parisc/ccio-dma.c b/drivers/parisc/ccio-dma.c
index 5d610cb..0f0e0b9 100644
--- a/drivers/parisc/ccio-dma.c
+++ b/drivers/parisc/ccio-dma.c
@@ -1134,7 +1134,7 @@ static const struct file_operations ccio_proc_bitmap_fops = {
  .llseek = seq_lseek,
  .release = single_release,
 };
-#endif
+#endif /* CONFIG_PROC_FS */
 
 /**
  * ccio_find_ioc - Find the ioc in the ioc_list
@@ -1568,14 +1568,15 @@ static int __init ccio_probe(struct parisc_device *dev)
  /* if this fails, no I/O cards will work, so may as well bug */
  BUG_ON(dev->dev.platform_data == NULL);
  HBA_DATA(dev->dev.platform_data)->iommu = ioc;
-
+
+#ifdef CONFIG_PROC_FS
  if (ioc_count == 0) {
  proc_create(MODULE_NAME, 0, proc_runway_root,
     &ccio_proc_info_fops);
  proc_create(MODULE_NAME"-bitmap", 0, proc_runway_root,
     &ccio_proc_bitmap_fops);
  }
-
+#endif
  ioc_count++;
 
  parisc_has_iommu();
diff --git a/drivers/parisc/dino.c b/drivers/parisc/dino.c
index 52ae0b1..c590974 100644
--- a/drivers/parisc/dino.c
+++ b/drivers/parisc/dino.c
@@ -353,7 +353,7 @@ static unsigned int dino_startup_irq(unsigned int irq)
  return 0;
 }
 
-static struct hw_interrupt_type dino_interrupt_type = {
+static struct irq_chip dino_interrupt_type = {
  .typename = "GSC-PCI",
  .startup = dino_startup_irq,
  .shutdown = dino_disable_irq,
@@ -1019,22 +1019,22 @@ static int __init dino_probe(struct parisc_device *dev)
  ** It's not used to avoid chicken/egg problems
  ** with configuration accessor functions.
  */
- bus = pci_scan_bus_parented(&dev->dev, dino_current_bus,
-    &dino_cfg_ops, NULL);
+ dino_dev->hba.hba_bus = bus = pci_scan_bus_parented(&dev->dev,
+ dino_current_bus, &dino_cfg_ops, NULL);
+
  if(bus) {
- pci_bus_add_devices(bus);
  /* This code *depends* on scanning being single threaded
  * if it isn't, this global bus number count will fail
  */
  dino_current_bus = bus->subordinate + 1;
  pci_bus_assign_resources(bus);
+ pci_bus_add_devices(bus);
  } else {
- printk(KERN_ERR "ERROR: failed to scan PCI bus on %s (probably duplicate bus number %d)\n",
+ printk(KERN_ERR "ERROR: failed to scan PCI bus on %s (duplicate bus number %d?)\n",
        dev_name(&dev->dev), dino_current_bus);
  /* increment the bus number in case of duplicates */
  dino_current_bus++;
  }
- dino_dev->hba.hba_bus = bus;
  return 0;
 }
 
diff --git a/drivers/parisc/eisa.c b/drivers/parisc/eisa.c
index f415fdd..eb079d6 100644
--- a/drivers/parisc/eisa.c
+++ b/drivers/parisc/eisa.c
@@ -188,7 +188,7 @@ static unsigned int eisa_startup_irq(unsigned int irq)
  return 0;
 }
 
-static struct hw_interrupt_type eisa_interrupt_type = {
+static struct irq_chip eisa_interrupt_type = {
  .typename = "EISA",
  .startup = eisa_startup_irq,
  .shutdown = eisa_disable_irq,
diff --git a/drivers/parisc/gsc.c b/drivers/parisc/gsc.c
index d336329..647adc9 100644
--- a/drivers/parisc/gsc.c
+++ b/drivers/parisc/gsc.c
@@ -148,7 +148,7 @@ static unsigned int gsc_asic_startup_irq(unsigned int irq)
  return 0;
 }
 
-static struct hw_interrupt_type gsc_asic_interrupt_type = {
+static struct irq_chip gsc_asic_interrupt_type = {
  .typename = "GSC-ASIC",
  .startup = gsc_asic_startup_irq,
  .shutdown = gsc_asic_disable_irq,
@@ -158,7 +158,7 @@ static struct hw_interrupt_type gsc_asic_interrupt_type = {
  .end = no_end_irq,
 };
 
-int gsc_assign_irq(struct hw_interrupt_type *type, void *data)
+int gsc_assign_irq(struct irq_chip *type, void *data)
 {
  static int irq = GSC_IRQ_BASE;
  struct irq_desc *desc;
diff --git a/drivers/parisc/gsc.h b/drivers/parisc/gsc.h
index 762a1ba..b9d7bfb 100644
--- a/drivers/parisc/gsc.h
+++ b/drivers/parisc/gsc.h
@@ -38,7 +38,7 @@ struct gsc_asic {
 int gsc_common_setup(struct parisc_device *parent, struct gsc_asic *gsc_asic);
 int gsc_alloc_irq(struct gsc_irq *dev); /* dev needs an irq */
 int gsc_claim_irq(struct gsc_irq *dev, int irq); /* dev needs this irq */
-int gsc_assign_irq(struct hw_interrupt_type *type, void *data);
+int gsc_assign_irq(struct irq_chip *type, void *data);
 int gsc_find_local_irq(unsigned int irq, int *global_irq, int limit);
 void gsc_fixup_irqs(struct parisc_device *parent, void *ctrl,
  void (*choose)(struct parisc_device *child, void *ctrl));
diff --git a/drivers/parisc/iosapic.c b/drivers/parisc/iosapic.c
index 73348c4..230a5a4 100644
--- a/drivers/parisc/iosapic.c
+++ b/drivers/parisc/iosapic.c
@@ -727,7 +727,7 @@ static void iosapic_set_affinity_irq(unsigned int irq,
 }
 #endif
 
-static struct hw_interrupt_type iosapic_interrupt_type = {
+static struct irq_chip iosapic_interrupt_type = {
  .typename = "IO-SAPIC-level",
  .startup = iosapic_startup_irq,
  .shutdown = iosapic_disable_irq,
diff --git a/drivers/parisc/lba_pci.c b/drivers/parisc/lba_pci.c
index 59fbbf1..da75cd4 100644
--- a/drivers/parisc/lba_pci.c
+++ b/drivers/parisc/lba_pci.c
@@ -980,28 +980,38 @@ static void
 lba_pat_resources(struct parisc_device *pa_dev, struct lba_device *lba_dev)
 {
  unsigned long bytecnt;
- pdc_pat_cell_mod_maddr_block_t pa_pdc_cell; /* PA_VIEW */
- pdc_pat_cell_mod_maddr_block_t io_pdc_cell; /* IO_VIEW */
  long io_count;
  long status; /* PDC return status */
  long pa_count;
+ pdc_pat_cell_mod_maddr_block_t *pa_pdc_cell;    /* PA_VIEW */
+ pdc_pat_cell_mod_maddr_block_t *io_pdc_cell;    /* IO_VIEW */
  int i;
 
+ pa_pdc_cell = kzalloc(sizeof(pdc_pat_cell_mod_maddr_block_t), GFP_KERNEL);
+ if (!pa_pdc_cell)
+ return;
+
+ io_pdc_cell = kzalloc(sizeof(pdc_pat_cell_mod_maddr_block_t), GFP_KERNEL);
+ if (!io_pdc_cell) {
+ kfree(pa_pdc_cell);
+ return;
+ }
+
  /* return cell module (IO view) */
  status = pdc_pat_cell_module(&bytecnt, pa_dev->pcell_loc, pa_dev->mod_index,
- PA_VIEW, & pa_pdc_cell);
- pa_count = pa_pdc_cell.mod[1];
+ PA_VIEW, pa_pdc_cell);
+ pa_count = pa_pdc_cell->mod[1];
 
  status |= pdc_pat_cell_module(&bytecnt, pa_dev->pcell_loc, pa_dev->mod_index,
- IO_VIEW, &io_pdc_cell);
- io_count = io_pdc_cell.mod[1];
+ IO_VIEW, io_pdc_cell);
+ io_count = io_pdc_cell->mod[1];
 
  /* We've already done this once for device discovery...*/
  if (status != PDC_OK) {
  panic("pdc_pat_cell_module() call failed for LBA!\n");
  }
 
- if (PAT_GET_ENTITY(pa_pdc_cell.mod_info) != PAT_ENTITY_LBA) {
+ if (PAT_GET_ENTITY(pa_pdc_cell->mod_info) != PAT_ENTITY_LBA) {
  panic("pdc_pat_cell_module() entity returned != PAT_ENTITY_LBA!\n");
  }
 
@@ -1016,8 +1026,8 @@ lba_pat_resources(struct parisc_device *pa_dev, struct lba_device *lba_dev)
  } *p, *io;
  struct resource *r;
 
- p = (void *) &(pa_pdc_cell.mod[2+i*3]);
- io = (void *) &(io_pdc_cell.mod[2+i*3]);
+ p = (void *) &(pa_pdc_cell->mod[2+i*3]);
+ io = (void *) &(io_pdc_cell->mod[2+i*3]);
 
  /* Convert the PAT range data to PCI "struct resource" */
  switch(p->type & 0xff) {
@@ -1096,6 +1106,9 @@ lba_pat_resources(struct parisc_device *pa_dev, struct lba_device *lba_dev)
  break;
  }
  }
+
+ kfree(pa_pdc_cell);
+ kfree(io_pdc_cell);
 }
 #else
 /* keep compiler from complaining about missing declarations */
@@ -1509,10 +1522,6 @@ lba_driver_probe(struct parisc_device *dev)
  lba_bus = lba_dev->hba.hba_bus =
  pci_scan_bus_parented(&dev->dev, lba_dev->hba.bus_num.start,
  cfg_ops, NULL);
- if (lba_bus) {
- lba_next_bus = lba_bus->subordinate + 1;
- pci_bus_add_devices(lba_bus);
- }
 
  /* This is in lieu of calling pci_assign_unassigned_resources() */
  if (is_pdc_pat()) {
@@ -1533,7 +1542,6 @@ lba_driver_probe(struct parisc_device *dev)
  }
  pci_enable_bridges(lba_bus);
 
-
  /*
  ** Once PCI register ops has walked the bus, access to config
  ** space is restricted. Avoids master aborts on config cycles.
@@ -1543,6 +1551,11 @@ lba_driver_probe(struct parisc_device *dev)
  lba_dev->flags |= LBA_FLAG_SKIP_PROBE;
  }
 
+ if (lba_bus) {
+ lba_next_bus = lba_bus->subordinate + 1;
+ pci_bus_add_devices(lba_bus);
+ }
+
  /* Whew! Finally done! Tell services we got this one covered. */
  return 0;
 }
diff --git a/drivers/parisc/pdc_stable.c b/drivers/parisc/pdc_stable.c
index f9f9a5f..13a64bc 100644
--- a/drivers/parisc/pdc_stable.c
+++ b/drivers/parisc/pdc_stable.c
@@ -370,7 +370,7 @@ pdcspath_layer_read(struct pdcspath_entry *entry, char *buf)
  if (!i) /* entry is not ready */
  return -ENODATA;
 
- for (i = 0; devpath->layers[i] && (likely(i < 6)); i++)
+ for (i = 0; i < 6 && devpath->layers[i]; i++)
  out += sprintf(out, "%u ", devpath->layers[i]);
 
  out += sprintf(out, "\n");
diff --git a/drivers/parisc/sba_iommu.c b/drivers/parisc/sba_iommu.c
index e5999c4..4b62b89 100644
--- a/drivers/parisc/sba_iommu.c
+++ b/drivers/parisc/sba_iommu.c
@@ -2057,6 +2057,7 @@ void sba_directed_lmmio(struct parisc_device *pci_hba, struct resource *r)
  r->start = (base & ~1UL) | PCI_F_EXTEND;
  size = ~ READ_REG32(reg + LMMIO_DIRECT0_MASK);
  r->end = r->start + size;
+ r->flags = IORESOURCE_MEM;
  }
 }
 
@@ -2093,4 +2094,5 @@ void sba_distributed_lmmio(struct parisc_device *pci_hba, struct resource *r )
  size = (~READ_REG32(sba->sba_hpa + LMMIO_DIST_MASK)) / ROPES_PER_IOC;
  r->start += rope * (size + 1); /* adjust base for this rope */
  r->end = r->start + size;
+ r->flags = IORESOURCE_MEM;
 }
diff --git a/drivers/parisc/superio.c b/drivers/parisc/superio.c
index 33e5ade..675f04e 100644
--- a/drivers/parisc/superio.c
+++ b/drivers/parisc/superio.c
@@ -325,7 +325,7 @@ static unsigned int superio_startup_irq(unsigned int irq)
  return 0;
 }
 
-static struct hw_interrupt_type superio_interrupt_type = {
+static struct irq_chip superio_interrupt_type = {
  .typename = SUPERIO,
  .startup = superio_startup_irq,
  .shutdown = superio_disable_irq,
@@ -434,8 +434,8 @@ static void __init superio_parport_init(void)
  0 /*base_hi*/,
  PAR_IRQ,
  PARPORT_DMA_NONE /* dma */,
- NULL /*struct pci_dev* */),
- 0 /* shared irq flags */ )
+ NULL /*struct pci_dev* */,
+ 0 /* shared irq flags */))
 
  printk(KERN_WARNING PFX "Probing parallel port failed.\n");
 #endif /* CONFIG_PARPORT_PC */
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 0048f11..9eecbc0 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -616,6 +616,8 @@ config FB_STI
  select FB_CFB_FILLRECT
  select FB_CFB_COPYAREA
  select FB_CFB_IMAGEBLIT
+ select STI_CONSOLE
+ select VT
  default y
  ---help---
   STI refers to the HP "Standard Text Interface" which is a set of

[John David Anglin-4]

> End of assembler dump.
> (gdb) p/x $r21
> $2 = 0x1

>From the values in the core dump and the code, I calculate that r21
should contain the value 0x40368880.  So, it seems another instance
of cache corruption.  However, in this case, it's not at program
startup.

Dave
--
J. David Anglin                                  dave.anglin@...
National Research Council of Canada              [phone] (FAX: [phone])


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Carlos O'Donell-2]

On Mon, Aug 3, 2009 at 1:14 PM, John David
Anglin<dave@...> wrote:
>> End of assembler dump.
>> (gdb) p/x $r21
>> $2 = 0x1
>
> From the values in the core dump and the code, I calculate that r21
> should contain the value 0x40368880.  So, it seems another instance
> of cache corruption.  However, in this case, it's not at program
> startup.

What we need here is a smaller testcase that triest to reproduce what
you are seeing.

I'm currently pouring all my time into glibc and debian-hppa package
build issues.

When I bubble up the problem stack, if you have a test case for this,
I can look into it with more detail.

Cheers,
CArlos.


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andreas Barth]

* Andreas Barth (aba@...) [090730 16:51]:
> As from release team point of view, it is necessary that there is a plan
> how hppa can and will return in the forseeable future to normal mode of
> operation, i.e. there are not many issues with e.g. architecture specific
> build failures.

I have seen some activity from your side. Thank you for that.

However, it would be really good if we could get some written down
plan with maximum amount of time it takes till we are in normale
operation mode.


Let me try to explain what we mean with that:

As an current exmaple, take the libcdio-transition. This transition
needs to have updated packages xmms2, xmp and vlc. However, the
packages are out-of-date on hppa, and for this reason cannot enter
testing (and they depend on an old library that will go away with the
transition).


Of course, this happens with any architecture from time to time. But
hppa is quite often hit there.


Forcing the transition as of now breaks these packages on hppa:
libvlc-dev, libvlc2, libvlccore-dev, libvlccore2, mozilla-plugin-vlc, vlc,
vlc-dbg, vlc-nox, vlc-plugin-ggi, vlc-plugin-jack, vlc-plugin-pulse,
vlc-plugin-sdl, xmp, xmp-audacious


It is very tempting for me to just put hppa to the list of broken
architectures.


For us as release team it is necessary that an architecture is not
outstanding often hit by "out of date"-packages in an transition. If
you look at https://buildd.debian.org/stats/graph2-week-big.png you
can see that hppa has issues to keep up.

I see that issues that are brought up here are most often resolved
quite fast, but this forces us to manually dig for issues. I would
like that we can relay on the fact that packages (unless a specific
bug exists in the package of course) are normally built within a few
days, and that build failures are investigated by the porters and
fixed if these are port-specific issues (falling kernel, whatever).

If you need help in setting up infrastructure for that, please let us
know.


Cheers,
Andi


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Frans Pop-3]

Andreas Barth wrote:
> As an current exmaple, take the libcdio-transition. This transition
> needs to have updated packages xmms2, xmp and vlc. However, the
> packages are out-of-date on hppa, and for this reason cannot enter
> testing (and they depend on an old library that will go away with the
> transition).

I'm not an hppa porter and also have not looked at the current general
state of hppa build failures, but are you sure this is a good example?

1) vlc is also not yet built on mips/mipsel, so hppa is not *the* blocking
arch.

2) The current build was tried 3 times and failed three times with
different errors; it also needed 3 tries on powerpc and required binNMUs
on 2 arches. So, there *has* been action by the porters (retries) and
clearly there are also problems with the package itself or its
dependencies.
Is it realistic to require porters to spend a lot of time or give priority
to such an apparently fragile package? Isn't there some obligation on the
maintainer of the package too?

3) Looking at the error, it seems to me that this is hardly an
architecture-specific issue:
/bin/sh ../../libtool --tag=CC   --mode=link gcc -std=gnu99
`top_srcdir="../.." top_builddir="../.." ../../vlc-config --cflags plugin
libflac_plugin.la` -g -O2 -Wall -Wextra -Wsign-compare -Wundef -Wpointer-arith -Wbad-function-cast -Wcast-align -Wwrite-strings -Wmissing-prototypes -Wvolatile-register-var -Werror-implicit-function-declaration -pipe -rpath '/usr/lib/vlc/codec' -avoid-version -module -export-symbol-regex
^vlc_entry -shrext .so -no-undefined `top_srcdir="../.."
top_builddir="../.." ../../vlc-config --ldflags plugin
libflac_plugin.la` -Wl,--as-needed -o
libflac_plugin.la -rpath /usr/lib/vlc/codec libflac_plugin_la-flac.lo  
`top_srcdir="../.." top_builddir="../.." ../../vlc-config -libs plugin
libflac_plugin.la` ../../src/libvlccore.la ../../compat/libcompat.la
libtool: link:
gcc -std=gnu99 -shared  .libs/libflac_plugin_la-flac.o  -Wl,--whole-archive ../../compat/.libs/libcompat.a -Wl,--no-whole-archive  -Wl,-rpath -Wl,/build/buildd-vlc_1.0.1-1-hppa-1oK93U/vlc-1.0.1/src/.libs -Wl,--as-needed -lpthread /usr/lib/libFLAC.so -logg ../../src/.libs/libvlccore.so    -Wl,-soname -Wl,libflac_plugin.so -o .libs/libflac_plugin.so
/bin/sed: can't read /usr/lib/libogg.la: No such file or directory
libtool: link: `/usr/lib/libogg.la' is not a valid libtool archive

Or are you simply asking the hppa porters to be more active in filing
FTBFS bugs against packages after build failures?

Cheers,
FJP


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Luk Claes]

Frans Pop wrote:
> Andreas Barth wrote:
>> As an current exmaple, take the libcdio-transition. This transition
>> needs to have updated packages xmms2, xmp and vlc. However, the
>> packages are out-of-date on hppa, and for this reason cannot enter
>> testing (and they depend on an old library that will go away with the
>> transition).
>
> I'm not an hppa porter and also have not looked at the current general
> state of hppa build failures, but are you sure this is a good example?

It's a good example of why having a suboptimal working architecture can
delay more and more things which makes it either harder for everyone or
harder for the port.

> 1) vlc is also not yet built on mips/mipsel, so hppa is not *the* blocking
> arch.

The build failure for mips/mipsel is due to a bug in iceape which is
solved upstream.

> 2) The current build was tried 3 times and failed three times with
> different errors; it also needed 3 tries on powerpc and required binNMUs
> on 2 arches. So, there *has* been action by the porters (retries) and
> clearly there are also problems with the package itself or its
> dependencies.

Note that these retries for hppa have been done by me.

The first failure was because of a broken hppa chroot due to a non arch
specific issue. The second failure was because of a broken chroot due to
another non arch specific issue. The third one is due to an
uncoordinated transition of libogg.

The reason it takes long to fix these issues is mainly because of the
recurring segfaults which delay having fixed packages to be able to fix
the chroot or rebuild the dependencies that need to be rebuilt first.

Also the other retries and the binNMUs had nothing to do with the
package quality.

> Is it realistic to require porters to spend a lot of time or give priority
> to such an apparently fragile package? Isn't there some obligation on the
> maintainer of the package too?

So this is not applicable.

> Or are you simply asking the hppa porters to be more active in filing
> FTBFS bugs against packages after build failures?

Looking at build logs is indeed not a bad idea, though not only to file
bug reports against the failing to build package, but also to notice
chroot issues or other reasons the build failed. So the issues can be
solved or reproduced earlier.

Cheers

Luk


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andreas Barth]

* Frans Pop (elendil@...) [090816 15:57]:
> Andreas Barth wrote:
> > As an current exmaple, take the libcdio-transition. This transition
> > needs to have updated packages xmms2, xmp and vlc. However, the
> > packages are out-of-date on hppa, and for this reason cannot enter
> > testing (and they depend on an old library that will go away with the
> > transition).

> 1) vlc is also not yet built on mips/mipsel, so hppa is not *the* blocking
> arch.

You might have noticed that I spoke of three packages, where for xmms2
hppa is the only one, xmp hppa together with ppc (buildd maintainer
looks for it, issue on ppc probably found) and vlc together with
mips*.

For vlc and mips* the core cause is http://bugs.debian.org/541797 .

Please notice that it is ok if that happens from time to time - just
hppa is too often involved into that. Please refer to the "uploaded
packages out of date" for statistics.


> 2) The current build was tried 3 times and failed three times with
> different errors; it also needed 3 tries on powerpc and required binNMUs
> on 2 arches. So, there *has* been action by the porters (retries) and
> clearly there are also problems with the package itself or its
> dependencies.
> Is it realistic to require porters to spend a lot of time or give priority
> to such an apparently fragile package? Isn't there some obligation on the
> maintainer of the package too?

If porters think the package is too fragile they are certainly free to
file RC bugs or ask for help on -release.

> 3) Looking at the error, it seems to me that this is hardly an
> architecture-specific issue:
> /bin/sh ../../libtool --tag=CC   --mode=link gcc -std=gnu99
> `top_srcdir="../.." top_builddir="../.." ../../vlc-config --cflags plugin
> libflac_plugin.la` -g -O2 -Wall -Wextra -Wsign-compare -Wundef -Wpointer-arith -Wbad-function-cast -Wcast-align -Wwrite-strings -Wmissing-prototypes -Wvolatile-register-var -Werror-implicit-function-declaration -pipe -rpath '/usr/lib/vlc/codec' -avoid-version -module -export-symbol-regex
> ^vlc_entry -shrext .so -no-undefined `top_srcdir="../.."
> top_builddir="../.." ../../vlc-config --ldflags plugin
> libflac_plugin.la` -Wl,--as-needed -o
> libflac_plugin.la -rpath /usr/lib/vlc/codec libflac_plugin_la-flac.lo  
> `top_srcdir="../.." top_builddir="../.." ../../vlc-config -libs plugin
> libflac_plugin.la` ../../src/libvlccore.la ../../compat/libcompat.la
> libtool: link:
> gcc -std=gnu99 -shared  .libs/libflac_plugin_la-flac.o  -Wl,--whole-archive ../../compat/.libs/libcompat.a -Wl,--no-whole-archive  -Wl,-rpath -Wl,/build/buildd-vlc_1.0.1-1-hppa-1oK93U/vlc-1.0.1/src/.libs -Wl,--as-needed -lpthread /usr/lib/libFLAC.so -logg ../../src/.libs/libvlccore.so    -Wl,-soname -Wl,libflac_plugin.so -o .libs/libflac_plugin.so
> /bin/sed: can't read /usr/lib/libogg.la: No such file or directory
> libtool: link: `/usr/lib/libogg.la' is not a valid libtool archive

Well, that sounds like an architecture specific issue with libogg.la
which will probably need an binNMU on hppa.


> Or are you simply asking the hppa porters to be more active in filing
> FTBFS bugs against packages after build failures?

If they would do that, that might be quite helpful to distinguish
between "hppa issue" and "package issue".



Cheers,
Andi


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Carlos O'Donell-2]

On Sun, Aug 16, 2009 at 10:08 AM, Andreas Barth<aba@...> wrote:
>> Or are you simply asking the hppa porters to be more active in filing
>> FTBFS bugs against packages after build failures?
>
> If they would do that, that might be quite helpful to distinguish
> between "hppa issue" and "package issue".

I didn't know vlc, xmms2, and xmp were not building. I'll add them to
my list and look over the failures. I don't know how to get visibility
into what's failing for hppa.

I believed the role of the porter was to cater to the package
maintainers when something failed on the porters architecture.

For example I recently resolved the guile-gnome-platform build issue
that was brought to debian-hppa.

The petsc build issue is in my queue.

The top of my list is the glibc nptl transition.

I strongly suggest any other package build problems should be brought
to debian-hppa.

Cheers,
Carlos.


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andreas Barth]

* Carlos O'Donell (carlos@...) [090819 14:56]:
> I didn't know vlc, xmms2, and xmp were not building. I'll add them to
> my list and look over the failures. I don't know how to get visibility
> into what's failing for hppa.

Basically, by e.g. checking the testing excuse page which packages
don't have an upload after e.g. 4 days (and where hppa is the only one
or one of only two, not counting *bsd* for the moment, and mips* is
only one architecture for that). And/or by access to wanna-build. (All
of that can of course be automated, and if you need help to set
something up, we could of course do that together.)


> I believed the role of the porter was to cater to the package
> maintainers when something failed on the porters architecture.

That too. I consider the responsibility of "packages compile on all
architectures" be shared between maintainers and porters.

I know that there will always be cases where "default handling"
doesn't work, but I would wish that most cases work without someone
from the release team intervening (one reason because we see such
issues usually quite late, when we really *need* the package for a
transition). If a package only FTBFS on one or two architectures, it
mostly hints to a problem specific to the buildd or architecture.

> I strongly suggest any other package build problems should be brought
> to debian-hppa.

No doubt that that's usefull.



Cheers,
Andi


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Carlos O'Donell-2]

On Wed, Aug 19, 2009 at 9:20 AM, Andreas Barth<aba@...> wrote:

> * Carlos O'Donell (carlos@...) [090819 14:56]:
>> I didn't know vlc, xmms2, and xmp were not building. I'll add them to
>> my list and look over the failures. I don't know how to get visibility
>> into what's failing for hppa.
>
> Basically, by e.g. checking the testing excuse page which packages
> don't have an upload after e.g. 4 days (and where hppa is the only one
> or one of only two, not counting *bsd* for the moment, and mips* is
> only one architecture for that). And/or by access to wanna-build. (All
> of that can of course be automated, and if you need help to set
> something up, we could of course do that together.)

OK, this will need to be setup. I'll contact you in early September.
Until I set this up, I will rely on package maintainers to contact
debian-hppa.

>> I believed the role of the porter was to cater to the package
>> maintainers when something failed on the porters architecture.
>
> That too. I consider the responsibility of "packages compile on all
> architectures" be shared between maintainers and porters.

I agree about the shared responsibility. However, with busy porters I
expect the package maintainer to reach out, instead of waiting for
porters to become pro-active. The best case scenario is a pro-active
porter (some day soon).

> I know that there will always be cases where "default handling"
> doesn't work, but I would wish that most cases work without someone
> from the release team intervening (one reason because we see such
> issues usually quite late, when we really *need* the package for a
> transition). If a package only FTBFS on one or two architectures, it
> mostly hints to a problem specific to the buildd or architecture.

Yes, I agree again, and we're struggling up hill to get everything
back on track for hppa.

>> I strongly suggest any other package build problems should be brought
>> to debian-hppa.
>
> No doubt that that's usefull.

Thanks.

Cheers,
Carlos.


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Frans Pop-3]

Carlos O'Donell wrote:
> I didn't know vlc, xmms2, and xmp were not building. I'll add them to
> my list and look over the failures. I don't know how to get visibility
> into what's failing for hppa.

Do you know of:
https://buildd.debian.org/~luk/status/architecture.php?suite=&a=hppa
?

Note that the numbers between parens (e.g. 6/7 for newlib) refer to
<number of arches on which the package was build successfully>/<total
number of arches on which it was built>. You can probably concentrate on
packages that built successfully on most arches, but fail on hppa.

Cheers,
FJP


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Carlos O'Donell-2]

On Wed, Aug 19, 2009 at 9:53 AM, Frans Pop<elendil@...> wrote:

> Carlos O'Donell wrote:
>> I didn't know vlc, xmms2, and xmp were not building. I'll add them to
>> my list and look over the failures. I don't know how to get visibility
>> into what's failing for hppa.
>
> Do you know of:
> https://buildd.debian.org/~luk/status/architecture.php?suite=&a=hppa
> ?
>
> Note that the numbers between parens (e.g. 6/7 for newlib) refer to
> <number of arches on which the package was build successfully>/<total
> number of arches on which it was built>. You can probably concentrate on
> packages that built successfully on most arches, but fail on hppa.

Thanks Frans!

So I should be looking for packages in the "Failed" state that say
"(N-1)/N" (fails only on hppa)?

Cheers,
Carlos.


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...