[parisc-linux] Re: Kernel faults on boot

[parisc-linux] Re: Kernel faults on boot

[Richard Hirst]

On Fri, Jun 08, 2001 at 07:28:51PM +0200, Peter Weilbacher wrote:
> I have played with a 712/60 and had the same problem as Frank. I got
> it installed over the first reboot, but after a the next one on
> every reboot it crashed with Kernel faults at cron.
> 
> Now I have reinstalled and I do not get over the reboot. Is it
> explained somewhere, which I need to write down, to help you debug
> the problem? (I guess it doesn't make it into any logs, which I
> could look at by putting the disk on another machine.)

I expect to get my hands on a 712 very soon, so I'll see if I can
reproduce this problem.  So far as what you can write down for me...
Usually a kernel crash gives a stack dump followed by the fault type
and address, then a bunch of registers.  I'm not too interested in the
stack dump (which has probably scrolled off the screen, anyway), but
everything after the stack dump would be useful.

You could interact with the IPL and add 'init=/bin/sh' to the parameters.
It might at least boot to a shell prompt then.  It is unlikely to be
cron itself that causes the problem, but just in case you could disable
it by renaming /usr/sbin/cron.  Something like

boot to a shell
e2fsck /dev/sda<whatever your root device is>
mount -o remount,rw /
mv /usr/sbin/cron /usr/sbin/cron.ori
sync
mount -o remount,ro /
hit the reset button and try a normal boot again


Thanks,
  Richard

Re: [parisc-linux] Re: Kernel faults on boot

[Peter Weilbacher]

On Sun, 10 Jun 2001, Richard Hirst wrote:

> On Fri, Jun 08, 2001 at 07:28:51PM +0200, Peter Weilbacher wrote:
> > I have played with a 712/60 and had the same problem as Frank. I got
> > it installed over the first reboot, but after a the next one on
> > every reboot it crashed with Kernel faults at cron.
> >
> > Now I have reinstalled and I do not get over the reboot. Is it
> > explained somewhere, which I need to write down, to help you debug
> > the problem? (I guess it doesn't make it into any logs, which I
> > could look at by putting the disk on another machine.)
>
> I expect to get my hands on a 712 very soon, so I'll see if I can
> reproduce this problem.  So far as what you can write down for me...
> Usually a kernel crash gives a stack dump followed by the fault type
> and address, then a bunch of registers.  I'm not too interested in the
> stack dump (which has probably scrolled off the screen, anyway), but
> everything after the stack dump would be useful.

Hmm, it seems that the numbers change every time, but here are the
ones from the last instance:

	Kernel Fault: Code=15 regs=1051ca80 (Addr=1dc0ce18)

	     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
	PSW: 00000000000001000000000000001111
	r0-3o 00000000 10236000 10193d70 1dc0cd18
	r4-7o 146fc000 102fe13c 00000001 00000100
	r8-11o 4020b1a8 00000000 00000004 146ff000
	r12-15o 00000100 00000030 00003000 102fe138
	r16-19o 00000080 1051c908 00000001 14786000
	r20-23o 146fc000 102959f8 101da1d4 00000000
	r24-27o 000000ff 1dc0ce18 146fc000 10268010
	r28-31o 00001920 00000004 1051ccc0 10192c78
	sr0-3o 00000000 0000012a 00000000 0000012a
	sr4-7o 00000000 00000000 00000000 00000000

	IASQ: 00000000 00000000 IAOQ: 10236234 10236238
	 IIR: 0f221033    ISR: 00000000  IOR: 1dc0ce18
	 ORIG_R28: 1005f210

Phew, quite a work to type all this stuff, I am glad that you are
not interested in the stack... Perhaps this is useful.

In the meantime I noticed that about every 6th time it boots up
without crashing, but the keyboard setting from the installation
(German) was obviously not saved.

Peter.

Re: [parisc-linux] Re: Kernel faults on boot

[Peter Weilbacher]

On Sun, 10 Jun 2001, Richard Hirst wrote:

> boot to a shell
> e2fsck /dev/sda<whatever your root device is>
> mount -o remount,rw /
> mv /usr/sbin/cron /usr/sbin/cron.ori
> sync
> mount -o remount,ro /
> hit the reset button and try a normal boot again

