Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
soc:2008:mdeck:journal:week7 [2008/07/10 11:56] mdeck |
soc:2008:mdeck:journal:week7 [2008/07/13 12:23] (current) mdeck |
||
|---|---|---|---|
| Line 128: | Line 128: | ||
| Thus, I now have nailed down at least //one// bug, and now I can determine what's going wrong. | Thus, I now have nailed down at least //one// bug, and now I can determine what's going wrong. | ||
| + | |||
| + | * [[http://git.etherboot.org/?p=people/mdeck/gpxe.git;a=commit;h=9f561a19282078cc0346487d2a2b34060e1a3f62|[Drivers-eepro100] Bug fixes]] | ||
| The end of ''ifec_tx_wake()'' performs different operations depending if the state of the CU is active or suspended. After some consideration, it seems if the CU is active, a RESUME should still be issued - this will cause the CU to re-read the current TCB's S-bit. Thus, after clearing that bit, the CU will continue on and process this newly appended transmit command. | The end of ''ifec_tx_wake()'' performs different operations depending if the state of the CU is active or suspended. After some consideration, it seems if the CU is active, a RESUME should still be issued - this will cause the CU to re-read the current TCB's S-bit. Thus, after clearing that bit, the CU will continue on and process this newly appended transmit command. | ||
| Line 185: | Line 187: | ||
| </file> | </file> | ||
| This ensures the suspend bit isn't cleared except in the ''ifec_tx_wake()'' routine. This line was redundant. | This ensures the suspend bit isn't cleared except in the ''ifec_tx_wake()'' routine. This line was redundant. | ||
| + | |||
| + | === 13 July === | ||
| + | |||
| + | In lieu of having iSCSI packet captures to look at, I decided to try booting over AoE. This involves sufficient driver activity that I hope to locate a bug via it. | ||
| + | |||
| + | Booting a Windows image over AoE got stuck at the Windows splash screen. I then tried booting this image using Safe Mode. Every .sys driver loads until it gets to aoe32.sys. The system freezes at this line. I don't know enough about the AoE driver to determine what could be causing this. | ||
| + | |||
| + | I then compiled and attempted the same AoE boot using the legacy eepro100 driver. The boot sequence was exactly the same, with the machine freezing once loading aoe32.sys. I'll need to get a working AoE image to test this properly. | ||
