====== Differences ====== This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision | |||
|
soc:2008:mdeck:journal:week6 [2008/07/03 13:44] mdeck |
soc:2008:mdeck:journal:week6 [2008/07/05 11:05] (current) mdeck |
||
|---|---|---|---|
| Line 20: | Line 20: | ||
| The 82559 now appears to operate properly under normal conditions. However, I still have a problem if I boot the system with both cards, and the first card fails to boot. The second card causes a triple fault around when the http get is being performed. I haven't tested the legacy driver in such a double-booting situation, so I'm not sure if there are any special hardware issues to consider in this setup. | The 82559 now appears to operate properly under normal conditions. However, I still have a problem if I boot the system with both cards, and the first card fails to boot. The second card causes a triple fault around when the http get is being performed. I haven't tested the legacy driver in such a double-booting situation, so I'm not sure if there are any special hardware issues to consider in this setup. | ||
| + | |||
| + | === 5 July === | ||
| + | |||
| + | The **debugging** continues. | ||
| + | |||
| + | I tested the legacy eepro100 driver with two 8255x PCI cards installed in my target system. Only one card had the network cable attached at a time. gPXE acted as if only one card was installed, a behavior which differed from the new driver. Near the [[http://git.etherboot.org/?p=people/mdeck/gpxe.git;a=blob;f=src/drivers/net/eepro100.c;h=f746976add6f53a0bf39201e30b8848c286b13b4;hb=c899bdc5a823e623b3e8f7598a7f77d65dcf2d2c#l765|end of the probe routine]] of the legacy driver: | ||
| + | <file> | ||
| + | 765 if (!(mdio_read(eeprom[6] & 0x1f, 1) & (1 << 2))) { | ||
| + | 766 printf("Valid link not established\n"); | ||
| + | 767 eepro100_disable(nic); | ||
| + | 768 return 0; | ||
| + | 769 } | ||
| + | </file> | ||
| + | I commented out lines 767 & 768 and re-tested. This time, gPXE did not attempt to boot both cards. The original, legacy driver used common global data which would make these tests fruitless, nonetheless. | ||
| + | |||
| + | It seems likely there is //something// wrong with the driver code which is causing a failure after the first boot attempt. In a previous journal entry, I alluded to a possible hardware issue because all global state data for each driver instance is located within a ''struct ifec_private'', created with ''alloc_etherdev()'' in ''ifec_pci_probe()''. The only globally-defined data is ''ifec_cfg'', which is only read from when initializing the ''malloc_dma()''ed configure command. | ||
| + | |||
| + | This routine is called two times in sequence when gPXE boots, as each card is probed. This allocation should completely separate the state of each card. The only difference between the second card's booting sequence from a boot without the first boot attempt is a time delay. | ||
| + | |||
| + | There is a short duration while the first card attempts to network boot. After this period, the second card is attempted. Any other changes in the state of the machine should be dependent on other parts of gPXE outside of the driver code. | ||
| + | |||
| + | Perhaps some [[:dev:gdbstub|GDB debugging]] is in order? | ||
