Really? Well then .. let me see what I have that is ancient in the
warehouse.
How about PA-RISC? I happen to have some superdomes kicking about but
they require truely a ton of power to operate.
On 04/14/2018 06:11 PM, Dennis Clarke wrote:
Really? Well then .. let me see what I have that is ancient in the
warehouse.
How about PA-RISC? I happen to have some superdomes kicking about but they require truely a ton of power to operate.
I assume hppa people in Debian (debian-hppa@l.d.o in CC) would appreciate testing on such gear.
Not sure if those superdomes will work out of the box though.
I know from my own testing that the following "smaller" machines work with Debian GNU/Linux Sid for hppa:
* 712/80
* c3700, c3750, J5600, rp2470
* c8000, rp3440
Apart from the rp3440 - and maybe also the 712/80 which showed some issue with it's built-in NIC after netbooting the Linux kernel and the OS
- all machines also work diskless, which could speed up testing for you and avoid a manual Debian installation - although this could still be interesting.
On 14.04.2018 20:13, Frank Scheiner wrote:
I know from my own testing that the following "smaller" machines work with Debian GNU/Linux Sid for hppa:
* 712/80
* c3700, c3750, J5600, rp2470
* c8000, rp3440
Apart from the rp3440 - and maybe also the 712/80 which showed some issue with it's built-in NIC after netbooting the Linux kernel and the OS
What kind of problems?
Interestingly after upgrading all packages (obviously including palo)A quirk was added to disable the radeon driver for the builtin RV100 in
on the NFS root FS and building a new lifimage with Linux 4.15.x, blacklisting the radeon module seems to be no longer required. Not
sure if this is due to palo 2.00 or Linux 4.15.x. Anyways the radeon
module is no longer loaded automatically with this configuration.
On 2018-04-19 3:29 PM, Frank Scheiner wrote:
Interestingly after upgrading all packages (obviously including palo)A quirk was added to disable the radeon driver for the builtin RV100 in
on the NFS root FS and building a new lifimage with Linux 4.15.x,
blacklisting the radeon module seems to be no longer required. Not
sure if this is due to palo 2.00 or Linux 4.15.x. Anyways the radeon
module is no longer loaded automatically with this configuration.
the rp3440. It's broken. There should be a message in the dmesg log
about this.
Seems to be a generic issue. https://www.linuxquestions.org/questions/showthread.php?p=5803405#post5803405Apart from the rp3440 - and maybe also the 712/80 which showed some issue with it's built-in NIC after netbooting the Linux kernel and the OS
What kind of problems?
Unfortunately I seem to not have made any notes for the issue with the 712/80, so I retried with the assumed issue creating configuration earlier this week:
This configuration was using a Debian Linux kernel 4.9.25-1 (4.9.0-3-parisc from 2017-05-02). And when netbooting it, shortly after login the machine seems to loose contact to the NFS server:
```
[...]
[ OK ] Started Serial Getty on ttyS0.
[ OK ] Started Getty on tty1.
[ OK ] Reached target Login Prompts.
Debian GNU/Linux buster/sid hp-712 ttyS0
hp-712 login: root
Password:
Last login: Thu Sep 18 11:30:50 CET 1902 from 172.16.1.1 on pts/0
Linux hp-712 4.9.0-3-parisc #1 Debian 4.9.25-1 (2017-05-02) parisc
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
[ 232.973913] nfs: server 172.16.0.2 not responding, still trying
[ 233.094265] nfs: server 172.16.0.2 not responding, still trying
[ 233.205127] nfs: server 172.16.0.2 not responding, still trying
[ 233.568429] nfs: server 172.16.0.2 not responding, still trying
[ 233.692383] nfs: server 172.16.0.2 not responding, still trying
[ 233.808818] nfs: server 172.16.0.2 not responding, still trying
[...]
[ 235.179253] nfs: server 172.16.0.2 OK
[ 235.251896] nfs: server 172.16.0.2 not responding, still trying
[...]
```
Although it seems to be able to reconnect from time to time, the machine is not accessible.
Afterwards I found some older notes about this machine which mention
no issues during diskless operation with the very same configuration
(kernel and possibly also userland), which made me wonder, if there's
maybe an issue between the machine's built-in NIC and my used 1000
Mbit network switch. And indeed, when connecting another 100 Mbit
network switch in between the 712/80 and the 1000 Mbit network switch
the issue seemed to be gone and the machine stayed accessible .
But later this week I retried the 712/80 with the current Linux
kernel (4.15.x) and Debian userland and the issue hit me again,
although much later and despite the 100 Mbit network switch in
between. Looking at it I could see that the collision indicator was
active on the switch for the port used by the 712/80. I then
configured a singular port of the 1000 Mbit network switch to 10 Mbit
full duplex and attached the 712/80 to it. And then the issue again
seemed to be gone. But trying to install a package or updating the
package cache again quickly triggered it. Well that's not that of an
issue, as I can do the package management for the 712/80 with another
machine (e.g. c8000).
Also interesting, the kernel messages for 4.15.11, please notice the
time difference between "random: crng init done" and "Key type
asymmetric registered":
```When loading via TFTP not much traffic is generated.
[ 0.000000] Linux version 4.15.0-2-parisc (debian-kernel@lists.debian.org) (gcc version 7.3.0 (Debian 7.3.0-12)) #1 Debian 4.15.11-1 (2018-03-20)
[ 0.000000] unwind_init: start = 0x1086e8b4, end = 0x108c5644, entries = 22233
[ 0.000000] FP[0] enabled: Rev 1 Model 13
[ 0.000000] The 32-bit Kernel has started...
[...]
[ 9.919844] workingset: timestamp_bits=14 max_order=15 bucket_order=1 [ 10.168866] zbud: loaded
[ 56.112387] random: crng init done
[ 433.392379] Key type asymmetric registered
[ 433.445502] Asymmetric key parser 'x509' registered
[...]
[ 544.565451] systemd[1]: Detected architecture parisc.
Welcome to Debian GNU/Linux buster/sid!
[...]
[ OK ] Started Serial Getty on ttyS0.
[ OK ] Started Getty on tty1.
[ OK ] Reached target Login Prompts.
Debian GNU/Linux buster/sid hp-712 ttyS0
hp-712 login:
```
...On first try I assumed the machine or the kernel would hang, but no, it was still working all the time.
Today I tested it again (with 4.15.11) and the issue this time hit me already during login, after I entered the username.
So I'm actually back at where I'm started. :-(
I suspect that maybe the built-in 82596 NIC cannot cope with the
amount of traffic that happens during diskless operation - although I
then wonder why it doesn't have a problem during the TFTP operation
to load the lifimage.
Next thing I'll examine will be the parameters used for the NFS mount (especially for rsize and wsize) - if I ever can login to it again
:-). And maybe a fan for the passive heat sink of the CPU which gets
quite hot during operation.
Any suggestions on where to look else?
****
For the rp3440 I (also) have to retract my earlier statement as it
looks like my second rp3440 actually **works** diskless. I have to
retest with my first rp3440 (currently in storage) as it seems it
behaves differently in this regard - or maybe I misconfigured
something there in the past. I have to recheck.
But for my second rp3440 I still had to blacklist the `radeon` module
to achieve this, as otherwise the system (console) seems to crash
shortly before the login prompt would have appeared or just after.
This is my used kernel command line as configured with palo 1.99 and
Linux 4.14.x:
```
Current command line:
0/vmlinux HOME=/ root=/dev/nfs ip=:::::enp32s2:dhcp modprobe.blacklist=radeon initrd=0/ramdisk TERM=vt102 console=ttyS0
0: 0/vmlinux
1: HOME=/
2: root=/dev/nfs
3: ip=:::::enp32s2:dhcp
4: modprobe.blacklist=radeon
5: initrd=0/ramdisk
6: TERM=vt102
7: console=ttyS0
```
Interestingly after upgrading all packages (obviously including palo)
on the NFS root FS and building a new lifimage with Linux 4.15.x, blacklisting the radeon module seems to be no longer required. Not
sure if this is due to palo 2.00 or Linux 4.15.x. Anyways the radeon
module is no longer loaded automatically with this configuration.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bcf3f1752a622f1372d3252d0fea8855d89812e7
Afterwards I found some older notes about this machine which mention
no issues during diskless operation with the very same configuration
(kernel and possibly also userland), which made me wonder, if there's
maybe an issue between the machine's built-in NIC and my used 1000
Mbit network switch. And indeed, when connecting another 100 Mbit
network switch in between the 712/80 and the 1000 Mbit network switch
the issue seemed to be gone and the machine stayed accessible .
But later this week I retried the 712/80 with the current Linux
kernel (4.15.x) and Debian userland and the issue hit me again,
although much later and despite the 100 Mbit network switch in
between. Looking at it I could see that the collision indicator was
active on the switch for the port used by the 712/80. I then
configured a singular port of the 1000 Mbit network switch to 10 Mbit
full duplex and attached the 712/80 to it. And then the issue again
seemed to be gone. But trying to install a package or updating the
package cache again quickly triggered it.
From the manual, it seems the 10BASE-T port is half duplex (CSMA/CD).But later this week I retried the 712/80 with the current LinuxYou could try setting the internal NIC to half-duplex, or perhaps use a (passive) 10BASE-T hub instead of a switch if you cannot configure that internally, on the kernel command line, or doing it in userland is too
kernel (4.15.x) and Debian userland and the issue hit me again,
although much later and despite the 100 Mbit network switch in
between. Looking at it I could see that the collision indicator was
active on the switch for the port used by the 712/80. I then
configured a singular port of the 1000 Mbit network switch to 10 Mbit
full duplex and attached the 712/80 to it. And then the issue again
seemed to be gone. But trying to install a package or updating the
package cache again quickly triggered it.
late.
I think this is caused by cryptomgr_test. It can be disabled with "cryptomgr.notests" on commandAlso interesting, the kernel messages for 4.15.11, please notice theSeems to be a generic issue. https://www.linuxquestions.org/questions/showthread.php?p=5803405#post5803405
time difference between "random: crng init done" and "Key type
asymmetric registered":
My assumption is, that the kernel waits until it has
enough randomness for the various encryption algorithms.
Not recently. I found this when I was working on the cache.TLB patch.It can be disabled with "cryptomgr.notests" on command line.Did you tested this?
Unless I typed it wrong it didn't worked on my B160L:You typed it wrong.
[ 0.000000] Kernel command line: root=/dev/sda5 crpytomgr.notests HOME=/ console=ttyS0 TERM=vt102 palo_kernel=2/vmlinux
On 2018-04-20 2:37 AM, Helge Deller wrote:
Also interesting, the kernel messages for 4.15.11, please notice theSeems to be a generic issue.
time difference between "random: crng init done" and "Key type
asymmetric registered":
https://www.linuxquestions.org/questions/showthread.php?p=5803405#post5803405
My assumption is, that the kernel waits until it has
enough randomness for the various encryption algorithms.
I think this is caused by cryptomgr_test.
It can be disabled with "cryptomgr.notests" on command line.
On 2018-04-21 6:17 PM, Helge Deller wrote:
Not recently. I found this when I was working on the cache.TLB patch. It caused a stall in one version.It can be disabled with "cryptomgr.notests" on command line.Did you tested this?
Unless I typed it wrong it didn't worked on my B160L:
[ 0.000000] Kernel command line: root=/dev/sda5 crpytomgr.notests HOME=/ console=ttyS0 TERM=vt102 palo_kernel=2/vmlinux
You typed it wrong.
On 22.04.2018 00:36, John David Anglin wrote:
On 2018-04-21 6:17 PM, Helge Deller wrote:
Not recently. I found this when I was working on the cache.TLB patch. It caused a stall in one version.It can be disabled with "cryptomgr.notests" on command line.Did you tested this?
Unless I typed it wrong it didn't worked on my B160L:
[ 0.000000] Kernel command line: root=/dev/sda5 crpytomgr.notests HOME=/ console=ttyS0 TERM=vt102 palo_kernel=2/vmlinux
You typed it wrong.
Yes, my fault.
"cryptomgr.notests" did worked as expected.
You could try setting the internal NIC to half-duplex, or perhaps use a (passive) 10BASE-T hub instead of a switch if you cannot configure that internally, on the kernel command line, or doing it in userland is too
late.
From the manual, it seems the 10BASE-T port is half duplex (CSMA/CD).
The MAU
interface is definitely half duplex and the word duplex is not mentioned
in the manual.
The 10BASE-T port probably doesn't support auto negotiation, so you will
need to manually
set the switch port to 10BASE-T half duplex if it doesn't automatically configure to this mode
when auto negotiation fails.
Some switches support a half-duplex back pressure form of flow control.
On 04/21/2018 02:22 AM, John David Anglin wrote:I looked at the "Technical Reference".
From the manual, it seems the 10BASE-T port is half duplex
(CSMA/CD). The MAU
interface is definitely half duplex and the word duplex is not
mentioned in the manual.
I also didn't find any info about half-/full-duplex in the two manuals
I have at hand for the 712/80 ("Service Handbook" and "Technical
Reference Manual"). To be sure, which one did you consult?
Seems like hardware problem, probably in 712. The switch and 712 need
The 10BASE-T port probably doesn't support auto negotiation, so you
will need to manually
set the switch port to 10BASE-T half duplex if it doesn't
automatically configure to this mode
when auto negotiation fails.
Did this at first but then went for full-duplex again. Today I started
with full-duplex and actively cooling the heatsink (now smoothed and
with fresh thermal grease applied) of the 712/80's processor, but that
didn't help alone. The issue hit me after entering the password during
login.
Then I reconfigured half-duplex and tried again. The machine now
worked through the whole login and I could also do an `apt update`
without issues afterwards. Then I let it alone for about twenty
minutes and on return I did an `apt list --upgradable` which triggered
the issue again.
:-/It's possible flow control on the server port might help given that the
Some switches support a half-duplex back pressure form of flow control.
I'll try that now. According to the documentation my switch can create back-pressure as form of flow control.
Some switches support a half-duplex back pressure form of flow control.
I'll try that now. According to the documentation my switch can create back-pressure as form of flow control.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 64:05:36 |
| Calls: | 6,654 |
| Files: | 12,200 |
| Messages: | 5,331,763 |