Re: Re: Have my PA8800 back online...
Hi all,
Regarding the kernel, the v4.13 series was pretty good on my rp3440. I've only run the v4.14.2 and
v4.14.3 for about 3 days. It seems the number of random segvs has increased again and I had one
stall:
INFO: task updatedb.mlocat:5610 blocked for more than 120 seconds.
Not tainted 4.14.3+ #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
updatedb.mlocat D 0 5610 5607 0x00000010
Backtrace:
[<00000000401636f0>] __schedule+0x318/0x650
[<0000000040163a84>] schedule+0x5c/0xe8
[<0000000040168f68>] schedule_timeout+0x1b8/0x218
[<0000000040164c48>] wait_for_common+0x140/0x228
[<0000000040164d54>] wait_for_completion+0x24/0x38
[<000000001cd27628>] xfs_buf_submit_wait+0x130/0x1e0 [xfs]
[<000000001cd2771c>] _xfs_buf_read+0x44/0xc8 [xfs]
[<000000001cd278a0>] xfs_buf_read_map+0x100/0x158 [xfs]
[<000000001cd7c890>] xfs_trans_read_buf_map+0xf8/0x2c8 [xfs]
[<000000001cd07918>] xfs_imap_to_bp+0x78/0x140 [xfs]
[<000000001cd08338>] xfs_iread+0xa8/0x2f8 [xfs]
[<000000001cd372b4>] xfs_iget+0x374/0xa28 [xfs]
[<000000001cd4603c>] xfs_lookup+0xac/0x160 [xfs]
[<000000001cd40708>] xfs_vn_lookup+0x70/0x110 [xfs]
[<0000000040304f90>] lookup_slow+0x108/0x248
This looks like a good opportunity to add some info about my experience
with v4.14.x (v4.14.2 to be exact, from Debian Ports) on my recently
acquired rp3440.
Unfortunately I wasn't yet able to get it to operate diskless like my
other hppa machines, so resorted to an on-disk installation to see if
the machine maybe has issues. I have performed this disk install with
the installer ISO from Adrian (the version prior to the recently (i.e.
today in the morning) uploaded version) - still with Linux v4.13.4 and
this lead to a working system.
But after installing v4.14.x and then trying to boot it, my rp3440
seemed to have locked up after the following messages:
```
[ 28.618056] io scheduler deadline registered
[ 28.618308] io scheduler cfq registered (default)
[ 28.618481] io scheduler mq-deadline registered
[ 28.623261] PDC Stable Storage facility v0.30
[ 28.671368] STI GSC/PCI core graphics driver Version 0.9b
[ 28.671984] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[ 28.708902] 0000:e0:01.1: ttyS0 at MMIO 0xfffffffff4050000 (irq = 73,
base_baud = 115200) is a 16550A
[ 28.731145] 0000:e0:01.1: ttyS1 at MMIO 0xfffffffff4050010 (irq = 73,
base_baud = 115200) is a 16550A
[ 28.731499] console [ttyS1] enabled
[ 28.732307] bootconsole [ttyB0] disabled
```
It didn't seem to have completed the Debian boot, at least it looked
like that, as the machine couldn't be reached via network afterwards
(even after I waited a few minutes and noticed disk activity in
between). The machine itself didn't seem to detect a problem, the system
LED stayed steady green.
UPDATE:
What I just noticed by comparing kernel output for v4.13.x and v4.14.x
is, that for v4.13.x it detects the following serial ports:
```
[ 28.882849] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[ 28.898720] 0000:e0:01.0: ttyS0 at MMIO 0xfffffffff4051000 (irq = 73,
base_baud = 115200) is a 16450
[ 28.934669] 0000:e0:01.1: ttyS1 at MMIO 0xfffffffff4050000 (irq = 73,
base_baud = 115200) is a 16550A
[ 28.935303] console [ttyS1] enabled
[ 28.935303] console [ttyS1] enabled
[ 28.935742] bootconsole [ttyB0] disabled
[ 28.935742] bootconsole [ttyB0] disabled
[ 28.963031] 0000:e0:01.1: ttyS2 at MMIO 0xfffffffff4050010 (irq = 73,
base_baud = 115200) is a 16550A
[ 28.984946] 0000:e0:01.1: ttyS3 at MMIO 0xfffffffff4050038 (irq = 73,
base_baud = 115200) is a 16550A
```
...but for v4.14.x only the following serial ports are detected:
```
[ 28.671984] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[ 28.708902] 0000:e0:01.1: ttyS0 at MMIO 0xfffffffff4050000 (irq = 73,
base_baud = 115200) is a 16550A
[ 28.731145] 0000:e0:01.1: ttyS1 at MMIO 0xfffffffff4050010 (irq = 73,
base_baud = 115200) is a 16550A
```
According to the addresses the order of the serial ports is quite
different with v4.14.x compared to older Linux kernels and the serial
console of the system used by the iLO MP is now at ttyS0 but was and is
assumed to be at ttyS1 by palo (for rp3440).
With the console argument changed manually to ttyS0 it now also works
with v4.14.x:
```
root@rp3440:~# uname -a
Linux rp3440 4.14.0-1-parisc64-smp #1 SMP Debian 4.14.2-1 (2017-11-30)
parisc64 GNU/Linux
```
No issues so far after 500 consecutive STREAM runs.
And just for the record, I'm using the latest firmware available for
PDC, BMC and iLO MP:
```
SYSREV
Current firmware revisions
MP FW : E.03.32
BMC FW : 03.53
System FW : 50.40
```
Regards,
Frank
Reply to: