Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
soc:2010:andreif:journal:week7 [2010/07/08 08:46]
andreif
soc:2010:andreif:journal:week7 [2010/07/12 09:37] (current)
andreif
Line 63: Line 63:
  
 After adding a host configuration in the .conf, the server finally replied with a DHCP OFFER packet. Still, the NIC remained silent, so now there probably are issues in RX. After adding a host configuration in the .conf, the server finally replied with a DHCP OFFER packet. Still, the NIC remained silent, so now there probably are issues in RX.
 +
 +==== Day 5 [ Fri 9 Jul 2010 ] ====
 +
 +me.away()
 +
 +==== Day 6 [ Sat 10 Jul 2010 ] ====
 +
 +Git commit: [[http://​git.etherboot.org/?​p=people/​andreif/​gpxe.git;​a=commit;​h=7b189803f76097d4b6b47bb5b90146259b7c8834|7b189803f76097d4b6b47bb5b90146259b7c8834]]
 +
 +Yet Another Debugging Session. Managed to fix more bugs, still not working properly.
 +
 +Bugs:
 +  * When allocating rx descriptors,​ was using the original descriptor format instead of the extended one
 +  * I was not sending received packets to the upper layers correctly. Used iob_put and fixed a bug where a NULL iobuf would be netdev_rx-ed
 +  * This one was the most difficult to fix. Last time, I left off with the server replying with a DHCP OFFER packet and the NIC remaining silent after that. I thought it was an RX issue. Still, after finding and fixing some RX bugs, the problem still remained. Running out of ideas, I tried sending another packet to the NIC (aka, not a DHCP OFFER). Lo and behold, an ARP packet was received properly by the NIC. The destination address of the ARP packet was 255.255.255.255. The DHCP OFFER destination address was a unicast address. Clearly, the NIC did unwanted filtering. Digging through the registers I set the NIC in promiscuous mode and it replied to the DHCP server.{{:​soc:​2010:​andreif:​journal:​forcedet-buggy1.png?​1000|forcedeth driver first packets}}
 +  * Finally got NV_RX_AVAIL and NV_TX_VALID right
 +
 +Eventually, the above process stops with an TX overflow error. The NIC is not sending out packets properly, even though the flaglen field is marked with NV_TX_VALID. I fiddled with the code some more and right now it does not send packets at all (sometimes it does, sometimes it sends the first two DISCOVER packets but the server does not reply). Also, notice in the above picture that there are some malformed-packets (the white ones). I've yet to figure out what is causing these issues.
 +
 +
 +==== Day 7 [ Sun 11 Jul 2010 ] ====
 +
 +Git commit: [[http://​git.etherboot.org/?​p=people/​andreif/​gpxe.git;​a=commit;​h=d6dd69ea626d2033f51f18673947148b63530087|d6dd69ea626d2033f51f18673947148b63530087]]
 +
 +The only significant improvement made today was that now the driver consistently transmits packets (eventually stopping with an overflow error)
 +
 +Bugs:
 +  * I started by comparing the PHY register values with the old driver. One of the registers had a different value than expected and this was because I forgot to initialize a local variable in the ''​phy_init()''​ routine.
 +  * I also forgot to pad small packets. Used iob_pad for this.
 +  * Comparing the flaglen field of tx packets I noticed that the old driver has an additional bit set. Setting it didn't make any difference but I am keeping it for now and will try to remove it later after the driver works.
 +
 +I got some good suggestions in today'​s meeting regarding debugging so I'll try them out tomorrow.

QR Code
QR Code soc:2010:andreif:journal:week7 (generated for current page)