Dear Helge,

some time ago I noticed a minor issue with palo (confirmed with v2.0 but
maybe already existing in earlier versions) and finally find the time to
report it:

When booting a rp3440 and interacting with IPL or booting a 712/80 with
`bo [...] isl` an then waiting at the palo prompt for a few minutes or
so before actually changing parts of the kernel command line and boot
(with `b`) or just boot, the boot process seems to hang for minutes
before the machine is reset instead of booting the actual kernel.

Example (rp3440):
```
[...]
Main Menu: Enter command or menu > bo
Interact with IPL (Y, N, or Cancel)?> y

Booting...
Boot IO Dependent Code (IODC) revision 4


HARD Booted.
palo ipl 2.00 http://www.parisc-linux.org - Mon, 01 Jan 2018 21:07:58 +0100

Boot image contains:
0/vmlinux64 3937664(0) bytes @ 0xc000
0/ramdisk 4347450 bytes @ 0x3cd800

Information: No console specified on kernel command line. This is normal.
PALO will choose the console currently used by firmware (serial).
WARNING: Found rp34x0 machine. Older Linux kernel may need console=ttyS1. Current command line:
0/vmlinux HOME=/ root=/dev/ram initrd=0/ramdisk TERM=vt102 console=ttyS0
0: 0/vmlinux
1: HOME=/
2: root=/dev/ram
3: initrd=0/ramdisk
4: TERM=vt102
5: console=ttyS0

<#> edit the numbered field
'b' boot with this command line
'r' restore command line
'l' list dir
'x' reset and reboot machine
? 0
<waited a few minutes before changing `0` to `b`>
? b

Command line for kernel: 'HOME=/ root=/dev/ram TERM=vt102 console=ttyS0 palo_kernel=0/vmlinux'
Selected kernel: /vmlinux from partition 0
Selected ramdisk: /ramdisk from partition 0
Warning: kernel name doesn't end with 32 or 64 -- Guessing... Choosing
64-bit kernel
<multiple minutes in between without any outpout>
pdc_iodc_bootin() died during seekread

Resetting machine.
```

The following should actually happen after issuing `b`:
```
[...]
Command line for kernel: 'HOME=/ root=/dev/ram TERM=vt102 console=ttyS0 palo_kernel=0/vmlinux'
Selected kernel: /vmlinux from partition 0
Selected ramdisk: /ramdisk from partition 0
Warning: kernel name doesn't end with 32 or 64 -- Guessing... Choosing
64-bit kernel
ELF64 executable

Entry 000e0000 first 000e0000 n 2
Segment 0 load 000e0000 size 1080 mediaptr 0x1000
Segment 1 load 01300000 size 3922892 mediaptr 0x2000
Loading ramdisk 4347450 bytes @ 3fbc9000...
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

Uncompressing ...
Booting kernel ...
[ 0.000000] Linux version 4.16.0-2-parisc64-smp (debian-kernel@lists.debian.org) (gcc version 7.3.0 (GCC)) #1 SMP Debian 4.16.12-1 (2018-05-27)
[...]
```

Output and result are practically the same on the 712/80.

As said earlier, it's no big problem, but one shouldn't leave for making
a tea or so when planning to interact with IPL. :-)

Regards,
Frank

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

Hi Helge,

On 12/7/18 20:44, Helge Deller wrote:

I think this can happen e.g. if you boot from Network via TFTP.

First the firmware IODC opens network connection and asks the tftpboot server to provide the file. The first part of the file has the palo boot code which is then executed.

So the firmware IODC doesn't download the whole lifimage but just sort
of "opens" it and starts the first part that contains palo?

When palo has started, it rewinds the file to the start and reloads the first sectors to get the offsets for vmlinux and ramdisk.

And palo actually doesn't download the lifimage, but just operates on a
sort of file descriptor the firmware IODC provides to find the offsets.
And then keeps the lifimage sort of "open" until a user continues to boot.

Sorry if I repeat things, I thought it would work totally different.
Actually I didn't know, that it was possible with TFTP, to open a remote
file and operate on it as if it was local.

After that it jumps to the loop which interacts with the user until he pressed "b"
to continue booting.

If you wait a few minutes until you continue booting, I assume
the tftpboot server (and the parisc box) will kill the network
connection in the meantime. That's the reason why you see:

