cremes' OpenDarwin Blog
See all the tasks and projects that I may or may not be currently working on for the OpenDarwin project at www.opendarwin.org

 



Project Downloads:

OpenDarwin & contributors:


My Other Projects:

External Links:




Click to see the XML version of this web page.

Click here to send an email to the editor of this weblog.

 

 

  Monday, February 16, 2004


Struggled most of the day trying to get the PNIC to work under darwin-x86. This code really had not been touched for about a year. When I last left it, I'm pretty sure it worked at 10/half. The machine I was testing it on then (PowerMac G4 533) was a nice little box. The machine I have now, a dual G5, doesn't have the right PCI slot to take the 5volt card so I can't test it there anymore.

It ain't working over in x86-land. By all appearances it is working, but nothing hits the wire. I can successfully download the setup frame, and the MII logic detects link up and down. It also successfully receives broadcast and multicast traffic. However, it won't transmit anything. Since it successfully sees the broadcasts, I know the packet byte flipping is working correctly (I use an IOMbufNaturalMemoryCursor which picks the natural byte-order of the host architecture... works great for all the other cards).

TX failure... I'm assuming this has something to do with the GPIO register. I was testing a 10/100 switch and it was writing 0x20 to CSR12. I switched back to using the 10/half hub and it went back to writing 0x34. My notes from a year ago say that is correct. I need to overhaul that logic to see if I can get this thing going. Right now in the log it prints that it is set for 10/half even when it was plugged in at 100/full. Argh.

Very frustrating. I'm stuck on my QT Component project and this one isn't faring much better. Can I get a brain transplant, cuz I'm just not smart enough to figure this shit out.

10:37:19 PM    comment []



Changed the static method for managing the primary interrupt filter so that I could override it in a subclass. This is the same technique I used for the IOInterruptEventSource and IOTimerEventSource methods, so I'm pretty comfortable with it.

It serves two functions. One, it gets rid of a ton of gcc warnings during compilation (I like things clean). Two, it allows me to override the primary interrupt filter in a subclass. I'm doing that right now to track down an ugly problem with the PNIC on x86.

It gets stuck in an interrupt loop, constantly calling the driver to handle a secondary interrupt. This must mean that the interrupt condition isn't being cleared by the primary interrupt filter, but it works just fine for the DEC2114x and ADMtek classes. Odd.

3:28:13 PM    comment []



I had a ton of trouble profiling the driver a couple of weeks ago. Shark would generate some information for me, but double-clicking on the offending routine name would cause it to jump to the wrong source code in the file. This frustrated me no end. I checked the search paths, I did clean builds, I reinstalled Shark... nothing cured the problem.

Today I was rereading an <a href="http://www.opendarwin.org/en/faq.php#chud2">entry I wrote for the OpenDarwin FAQ on performance and tuning</a>.  In a flash it occurred to me what I was doing wrong.

Here's how I was testing. I had a known, good copy of the driver sitting in /System/Library/Extensions. I would kextunload it. Next, I would copy my debug or test version to /tmp and kextload it from there. Then I'd run my performance test. The idea was that if the machine crashed or needed a reboot, /tmp gets blown out so the "bad" driver is erased, and the good driver will get loaded since it still lives at /S/L/E.

Here's the problem. Shark was loading the symbol file from the driver sitting in /S/L/E. It didn't know about the one sitting in /tmp. The one in /tmp was, at times, pretty radically modified from the stock version so it makes total sense that the symbols and source code line numbers no longer matched up in Shark.

Two ways to fix this. One, move the good version of the driver out of /S/L/E and do all testing there. This is a bad solution since a buggy, crashy driver could force me to boot to another partition to remove it (e.g. it crashes during boot). Second, edit the Shark preference file to point to the driver sitting in /tmp.

I like Option 2.

11:42:05 AM    comment []




Click here to visit the Radio UserLand website. © Copyright 2004 Chuck Remes.
Last update: 10/2/04; 11:47:59 AM.

February 2004
Sun Mon Tue Wed Thu Fri Sat
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29            
Jan   Mar