On 11.06.2018 11:08, Viktor VM Mihajlovski wrote: > On 07.06.2018 14:22, Thomas Huth wrote: >> This patch series adds pxelinux.cfg-style network booting to the s390-ccw >> firmware. The core pxelinux.cfg loading and parsing logic has recently >> been merged to SLOF, so these patches now just have to make sure to call >> the right functions to get the config file loaded and parsed. Once this is >> done, the kernel and initrd are loaded separately, and are then glued >> together in RAM. >> >> v2: >> - Update SLOF submodule now that the git mirror is in sync again >> - Last parameter to tftp_get_error_info() must not be NULL >> - Check CC when calling STSI, and use a #define for the UUID offset >> - Only support files with the magic "# pxelinux" string comment when >> trying to guess the contents of a file that has been downloaded via >> the "bootfile" DHCP parameter. This is just for developers' convenience, >> the official way to specify pxelinux.cfg files is to use the DHCP >> options 209 and 210 instead. >> >> Thomas Huth (4): >> roms: Update SLOF submodule to current status >> pc-bios/s390-ccw/net: Update code for the latest changes in SLOF >> pc-bios/s390-ccw/net: Add support for pxelinux-style config files >> pc-bios/s390-ccw/net: Try to load pxelinux.cfg file accoring to the >> UUID >> >> pc-bios/s390-ccw/netboot.mak | 9 +- >> pc-bios/s390-ccw/netmain.c | 226 >> +++++++++++++++++++++++++++++-------------- >> roms/SLOF | 2 +- >> 3 files changed, 162 insertions(+), 75 deletions(-) >> > I tested the series both with a self-created pxelinux.0 blob (to verify > backward compatibility) and without an existing pxelinux.0 file (to > force the standard pxelinux pattern). Both worked as expected, although > the built-in search took significantly longer (timeout?). > > Tested-by: Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com>
Thanks a lot for the testing! Hmm, I've got no real clue why there should be a big difference in the amount of time here ... is there maybe a lot of unrelated broadcast network traffic from other hosts going on in that network where you've tested it? It could be that the virtio-net driver of the s390-ccw bios can not deal with that situation very well yet. You could try to increase the "64" in virtio_net_init() in pc-bios/s390-ccw/virtio-net.c to see whether it makes a difference. Or if you've got some spare time, could you maybe run Wireshark on the server side to have a look at the time-stamps of the related packets, and to see whether there are duplicated TFTP read requests? This could indicate that the firmware missed a packet and thus ran into a timeout. Thomas PS: After I posted v1 of the patch set, you reported on IRC that you saw a problem with a corrupted initrd download or something similar. Is that problem now fixed for you?