<multiple minutes in between without any outpout>
pdc_iodc_bootin() died during seekread

seekread() is the rewind-function and pdc_iodc_bootin() is the palo
function which reads in the bytes.

So, I don't think there is much in palo what can be done about that.

Could one "close" the lifimage and "reopen" it after a user issues `b`?

Have you seen this issue when booting from hard disc too?

I don't boot from HDDs that often, but will give that a try. This can
take some time if I can't find an old on-disk installation to use and
have to recreate one.

Thanks for the background information
Cheers,
Frank

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

Hi Frank,

On 07.12.18 19:42, Frank Scheiner wrote:

some time ago I noticed a minor issue with palo (confirmed with v2.0
but maybe already existing in earlier versions) and finally find the
time to report it:

When booting a rp3440 and interacting with IPL or booting a 712/80
with `bo [...] isl` an then waiting at the palo prompt for a few
minutes or so before actually changing parts of the kernel command
line and boot (with `b`) or just boot, the boot process seems to hang
for minutes before the machine is reset instead of booting the actual
kernel.

Example (rp3440):
```
[...]
Main Menu: Enter command or menu > bo
Interact with IPL (Y, N, or Cancel)?> y

Booting...
Boot IO Dependent Code (IODC) revision 4

HARD Booted.
palo ipl 2.00 http://www.parisc-linux.org - Mon, 01 Jan 2018 21:07:58 +0100

Boot image contains:
    0/vmlinux64 3937664(0) bytes @ 0xc000
    0/ramdisk 4347450 bytes @ 0x3cd800

Information: No console specified on kernel command line. This is normal. PALO will choose the console currently used by firmware (serial).
WARNING: Found rp34x0 machine. Older Linux kernel may need console=ttyS1. Current command line:
0/vmlinux HOME=/ root=/dev/ram initrd=0/ramdisk TERM=vt102 console=ttyS0
 0: 0/vmlinux
 1: HOME=/
 2: root=/dev/ram
 3: initrd=0/ramdisk
 4: TERM=vt102
 5: console=ttyS0

<#>    edit the numbered field
'b'    boot with this command line
'r'    restore command line
'l'    list dir
'x'    reset and reboot machine
? 0
<waited a few minutes before changing `0` to `b`>
? b

Command line for kernel: 'HOME=/ root=/dev/ram TERM=vt102 console=ttyS0 palo_kernel=0/vmlinux'
Selected kernel: /vmlinux from partition 0
Selected ramdisk: /ramdisk from partition 0
Warning: kernel name doesn't end with 32 or 64 -- Guessing... Choosing 64-bit kernel
<multiple minutes in between without any outpout>
pdc_iodc_bootin() died during seekread

Resetting machine.
```

The following should actually happen after issuing `b`:
```
[...]
Command line for kernel: 'HOME=/ root=/dev/ram TERM=vt102 console=ttyS0 palo_kernel=0/vmlinux'
Selected kernel: /vmlinux from partition 0
Selected ramdisk: /ramdisk from partition 0
Warning: kernel name doesn't end with 32 or 64 -- Guessing... Choosing 64-bit kernel
ELF64 executable

Entry 000e0000 first 000e0000 n 2
Segment 0 load 000e0000 size 1080 mediaptr 0x1000
Segment 1 load 01300000 size 3922892 mediaptr 0x2000
Loading ramdisk 4347450 bytes @ 3fbc9000...
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

Uncompressing ...
Booting kernel ...
[    0.000000] Linux version 4.16.0-2-parisc64-smp (debian-kernel@lists.debian.org) (gcc version 7.3.0 (GCC)) #1 SMP Debian 4.16.12-1 (2018-05-27)
[...]
```

Output and result are practically the same on the 712/80.

As said earlier, it's no big problem, but one shouldn't leave for making a tea or so when planning to interact with IPL. :-)

I think this can happen e.g. if you boot from Network via TFTP.

First the firmware IODC opens network connection and asks the tftpboot server to provide the file. The first part of the file has the palo boot code which
is then executed.
When palo has started, it rewinds the file to the start and reloads the first sectors to get the offsets for vmlinux and ramdisk.
After that it jumps to the loop which interacts with the user until he pressed "b"
to continue booting.

