James Bottomley wrote: > On Mon, 2009-04-13 at 18:25 -0700, Matt Carlson wrote: > > On Mon, Apr 13, 2009 at 03:32:14PM -0700, James Bottomley wrote: > > > > > > ion:~# ethtool -e eth0 length 0x90 > > > Address Data > > > ---------- ---- > > > 0x00000000 0xaa > > > 0x00000001 0x55 > > > 0x00000002 0x99 > > > 0x00000003 0x66 > > > > Michael noticed that your NVRAM signature is byteswapped in > NVRAM. (!) > > That also explains why the driver is trying to obtain the > MAC address > > through NVRAM, rather than getting it from shared memory. > The device's > > bootcode is not working correctly. > > Um, well, this is a parisc: the device's boot code won't be > working at > all (parisc doesn't have open firmware boot). The values > might be laid > down by the platform IODC, but usually for add in cards, they're the > default initialise values the card comes up with. > Matt was referring to MIPS code that runs inside the MIPS core inside the TG3 chip. The code is loaded from NVRAM and will start running after chip reset. But I don't agree with Matt that the swapped NVRAM values were caused by bad MIPS code programmed in the NVRAM. I agree with DaveM that this appears to be a driver big-endian problem when reading the NVRAM. Can you run the same ethtool -e on 2.6.29 to confirm? Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
