• debian-hppa on a C8000

    From Helge Deller@21:1/5 to Lothar Paltins on Tue Mar 12 15:10:01 2019
    Hi Lothar,

    On 12.03.19 14:31, Lothar Paltins wrote:
    the "native" OS of the old HP workstations is HP-UX, but just out of curiosity I've tried to install Linux on one of my C8000. Installing
    using a CD with debian-8.0-hppa-CD-1.iso as described in the Linux
    PARISC Wiki succeeded without problems, but I couldn't install any
    updates. During the installation, the installer asks for the radeon
    firmware R300_cp.bin, but I continued the installation without it.

    Correct, PA-Linux currently doesn't support the Radeon cards in the C8000.

    Installing /lib/firmware/radeon/R300_cp.bin afterwards breaks the
    system, it crashes during booting.

    It shouldn't crash with a recent kernel. Can you post the crash dump?

    This is also the case after an "apt-get update;apt-get upgrade".
    Latest debian-unstable packages do work on the c8000.
    Some of the debian buildd servers are c8000 machines running latest
    debian unstable packages.
    So, can you maybe also give some more info what happens when you
    upgrade?
    For example I can imaginge that you manually need to upgrade the
    palo boot code on the hard disc boot sector before reboot.

    I've then tried to install debian-9.0-Stretch-hppa-NETINST-1.iso and debian-10.0-hppa-NETINST-1.iso, but here the installer crashes
    already shortly after entering the locale information.
    Yes, that's known and is being worked on. That's not c8000 specific.

    Did anybody succeed in installing a more recent version than debian-8.0?

    I do (with upgrades from debian-8).

    Helge

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lothar Paltins@21:1/5 to All on Tue Mar 12 14:40:01 2019
    Hi,

    the "native" OS of the old HP workstations is HP-UX, but just out of
    curiosity I've tried to install Linux on one of my C8000. Installing
    using a CD with debian-8.0-hppa-CD-1.iso as described in the Linux
    PARISC Wiki succeeded without problems, but I couldn't install any
    updates. During the installation, the installer asks for the radeon
    firmware R300_cp.bin, but I continued the installation without it.
    Installing /lib/firmware/radeon/R300_cp.bin afterwards breaks the
    system, it crashes during booting. This is also the case after an
    "apt-get update;apt-get upgrade". I've then tried to install debian-9.0-Stretch-hppa-NETINST-1.iso and
    debian-10.0-hppa-NETINST-1.iso, but here the installer crashes already
    shortly after entering the locale information.

    Did anybody succeed in installing a more recent version than debian-8.0?
    --
    Lothar

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John David Anglin@21:1/5 to Lothar Paltins on Tue Mar 12 15:10:01 2019
    On 2019-03-12 9:31 a.m., Lothar Paltins wrote:
    Installing using a CD with debian-8.0-hppa-CD-1.iso as described in the Linux PARISC Wiki succeeded without problems, but I couldn't install
    any updates.

    Updates are only available for unstable (sid) as hppa isn't a Debian release architecture.  You need to edit /etc/apt/sources.list to access
    packages
    from unstable.

    Dave

    --
    John David Anglin dave.anglin@bell.net

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From LX@21:1/5 to All on Wed Mar 13 12:00:02 2019
    This is a multi-part message in MIME format.

    PkZvciBleGFtcGxlIEkgY2FuIGltYWdpbmdlIHRoYXQgeW91IG1hbnVhbGx5IG5lZWQgdG8gdXBn cmFkZSB0aGUKcGFsbyBib290IGNvZGUgb24gdGhlIGhhcmQgZGlzYyBib290IHNlY3RvciBiZWZv cmUgcmVib290CgppcyB0aGVyZSBhIG1hbnVhbCBvciBwcm9jZWR1cmUgaG93IHRvIGRvPyBJIGNh biBpbnN0YWxsIGRlYmlhbiBidXQgYWZ0ZXIgdXBncmFkZSBpdCBkb2Vzbid0IGJvb3QgYW55bW9y ZS4uLgoKLS0tLS0tLS0gT3JpZ2luYWwtTmFjaHJpY2h0IC0tLS0tLS0tCkFuIDEyLiBNw6RyeiAy MDE5LCAxNTowMSwgSGVsZ2UgRGVsbGVyIHNjaHJpZWI6Cgo+IEhpIExvdGhhciwKPgo+IE9uIFsx Mi4wMy4xOSAxNF0odGVsOjEyMDMxOTE0KTozMSwgTG90aGFyIFBhbHRpbnMgd3JvdGU6Cj4+IHRo ZSAibmF0aXZlIiBPUyBvZiB0aGUgb2xkIEhQIHdvcmtzdGF0aW9ucyBpcyBIUC1VWCwgYnV0IGp1 c3Qgb3V0IG9mCj4+IGN1cmlvc2l0eSBJJ3ZlIHRyaWVkIHRvIGluc3RhbGwgTGludXggb24gb25l IG9mIG15IENbODAwMF0odGVsOjgwMDApLiBJbnN0YWxsaW5nCj4+IHVzaW5nIGEgQ0Qgd2l0aCBk ZWJpYW4tOC4wLWhwcGEtQ0QtMS5pc28gYXMgZGVzY3JpYmVkIGluIHRoZSBMaW51eAo+PiBQQVJJ U0MgV2lraSBzdWNjZWVkZWQgd2l0aG91dCBwcm9ibGVtcywgYnV0IEkgY291bGRuJ3QgaW5zdGFs bCBhbnkKPj4gdXBkYXRlcy4gRHVyaW5nIHRoZSBpbnN0YWxsYXRpb24sIHRoZSBpbnN0YWxsZXIg YXNrcyBmb3IgdGhlIHJhZGVvbgo+PiBmaXJtd2FyZSBSWzMwMF0odGVsOjMwMClfY3AuYmluLCBi dXQgSSBjb250aW51ZWQgdGhlIGluc3RhbGxhdGlvbiB3aXRob3V0IGl0Lgo+Cj4gQ29ycmVjdCwg UEEtTGludXggY3VycmVudGx5IGRvZXNuJ3Qgc3VwcG9ydCB0aGUgUmFkZW9uIGNhcmRzIGluIHRo ZSBDWzgwMDBdKHRlbDo4MDAwKS4KPgo+PiBJbnN0YWxsaW5nIC9saWIvZmlybXdhcmUvcmFkZW9u L1JbMzAwXSh0ZWw6MzAwKV9jcC5iaW4gYWZ0ZXJ3YXJkcyBicmVha3MgdGhlCj4+IHN5c3RlbSwg aXQgY3Jhc2hlcyBkdXJpbmcgYm9vdGluZy4KPgo+IEl0IHNob3VsZG4ndCBjcmFzaCB3aXRoIGEg cmVjZW50IGtlcm5lbC4gQ2FuIHlvdSBwb3N0IHRoZSBjcmFzaCBkdW1wPwo+Cj4+IFRoaXMgaXMg YWxzbyB0aGUgY2FzZSBhZnRlciBhbiAiYXB0LWdldCB1cGRhdGU7YXB0LWdldCB1cGdyYWRlIi4K PiBMYXRlc3QgZGViaWFuLXVuc3RhYmxlIHBhY2thZ2VzIGRvIHdvcmsgb24gdGhlIGNbODAwMF0o dGVsOjgwMDApLgo+IFNvbWUgb2YgdGhlIGRlYmlhbiBidWlsZGQgc2VydmVycyBhcmUgY1s4MDAw XSh0ZWw6ODAwMCkgbWFjaGluZXMgcnVubmluZyBsYXRlc3QKPiBkZWJpYW4gdW5zdGFibGUgcGFj a2FnZXMuCj4gU28sIGNhbiB5b3UgbWF5YmUgYWxzbyBnaXZlIHNvbWUgbW9yZSBpbmZvIHdoYXQg aGFwcGVucyB3aGVuIHlvdQo+IHVwZ3JhZGU/Cj4gRm9yIGV4YW1wbGUgSSBjYW4gaW1hZ2luZ2Ug dGhhdCB5b3UgbWFudWFsbHkgbmVlZCB0byB1cGdyYWRlIHRoZQo+IHBhbG8gYm9vdCBjb2RlIG9u IHRoZSBoYXJkIGRpc2MgYm9vdCBzZWN0b3IgYmVmb3JlIHJlYm9vdC4KPgo+PiBJJ3ZlIHRoZW4g dHJpZWQgdG8gaW5zdGFsbCBkZWJpYW4tOS4wLVN0cmV0Y2gtaHBwYS1ORVRJTlNULTEuaXNvIGFu ZAo+PiBkZWJpYW4tWzEwLjBdKHRlbDoxMDApLWhwcGEtTkVUSU5TVC0xLmlzbywgYnV0IGhlcmUg dGhlIGluc3RhbGxlciBjcmFzaGVzCj4+IGFscmVhZHkgc2hvcnRseSBhZnRlciBlbnRlcmluZyB0 aGUgbG9jYWxlIGluZm9ybWF0aW9uLgo+IFllcywgdGhhdCdzIGtub3duIGFuZCBpcyBiZWluZyB3 b3JrZWQgb24uIFRoYXQncyBub3QgY1s4MDAwXSh0ZWw6ODAwMCkgc3BlY2lmaWMuCj4KPj4gRGlk IGFueWJvZHkgc3VjY2VlZCBpbiBpbnN0YWxsaW5nIGEgbW9yZSByZWNlbnQgdmVyc2lvbiB0aGFu IGRlYmlhbi04LjA/Cj4KPiBJIGRvICh3aXRoIHVwZ3JhZGVzIGZyb20gZGViaWFuLTgpLgo+Cj4g SGVsZ2U=


    PkZvciBleGFtcGxlIEkgY2FuIGltYWdpbmdlIHRoYXQgeW91IG1hbnVhbGx5IG5lZWQgdG8gdXBn cmFkZSB0aGU8YnI+cGFsbyBib290IGNvZGUgb24gdGhlIGhhcmQgZGlzYyBib290IHNlY3RvciBi ZWZvcmUgcmVib290PGJyPjxicj5pcyB0aGVyZSBhIG1hbnVhbCBvciBwcm9jZWR1cmUgaG93IHRv IGRvPyBJIGNhbiBpbnN0YWxsIGRlYmlhbiBidXQgYWZ0ZXIgdXBncmFkZSBpdCBkb2Vzbid0IGJv b3QgYW55bW9yZS4uLiA8YnI+PGJyPjxicj48YnI+PGJyPjxicj48YnI+LS0tLS0tLS0gT3JpZ2lu YWwtTmFjaHJpY2h0IC0tLS0tLS0tPGJyPkFuIDEyLiBNw6RyeiAyMDE5LCAxNTowMSwgSGVsZ2Ug RGVsbGVyIHNjaHJpZWI6PGJsb2NrcXVvdGUgY2xhc3M9InByb3Rvbm1haWxfcXVvdGUiPjxicj48 cCBkaXI9Imx0ciI+SGkgTG90aGFyLDwvcD4NCjxwIGRpcj0ibHRyIj5PbiA8YSBocmVmPSJ0ZWw6 MTIwMzE5MTQiPjEyLjAzLjE5IDE0PC9hPjozMSwgTG90aGFyIFBhbHRpbnMgd3JvdGU6PGJyPg0K Jmd0OyB0aGUgIm5hdGl2ZSIgT1Mgb2YgdGhlIG9sZCBIUCB3b3Jrc3RhdGlvbnMgaXMgSFAtVVgs IGJ1dCBqdXN0IG91dCBvZjxicj4NCiZndDsgY3VyaW9zaXR5IEkndmUgdHJpZWQgdG8gaW5zdGFs bCBMaW51eCBvbiBvbmUgb2YgbXkgQzxhIGhyZWY9InRlbDo4MDAwIj44MDAwPC9hPi4gSW5zdGFs bGluZzxicj4NCiZndDsgdXNpbmcgYSBDRCB3aXRoIGRlYmlhbi04LjAtaHBwYS1DRC0xLmlzbyBh cyBkZXNjcmliZWQgaW4gdGhlIExpbnV4PGJyPg0KJmd0OyBQQVJJU0MgV2lraSBzdWNjZWVkZWQg d2l0aG91dCBwcm9ibGVtcywgYnV0IEkgY291bGRuJ3QgaW5zdGFsbCBhbnk8YnI+DQomZ3Q7IHVw ZGF0ZXMuIER1cmluZyB0aGUgaW5zdGFsbGF0aW9uLCB0aGUgaW5zdGFsbGVyIGFza3MgZm9yIHRo ZSByYWRlb248YnI+DQomZ3Q7IGZpcm13YXJlIFI8YSBocmVmPSJ0ZWw6MzAwIj4zMDA8L2E+X2Nw LmJpbiwgYnV0IEkgY29udGludWVkIHRoZSBpbnN0YWxsYXRpb24gd2l0aG91dCBpdC48L3A+DQo8 cCBkaXI9Imx0ciI+Q29ycmVjdCwgUEEtTGludXggY3VycmVudGx5IGRvZXNuJ3Qgc3VwcG9ydCB0 aGUgUmFkZW9uIGNhcmRzIGluIHRoZSBDPGEgaHJlZj0idGVsOjgwMDAiPjgwMDA8L2E+LjwvcD4N CjxwIGRpcj0ibHRyIj4mZ3Q7IEluc3RhbGxpbmcgL2xpYi9maXJtd2FyZS9yYWRlb24vUjxhIGhy ZWY9InRlbDozMDAiPjMwMDwvYT5fY3AuYmluIGFmdGVyd2FyZHMgYnJlYWtzIHRoZTxicj4NCiZn dDsgc3lzdGVtLCBpdCBjcmFzaGVzIGR1cmluZyBib290aW5nLjwvcD4NCjxwIGRpcj0ibHRyIj5J dCBzaG91bGRuJ3QgY3Jhc2ggd2l0aCBhIHJlY2VudCBrZXJuZWwuIENhbiB5b3UgcG9zdCB0aGUg Y3Jhc2ggZHVtcD88L3A+DQo8cCBkaXI9Imx0ciI+Jmd0OyBUaGlzIGlzIGFsc28gdGhlIGNhc2Ug YWZ0ZXIgYW4gImFwdC1nZXQgdXBkYXRlO2FwdC1nZXQgdXBncmFkZSIuPGJyPg0KTGF0ZXN0IGRl Ymlhbi11bnN0YWJsZSBwYWNrYWdlcyBkbyB3b3JrIG9uIHRoZSBjPGEgaHJlZj0idGVsOjgwMDAi PjgwMDA8L2E+Ljxicj4NClNvbWUgb2YgdGhlIGRlYmlhbiBidWlsZGQgc2VydmVycyBhcmUgYzxh IGhyZWY9InRlbDo4MDAwIj44MDAwPC9hPiBtYWNoaW5lcyBydW5uaW5nIGxhdGVzdDxicj4NCmRl YmlhbiB1bnN0YWJsZSBwYWNrYWdlcy48YnI+DQpTbywgY2FuIHlvdSBtYXliZSBhbHNvIGdpdmUg c29tZSBtb3JlIGluZm8gd2hhdCBoYXBwZW5zIHdoZW4geW91PGJyPg0KdXBncmFkZT88YnI+DQpG b3IgZXhhbXBsZSBJIGNhbiBpbWFnaW5nZSB0aGF0IHlvdSBtYW51YWxseSBuZWVkIHRvIHVwZ3Jh ZGUgdGhlPGJyPg0KcGFsbyBib290IGNvZGUgb24gdGhlIGhhcmQgZGlzYyBib290IHNlY3RvciBi ZWZvcmUgcmVib290LjwvcD4NCjxwIGRpcj0ibHRyIj4mZ3Q7IEkndmUgdGhlbiB0cmllZCB0byBp bnN0YWxsIGRlYmlhbi05LjAtU3RyZXRjaC1ocHBhLU5FVElOU1QtMS5pc28gYW5kPGJyPg0KJmd0 OyBkZWJpYW4tPGEgaHJlZj0idGVsOjEwMCI+MTAuMDwvYT4taHBwYS1ORVRJTlNULTEuaXNvLCBi dXQgaGVyZSB0aGUgaW5zdGFsbGVyIGNyYXNoZXM8YnI+DQomZ3Q7IGFscmVhZHkgc2hvcnRseSBh ZnRlciBlbnRlcmluZyB0aGUgbG9jYWxlIGluZm9ybWF0aW9uLjxicj4NClllcywgdGhhdCdzIGtu b3duIGFuZCBpcyBiZWluZyB3b3JrZWQgb24uIFRoYXQncyBub3QgYzxhIGhyZWY9InRlbDo4MDAw Ij44MDAwPC9hPiBzcGVjaWZpYy48L3A+DQo8cCBkaXI9Imx0ciI+Jmd0OyBEaWQgYW55Ym9keSBz dWNjZWVkIGluIGluc3RhbGxpbmcgYSBtb3JlIHJlY2VudCB2ZXJzaW9uIHRoYW4gZGViaWFuLTgu MD88L3A+DQo8cCBkaXI9Imx0ciI+SSBkbyAod2l0aCB1cGdyYWRlcyBmcm9tIGRlYmlhbi04KS48 L3A+DQo8cCBkaXI9Imx0ciI+SGVsZ2U8L3A+DQo8L2Rpdj4=

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Helge Deller@21:1/5 to All on Wed Mar 13 12:20:01 2019
    On 13.03.19 11:54, LX wrote:
    For example I can imaginge that you manually need to upgrade the
    palo boot code on the hard disc boot sector before reboot

    is there a manual or procedure how to do?

    Run "apt-get update" and "apt-get install palo linux-image-parisc64-smp".
    Make sure you get latest Linux kernels (e.g. > 4.19.x).
    Then run "palo -v" once, that updates the boot sector with latest palo boot code.

    I can install debian but after upgrade it doesn't boot anymore...

    Which kernel?
    What is the boot log?
    Where does it hang?


    Helge




    -------- Original-Nachricht --------
    An 12. März 2019, 15:01, Helge Deller schrieb:


    Hi Lothar,

    On 12.03.19 14 <tel:12031914>:31, Lothar Paltins wrote:
    > the "native" OS of the old HP workstations is HP-UX, but just out of
    > curiosity I've tried to install Linux on one of my C8000 <tel:8000>. Installing
    > using a CD with debian-8.0-hppa-CD-1.iso as described in the Linux
    > PARISC Wiki succeeded without problems, but I couldn't install any
    > updates. During the installation, the installer asks for the radeon
    > firmware R300 <tel:300>_cp.bin, but I continued the installation without it.

    Correct, PA-Linux currently doesn't support the Radeon cards in the C8000 <tel:8000>.

    > Installing /lib/firmware/radeon/R300 <tel:300>_cp.bin afterwards breaks the
    > system, it crashes during booting.

    It shouldn't crash with a recent kernel. Can you post the crash dump?

    > This is also the case after an "apt-get update;apt-get upgrade".
    Latest debian-unstable packages do work on the c8000 <tel:8000>.
    Some of the debian buildd servers are c8000 <tel:8000> machines running latest
    debian unstable packages.
    So, can you maybe also give some more info what happens when you
    upgrade?
    For example I can imaginge that you manually need to upgrade the
    palo boot code on the hard disc boot sector before reboot.

    > I've then tried to install debian-9.0-Stretch-hppa-NETINST-1.iso and
    > debian-10.0 <tel:100>-hppa-NETINST-1.iso, but here the installer crashes
    > already shortly after entering the locale information.
    Yes, that's known and is being worked on. That's not c8000 <tel:8000> specific.

    > Did anybody succeed in installing a more recent version than debian-8.0?

    I do (with upgrades from debian-8).

    Helge


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lothar Paltins@21:1/5 to All on Wed Mar 13 23:30:01 2019
    Hi John,

    Updates are only available for unstable (sid) as hppa isn't a Debian release architecture.  You need to edit /etc/apt/sources.list to access
    packages
    from unstable.

    thanks, but that's already mentioned in the "Installation of PA-RISC
    Linux" page of the Linux PARISC Wiki. Maybe I forgot to do it, but IIRC
    I added "deb http://ftp.ports.debian.org/debian-ports unstable main" to /etc/apt/sources.list and executed "apt-get install debian-ports-archive-keyring" before the "apt-get update;apt-get upgrade".

    But as I've said in my reply to Helge, I've repeated the upgrade
    procedure and now it works. I must have done something wrong the first
    time, but I can't remember what.

    Lothar
    --
    Lothar Paltins lptmp10@arcor.de

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lothar Paltins@21:1/5 to All on Wed Mar 13 23:20:02 2019
    Hi Helge,

    thanks for the answer. Something must have gone wrong here. I've
    repeated the upgrade and now it works! I did save the disk partition
    images directly after the installation and before the upgrade. I cloned
    them to a different disk and repeated the update/upgrade. This time it
    was successful and it still works after a reboot. I will now try to
    reinstall R300_cp.bin and see what happens.

    BTW, I've seen, that the UUID of the root partition is hard coded in the
    kernel command line in the first MB of the disk. To avoid problems with duplicate UUIDs, I've changed the partition UUIDs of the cloned disk and therefore the boot loader didn't find the root partition. I've changed
    it directly on the disk, but what is the "official" way to change the parameters of the boot loader?

    Lothar

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Helge Deller@21:1/5 to Lothar Paltins on Wed Mar 13 23:40:01 2019
    Hi Lothar,

    On 13.03.19 23:10, Lothar Paltins wrote:
    thanks for the answer. Something must have gone wrong here. I've
    repeated the upgrade and now it works!
    Very good!

    I did save the disk partition images directly after the installation
    and before the upgrade. I cloned them to a different disk and
    repeated the update/upgrade. This time it was successful and it still
    works after a reboot. I will now try to reinstall R300_cp.bin and see
    what happens.

    Unless you want to debug why the ring test fails on parisc when loading
    the ATI card driver, I'd suggest to skip that.

    BTW, I've seen, that the UUID of the root partition is hard coded in
    the kernel command line in the first MB of the disk. To avoid
    problems with duplicate UUIDs, I've changed the partition UUIDs of
    the cloned disk and therefore the boot loader didn't find the root
    partition. I've changed it directly on the disk, but what is the
    "official" way to change the parameters of the boot loader?

    I think editing /etc/palo.conf and rerun "palo -v".

    Helge

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John David Anglin@21:1/5 to Helge Deller on Thu Mar 14 00:20:01 2019
    On 2019-03-13 6:32 p.m., Helge Deller wrote:
    I did save the disk partition images directly after the installation
    and before the upgrade. I cloned them to a different disk and
    repeated the update/upgrade. This time it was successful and it still
    works after a reboot. I will now try to reinstall R300_cp.bin and see
    what happens.
    Unless you want to debug why the ring test fails on parisc when loading
    the ATI card driver, I'd suggest to skip that.

    Helge is right.  Unless you are a ATI graphics card expert, you won't be able to fix the ring
    test failure.

    Dave

    --
    John David Anglin dave.anglin@bell.net

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lothar Paltins@21:1/5 to All on Fri Mar 15 10:20:01 2019
    Hi,

    I've tried to send a reply to the list with an attachment, but it seems,
    that it was silently ignored. I'm now sending it without the attachment.

    Am 14.03.19 um 00:17 schrieb John David Anglin:
    Helge is right. Unless you are a ATI graphics card expert, you
    won't be able to fix the ring test failure.

    I don't want to fix it, although my profession as a software engineer
    was the development and debugging of hardware control software. But I'm
    not an ATI graphics card expert and I think the graphics acceleration
    isn't very important. I don't want to do real work on this more than 13
    years old machine. It's slow compared to current machines and it
    consumes almost 300W of electrical power without any load. All of my HP workstations are just museum pieces and to be authentic, all of them are running HP-UX, except for this one C8000.

    But anyway, it's interesting to see that an almost current Linux runs on
    it. But it seems to be a little bit fragile. I booted it today and all
    messages on the serial console seemed to be correct, but the connected
    monitor didn't show the KDE login screen, neither via the DVI nor the
    VGA connector. I tried to log in blindly and this worked, but the
    desktop was displayed only on the VGA connector. I logged out from the
    session and logged in again, but then the system freezes up after the
    desktop background was drawn. I had to switch it off and after powering
    it up again it crashed during the next booting. But eventually, after
    booting the machine a third time, everything works again as before.
    There are only a lot of "unaligned access" messages on the console
    coming from KDE applications, but I guess, that's a known issue.

    I've taken a photo of the console with the backtrace after the crash,
    but it doesn't seem to be possible to send a mail with an attachment. If anybody is interested, I could send it directly.

    Lothar
    --
    Lothar Paltins lptmp10@arcor.de

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Helge Deller@21:1/5 to Lothar Paltins on Fri Mar 15 13:40:02 2019
    On 15.03.19 10:17, Lothar Paltins wrote:
    I've tried to send a reply to the list with an attachment, but it seems,
    that it was silently ignored. I'm now sending it without the attachment.

    Am 14.03.19 um 00:17 schrieb John David Anglin:
    Helge is right.  Unless you are a ATI graphics card expert, you
    won't be able to fix the ring test failure.

    I don't want to fix it, although my profession as a software engineer
    was the development and debugging of hardware control software. But I'm
    not an ATI graphics card expert and I think the graphics acceleration
    isn't very important. I don't want to do real work on this more than 13
    years old machine. It's slow compared to current machines and it
    consumes almost 300W of electrical power without any load. All of my HP workstations are just museum pieces and to be authentic, all of them are running HP-UX, except for this one C8000.

    But anyway, it's interesting to see that an almost current Linux runs on
    it.

    The very newest Linux (git head, Debian unstable, ...) runs on it,
    most times better than older ones.

    But it seems to be a little bit fragile. I booted it today and all
    messages on the serial console seemed to be correct, but the connected monitor didn't show the KDE login screen, neither via the DVI nor the
    VGA connector. I tried to log in blindly and this worked, but the
    desktop was displayed only on the VGA connector. I logged out from the session and logged in again, but then the system freezes up after the
    desktop background was drawn.

    I'm astonished that you got some graphical output at all.
    But in fact, nobody really tests C8000 with graphics card.
    All c8000 machines I own run "server-like" in the datacenter.

    I had to switch it off and after powering it up again it crashed
    during the next booting. But eventually, after booting the machine a
    third time, everything works again as before.
    Of course that's not how it should be. I assume this is based on the fact
    that you used graphics before.

    There are only a lot of "unaligned access" messages on the console
    coming from KDE applications, but I guess, that's a known issue.

    Yes, they are non-critical and just show that applications don't
    respect the natural alignments of data.

    I've taken a photo of the console with the backtrace after the crash,
    but it doesn't seem to be possible to send a mail with an attachment. If anybody is interested, I could send it directly.

    You can send me everything in private mail.

    Thanks!
    Helge

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Frank Scheiner@21:1/5 to Lothar Paltins on Fri Mar 15 15:10:02 2019
    Dear Lothar,

    On 3/15/19 10:17, Lothar Paltins wrote:
    Am 14.03.19 um 00:17 schrieb John David Anglin:
    Helge is right.  Unless you are a ATI graphics card expert, you
    won't be able to fix the ring test failure.
    [...]
    I don't want to do real work on this more than 13
    years old machine. It's slow compared to current machines and it
    consumes almost 300W of electrical power without any load.

    But did you notice how silent the c8000 is at the same time (even with
    two dual-core PA-8800/8900 installed)? :-) And for the hppa port of
    Debian GNU/Linux I think it's a very good combination of size and
    hardware resources. In addition it has built-in remote control
    capabilities (see [1]).

    [1]: https://parisc.wiki.kernel.org/index.php/BMC

    All of my HP
    workstations are just museum pieces and to be authentic, all of them are running HP-UX, except for this one C8000.

    Nice! Would you be interested in testing these with Debian to see what
    works and what does not?

    All of the PA-RISC machines I own, support network booting, so maybe
    yours will, too. Testing wouldn't then require an actual on disk
    installation, so not touching any existing HP/UX installations or
    creating the need for a disk. You only need to setup the needed
    infrastructure services (DNS, DHCP, TFTP, NFS, etc.).

    But anyway, it's interesting to see that an almost current Linux runs on
    it. But it seems to be a little bit fragile. I booted it today and all messages on the serial console seemed to be correct, but the connected monitor didn't show the KDE login screen, neither via the DVI nor the
    VGA connector.

    It could be needed to explicitly activate the graphics card in the BCH.
    At least I assume, if you could use the serial console, it either
    doesn't switch to graphics console automatically when a keyboard is
    attached (as this is done for machines from other vendors, e.g. SGI,
    Sun) or the console device is configured to the serial port explicitly.

    I tried to log in blindly and this worked, but the
    desktop was displayed only on the VGA connector. I logged out from the session and logged in again, but then the system freezes up after the
    desktop background was drawn. I had to switch it off and after powering
    it up again it crashed during the next booting.

    Did that crash already happen during POST? And does your used graphics
    card have an additional power connector?

    I noticed instabilities on one of my c8000s with the originally equipped
    ATI FireGL X1, which draws all power from the AGP port alone. Changing
    it to a graphics card powered by both AGP port and additional power
    connector or just removing it, "solved" the instability issues during
    POST and boot for me. I wonder if these instabilities are perhaps
    related to the aging of the PSU internals. In the end the exhaust air is
    always pretty hot with this machine.

    Cheers,
    Frank

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John David Anglin@21:1/5 to Helge Deller on Fri Mar 15 15:20:01 2019
    On 2019-03-15 8:36 a.m., Helge Deller wrote:
    On 15.03.19 10:17, Lothar Paltins wrote:
    I've tried to send a reply to the list with an attachment, but it seems,
    that it was silently ignored. I'm now sending it without the attachment.

    Am 14.03.19 um 00:17 schrieb John David Anglin:
    Helge is right.  Unless you are a ATI graphics card expert, you
    won't be able to fix the ring test failure.
    I don't want to fix it, although my profession as a software engineer
    was the development and debugging of hardware control software. But I'm
    not an ATI graphics card expert and I think the graphics acceleration
    isn't very important. I don't want to do real work on this more than 13
    years old machine. It's slow compared to current machines and it
    consumes almost 300W of electrical power without any load. All of my HP
    workstations are just museum pieces and to be authentic, all of them are
    running HP-UX, except for this one C8000.

    But anyway, it's interesting to see that an almost current Linux runs on
    it.
    Linux  5.0.1-1~exp1 is available in experimental.
    The very newest Linux (git head, Debian unstable, ...) runs on it,
    most times better than older ones.
    You are correct about the hardware.  However, I might suggest that there are other reasons
    to play with old hardware. You can learn a lot about the internals of linux and open source
    software development in general with old hardware.  Development on the major release
    architectures is dominated by commercial interests.  You have to have a narrow focus to
    make a contribution to these architectures.

    But it seems to be a little bit fragile. I booted it today and all
    messages on the serial console seemed to be correct, but the connected
    monitor didn't show the KDE login screen, neither via the DVI nor the
    VGA connector. I tried to log in blindly and this worked, but the
    desktop was displayed only on the VGA connector. I logged out from the
    session and logged in again, but then the system freezes up after the
    desktop background was drawn.
    I'm astonished that you got some graphical output at all.
    But in fact, nobody really tests C8000 with graphics card.
    All c8000 machines I own run "server-like" in the datacenter.
    Same here.

    I had to switch it off and after powering it up again it crashed
    during the next booting. But eventually, after booting the machine a
    third time, everything works again as before.
    Of course that's not how it should be. I assume this is based on the fact that you used graphics before.

    There are only a lot of "unaligned access" messages on the console
    coming from KDE applications, but I guess, that's a known issue.
    Yes, they are non-critical and just show that applications don't
    respect the natural alignments of data.
    The PA-RISC architecture requires accesses to be strictly aligned and unaligned accesses
    are fixed in the kernel.  On x86, etc, unaligned accesses work but there is a performance
    hit relative to accesses that respect the natural alignment of data.  So, these messages
    reflect application bugs that should be fixed...

    I've taken a photo of the console with the backtrace after the crash,
    but it doesn't seem to be possible to send a mail with an attachment. If
    anybody is interested, I could send it directly.
    You can send me everything in private mail.
    Kernel related mail should generally be sent to <linux-parisc@vger.kernel.org>.

    Dave

    --
    John David Anglin dave.anglin@bell.net

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Helge Deller@21:1/5 to Lothar Paltins on Sat Mar 16 22:50:02 2019
    On 16.03.19 22:42, Lothar Paltins wrote:
    Nice! Would you be interested in testing these with Debian to see what
    works and what does not?

    Why not? My 68k workstations are out of topic here, but I've got the following running parisc machines: 710, several 715, one with HCRX-24 graphics, 725, C360, C3600, J5600, C8000. Is there a machine, where I
    could help testing?

    A boot log of the 710, 725 and C360 would be interesting.
    All others should at least work without problems.

    Helge

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lothar Paltins@21:1/5 to All on Sat Mar 16 23:00:01 2019
    Am 16.03.19 um 22:49 schrieb Helge Deller:
    A boot log of the 710, 725 and C360 would be interesting.

    Would it be possible to install it on a 710 at all? It has the maximum
    possible RAM, but that's only 64MB.

    --
    Lothar Paltins lptmp10@arcor.de

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lothar Paltins@21:1/5 to All on Sat Mar 16 22:50:02 2019
    Hi Frank,

    But did you notice how silent the c8000 is at the same time (even with
    two dual-core PA-8800/8900 installed)? :-)

    no wonder, with this heavy metal case! ;-)

    And for the hppa port of
    Debian GNU/Linux I think it's a very good combination of size and
    hardware resources. In addition it has built-in remote control
    capabilities (see [1]).

    Interesting for a remote server with modem access to the serial port.
    I've tried it out on my machine, but after entering ESC-(, the serial
    line simply freezes up. Maybe a BMC-password is set that should be cleared.

    All of my HP
    workstations are just museum pieces and to be authentic, all of them are
    running HP-UX, except for this one C8000.

    Nice! Would you be interested in testing these with Debian to see what
    works and what does not?

    Why not? My 68k workstations are out of topic here, but I've got the
    following running parisc machines: 710, several 715, one with HCRX-24
    graphics, 725, C360, C3600, J5600, C8000. Is there a machine, where I
    could help testing?

    All of the PA-RISC machines I own, support network booting, so maybe
    yours will, too. Testing wouldn't then require an actual on disk installation, so not touching any existing HP/UX installations or
    creating the need for a disk. You only need to setup the needed infrastructure services (DNS, DHCP, TFTP, NFS, etc.).

    No problem, if you tell me exactly what to do. But be aware, that I do
    have a lot of Linux experience, but only with RHEL and openSuse, not
    with Debian.

    And regarding the crashes and instabilities I see, I'm now sure, that
    they are coming from the "apt-get upgrade". The original 8 (jessie) installation works absolutely stable. But after the upgrade, the system
    either doesn't boot or it crashes sometime later. This doesn't happen
    without the upgrade.

    Lothar
    --
    Lothar Paltins lptmp10@arcor.de

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Frank Scheiner@21:1/5 to Lothar Paltins on Mon Mar 18 00:00:02 2019
    Hi Lothar,

    On 3/16/19 22:42, Lothar Paltins wrote:
    And for the hppa port of
    Debian GNU/Linux I think it's a very good combination of size and
    hardware resources. In addition it has built-in remote control
    capabilities (see [1]).

    Interesting for a remote server with modem access to the serial port.
    I've tried it out on my machine, but after entering ESC-(, the serial
    line simply freezes up. Maybe a BMC-password is set that should be cleared.

    Can't remember seeing something like this on my c8000s, but I can check tomorrow.


    All of my HP
    workstations are just museum pieces and to be authentic, all of them are >>> running HP-UX, except for this one C8000.

    Nice! Would you be interested in testing these with Debian to see what
    works and what does not?

    Why not? My 68k workstations are out of topic here

    There is still an active port for m68k, though I don't have any
    experience with that and don't know if your hardware would be supported.
    ISO images are on [1], the mailing list archive is on [2].

    [1]: https://cdimage.debian.org/cdimage/ports/current/m68k/

    [2]: https://lists.debian.org/debian-68k/

    , but I've got the
    following running parisc machines: 710, several 715, one with HCRX-24 graphics, 725, C360, C3600, J5600, C8000. Is there a machine, where I
    could help testing?

    I myself have a J5600, a c3700 and a c3750 and c8000s available, from
    which I know they're working with Debian GNU/Linux. From Helge's answer
    I assume 715 and C3600 (most likely identical to a c3700 or c3750 except
    for the processor and maybe chipset revision) are supposed to work in
    addition. I don't know how much hardware is identical between C200 and
    C360, but my C200 also works, so chances are good for the C360, I think.


    All of the PA-RISC machines I own, support network booting, so maybe
    yours will, too. Testing wouldn't then require an actual on disk
    installation, so not touching any existing HP/UX installations or
    creating the need for a disk. You only need to setup the needed
    infrastructure services (DNS, DHCP, TFTP, NFS, etc.).

    No problem, if you tell me exactly what to do. But be aware, that I do
    have a lot of Linux experience, but only with RHEL and openSuse, not
    with Debian.

    Great! Actually this is pretty easy to set up as soon as you have found
    out all needed details. :-) You only need a lifimage (with palo, Linux
    kernel and initramfs), a NFS root FS for the host and - as said - the
    following infrastructure services in addition:

    * DNS (I use dnsmasq)
    * DHCP (I use ISC's DHCP server)
    * TFTP (I use HPA's TFTP server)
    * NFS (I use the in-kernel NFS server limited to NFS v2 and v3)

    I have them spread over two hosts, one for DNS and DHCP and one for TFTP
    and NFS, but that is not necessary. You can basically host everything on
    just a Raspberry Pi, but use a separate real block device for the NFS
    shares to not spoil the SD card too much.

    ## Configuration ##

    Typical configuration (you should be able to configure the same services
    on your Linux distribution of choice):

    `/etc/hosts` (for dnsmasq):
    ```
    [...]
    172.16.0.2 nfs.domain.tld nfs
    <IP_ADDRESS_1> hp-710.domain.tld hp710
    <IP_ADDRESS_2> hp-725.domain.tld hp725
    <IP_ADDRESS_3> c360.domain.tld c360
    [...]
    ```

    `/etc/dhcp/dhcpd.conf`
    ```
    option domain-name "domain.tld";
    option domain-name-servers 172.16.0.1;
    [...]
    authoritative;
    [...]
    ## Example for one host; should work the same for all others, too.
    ## AC100003 is the IP address in upper case hex and actually a symlink
    ## to the actual lifimage in the TFTP server's base directory, i.e.:
    ##
    ## AC100003 -> linux.sp.lifimage.4.17.0-1-parisc.debian.sid.hppa
    host hp-710 {
    fixed-address hp-710.domain.tld;
    hardware ethernet 08:00:09:11:22:33;
    option root-path "/srv/nfs/hp-710/root";
    filename "/AC100003";
    next-server nfs.domain.tld;
    option host-name "hp-710";
    }
    [...]
    ```

    `/etc/default/tftpd-hpa`
    ```
    ## Configured to work in a changed root, so `/srv/tftp` transforms to
    ## `/` in any path specs.. I only use IPv4 and increased verbosity. You
    ## should check how this is configured on your Linux distribution. TFTP_USERNAME="tftp"
    TFTP_DIRECTORY="/srv/tftp"
    [...]
    TFTP_OPTIONS="-4 --secure -vvv"
    ```

    `/etc/exports`
    ```
    ## As shown in the DHCP configuration I usually use a per-host directory
    ## plus separate dir for the actual root directory. I don't mind that
    ## all local machines can mount all host directories so I also allow
    ## them to mount everything if needed. This is useful for doing package
    ## management with a more powerful host (e.g. I use a rp3440 to manage
    ## the root directory pf my 712/80).
    ##
    ## Notice if you use BTRFS: You (still) need per-host directives if the
    ## host directories are on subvolumes.
    /srv/nfs 172.16.0.0/255.255.0.0(rw,async,no_subtree_check,no_root_squash)
    [...]
    ```

    `/etc/default/nfs-kernel-server`
    ```
    ## I limit NFS to version 2 and 3. You should check how this is
    ## configured on your Linux distribution.
    [...]
    RPCNFSDOPTS="--nfs-version 2 --nfs-version 3 --no-nfs-version 4"
    [...]
    RPCMOUNTDOPTS="--manage-gids --nfs-version 2 --nfs-version 3
    --no-nfs-version 4"
    ```

    ## Kernel and initramfs ##

    This needs to be done from a hppa host with installed Debian, e.g. your
    c8000 or an emulated one (i.e. using QEMU as in [3]). Maybe it will also
    work with QEMU hppa user emulation from a x86 machine (see [4] for
    details), but you need a ready-made installation of Debian for hppa for
    this option anyhow, so can just stay with one of the other two options.

    [3]: https://parisc.wiki.kernel.org/index.php/Qemu

    [4]: https://wiki.debian.org/QemuUserEmulation

    ### Kernel ###

    My C200 - though using a 64bit PA-8200 - uses a 32bit kernel, so maybe
    this will also work on your C360 with PA-8500. If not, you'll already
    have the 64bit kernel installed in your on-disk installation on your
    c8000. Install the 32bit kernel with:

    ```
    # apt install linux-image-parisc
    ```

    Installed 32bit kernels have "parisc" in the kernel name, 64bit kernels
    have "parisc64" in the kernel name instead.

    ### Initramfs ###

    Add "BOOT=nfs" to `/etc/initramfs-tools/initramfs.conf` and change the "MODULES" definition to "MODULES=list". I use the following modules lists:

    * for the 712/80
    `/etc/initramfs-tools/modules`:
    ```
    lasi_82596
    nfsv3
    nfs_acl
    nfs
    lockd
    grace
    sunrpc
    fscache
    ```

    * for all other hppa hosts:
    `/etc/initramfs-tools/modules`:
    ```
    pps_core
    ptp
    libphy
    tg3
    lasi_82596
    tulip
    e100
    e1000
    nfsv3
    nfs_acl
    nfs
    lockd
    grace
    sunrpc
    fscache
    ```

    Theoretically the last one should also work with the 712/80 (and 710 and
    725 accordingly), but it actually only needs the `lasi_82596` module
    during network booting. Make sure that there is no overwrite active in `/etc/initramfs-tools/conf.d` for the "MODULES" definition.

    Well, actually it might also work with "MODULES=netboot" instead, but
    using a short module list will also limit the size of the final
    initramfs and hence also shorten the boot times.

    Then run `update-initramfs -c -k <KERNEL_RELEASE>`. If an initramfs for
    the specified kernel release already exists, use `-u` instead of `-c`.
    The kernel release string in Debian on hppa is everything after
    "vmlinuz-" ("vmlinux-" in the past) in the actual kernel's file name in `/boot`.

    ## Lifimage ##

    This is created with palo. You can basically use the stock
    `/etc/palo.conf`. Put the desired kernel and initramfs into your $CWD or
    just `cd` to `/boot` and create two symlinks matching the names for
    kernel and initramfs in the used palo configuration file. Don't mind the
    part about NFS root in the stock palo configuration, this is not needed,
    as this is done by our initramfs. Then just run `palo -f
    /etc/palo.conf`. This will create a lifimage (conveniently named
    "lifimage") in $CWD that needs to be placed in the TFTP server's base
    directory and symlinked as written in the DHCP server's configuration
    file. You can hard-code the kernel command line in the palo
    configuration or interact with palo at the start of the boot process.

    ## Root directory ##

    As the hppa port uses a 32bit userland, you should be able to use any
    Debian hppa userland on any compatible hppa host.

    * You can either make a tarball of your existing on-disk installation on
    your c8000, e.g. from the Debian installer environment and untar that on
    your NFS server. There are SSH clients available as udeb packages, you
    can install these in the installer environment by using the expert mode installation or changing the debconf priority to medium and then
    selecting the additional udebs for installation. In the resulting FS you
    just need to change (remove could also work) the `/etc/fstab` and update `/etc/hostname` for a network boot.

    * Or you can use `debootstrap` to create a root directory from a working
    Debian installation on your c8000. The whole process is a little too
    long to explain in this message and I'm afraid I might have already
    bored the remainder of the subscribers, so I'd propose to first check if
    a specific lifimage boots on your machines and if that works, also build
    a root FS.

    ## Actual network boot ##

    With everything above in place, you should be able to network boot using
    just `bo[ot] lan` from BCH. To be able to modify the kernel command line
    from palo on my 712/80, I needed to add ` isl`. I believe later machines
    ask if one wants to interact with IPL when booting manually. Because of
    [5] and the 710 and 725 using a similar(?) built-in NIC, I'd recommend
    to (1) use the same settings for NFS (rsize/wsize=16384) in the kernel
    command line argument (add `nfsroot=/srv/nfs/<HOSTNAME>/root,rsize=16384,wsize=16384`) and (2)
    configure the used switch port to 10 Mbps half-duplex and enable flow
    control or better use a 10 Mbps Ethernet hub for these machines. In
    addition use `cryptomgr.notests` in the kernel command line to speed up
    the kernel boot process on slow machines.

    [5]: https://lists.debian.org/debian-hppa/2018/04/msg00024.html

    I hope I didn't forget anything important. In case of questions just
    make contact.

    And regarding the crashes and instabilities I see, I'm now sure, that
    they are coming from the "apt-get upgrade". The original 8 (jessie) installation works absolutely stable. But after the upgrade, the system either doesn't boot or it crashes sometime later. This doesn't happen
    without the upgrade.

    Never noticed a difference in stability for my c8000s depending on the
    OS release level, but mostly used rp3440s since I have acquired them. I
    can check with a c8000 tomorrow if I notice any differences in behaviour.

    Cheers,
    Frank

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Frank Scheiner@21:1/5 to Lothar Paltins on Mon Mar 18 00:10:02 2019
    On 3/16/19 22:57, Lothar Paltins wrote:
    Am 16.03.19 um 22:49 schrieb Helge Deller:
    A boot log of the 710, 725 and C360 would be interesting.

    Would it be possible to install it on a 710 at all? It has the maximum possible RAM, but that's only 64MB.

    My 712/80 has 128MB and gives the following after the boot is completed:

    ```
    root@hp-712-80:~# free -m
    total used free shared buff/cache
    available
    Mem: 117 16 60 0 41
    96
    Swap: 0 0 0
    ```

    This doesn't say anything about an installation (you don't need to
    install with network boot), but I'd assume that 64MB ought to be enough.

    Cheers,
    Frank

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lothar Paltins@21:1/5 to All on Mon Mar 18 13:50:02 2019
    Hi Frank,

    Great! Actually this is pretty easy to set up as soon as you have found
    out all needed details. :-) You only need a lifimage (with palo, Linux
    kernel and initramfs), a NFS root FS for the host and - as said - the following infrastructure services in addition:

    ... (215 lines deleted)

    I hope I didn't forget anything important. In case of questions just
    make contact.

    Oh boy, and you call this all "pretty easy to set up"? It may be easy in
    terms of complexity, but the effort isn't negligible.

    And the first difficulty is that my C8000 doesn't boot with the new
    kernel (vmlinuz-4.19.0-4-parisc64-smp). It stops after this message:

    Branching to kernel entry point 0x000e0000. If this is the last
    message you see, you may need to switch your console. This is
    a common symptom -- search the FAQ and mailing list at parisc-linux.org

    Of course it has nothing to do with the console setting. Maybe it's
    caused by the fact that it's a 4 core machine with two 1 GHz dual core
    PA-8800 processors. And even kernel vmlinux-3.16.0-4-parisc64-smp
    doesn't boot absolutely reliable. Sometimes it crashes after "Reached
    target Graphical Interface" and "Started Update UTMP about System
    Runlevel Changes". And sometimes it boots up and the connected monitor
    wakes up from power save mode, but the screen stays black. I guess, both
    is related to the ATI graphics card driver which is not in the focus of
    the debian-hppa project.

    Lothar
    --
    Lothar Paltins lptmp10@arcor.de

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Helge Deller@21:1/5 to Lothar Paltins on Mon Mar 18 15:20:01 2019
    On 18.03.19 13:43, Lothar Paltins wrote:
    And the first difficulty is that my C8000 doesn't boot with the new kernel (vmlinuz-4.19.0-4-parisc64-smp). It stops after this message:

      Branching to kernel entry point 0x000e0000. If this is the last
      message you see, you may need to switch your console. This is
      a common symptom -- search the FAQ and mailing list at parisc-linux.org

    It should boot further than that.
    Which palo version are you running?
    Did you ran "palo -v" before reboot?
    Can you send a full log or screenshot ?

    Of course it has nothing to do with the console setting. Maybe it's caused by the fact that it's a 4 core machine with two 1 GHz dual core PA-8800 processors.

    For me it works on a c800 machine:

    root@phantom:~# lscpu
    Architecture: parisc64
    Byte Order: Big Endian
    CPU(s): 4
    On-line CPU(s) list: 0-3
    Thread(s) per core: 1
    Core(s) per socket: 2
    Socket(s): 2
    CPU family: PA-RISC 2.0
    Model: 9000/785/C8000
    Model name: PA8900 (Shortfin)
    CPU MHz: 1000.000000
    BogoMIPS: 1988.60
    root@phantom:~# uname -a
    Linux phantom.physik.xxxx.de 4.19.0-4-parisc64-smp #1 SMP Debian 4.19.28-1 (2019-03-12) parisc64 GNU/Linux

    I pulled out any graphics card of this machine though.


    Helge

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lothar Paltins@21:1/5 to All on Mon Mar 18 20:40:01 2019
    Am 18.03.19 um 15:10 schrieb Helge Deller:
    It should boot further than that.
    Which palo version are you running?
    Did you ran "palo -v" before reboot?

    No, I didn't know, that this is necessary. After "palo -v" the system is booting now. Booting continues now with "Uncompressing ...". The old
    palo (1.95) seems to be unable to uncompress the kernel.

    I pulled out any graphics card of this machine though.

    And this seems to be necessary. It's still pure chance, whether the
    graphics card is working or not. It may even cause a crash during
    booting. Here's a boot log of a crash:

    [ 93.621614] [drm] radeon kernel modesetting enabled.
    [ 93.871832] radeon 0000:80:00.0: enabling SERR and PARITY (0107 -> 0147)
    [ 94.010799] [drm] initializing kernel modesetting (RV350
    0x1002:0x4154 0x1002:0x0002 0x80).
    [ 94.179812] ipmi 16: Found new BMC (man_id: 0x00000b, prod_id:
    0x8201, dev_id: 0x32)
    [ 94.219177] [drm] GPU not posted. posting now...
    [ 94.347007] ipmi 16: IPMI kcs interface initialized
    [ 94.512299] radeon 0000:80:00.0: putting AGP V3 device into 8x mode
    [ 94.599144] radeon 0000:80:00.0: GTT: 512M 0x60000000 - 0x7FFFFFFF
    [ 94.599165] [drm] Generation 2 PCI interface, using max accessible memory
    [ 94.599179] radeon 0000:80:00.0: VRAM: 128M 0xFFFFFFFFC0000000 - 0xFFFFFFFFC7FFFFFF (128M used)
    [ 94.599496] [drm] Detected VRAM RAM=128M, BAR=128M
    [ 94.599504] [drm] RAM width 128bits DDR
    [ 94.603570] [TTM] Zone kernel: Available graphics memory: 8218164 kiB
    [ 94.603578] [TTM] Zone dma32: Available graphics memory: 2097152 kiB
    [[ 94.603584] [TTM] Initializing pool allocator
    [ 94.887738] [drm] radeon: 128M of VRAM memory ready
    OK 94.887756] [drm] radeon: 512M of GTT memory ready.
    m] Found device 94.888008] [drm] radeon: 1 quad pipes, 1 Z pipes
    initialized
    ;1;39m82540EM Gi[ 94.923120] radeon 0000:80:00.0: WB disabled

    gabit Ethernet C[ 94.923159] radeon 0000:80:00.0: fence driver on ring
    0 use gpu addr 0x0000000060000000 and cpu addr 0x000000002cdcd946


    ontroller.
    [ 94.930972] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
    [ 95.807136] [drm] Driver supports precise vblank timestamp query.
    [ 95.807402] [drm] radeon: irq initialized.
    [ 95.807548] [drm] Loading R300 Microcode
    [ 95.835137] radeon 0000:80:00.0: firmware: failed to load
    radeon/R300_cp.bin (-2)
    [ 95.835160] firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware
    [ 95.835172] radeon 0000:80:00.0: Direct firmware load for
    radeon/R300_cp.bin failed with error -2
    [ 95.835558] [drm:r100_cp_init [radeon]] *ERROR* Failed to load firmware!
    [ 95.835581] radeon 0000:80:00.0: failed initializing CP (-2).
    [ 96.503094] radeon 0000:80:00.0: Disabling GPU acceleration
    [ 96.504398] [drm] radeon: cp finalized
    [ 96.531896] [drm] radeon: cp finalized
    [ 96.683535] [TTM] Finalizing pool allocator
    [ 96.735229] [TTM] Zone kernel: Used memory at exit: 0 kiB
    [ 96.735229] [TTM] Zone dma32: Used memory at exit: 0 kiB
    [ 96.735229] [drm] radeon: ttm finalized
    [ 96.735229] [drm] Forcing AGP to PCI mode
    [ 96.793669] [drm] Generation 2 PCI interface, using max accessible memory
    [ 97.099110] radeon 0000:80:00.0: VRAM: 128M 0xFFFFFFFFC0000000 - 0xFFFFFFFFC7FFFFFF (128M used)
    [ 97.099121] radeon 0000:80:00.0: GTT: 512M 0xFFFFFFFFA0000000 - 0xFFFFFFFFBFFFFFFF
    [ 97.099142] [drm] Detected VRAM RAM=128M, BAR=128M
    [ 97.099149] [drm] RAM width 128bits DDR
    [ 97.203340] [TTM] Zone kernel: Available graphics memory: 8218164 kiB
    [ 97.203349] [TTM] Zone dma32: Available graphics memory: 2097152 kiB
    [ 97.203356] [TTM] Initializing pool allocator
    [ 97.203554] [drm] radeon: 128M of VRAM memory ready
    [ 97.203563] [drm] radeon: 512M of GTT memory ready.
    [ 97.203683] [drm] GART: num cpu pages 131072, num gpu pages 131072
    [ 97.396449] [drm] radeon: 1 quad pipes, 1 Z pipes initialized
    [ 97.396472] [drm] PCI GART of 512M enabled (table at 0x0000000043D00000).
    [ 97.396631] radeon 0000:80:00.0: WB enabled
    [ 97.396652] radeon 0000:80:00.0: fence driver on ring 0 use gpu addr 0xffffffffa0000000 and cpu addr 0x00000000e3b927cf
    [ 97.396665] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
    [ 97.396671] [drm] Driver supports precise vblank timestamp query.
    [ 97.396753] [drm] radeon: irq initialized.
    [ 97.396763] [drm] Loading R300 Microcode
    [ 97.396855] radeo

    At this point it crashed with a blinking red LED.

    But even if the graphics card works, it's almost unusable now. The
    previous version with KDE4 worked reasonable fast, but the new Plasma
    desktop is incredibly slow. Even the simple systemsettings5 application
    uses about 100% CPU time and everything reacts extremely slow on
    keyboard and mouse events.

    Lothar
    --
    Lothar Paltins lptmp10@arcor.de

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Frank Scheiner@21:1/5 to Frank Scheiner on Mon Mar 18 21:30:02 2019
    Hi Lothar,

    On 3/17/19 23:50, Frank Scheiner wrote:
    Hi Lothar,

    On 3/16/19 22:42, Lothar Paltins wrote:
    And for the hppa port of
    Debian GNU/Linux I think it's a very good combination of size and
    hardware resources. In addition it has built-in remote control
    capabilities (see [1]).

    Interesting for a remote server with modem access to the serial port.
    I've tried it out on my machine, but after entering ESC-(, the serial
    line simply freezes up. Maybe a BMC-password is set that should be
    cleared.

    Can't remember seeing something like this on my c8000s, but I can check tomorrow.

    I did a few tests and when a password was set I always got a "Password:
    " prompt when it was needed to enter a password (e.g. after issuing "q"
    to end a BMC (admin) session). Not sure what's the reason for your issue.

    What did you type in exactly?

    I always had to finish the escape sequence with the <Enter> key after
    typing in `<ESC>(` and also when escaping from the BMC with `<ESC>)`.

    BTW, I use `screen` to access the serial console. Maybe you try with
    that tool, too, with e.g. `screen /dev/ttyUSB0 9600,cs8` (`<Ctrl>ak` to
    exit).

    The firmware version on the tested c8000 is "2.13" and the BMC firmware revision is "2.32".

    And regarding the crashes and instabilities I see, I'm now sure, that
    they are coming from the "apt-get upgrade". The original 8 (jessie)
    installation works absolutely stable. But after the upgrade, the system
    either doesn't boot or it crashes sometime later. This doesn't happen
    without the upgrade.

    Never noticed a difference in stability for my c8000s depending on the
    OS release level, but mostly used rp3440s since I have acquired them. I
    can check with a c8000 tomorrow if I notice any differences in behaviour.

    I didn't experience any instabilities with the c8000 I tested today.
    Like yours it has two 1 GHz PA-8800 dual cores installed.

    I really assume that removing the graphics card will be key to stability
    for your c8000. This or maybe blacklisting the radeon module with `modprobe.blacklist=radeon` in the kernel command line.

    Cheers,
    Frank

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Helge Deller@21:1/5 to Lothar Paltins on Mon Mar 18 23:10:01 2019
    Hi Lothar,

    On 18.03.19 20:39, Lothar Paltins wrote:
    Am 18.03.19 um 15:10 schrieb Helge Deller:
    It should boot further than that.
    Which palo version are you running?
    Did you ran "palo -v" before reboot?

    No, I didn't know, that this is necessary. After "palo -v" the system
    is booting now. Booting continues now with "Uncompressing ...". The
    old palo (1.95) seems to be unable to uncompress the kernel.

    This "Uncompressing..." happens in the kernel itself, it's not part of palo.
    I think the problem was, that the old palo had a bug which
    couldn't cope with kernels bigger than a specific size (and other bugs). Anyway, good to know that updating palo fixes the issue.

    I pulled out any graphics card of this machine though.

    And this seems to be necessary. It's still pure chance, whether the
    graphics card is working or not. It may even cause a crash during
    booting. Here's a boot log of a crash:

    [   93.621614] [drm] radeon kernel modesetting enabled.
    [   93.871832] radeon 0000:80:00.0: enabling SERR and PARITY (0107 -> 0147) [   94.010799] [drm] initializing kernel modesetting (RV350 0x1002:0x4154 0x1002:0x0002 0x80).
    [   94.179812] ipmi 16: Found new BMC (man_id: 0x00000b, prod_id: 0x8201, dev_id: 0x32)
    [   94.219177] [drm] GPU not posted. posting now...
    [   94.347007] ipmi 16: IPMI kcs interface initialized
    [   94.512299] radeon 0000:80:00.0: putting AGP V3 device into 8x mode
    [   94.599144] radeon 0000:80:00.0: GTT: 512M 0x60000000 - 0x7FFFFFFF
    [   94.599165] [drm] Generation 2 PCI interface, using max accessible memory [   94.599179] radeon 0000:80:00.0: VRAM: 128M 0xFFFFFFFFC0000000 - 0xFFFFFFFFC7FFFFFF (128M used)
    [   94.599496] [drm] Detected VRAM RAM=128M, BAR=128M
    [   94.599504] [drm] RAM width 128bits DDR
    [   94.603570] [TTM] Zone  kernel: Available graphics memory: 8218164 kiB
    [   94.603578] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB [[   94.603584] [TTM] Initializing pool allocator
    [   94.887738] [drm] radeon: 128M of VRAM memory ready
      OK     94.887756] [drm] radeon: 512M of GTT memory ready.
    m] Found device    94.888008] [drm] radeon: 1 quad pipes, 1 Z pipes initialized
    ;1;39m82540EM Gi[   94.923120] radeon 0000:80:00.0: WB disabled
    gabit Ethernet C[   94.923159] radeon 0000:80:00.0: fence driver on ring 0 use gpu addr 0x0000000060000000 and cpu addr 0x000000002cdcd946

    ontroller.
    [   94.930972] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [   95.807136] [drm] Driver supports precise vblank timestamp query.
    [   95.807402] [drm] radeon: irq initialized.
    [   95.807548] [drm] Loading R300 Microcode
    [   95.835137] radeon 0000:80:00.0: firmware: failed to load radeon/R300_cp.bin (-2)
    [   95.835160] firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware
    [   95.835172] radeon 0000:80:00.0: Direct firmware load for radeon/R300_cp.bin failed with error -2
    [   95.835558] [drm:r100_cp_init [radeon]] *ERROR* Failed to load firmware! [   95.835581] radeon 0000:80:00.0: failed initializing CP (-2).
    [   96.503094] radeon 0000:80:00.0: Disabling GPU acceleration
    [   96.504398] [drm] radeon: cp finalized
    [   96.531896] [drm] radeon: cp finalized
    [   96.683535] [TTM] Finalizing pool allocator
    [   96.735229] [TTM] Zone  kernel: Used memory at exit: 0 kiB
    [   96.735229] [TTM] Zone   dma32: Used memory at exit: 0 kiB
    [   96.735229] [drm] radeon: ttm finalized
    [   96.735229] [drm] Forcing AGP to PCI mode
    [   96.793669] [drm] Generation 2 PCI interface, using max accessible memory [   97.099110] radeon 0000:80:00.0: VRAM: 128M 0xFFFFFFFFC0000000 - 0xFFFFFFFFC7FFFFFF (128M used)
    [   97.099121] radeon 0000:80:00.0: GTT: 512M 0xFFFFFFFFA0000000 - 0xFFFFFFFFBFFFFFFF
    [   97.099142] [drm] Detected VRAM RAM=128M, BAR=128M
    [   97.099149] [drm] RAM width 128bits DDR
    [   97.203340] [TTM] Zone  kernel: Available graphics memory: 8218164 kiB
    [   97.203349] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
    [   97.203356] [TTM] Initializing pool allocator
    [   97.203554] [drm] radeon: 128M of VRAM memory ready
    [   97.203563] [drm] radeon: 512M of GTT memory ready.
    [   97.203683] [drm] GART: num cpu pages 131072, num gpu pages 131072
    [   97.396449] [drm] radeon: 1 quad pipes, 1 Z pipes initialized
    [   97.396472] [drm] PCI GART of 512M enabled (table at 0x0000000043D00000). [   97.396631] radeon 0000:80:00.0: WB enabled
    [   97.396652] radeon 0000:80:00.0: fence driver on ring 0 use gpu addr 0xffffffffa0000000 and cpu addr 0x00000000e3b927cf
    [   97.396665] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [   97.396671] [drm] Driver supports precise vblank timestamp query.
    [   97.396753] [drm] radeon: irq initialized.
    [   97.396763] [drm] Loading R300 Microcode
    [   97.396855] radeo

    At this point it crashed with a blinking red LED.

    But even if the graphics card works, it's almost unusable now. The
    previous version with KDE4 worked reasonable fast, but the new Plasma
    desktop is incredibly slow. Even the simple systemsettings5
    application uses about 100% CPU time and everything reacts extremely
    slow on keyboard and mouse events.

    Ok, that needs more analyzing.
    Hard to say from here what's wrong.
    I can try to debug further when I found time at some point.
    Helge

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John David Anglin@21:1/5 to Helge Deller on Mon Mar 18 23:20:01 2019
    On 2019-03-18 6:08 p.m., Helge Deller wrote:
    I pulled out any graphics card of this machine though.
    And this seems to be necessary. It's still pure chance, whether the
    graphics card is working or not. It may even cause a crash during
    booting. Here's a boot log of a crash:

    [   93.621614] [drm] radeon kernel modesetting enabled.
    [   93.871832] radeon 0000:80:00.0: enabling SERR and PARITY (0107 -> 0147) >> [   94.010799] [drm] initializing kernel modesetting (RV350 0x1002:0x4154 0x1002:0x0002 0x80).
    [   94.179812] ipmi 16: Found new BMC (man_id: 0x00000b, prod_id: 0x8201, dev_id: 0x32)
    [   94.219177] [drm] GPU not posted. posting now...
    [   94.347007] ipmi 16: IPMI kcs interface initialized
    [   94.512299] radeon 0000:80:00.0: putting AGP V3 device into 8x mode
    [   94.599144] radeon 0000:80:00.0: GTT: 512M 0x60000000 - 0x7FFFFFFF
    [   94.599165] [drm] Generation 2 PCI interface, using max accessible memory >> [   94.599179] radeon 0000:80:00.0: VRAM: 128M 0xFFFFFFFFC0000000 - 0xFFFFFFFFC7FFFFFF (128M used)
    [   94.599496] [drm] Detected VRAM RAM=128M, BAR=128M
    [   94.599504] [drm] RAM width 128bits DDR
    [   94.603570] [TTM] Zone  kernel: Available graphics memory: 8218164 kiB
    [   94.603578] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
    [[   94.603584] [TTM] Initializing pool allocator
    [   94.887738] [drm] radeon: 128M of VRAM memory ready
      OK     94.887756] [drm] radeon: 512M of GTT memory ready.
    m] Found device    94.888008] [drm] radeon: 1 quad pipes, 1 Z pipes initialized
    ;1;39m82540EM Gi[   94.923120] radeon 0000:80:00.0: WB disabled
    gabit Ethernet C[   94.923159] radeon 0000:80:00.0: fence driver on ring 0 use gpu addr 0x0000000060000000 and cpu addr 0x000000002cdcd946

    ontroller.
    [   94.930972] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). >> [   95.807136] [drm] Driver supports precise vblank timestamp query.
    [   95.807402] [drm] radeon: irq initialized.
    [   95.807548] [drm] Loading R300 Microcode
    [   95.835137] radeon 0000:80:00.0: firmware: failed to load radeon/R300_cp.bin (-2)
    [   95.835160] firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware
    [   95.835172] radeon 0000:80:00.0: Direct firmware load for radeon/R300_cp.bin failed with error -2
    [   95.835558] [drm:r100_cp_init [radeon]] *ERROR* Failed to load firmware! >> [   95.835581] radeon 0000:80:00.0: failed initializing CP (-2).
    [   96.503094] radeon 0000:80:00.0: Disabling GPU acceleration
    [   96.504398] [drm] radeon: cp finalized
    [   96.531896] [drm] radeon: cp finalized
    [   96.683535] [TTM] Finalizing pool allocator
    [   96.735229] [TTM] Zone  kernel: Used memory at exit: 0 kiB
    [   96.735229] [TTM] Zone   dma32: Used memory at exit: 0 kiB
    [   96.735229] [drm] radeon: ttm finalized
    [   96.735229] [drm] Forcing AGP to PCI mode
    [   96.793669] [drm] Generation 2 PCI interface, using max accessible memory >> [   97.099110] radeon 0000:80:00.0: VRAM: 128M 0xFFFFFFFFC0000000 - 0xFFFFFFFFC7FFFFFF (128M used)
    [   97.099121] radeon 0000:80:00.0: GTT: 512M 0xFFFFFFFFA0000000 - 0xFFFFFFFFBFFFFFFF
    [   97.099142] [drm] Detected VRAM RAM=128M, BAR=128M
    [   97.099149] [drm] RAM width 128bits DDR
    [   97.203340] [TTM] Zone  kernel: Available graphics memory: 8218164 kiB
    [   97.203349] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
    [   97.203356] [TTM] Initializing pool allocator
    [   97.203554] [drm] radeon: 128M of VRAM memory ready
    [   97.203563] [drm] radeon: 512M of GTT memory ready.
    [   97.203683] [drm] GART: num cpu pages 131072, num gpu pages 131072
    [   97.396449] [drm] radeon: 1 quad pipes, 1 Z pipes initialized
    [   97.396472] [drm] PCI GART of 512M enabled (table at 0x0000000043D00000). >> [   97.396631] radeon 0000:80:00.0: WB enabled
    [   97.396652] radeon 0000:80:00.0: fence driver on ring 0 use gpu addr 0xffffffffa0000000 and cpu addr 0x00000000e3b927cf
    [   97.396665] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). >> [   97.396671] [drm] Driver supports precise vblank timestamp query.
    [   97.396753] [drm] radeon: irq initialized.
    [   97.396763] [drm] Loading R300 Microcode
    [   97.396855] radeo

    At this point it crashed with a blinking red LED.

    But even if the graphics card works, it's almost unusable now. The
    previous version with KDE4 worked reasonable fast, but the new Plasma
    desktop is incredibly slow. Even the simple systemsettings5
    application uses about 100% CPU time and everything reacts extremely
    slow on keyboard and mouse events.
    Ok, that needs more analyzing.
    Hard to say from here what's wrong.
    I can try to debug further when I found time at some point.
    I've never seen the kernel try PCI after AGP as far as I can recall.  One as WB enabled and the
    other doesn't.

    Dave

    --
    John David Anglin dave.anglin@bell.net

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lothar Paltins@21:1/5 to All on Tue Mar 19 01:00:02 2019
    Hi Frank,

    BTW, I use `screen` to access the serial console. Maybe you try with
    that tool, too, with e.g. `screen /dev/ttyUSB0 9600,cs8` (`<Ctrl>ak` to exit).

    I did use a "real" terminal, an HP700/94. I've now tried it with a
    simple serial communication program running in a KDE Konsole window, and
    now it works. Something must have messed up the terminal.

    The firmware version on the tested c8000 is "2.13" and the BMC firmware revision is "2.32".

    Same here.

    I really assume that removing the graphics card will be key to stability
    for your c8000. This or maybe blacklisting the radeon module with `modprobe.blacklist=radeon` in the kernel command line.

    Yes, that would most likely fix the stability issues. But running a
    graphical workstation without graphics doesn't make a lot of sense, at
    least not for me.

    Lothar
    --
    Lothar Paltins lptmp10@arcor.de

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)