If you wait a few minutes until you continue booting, I assume
the tftpboot server (and the parisc box) will kill the network
connection in the meantime. That's the reason why you see:

<multiple minutes in between without any outpout>
pdc_iodc_bootin() died during seekread

seekread() is the rewind-function and pdc_iodc_bootin() is the palo
function which reads in the bytes.

So, I don't think there is much in palo what can be done about that.

Have you seen this issue when booting from hard disc too?

Helge

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

Hi Frank,

On 07.12.18 21:15, Frank Scheiner wrote:

On 12/7/18 20:44, Helge Deller wrote:

I think this can happen e.g. if you boot from Network via TFTP.

First the firmware IODC opens network connection and asks the tftpboot server
to provide the file. The first part of the file has the palo boot code which >> is then executed.

So the firmware IODC doesn't download the whole lifimage but just
sort of "opens" it and starts the first part that contains palo?

Yes.
Firmware loads just the "lifimage" part.
The first sector holds information for firmware where palo code starts and how long it is.
This code is loaded at some random address into memory and executed.
palo then loads the kernel & initrd later.

When palo has started, it rewinds the file to the start and reloads the first
sectors to get the offsets for vmlinux and ramdisk.

And palo actually doesn't download the lifimage, but just operates on
a sort of file descriptor the firmware IODC provides to find the
offsets.

Yes.

And then keeps the lifimage sort of "open" until a user
continues to boot.

Yes.

Sorry if I repeat things, I thought it would work totally different.
Actually I didn't know, that it was possible with TFTP, to open a
remote file and operate on it as if it was local.

TFTP doesn't allow to "open" some random remote file.
It just gets one file, and can rewind it, but not select another file.
It's like booting from a tape drive which is emulated by this file.
You can rewind to the start of the tape (and seek to another position of the tape),
but not directly choose another file.

After that it jumps to the loop which interacts with the user until he pressed "b"
to continue booting.

If you wait a few minutes until you continue booting, I assume
the tftpboot server (and the parisc box) will kill the network
connection in the meantime. That's the reason why you see:
 

<multiple minutes in between without any outpout>
pdc_iodc_bootin() died during seekread

seekread() is the rewind-function and pdc_iodc_bootin() is the palo
function which reads in the bytes.

So, I don't think there is much in palo what can be done about that.

Could one "close" the lifimage and "reopen" it after a user issues `b`?

No, if you close it, it's gone.
The TFTPserver will then just close the network connection.

  Have you seen this issue when booting from hard disc too?

I don't boot from HDDs that often, but will give that a try. This can
take some time if I can't find an old on-disk installation to use and
have to recreate one.

Ok.

Helge

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

Dear Helge,

thanks for the clarifications.

On 12/7/18 22:28, Helge Deller wrote:

  Have you seen this issue when booting from hard disc too?

I don't boot from HDDs that often, but will give that a try. This can
take some time if I can't find an old on-disk installation to use and
have to recreate one.

Ok.

Actually I needed to recreate an on-disk installation but that was a
good opportunity to test the latest installer image.

And as you expected there were no issues both when booting from the
installer CDROM and a HDD even with 10 minutes without interaction at
the respective palo prompts.

Just an idea regarding network boot with TFTP: Could it work for palo to regularly rewind and/or seek in the downloaded file as long as no user interaction happeds, so the TFTP server is forced to keep the connection
alive?

Maybe a little too much of an effort to solve such a minor issue.

Cheers,
Frank

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

On 10.12.18 21:34, Frank Scheiner wrote:

Dear Helge,

thanks for the clarifications.

On 12/7/18 22:28, Helge Deller wrote:

   Have you seen this issue when booting from hard disc too?

I don't boot from HDDs that often, but will give that a try. This can
take some time if I can't find an old on-disk installation to use and
have to recreate one.

Ok.

Actually I needed to recreate an on-disk installation but that was a good opportunity to test the latest installer image.

And as you expected there were no issues both when booting from the installer CDROM and a HDD even with 10 minutes without interaction at the respective palo prompts.

Just an idea regarding network boot with TFTP: Could it work for palo to regularly rewind and/or seek in the downloaded file as long as no user interaction happeds, so the TFTP server is forced to keep the connection alive?

Good idea. I'll check if I can add that. Shouldn't be too hard.

Helge

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