If I take cron out like that, then the next job (atd) is the one
which triggers the kernel fault. An error message about problems
with <sth>cron / <sth>atd is displayed, but I am never fast enough
to read and unterstand it entirely, before the stack dump causes it
to scroll off the screen.

Is it normal for PA-RISC Linux, that the typical Linux Key-Combo
<Shift>-<PgUp/Down> does not work on the console? Or is that even
normal for Debian?

Greetings,
	Peter.

Re: [parisc-linux] Re: Kernel faults on boot

[Richard Hirst]

On Mon, Jun 11, 2001 at 01:17:39PM +0200, Peter Weilbacher wrote:
> Hmm, it seems that the numbers change every time, but here are the
> ones from the last instance:
> 
> 	Kernel Fault: Code=15 regs=1051ca80 (Addr=1dc0ce18)
> 
> 	     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> 	PSW: 00000000000001000000000000001111
> 	r0-3o 00000000 10236000 10193d70 1dc0cd18
> 	r4-7o 146fc000 102fe13c 00000001 00000100
> 	r8-11o 4020b1a8 00000000 00000004 146ff000
> 	r12-15o 00000100 00000030 00003000 102fe138
> 	r16-19o 00000080 1051c908 00000001 14786000
> 	r20-23o 146fc000 102959f8 101da1d4 00000000
> 	r24-27o 000000ff 1dc0ce18 146fc000 10268010
> 	r28-31o 00001920 00000004 1051ccc0 10192c78
> 	sr0-3o 00000000 0000012a 00000000 0000012a
> 	sr4-7o 00000000 00000000 00000000 00000000
> 
> 	IASQ: 00000000 00000000 IAOQ: 10236234 10236238
> 	 IIR: 0f221033    ISR: 00000000  IOR: 1dc0ce18
> 	 ORIG_R28: 1005f210
> 
> Phew, quite a work to type all this stuff, I am glad that you are
> not interested in the stack... Perhaps this is useful.

The 'o' chars are actually tabs, which are supposed to make the register
dump line up.

IAOQ is the most important.  You can look up the value in the
sti/sys_map file on the CD:

...
10236204 T bcopy
10236228 T memcpy
1023624c T memmove
...

so it crashed in memcpy.  r2 is often the return address, so back to sys_map:

...
10193a98 T vc_allocate
10193bc8 T vc_resize
10193ed8 t .L1003
10193f40 t .L1043
10193fcc T vc_disallocate
...

looks like memcpy was called from vc_resize().

r236,r25,r24,r23 are the call params, if they havn't been overwritten.

memcpy() disassembles as

00000000 <memcpy>:
   0:   37 18 3f ff     ldo -1(r24),r24
   4:   87 1f 20 20     cmpib,= -1,r24,1c <memcpy+0x1c>
   8:   08 1a 02 54     copy r26,r20
   c:   0f 22 10 33     ldb,ma  1(sr0,r25),r19
  10:   37 18 3f ff     ldo -1(r24),r24
  14:   8f 1f 3f e5     cmpib,<> -1,r24,c <memcpy+0xc>
  18:   0e 93 12 22     stb,ma  r19,1(sr0,r20)
  1c:   e8 40 c0 00     bv r0(rp)
  20:   08 1a 02 5c     copy r26,ret0

r26 = r20, so it failed on the first byte of the move, so call was

  memcpy(0x146fc000,0x1dc0ce18,0x100);

with 0x1dc0ce18 being an invalid address.

I guess that comes from this loop in drivers/char/screen.c:

  while (ol < scr_end) {
          scr_memcpyw((unsigned short *) nl, (unsigned short *) ol, rlth);
          if (rrem)
                  scr_memsetw((void *)(nl + rlth), video_erase_char, rrem);
          ol += osr;
          nl += sr;
  }


At this point I'll stop and hope Helge can comment...


> In the meantime I noticed that about every 6th time it boots up
> without crashing, but the keyboard setting from the installation
> (German) was obviously not saved.

Correct, keyboard config is broken in the release sti image.  If you
manage to boot you could try

mv /bin/loadkeys /bin/loadkeys.old
mv /bin/dumpkeys /bin/dumpkeys.old
mv /etc/console-tools /etc/console-tools.old
apt-get install console-data console-common console-tools console-tools-libs


