This is an old revision of the document!
====== Michael Decker: Driver Development ====== ==== Week 6 ==== ---- === 9 July === A new branch, ''drivers6'' was created. This branch was merged with the mainline via ''git pull origin master''. This brought the GDB code into my tree. Experimenting with GDB, a segfault was reported following the point where gPXE was freezing during the second NIC boot. I ran a backtrace: <file> Program received signal SIGSEGV, Segmentation fault. alloc_memblock (size=96, align=<value optimized out>) at include/gpxe/list.h:64 64 __list_add ( new, head, head->next ); (gdb) backtrace #0 alloc_memblock (size=96, align=<value optimized out>) at include/gpxe/list.h:64 #1 0x00007cd1 in realloc (old_ptr=0x0, new_size=80) at core/malloc.c:265 #2 0x00007d2f in zalloc (size=96) at core/malloc.c:332 #3 0x0000814b in resolv (resolv=0x78a8, name=0xf "Ãë\t\017¾CÿèR", sa=0x33ad8) at core/resolv.c:260 #4 0x0000823b in xfer_open_named_socket (xfer=0x784c, semantics=208084, peer=0x33ad8, name=0x13356 "192.168.2.8", local=0x0) at core/resolv.c:389 #5 0x00005f64 in http_open_filter (xfer=0x12de8, uri=0x13324, default_port=80, filter=0) at net/tcp/http.c:501 #6 0x00012a70 in mtftp_uri_opener () #7 0x00012de8 in heap () #8 0x00005fc9 in http_open (xfer=0x60, uri=0xf) at net/tcp/http.c:527 #9 0x00000000 in ?? () </file> Not sure why the segfault occurred, although I do see the parameter to ''resolve'' is not valid. Marty recommended I install wireshark and take a look at what's happening. Additionally, testing at his end showed two different NICs failing iSCSI booting, but passing HTTP booting. I haven't tried iSCSI booting yet, so I'll need to set this up to recreate the errors he's seeing. In the meantime, analyzing wireshark output should show any problems with rx & tx during HTTP booting. I may also play with GDB a bit more to figure out what's going on, but currently I need to nail down the bug to something more specific.
