Git commit: a8e9adfd4a8e3775c227a5f8f8138ef9d2a9d922

I started out today by creating a new local branch and removing any non-critical code, constantly comparing what I had with the old driver. Eventually I reached a point where the new driver was very very similar to the old one, yet it still didn't work. I then remembered that Marty suggested that there might be alignment issues. And indeed there were. Using malloc_dma() and an alignment of 32 got the driver working and I finally booted a PXELINUX + DSL combo. Yay :)

Tomorrow I'll post some speed comparisons between the new and the old driver and start cleaning up the code.

No coding today, just some tests.

I ran both the old driver and the new one and got the following results ( the test downloads an 100mb image 5 times ):

The new driver does not perform better than the old one does, on the contrary. When I'll start cleaning up the code, I'll also try and optimize to get better performance.

Also, there is probably a bug in the driver since the last image was downloaded in over 60 seconds. Luckily, this behaviour is deterministic making it easier to fix. Plus, I saved the Wireshark dumps and I think they will help too.

I'll spend the rest of the day refreshing my TCP knowledge, I think it'll help when looking at the packet dumps.

me.rest()

Git commits:

1. 08fe740cba24f1a08bd1b236352ac1c912d78b4c
2. 2efaf9346b732409fbc5c1b2b73f8379b58fe12d
3. 3b6906c87fe07f375b513540c4ea45c6a8f068c0
4. a1ab8c074f968c60de95f316a779f53b4e746fb8

Cleanup time!

Initally I wanted to have a commit for each core routine but that didn't pan out since a change in one routine meant changing some .h variables which influenced other pieces of code.

[1] I started out with cleaning up .probe which also meant removing a lot of unnecessary variables (related to VLANs, MSIs, etc.), plus a lot of code being removed. In the end, .probe turned out pretty good.

[2] I had the most difficult time with the .open routine. It doesn't lend itself very well to organizing since most of it is just writing to all sorts of registers, and the related writes are usually only 3 or 4 which doesn't make them good candidates for a separate routine. Unwillingly I also changed a lot of the tx and rx code here. It is after this commit that the driver stopped having the bug I mentioned two days ago. It does now get the 100mb image in 12/11/11/11/11s consistently, just like the old driver.

[3] .close wasn't finished, I still had to cleanup the rings and deallocate any used memory. Also, .remove wasn't complete.

[4] I got .irq done, and also did a couple of other small fixes. Unfortunately, the driver does not work when chaining with undionly.kpxe for now. I have yet to debug this issue.

A few more iterations and I think I'll be happy with how the driver turns out :)

Git commit: 10fbb07b420d9db0edb2b1f7cb4430f76aba7977

The goal for today was to get the driver working under UNDI. At first I was a little discoraged because the IRQ enabling/disabling was done exactly like in the Linux driver. After printing out several debug messages and trying to figure it out I noticed the following thing: when calling .open after chaining undionly.kpxe, the MII registers had different values, plus the PHY complained that there was no link found. I started analyzing the registers to see what might cause the issue. After a bit of struggling I figured out that I was powering down the PHY in .close and this was what was causing the problem. Removing the related code got the driver running under UNDI.

I haven't tested it yet but I think that by waiting for the PHY to power up in .open the driver might work even when powering down the PHY in .close. Currently, the driver just sets the corresponding bit in the MII_BMCR register to power up the phy and moves on.

Anyway, now the driver works under UNDI and I've also sent an RFC patch to the mailing list. I hope that sometime in the beginning of the next week, after receiving feedback, I can get a proper patch up.

Git commits:

1. f375adb4608c684c019b424c10f671d02dc91bc1
2. e9b555e95177fe3b63d896bec6c543344da4ee10

Busy day today.

I started by setting up rom-o-matic for the new driver. Unfortunately, the server I have access to did not have syslinux installed. I proceeded to compile syslinux from sources, only to find out that I need nasm. I could not reach the server admin so Stefan set one up for me. Thanks Stefan!

After that, I've cleaned up the code further, removed some code that was never reached, along with some unused variables. I started digging into how I might solve link state, and got a look at the phantom driver. I implemented a similar solution in mine. Stefan suggested that another approach would be to use currticks() so I check link state related to time, not to the number of times .poll gets called. He mentioned that it might be slower since currticks does switch to real mode. For consistency with the other driver, and because of the possibility that it might be slower, I remained to my original solution. I will try to use currticks too, just to see the exact timing.

The next issue was the reversed MAC address issue. Stefan said that since we are in promiscuous mode anyway, we can stop writing the correct MAC address back in the NIC's registers. The problem with this approach is that there might be frames that could reach the upper layers and cause trouble. I implemented some simple filtering code in the driver that checks if the destination MAC address is a local address and that is consistent with the NIC's MAC address. Broadcast and multicast frames are thus still accepted. We only reject unicast addresses that are not for the NIC. Contrary to my expectations, the added code did not influence the driver's download times. After _both_ (link state + MAC) of the updates I now get: 12/12/12/12/13 seconds when fetching 5 100mb images. This is ~ 1s worse than the previous 12/11/11/11/11 but the MAC correctness and link state totally make up for the lost time.

Since we now don't have to write the correct MAC address to the NIC's registers, some code has been removed and we don't have to remember the original MAC address either. This, along with the elimination of a few other variables, resulted in a smaller private structure.

All in all, this was a good day :)

Tomorrow I'll send a new email on the mailing list, including the rom-o-matic info and the updated driver.

Not much going on today, posted the updated patch and added people that have previously contributed to the driver to the CC list, perhaps they can help with testing. Also, established with Stefan that I will work next on improving gPXE's multiboot support so it can be used with Xen, Solaris and VMware ESXi.