If that works, let me know and I'll add it to the errata.

Richard

Re: [parisc-linux] Re: Kernel faults on boot

[Richard Hirst]

On Mon, Jun 11, 2001 at 01:54:16PM +0200, Peter Weilbacher wrote:
> On Sun, 10 Jun 2001, Richard Hirst wrote:
> 
> > boot to a shell
> > e2fsck /dev/sda<whatever your root device is>
> > mount -o remount,rw /
> > mv /usr/sbin/cron /usr/sbin/cron.ori
> > sync
> > mount -o remount,ro /
> > hit the reset button and try a normal boot again
> 
> If I take cron out like that, then the next job (atd) is the one
> which triggers the kernel fault. An error message about problems
> with <sth>cron / <sth>atd is displayed, but I am never fast enough
> to read and unterstand it entirely, before the stack dump causes it
> to scroll off the screen.
> 
> Is it normal for PA-RISC Linux, that the typical Linux Key-Combo
> <Shift>-<PgUp/Down> does not work on the console? Or is that even
> normal for Debian?

I wouldn't expect that to work once the kernel has crashed, unfortunately.

Richard

Re: [parisc-linux] Re: Kernel faults on boot

[Matthieu Delahaye]

Hum, could you check your Hardware clock before booting.
I got this problem on a 742 box and when I set the hwclock
to the right date and time (The clock was unset due to lack
of battery), cron worked.

Peter Weilbacher wrote:
> 
> On Sun, 10 Jun 2001, Richard Hirst wrote:
> 
> > On Fri, Jun 08, 2001 at 07:28:51PM +0200, Peter Weilbacher wrote:
> > > I have played with a 712/60 and had the same problem as Frank. I got
> > > it installed over the first reboot, but after a the next one on
> > > every reboot it crashed with Kernel faults at cron.
> > >
> > > Now I have reinstalled and I do not get over the reboot. Is it
> > > explained somewhere, which I need to write down, to help you debug
> > > the problem? (I guess it doesn't make it into any logs, which I
> > > could look at by putting the disk on another machine.)
> >
> > I expect to get my hands on a 712 very soon, so I'll see if I can
> > reproduce this problem.  So far as what you can write down for me...
> > Usually a kernel crash gives a stack dump followed by the fault type
> > and address, then a bunch of registers.  I'm not too interested in the
> > stack dump (which has probably scrolled off the screen, anyway), but
> > everything after the stack dump would be useful.
> 
> Hmm, it seems that the numbers change every time, but here are the
> ones from the last instance:
> 
>         Kernel Fault: Code=15 regs=1051ca80 (Addr=1dc0ce18)
> 
>              YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
>         PSW: 00000000000001000000000000001111
>         r0-3o 00000000 10236000 10193d70 1dc0cd18
>         r4-7o 146fc000 102fe13c 00000001 00000100
>         r8-11o 4020b1a8 00000000 00000004 146ff000
>         r12-15o 00000100 00000030 00003000 102fe138
>         r16-19o 00000080 1051c908 00000001 14786000
>         r20-23o 146fc000 102959f8 101da1d4 00000000
>         r24-27o 000000ff 1dc0ce18 146fc000 10268010
>         r28-31o 00001920 00000004 1051ccc0 10192c78
>         sr0-3o 00000000 0000012a 00000000 0000012a
>         sr4-7o 00000000 00000000 00000000 00000000
> 
>         IASQ: 00000000 00000000 IAOQ: 10236234 10236238
>          IIR: 0f221033    ISR: 00000000  IOR: 1dc0ce18
>          ORIG_R28: 1005f210
> 
> Phew, quite a work to type all this stuff, I am glad that you are
> not interested in the stack... Perhaps this is useful.
> 
> In the meantime I noticed that about every 6th time it boots up
> without crashing, but the keyboard setting from the installation
> (German) was obviously not saved.
> 
> Peter.
> 
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/cgi-bin/mailman/listinfo/parisc-linux

-- 
Matthieu Delahaye
ESIEE Team
http://mkhppa1.esiee.fr/

[parisc-linux] Re: Kernel faults on boot

[Peter Weilbacher]

On Mon, 11 Jun 2001, Matthieu Delahaye wrote:

