On Mon, Apr 13, 2009 at 11:18:37AM -0700, James Bottomley wrote: > On Mon, 2009-04-13 at 11:13 -0700, Matt Carlson wrote: > > On Mon, Apr 13, 2009 at 11:04:26AM -0700, Kyle McMartin wrote: > > > On Mon, Apr 13, 2009 at 11:00:52AM -0700, Matt Carlson wrote: > > > > Hi James. I'd like to think about this some more before we apply it. I > > > > investigated this problem using a 5703 on a SPARC Ultra 10, and all my > > > > assumptions checked out. I don't dispute that you and Robin are having > > > > a problem. I just don't understand where the root cause of the problem > > > > is yet. Stay tuned. > > > > > > > > > > Did your card in the sparc have an openfirmware ROM? If so, it probably > > > used the ofw tree to obtain parameters instead of the card nvram... > > > > No, the test was run using a NIC. > > Possibly, then, the MAC comes from the MBOX, which looks correct? > > tg3_get_device_address() has four mechanisms to get the mac address > > 1. A sparc specific open firmware boot mac > 2. The card mac mbox > 3. the NVRAM (this is the failing one) > 4. a sparc specific default fallback if none of the above worked > > The mbox route doesn't have a memcpy, only the NVRAM one. > > James On this particular adapter, the MAC address would be obtained through shared memory. I had to modify the driver to force the code to obtain the MAC address through NVRAM. I printed both MAC addresses and they match. -- 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
