Git commit: 52f6bbd8471893361f264d3749b3f8c78df224b2

I managed to get the .irq routine implemented. I'm not sure how to test this, so I'll ask on email. I hope to get another round of feedback from people after which I'll send a patch containing the driver.

Once that was done I did one of those things I hate enjoy so much: manual labor! My old PC was broken into pieces plus I had to go out and get some SATA cables (it had none) because I want to set up a development environment on it too. Since there was no room for it in my room, I had to move the furniture around a bit so it had somewhere to go. Eventually I managed to turn it on and it now boots into its' old OS. Tomorrow I'll format the disk and set up a new Linux distro.

Git commit: 1807a8d7b9ca412cb7fa72b457b30cbc33b3069a

So I managed to test the .irq routine today by chainloading undionly.kpxe and it doesn't work :(. It gives a timeout when trying to dhcp. The weird thing is, if I activate debugging then dhcp works. I'll ask about this tomorrow.

Finally, the old PC is set up and lspci revealed that the nVidia NIC I have has a CK804 Ethernet Controller, device id 0x0057, which is currently supported by Linux's forcedeth driver. On tomorrow's list are setting up a driver skeleton for the forcedeth driver and seeking some help on #etherboot regarding pcnet32's .irq.

me.away()

pcnet32 git commit: 94c29d96c34aaa97d22664c1f52ba0564d8c2894

forcedeth git commit: 5f415833099737de5af558892488930032a58caf

mdc helped me today to fix the bug I had in my .irq implementation. Well, it wasn't actually there, but in the .transmit, where I disabled the interrupts by mistake. Fixed, and now the .irq works too. I noticed that after chainloading UNDI the driver was really slow. Tomorrow I'll start digging on this and see how other drivers fare.

Also, I set up a basic skeleton for the new forcedeth driver. By the end of the week I want to contact the Linux driver devs and see if they can give me the documentation they had.

me.awayAgain()

Git commit: 930c8b5335125c6aaaf4c13863b92bfdf1b57549

Today was pretty much about testing. I still did not manage to find out why UNDI works so slow, but I did fix a bug that cleared some interrupt-enabling flags from CSR0 thanks to mdc's observation that I should watch the Linux driver's CSR0 accesses.

After that, I tested to see the difference between another driver's UNDI and normal modes. I tested by setting the ethernet1.virtualDev field in my vms .vmx file to “e1000”. The Intel PRO/1000 downloads an 100mb file in 29s in “normal” mode and in 56s under UNDI. That's approximately 2x slower in UNDI. Like I've mentioned before my pcnet32 driver gets the 100mb file in 39-45s in “normal” mode and in ~120s under UNDI.

Another thing I noticed today was how much the time it takes to download the file varies. Sometimes my pcnet32 driver would get the image in 26s, other times in 50s or more. I've noticed this behaviour in the e1000 driver too. Not too sure what the cause is.

Anyway, I'm determined to post a patch containing the driver tomorrow, even though it still has problems. I don't expect this to be accepted, the purpose is to expose it to more experienced eyes. Finally, I'll shoot an email to some of the forcedeth driver devs tomorrow regarding the docs.

Git commit: 5a3434ce23f524788d5eb9959628cfa1789f687b

Well, today was full of gpxe-esque events :). Meteger managed to trace a bug that was causing pxelinux.0 to fail booting an Ubuntu image. I managed to mix the buffer length and the length of the received message so the iobuf didn't get trimmed to the proper size which I suspect caused some bad data to be received.

The weekly meeting went well too, and it is a real pleasure to debug stuff together with other people. I have a lot of work to do on my debugging skills but luckily I have awesome people to learn from.

Like I've planned, I sent a patch containing the driver. I usually formatted small, one-commit patches, using git-format-patch so I wasn't sure what to do with the driver since it had multiple commits. Stefanha guided me towards git-send-email and git-rebase which successfully got the patch sent. Unfortunately, it isn't properly formatted since the diff between the old driver and the new one makes it hard to read. So the patch sending wasn't what I call a successful attempt, but the things that are learned the hard way are best remembered.

I've also sent an email to one of the forcedeth driver devs to see if he can part with the documentation. Regardless, I'll start working on the driver since I feel that I have gained a sufficient amount of insight into driver writing to understand the forcedeth driver only from its source code. Tomorrow I'll start working on .probe.