> Hum, could you check your Hardware clock before booting.
> I got this problem on a 742 box and when I set the hwclock
> to the right date and time (The clock was unset due to lack
> of battery), cron worked.

No, I have set it to approximately the right time, when I installed,
and it is only off by a few minutes. Didn't find a netdate or
ntpdate on the CD to do it better, and with all the boot problems I
didn't have time to compile it myself...

Peter.

Re: [parisc-linux] Re: Kernel faults on boot

[Richard Hirst]

Just tried my new installer that tries to run the second stage installer
automatically on reboot.  Crashed the kernel in kfree(), called from
vc_resize() again.  I'm guessing there is something screwy about the
screenbuf allocation.  Possibly due to the first ones being allocated
from the bootmem allocator?

Richard


On Mon, Jun 11, 2001 at 01:16:36PM +0100, Richard Hirst wrote:
> On Mon, Jun 11, 2001 at 01:17:39PM +0200, Peter Weilbacher wrote:
> > Hmm, it seems that the numbers change every time, but here are the
> > ones from the last instance:
> > 
> > 	Kernel Fault: Code=15 regs=1051ca80 (Addr=1dc0ce18)
> > 
> > 	     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> > 	PSW: 00000000000001000000000000001111
> > 	r0-3o 00000000 10236000 10193d70 1dc0cd18
> > 	r4-7o 146fc000 102fe13c 00000001 00000100
> > 	r8-11o 4020b1a8 00000000 00000004 146ff000
> > 	r12-15o 00000100 00000030 00003000 102fe138
> > 	r16-19o 00000080 1051c908 00000001 14786000
> > 	r20-23o 146fc000 102959f8 101da1d4 00000000
> > 	r24-27o 000000ff 1dc0ce18 146fc000 10268010
> > 	r28-31o 00001920 00000004 1051ccc0 10192c78
> > 	sr0-3o 00000000 0000012a 00000000 0000012a
> > 	sr4-7o 00000000 00000000 00000000 00000000
> > 
> > 	IASQ: 00000000 00000000 IAOQ: 10236234 10236238
> > 	 IIR: 0f221033    ISR: 00000000  IOR: 1dc0ce18
> > 	 ORIG_R28: 1005f210
> > 
> > Phew, quite a work to type all this stuff, I am glad that you are
> > not interested in the stack... Perhaps this is useful.
> 
> The 'o' chars are actually tabs, which are supposed to make the register
> dump line up.
> 
> IAOQ is the most important.  You can look up the value in the
> sti/sys_map file on the CD:
> 
> ...
> 10236204 T bcopy
> 10236228 T memcpy
> 1023624c T memmove
> ...
> 
> so it crashed in memcpy.  r2 is often the return address, so back to sys_map:
> 
> ...
> 10193a98 T vc_allocate
> 10193bc8 T vc_resize
> 10193ed8 t .L1003
> 10193f40 t .L1043
> 10193fcc T vc_disallocate
> ...
> 
> looks like memcpy was called from vc_resize().
> 
> r236,r25,r24,r23 are the call params, if they havn't been overwritten.
> 
> memcpy() disassembles as
> 
> 00000000 <memcpy>:
>    0:   37 18 3f ff     ldo -1(r24),r24
>    4:   87 1f 20 20     cmpib,= -1,r24,1c <memcpy+0x1c>
>    8:   08 1a 02 54     copy r26,r20
>    c:   0f 22 10 33     ldb,ma  1(sr0,r25),r19
>   10:   37 18 3f ff     ldo -1(r24),r24
>   14:   8f 1f 3f e5     cmpib,<> -1,r24,c <memcpy+0xc>
>   18:   0e 93 12 22     stb,ma  r19,1(sr0,r20)
>   1c:   e8 40 c0 00     bv r0(rp)
>   20:   08 1a 02 5c     copy r26,ret0
> 
> r26 = r20, so it failed on the first byte of the move, so call was
> 
>   memcpy(0x146fc000,0x1dc0ce18,0x100);
> 
> with 0x1dc0ce18 being an invalid address.
> 
> I guess that comes from this loop in drivers/char/screen.c:
> 
>   while (ol < scr_end) {
>           scr_memcpyw((unsigned short *) nl, (unsigned short *) ol, rlth);
>           if (rrem)
>                   scr_memsetw((void *)(nl + rlth), video_erase_char, rrem);
>           ol += osr;
>           nl += sr;
>   }
> 
> 
> At this point I'll stop and hope Helge can comment...
> 
> 
> > In the meantime I noticed that about every 6th time it boots up
> > without crashing, but the keyboard setting from the installation
> > (German) was obviously not saved.
> 
> Correct, keyboard config is broken in the release sti image.  If you
> manage to boot you could try
> 
> mv /bin/loadkeys /bin/loadkeys.old
> mv /bin/dumpkeys /bin/dumpkeys.old
> mv /etc/console-tools /etc/console-tools.old
> apt-get install console-data console-common console-tools console-tools-libs
> 
> 
> If that works, let me know and I'll add it to the errata.
> 
> Richard
> 

