On 11.06.2018 13:12, Thomas Huth wrote: > 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. FWIW: I'm using the isolated libvirt network on an otherwise idle host, so it's unlikely that there's interference. If I find the time I'll have a look at the traffic. > > 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? > Yes, it was my bad. I used an older kernel with the following problem https://lkml.org/lkml/2017/3/13/683.
-- Regards, Viktor Mihajlovski