I don't think that the seprom is set on SPARC systems so there is not MAC address in there to read. You need to read it from the appropriate OBP properties. Search for local-mac-address and CONFIG_SPARC in tulip_core.c Regards Richard > -----Original Message----- > From: ultralinux-owner@xxxxxxxxxxxxxxx > [mailto:ultralinux-owner@xxxxxxxxxxxxxxx] On Behalf Of Grant Grundler > Sent: 04 November 2007 19:03 > To: ultralinux@xxxxxxxxxxxxxxx > Cc: grundler@xxxxxxxxxxxxxxxx; kovedi@xxxxxxxxx > Subject: fwd: [Bug 9106] Sun Fire v100 dmfe driver bug > > http://bugzilla.kernel.org/show_bug.cgi?id=9106 > > I have two possible reasons why dmfe driver is reading zeros > from the seprom for the MAC address. > 1) IO port space routing is fu-bar - ie we are only able to > talk to the chip's config space. > 2) outl() is implemented as a postable MMIO write (semantics > demand outl be non-postable). > > Pursueing (2) for a bit, I looked at > linux-2.6.22.9/include/asm-sparc64/io.h: > ... > 74 static __inline__ void _outl(u32 l, unsigned long addr) > 75 { > 76 __asm__ __volatile__("stwa\t%r0, [%1] %2\t/* pci_outl */" > 77 : /* no outputs */ > 78 : "Jr" (l), "r" (addr), "i" > (ASI_PHYS_BYPASS_EC _E_L)); > 79 } > ... > 86 #define outl(__l, __addr) (_outl((u32)(__l), > (unsigned long)(__addr))) > ... > > > Is "stwa" a posted write? > I'm also open to ideas of what else might be wrong in dmfe.c driver. > > > The initial symptom seems related to > linux-2.6.22.9/drivers/net/tulip/dmfe.c: > ... > 1576 static u16 read_srom_word(long ioaddr, int offset) > 1577 { > 1578 int i; > 1579 u16 srom_data = 0; > 1580 long cr9_ioaddr = ioaddr + DCR9; > 1581 > 1582 outl(CR9_SROM_READ, cr9_ioaddr); > 1583 outl(CR9_SROM_READ | CR9_SRCS, cr9_ioaddr); > 1584 > 1585 /* Send the Read Command 110b */ > 1586 SROM_CLK_WRITE(SROM_DATA_1, cr9_ioaddr); > 1587 SROM_CLK_WRITE(SROM_DATA_1, cr9_ioaddr); > 1588 SROM_CLK_WRITE(SROM_DATA_0, cr9_ioaddr); > ... > > where SROM_CLK_WRITE is defined as: > ... > 175 #define SROM_CLK_WRITE(data, ioaddr) \ > 176 outl(data|CR9_SROM_READ|CR9_SRCS,ioaddr); \ > 177 udelay(5); \ > 178 outl(data|CR9_SROM_READ|CR9_SRCS|CR9_SRCLK,ioaddr); \ > 179 udelay(5); \ > 180 outl(data|CR9_SROM_READ|CR9_SRCS,ioaddr); \ > 181 udelay(5); > > obviously, if outl() is posted, the udelay() won't be respected > and there are already two writes in flight when the CPU gets > to line 1586. > > > thanks, > grant > > ----- Forwarded message from bugme-daemon@xxxxxxxxxxxxxxxxxxx ----- > > X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-26) on > colo.lackof.org > X-Spam-Level: > X-Spam-Status: No, score=0.9 required=5.5 > tests=BAYES_40,FORGED_RCVD_HELO, > NO_REAL_NAME autolearn=no version=3.1.4 > Subject: [Bug 9106] Sun Fire v100 dmfe driver bug > X-Bugzilla-Product: Drivers > X-Bugzilla-Severity: high > X-Bugzilla-Keywords: > X-Bugzilla-Reason: CC AssignedTo > X-Bugzilla-Component: Network > To: grundler@xxxxxxxxxxxxxxxx > From: bugme-daemon@xxxxxxxxxxxxxxxxxxx > X-MIMEDefang-Filter: lf$Revision: 1.188 $ > X-Scanned-By: MIMEDefang 2.53 on 207.189.120.14 > X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lackof.org > > http://bugzilla.kernel.org/show_bug.cgi?id=9106 > > > > > > ------- Comment #4 from kovedi@xxxxxxxxx 2007-10-08 00:29 ------- > I try to use the udelay(5) after line 1583 and 1596 but the error > coming again after reboot. > > the devices not have mac adresses > > [ 69.450854] eth0: Davicom DM9102 at pci0000:00:0c.0, > 00:00:00:00:00:00, irq 9. > [ 69.477577] eth1: Davicom DM9102 at pci0000:00:05.0, > 00:00:00:00:00:00, irq 10. > > and always resetting the network devices. > > [ 84.923730] eth0: Tx timeout - resetting > [ 86.923705] eth0: Tx timeout - resetting > [ 88.923650] eth0: Tx timeout - resetting > [ 90.923636] eth0: Tx timeout - resetting > [ 92.923587] eth0: Tx timeout - resetting > > > -- > Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is. > You are the assignee for the bug, or are watching the assignee. > > ----- End forwarded message ----- > - > To unsubscribe from this list: send the line "unsubscribe > ultralinux" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > - To unsubscribe from this list: send the line "unsubscribe ultralinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html