Re: [parisc-linux] Re: Kernel faults on boot

[Simeon Walker]

Hi,
  I have just installed the from 0.9 ISO to a 712/80 (using the
sti kernel) and had the same problem. Modify the palo params and 
going into run level 1 works. I can then run all the services that
would have started at run level 2, it's actually the getty's
started by init that cause the crash.

I thought I'd try and compile my own kernel to see if that
had the same problem but have been unable to do so. First
I tried the apt-get'able kernel source and then I tried the
cvs version with the same problem. The error is:
   make: hppa-linux-gcc: Command not found
Is this because the kernel sources assume I'm cross compiling
whereas I'm actually trying to compile on the target machine
or am I missing some package? I've compiled kernels on 
debian x86 machines so I know what's usually required.

Any advice on either of these issues is appreciated

Regards,
Simeon

-- 
Simeon Walker,                      email: simeon@sbs.bangor.ac.uk
School of Biological Sciences,      phone: +44 (0)1248 383702
University of Wales, Bangor,        fax: +44 (0)1248 382569
Gwynedd, LL57 2UW, UK.              www: http://biology.bangor.ac.uk/

Re: [parisc-linux] Re: Kernel faults on boot

[Richard Hirst]

On Thu, Jun 14, 2001 at 04:15:41PM +0100, Simeon Walker wrote:
> Hi,
>   I have just installed the from 0.9 ISO to a 712/80 (using the
> sti kernel) and had the same problem. Modify the palo params and 
> going into run level 1 works. I can then run all the services that
> would have started at run level 2, it's actually the getty's
> started by init that cause the crash.

Yes, it is fixed in our latest cvs source.

> I thought I'd try and compile my own kernel to see if that
> had the same problem but have been unable to do so. First
> I tried the apt-get'able kernel source and then I tried the
> cvs version with the same problem. The error is:
>    make: hppa-linux-gcc: Command not found
> Is this because the kernel sources assume I'm cross compiling
> whereas I'm actually trying to compile on the target machine
> or am I missing some package? I've compiled kernels on 
> debian x86 machines so I know what's usually required.

Yes, comes from arch/parisc/Makefile

CROSS_COMPILE := hppa-linux-

changing that to

CROSS_COMPILE :=

is one solution.  You do need to use our cvs kernel source at
the moment, we don't have parisc kernel patches in the archive
yet.

Richard

Re: [parisc-linux] Re: Kernel faults on boot

[Matthew Wilcox]

On Thu, Jun 14, 2001 at 04:15:41PM +0100, Simeon Walker wrote:
> I thought I'd try and compile my own kernel to see if that
> had the same problem but have been unable to do so. First
> I tried the apt-get'able kernel source

don't do that -- we're not merged upstream.  ditto, don't do it for glibc,
gcc or gdb.  binutils should be OK, but no promises -- see some of the
recent breakages we've had.

> and then I tried the
> cvs version with the same problem. The error is:
>    make: hppa-linux-gcc: Command not found
> Is this because the kernel sources assume I'm cross compiling

that's right.  we're considering changing this.  it's a one-line
change in any case -- edit arch/parisc/Makefile and change
`CROSS_COMPILE=hppa-linux-' to `CROSS_COMPILE='

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] Re: Kernel faults on boot

[Simeon Walker]

