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
Last revision Both sides next revision
soc:2010:andreif:journal:week3 [2010/06/10 10:51]
andreif
soc:2010:andreif:journal:week3 [2010/06/13 13:58]
andreif
Line 30: Line 30:
  
 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. 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.
 +
 +==== Day 5 [ 11 Jun 2010 ] ====
 +
 +me.awayAgain()
 +
 +==== Day 6 [ 12 Jun 2010 ] ====
 +
 +Git commit: [[http://​git.etherboot.org/?​p=people/​andreif/​gpxe.git;​a=commit;​h=930c8b5335125c6aaaf4c13863b92bfdf1b57549|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.
 +
 +==== Day 7 [ 13 Jun 2010 ] ====
 +
 +Git commit: [[http://​git.etherboot.org/?​p=people/​andreif/​gpxe.git;​a=commit;​h=5a3434ce23f524788d5eb9959628cfa1789f687b|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.
 +

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