Kernel loaded

httpfs now works. It uses pxe_http code to open keep-alive connections to http-server. Also it ressurects it to life if connection is dead due server’s settings (e.g. timeout or exceeded max requests per connection). Need to think how to make requests optimal. Loader uses 4K buffers at request, may be I’ll add some sort of caching mechanism for httpfs to reduce count of requests to server.

So, it’s possible to use common commands of BTX such as ‘more’, ‘load’, ‘help’. I’ve played a lot with them while testing of http code, rather boring process. But after that one problem with interrupt handling in pxe_core was located. It seems, that end of interrupt is handled not correctly, so interrupt not occurs from time to time till some unrelated top pxe_core code finishes interrupt correctly. Problem is temporarily fixed by ignoring of __pxe_isr_occured flag and checking of available incoming frames in pxe_core_recv_packets() despite of value of this flag. Meanwhile TCP code was simplified by rewrtting it in pxe_tcp module, reducing code lines and function count. Testing showed it works identically to previous code, except one silly misprint, that was fixed in new variant of code.

Anyway, it’s possible to load modules, kernel and etc. It’s interesting that loader tries to load gzipped variants of files first, so it performs four requests to server. E.g. we need “loader.rc”, theese files will be requested: “loader.rc.gz.split”, “loader.rc.gz”, “loader.rc.split”, “loader.rc”. It was unexpected and exceeded limits of filters and connections tables, cause connections felt to TIME_WAIT state (keep-alived connection were actively closed by client. Need to try in nearest future sending of “Connection: close” field in header to make passive connection closing at closing of file), no new connections were possible to establish. Well, I’ve added opportunity to free connections structures in this state for establishing of new connections. It’s violates RFC, but helps keep relatively small amount of structures. If PXE_MAX_CONNECTIONS is set to big enough number, then TCP code behaviour is as expected in RFC.

After changing loader.rc to something very simple, my home made kernel was loaded and ‘lsmod’ showed a number of modules. But ‘boot’ command failed (hang or panic depending on which virtual machine and real machine were used). It was frustrating – result is practically visible, but yet goal not achieved. I’ve tried loading of RAM-drives, but also failed.

In bad mood of me normal loader.rc was started. The first surprise is that on VMWare machine I’m see normal booting process till time of mounting of root file system (which is unknown, cause not set by environment parameters in loader and /etc/fstab is empty in Apache’s DocumentRoot directory). Second surprise that another virtual machine hangs during loading of support.4th (according to Apache logs it’s read not completely, about 70-80%) and my real machine just reboots while reading same file. Rather suspicous :)
So next days I’ll be solving quest for finding why loading of support.4th, which have no nothing criminal in it, may cause such problems and exploring issue with lost somewhere interrupt.

Comments are closed.