Richard Hirst wrote:
> 
> On Thu, Jun 14, 2001 at 04:15:41PM +0100, Simeon Walker wrote:
> > Hi,
> >   I have just installed the from 0.9 ISO to a 712/80 (using the
> > sti kernel) and had the same problem. Modify the palo params and
> > going into run level 1 works. I can then run all the services that
> > would have started at run level 2, it's actually the getty's
> > started by init that cause the crash.
> 
> Yes, it is fixed in our latest cvs source.
> 
Great, I've got that.

> > I thought I'd try and compile my own kernel to see if that
> > had the same problem but have been unable to do so. First
> > I tried the apt-get'able kernel source and then I tried the
> > cvs version with the same problem. The error is:
> >    make: hppa-linux-gcc: Command not found
> > Is this because the kernel sources assume I'm cross compiling
> > whereas I'm actually trying to compile on the target machine
> > or am I missing some package? I've compiled kernels on
> > debian x86 machines so I know what's usually required.
> 
> Yes, comes from arch/parisc/Makefile
> 
> CROSS_COMPILE := hppa-linux-
> 
> changing that to
> 
> CROSS_COMPILE :=
> 
Ahhhh!

> is one solution.  You do need to use our cvs kernel source at
> the moment, we don't have parisc kernel patches in the archive
> yet.
> 
> Richard

I'm compiling the kernel now so I'll see how it goes. It
certainly compiles slowly on this 712/80...

Thanks,
Simeon

-- 
Simeon Walker,                      email: simeon@sbs.bangor.ac.uk
School of Biological Sciences,      phone: +44 (0)1248 383702
University of Wales, Bangor,        fax: +44 (0)1248 382569
Gwynedd, LL57 2UW, UK.              www: http://biology.bangor.ac.uk/

Re: [parisc-linux] Re: Kernel faults on boot

[Simeon Walker]

Matthew Wilcox wrote:
> 
> On Thu, Jun 14, 2001 at 04:15:41PM +0100, Simeon Walker wrote:
> > I thought I'd try and compile my own kernel to see if that
> > had the same problem but have been unable to do so. First
> > I tried the apt-get'able kernel source
> 
> don't do that -- we're not merged upstream.  ditto, don't do it for glibc,
> gcc or gdb.  binutils should be OK, but no promises -- see some of the
> recent breakages we've had.
> 
so I guess an apt-get upgrade is not such a good thing at this 
point in time?

Thanks for the advice,
Simeon

-- 
Simeon Walker,                      email: simeon@sbs.bangor.ac.uk
School of Biological Sciences,      phone: +44 (0)1248 383702
University of Wales, Bangor,        fax: +44 (0)1248 382569
Gwynedd, LL57 2UW, UK.              www: http://biology.bangor.ac.uk/

Re: [parisc-linux] Re: Kernel faults on boot

[Matt Taggart]

Simeon Walker writes...

> Matthew Wilcox wrote:
> > 
> > On Thu, Jun 14, 2001 at 04:15:41PM +0100, Simeon Walker wrote:
> > > I thought I'd try and compile my own kernel to see if that
> > > had the same problem but have been unable to do so. First
> > > I tried the apt-get'able kernel source
> > 
> > don't do that -- we're not merged upstream.  ditto, don't do it for glibc,
> > gcc or gdb.  binutils should be OK, but no promises -- see some of the
> > recent breakages we've had.
> > 
> so I guess an apt-get upgrade is not such a good thing at this 
> point in time?

No, an apt-get upgrade should be fine. For packages where we differ from 
upstream one of the three cases apply,

1.) the hppa-linux changes have been integrated into the Debian package
2.) a special hppa only deb has been done(which may not be in the archive)
3.) that package doesn't exist in the Debian archive yet

-- 
Matt Taggart        Linux Development Lab
taggart@fc.hp.com   HP Linux Systems Operation

Re: [parisc-linux] Re: Kernel faults on boot

[Matthew Wilcox]

On Thu, Jun 14, 2001 at 05:24:42PM +0100, Simeon Walker wrote:
> so I guess an apt-get upgrade is not such a good thing at this 
> point in time?

Oh, no, that's fine.  Packages don't get uploaded for hppa until they
work.  So, for example, right now, there is no gdb in the debian archive,
only on puffin.external.hp.com until we get it integrated.  glibc 2.2.3-6
has been released, but in't compiled for hppa yet, so you won't get it.

-- 
Revolutions do not require corporate support.