[parisc-linux] C180 oddness

[parisc-linux] C180 oddness

[Tom]

Okay - after a bit of downtime (due to houseguests being in the room with
the HP), I fired it back up to update things. Apt updated the system fine;
cvs updated the kernel from 2.4.18-pa59 to the latest -pa20 release
without errors. Recompiled using menuconfig (no errors), used make-kpkg to
create the kernel, then dpkg to install the generated .deb file (which
created all the links nicely, etc. Ran palo, which was happy, and
rebooted.

Now, the C180 runs headless, with a serial cable running to a Proliant
next to it so I can use minicom as a console if needed. After the reboot,
I couldn't ssh back in, so I checked the console, but minicom wouldn't
get a response. Power-cycled the HP, still no messages on console, no
errors on the LCDs, and eventually (several minutes) a heartbeat light.
Tried unplugging the serial cable, plugging in a keyboard/mouse/monitor
and rebooting again, but still nothing. With the monitor on, after power
on I do get a green signal light on the monitor, just no display. I tried
the "tab after powerup" to switch console settings, but nothing. According
to my C180 manual, having the monitor and keyboard on there should set the
monitor as console, while removing them should send console to ttyS0.

Anyone have any ideas how to rescue this, or what could have caused it?
It's running firmware 6.1, and has been for several months. There's no
error LEDs, no smell of smoke, no melted bits, and no actual response. I
tried switching off the UPS it's on and leaving it for an hour, but still
get the same lack of results. Minicom is set to 9600/8N1/VT100, which is
what worked last time I used the console this way...

Re: [parisc-linux] C180 oddness

[B. Douglas Hilton]

If you did a "make-kpkg" kernel and then a "dpkg -i kernel-image-...."
then you should be able to do a palo boot modification of something
like kernel=/vmlinux.old or /boot/vmlinux.old, etc.

I generally always keep some old "proven" kernel around in /boot
and symlink it to something I can remember easily like /vmlinux-rescue
or such. A couple extra megs of space will is definately worth it.

Thats why PALO, or (in X86: GRUB) is great because you don't have
to monkey with LILO every time you recompile your kernel. Just copy
it into /boot and use your firmware (or GRUB) to boot directly, leaving
your already proven boot sector safe and secure.

If all else fails, use Debian HPPA CDRom Disk-1 to get in there and
see what your old kernel is saved as.

Good Luck!

- Doug



Tom wrote:
 > Okay - after a bit of downtime (due to houseguests being in the room with
 > the HP), I fired it back up to update things. Apt updated the system fine;
 > cvs updated the kernel from 2.4.18-pa59 to the latest -pa20 release
 > without errors. Recompiled using menuconfig (no errors), used make-kpkg to
 > create the kernel, then dpkg to install the generated .deb file (which
 > created all the links nicely, etc. Ran palo, which was happy, and
 > rebooted.
 >
 > Now, the C180 runs headless, with a serial cable running to a Proliant
 > next to it so I can use minicom as a console if needed. After the reboot,
 > I couldn't ssh back in, so I checked the console, but minicom wouldn't
 > get a response. Power-cycled the HP, still no messages on console, no
 > errors on the LCDs, and eventually (several minutes) a heartbeat light.
 > Tried unplugging the serial cable, plugging in a keyboard/mouse/monitor
 > and rebooting again, but still nothing. With the monitor on, after power
 > on I do get a green signal light on the monitor, just no display. I tried
 > the "tab after powerup" to switch console settings, but nothing. According
 > to my C180 manual, having the monitor and keyboard on there should set the
 > monitor as console, while removing them should send console to ttyS0.
 >
 > Anyone have any ideas how to rescue this, or what could have caused it?
 > It's running firmware 6.1, and has been for several months. There's no
 > error LEDs, no smell of smoke, no melted bits, and no actual response. I
 > tried switching off the UPS it's on and leaving it for an hour, but still
 > get the same lack of results. Minicom is set to 9600/8N1/VT100, which is
 > what worked last time I used the console this way...
 >
 > _______________________________________________
 > parisc-linux mailing list
 > parisc-linux@lists.parisc-linux.org
 > http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
 >

Re: [parisc-linux] C180 oddness

[Grant Grundler]

Tom wrote:
> I couldn't ssh back in, so I checked the console, but minicom wouldn't
> get a response. Power-cycled the HP, still no messages on console, no
> errors on the LCDs, and eventually (several minutes) a heartbeat light.
...
> Anyone have any ideas how to rescue this, or what could have caused it?

Just some thoughts:
o if ssh doesn't work, try ping. ping will give a clue how far into the
  initialization the kernel got.

o after cyclepower on a system configured to run console on serial port,
  not seeing PDC init messages on the serial port suggests a HW problem.

o try another serial cable or a different "client" to start ruling
  out issues with serial connection.

> but still
> get the same lack of results. Minicom is set to 9600/8N1/VT100, which is
> what worked last time I used the console this way...

settings are correct.


grant

Re: [parisc-linux] C180 oddness

[Chuck Slivkoff]

Hi Tom,

On Wed, 2002-10-02 at 13:47, Tom wrote:
>
> the "tab after powerup" to switch console settings, but nothing. According
> to my C180 manual, having the monitor and keyboard on there should set the
> monitor as console, while removing them should send console to ttyS0.

If the console path in the PDC is explicitly set to one of the serial
ports, it will not automagically change back to graphics by connecting a
keyboard. The opposite is true, though: no/bad PS/2 keyboard, no/bad
graphics, or invalid PDC value (ie, graphics card moved/removed) & the
console will be directed to the first serial port.

Do the PS/2 keyboard LED's flash and Num_Lock LED light during POST?

Here's another suggestion: try removing all I/O cards, detaching all
disks, disconnecting the network, and removing all but 1 pair of SIMMs.

When you get the console back, you might want to enable "chassis codes" 
(to trace the POST codes) and disable "fast boot" (to get a better test
of RAM). I believe The service manual has a table which should be able
to give some indication of when the firmware chooses a console device.

http://h20000.www2.hp.com/bizsupport/TechSupport/DocumentIndex.jsp?contentType=SupportManual&docIndexName=hardware+manuals&locale=en_US&prodTypeId=43563&prodSeriesId=44435&prodSeriesName=hp+Visualize+c180+workstation

BTW, one of the nice things about the Allegro/Forte/Duet (4-digit
B/C/Jxxxx, less J2240) systems is the LCD display which indicates where
the console has be directed.

Good Luck.

[parisc-linux] /usr/bin/ld: can not size stub section: Bad value

[phi]

Hi All,

I got this from the final link of my application.

/usr/bin/ld: can not size stub section: Bad value
/usr/bin/ld: BFD 2.12.90.0.14 20020627 Debian GNU/Linux internal error,
aborting
 at ../../bfd/elf32-hppa.c line 4124 in elf32_hppa_relocate_section

/usr/bin/ld: Please report this bug.



Is this a bug or faq today?

It is while building a tiny prog linked with shared lib, 'may be' this as to
do with the way the shared libs are build i.e short pic vs long pic?

Thanx in advance?
Phi

Re: [parisc-linux] /usr/bin/ld: can not size stub section: Bad value

[John David Anglin]

> /usr/bin/ld: can not size stub section: Bad value
> /usr/bin/ld: BFD 2.12.90.0.14 20020627 Debian GNU/Linux internal error,

I presume that you are using debian gcc 3.0.4.  There are known problems with
branches.  This error is usually caused by a call branch being too far from
the start of the module, or function if using -ffunction-sections.
Compiling with gcc 3.2 or later may help.

> Is this a bug or faq today?

Both.  There are still some problems in this area that haven't been resolved.
However, the situation is better in 3.2 than 3.0.4.  kde30/Qt is one package
where there are still problems.

> It is while building a tiny prog linked with shared lib, 'may be' this as to
> do with the way the shared libs are build i.e short pic vs long pic?

I can't remember offhand when this was changed but there is no difference
between short and long pic in 3.2 and later.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] C180 oddness

[Tom]

In case this helps anyone else...

> > On Wed, 2002-10-02 at 13:47, Tom wrote:
> > the "tab after powerup" to switch console settings, but nothing. According
> > to my C180 manual, having the monitor and keyboard on there should set the
> > monitor as console, while removing them should send console to ttyS0.
>
> On 3 Oct 2002, Chuck Slivkoff wrote:
> If the console path in the PDC is explicitly set to one of the serial
> ports, it will not automagically change back to graphics by connecting a
> keyboard. The opposite is true, though: no/bad PS/2 keyboard, no/bad
> graphics, or invalid PDC value (ie, graphics card moved/removed) & the
> console will be directed to the first serial port.
>
> Do the PS/2 keyboard LED's flash and Num_Lock LED light during POST?

Yes, they did...

> Here's another suggestion: try removing all I/O cards, detaching all
> disks, disconnecting the network, and removing all but 1 pair of SIMMs.

Did this, didn't seem to make any difference.

Tracked down a new, known-good db9-db9 null-modem cable, scarfed the g/f
laptop (WinME), connected former to latter with cable and used
HyperTerminal. (Everything still disconnected/removed as suggested above.)
Console came up, with typical dire warnings about hardware changes.
Checked - fast boot disabled already, console path set to
serial_1.9600.n.1, so is correct. Displaying hardware showed VizEG video,
etc. Power off, plug in drives, power on, back to console. SEArch hung
while looking for drives... Discover the "scsi card" end of the FW cable
was bad - moved the next connector in line onto the card, SEA comes up
fine with FWSCSI.5 and SESCSI.5 (correct devices). Plug everything else
back in, all is redetected fine, and system is now merrily trying to
compile 2.4.19-pa24...

So, apparently the cable end being loose/bad was seriously screwing with
it's poor little RISC-brain.

> When you get the console back, you might want to enable "chassis codes"
> (to trace the POST codes) and disable "fast boot" (to get a better test
> of RAM). I believe The service manual has a table which should be able
> to give some indication of when the firmware chooses a console device.
>
> http://h20000.www2.hp.com/bizsupport/TechSupport/DocumentIndex.jsp?contentType=SupportManual&docIndexName=hardware+manuals&locale=en_US&prodTypeId=43563&prodSeriesId=44435&prodSeriesName=hp+Visualize+c180+workstation
>
> BTW, one of the nice things about the Allegro/Forte/Duet (4-digit
> B/C/Jxxxx, less J2240) systems is the LCD display which indicates where
> the console has be directed.

I think if I can find one of these cheap I'll grab it :-)  (The C180 was
$35 plus $50 shipping - too good to pass up! Gotta love eBay...)

BTW, I tried using apt to dist-upgrade from stable, but nothing's changed
in quite a while - at least a month. Are updates being pushed into
testing, or is it better to leave sources.list pointing to stable?