Sparc slowdown - problem identified...

Tillman tillman at seekingfire.com
Fri Aug 15 21:32:02 PDT 2003


On Fri, Aug 15, 2003 at 11:02:21AM -0600, Tillman wrote:
> On Fri, Aug 15, 2003 at 04:34:04PM +0200, Thomas Moestl wrote:
> > On Fri, 2003/08/15 at 08:00:56 -0600, Tillman wrote:
> > > Is OFW_NEWPCI where -CURRENT on Sparc is heading? I.e., if I enable it
> > > now and go through any needed reconfiguration will I be saving myself
> > > time in the future?
> > 
> > Yes.
> 
> Great, thanks for the info. I'll compile a new kernel with OFW_NEWPCI
> and try installing it over the weekend (compiling isn't fast at the
> moment ;-) ).

I can boot on the new kernel, but my hme interfaces don't seem to work
(I have 1 onboard and a 4-port card). I see this in dmesg:

hme1: error signaled, status=0x20001
(etc)
hme1: error signaled, status=0x30001eived, 100% packet loss
hme1: too may errors; not reporting any more

Here's my ifconfig:

hme0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 192.168.23.30 netmask 0xffffff00 broadcast 192.168.23.255
        ether 08:00:20:c6:7f:c7
        media: Ethernet autoselect (none)
        status: no carrier
hme1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 24.72.10.209 netmask 0xffffff00 broadcast 24.72.10.255
        ether 08:00:20:c6:7f:c7
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
hme2: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
        ether 08:00:20:c6:7f:c7
        media: Ethernet autoselect
hme3: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
        ether 08:00:20:c6:7f:c7
        media: Ethernet autoselect
hme4: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
        ether 08:00:20:c6:7f:c7
        media: Ethernet autoselect

Some of the dmesg that looks relevent:

pcib0: <U2P UPA-PCI bridge> on nexus0
pcib0: Sabre, impl 0, version 0, ign 0x7c0, bus A
DVMA map: 0xc0000000 to 0xc3ffffff
pci0: <OFW PCI bus> on pcib0
pcib1: <APB PCI-PCI bridge> at device 1.1 on pci0
pci1: <OFW PCI bus> on pcib1

and:

hme0: <Sun HME 10/100 Ethernet> mem 0xe0000000-0xe0007fff at device 1.1 on pci1
hme0: Ethernet address: 08:00:20:c6:7f:c7
miibus0: <MII bus> on hme0
nsphy0: <DP83840 10/100 media interface> on miibus0
nsphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto

and:

hme1: <Sun HME 10/100 Ethernet> mem 0x2800000-0x2807fff at device 0.1 on pci3
pcib3: slot 0 INTB is routed to irq 25
hme1: Ethernet address: 08:00:20:c6:7f:c7
miibus1: <MII bus> on hme1
ukphy0: <Generic IEEE 802.3u media interface> on miibus1
ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto

and:

arp: 192.168.23.3 is on hme0 but got reply from 00:10:4b:69:2a:86 on hme1
arp: 192.168.23.3 is on hme0 but got reply from 00:10:4b:69:2a:86 on hme1
arp: 192.168.23.3 is on hme0 but got reply from 00:10:4b:69:2a:86 on hme1

Any ideas? Is it possible that the hme interfaces are numbered in a
different order with the new kernel, similar to how the disk devices
could have been renumbered (but that wasn't an issue for me)?

I've reverted to the kernel.old in the meantime.

-T



More information about the freebsd-sparc64 mailing list