* Re: natsemi.c failure in 2.4.6
@ 2001-07-06 10:56 Studierende der Universitaet des Saarlandes
2001-07-06 11:40 ` Daniel A. Nobuto
0 siblings, 1 reply; 4+ messages in thread
From: Studierende der Universitaet des Saarlandes @ 2001-07-06 10:56 UTC (permalink / raw)
To: Daniel A. Nobuto; +Cc: linux-kernel
> Found that in 2.4.6, Natsetmi card I have doesn't receive
> traffic anymore. It worked in 2.4.5, though.
>
> The natsemi card is forced to 10/half via mii-diag at boot,
> and given a different MAC address (due to some problems I had with
> the original MAC address and netbooting a sparc). Forcing it to
> 100/full didn't work, either.
Could you try what happens without any special options? Default MAC
address, without mii-diag.
> Basic mode control register 0x2100: Auto-negotiation disabled, with
> Speed fixed at 100 mbps, full-duplex.
> [PC Linux 2.4.6] <--> p10/100 hub] <--> [SS4 NetBSD 1.5]
> Speed fixed at 100 mbps, full-duplex.
> I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT
> Advertising no additional info pages.
> IEEE 802.3 CSMA/CD protocol.
> Link partner capability is 45e1: Flow-control 100baseTx-FD 100baseTx
> 10baseT-FD. 10baseT. Negotiation completed.
Something is wrong.
Are you sure it's a hub? The link partner ability says FullDuplex
capable, it's either a switch or the negotiation produced wrong results.
The natsemi nic advertises 5e1, but the speed is fixed at 100 mbps.
Probably a forced renegotiation after mii-diag changes is missing, and
the forced settings aren't used properly.
I'll look at it.
--
Manfred
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: natsemi.c failure in 2.4.6
2001-07-06 10:56 natsemi.c failure in 2.4.6 Studierende der Universitaet des Saarlandes
@ 2001-07-06 11:40 ` Daniel A. Nobuto
[not found] ` <3B45F966.351D1C44@colorfullife.com>
0 siblings, 1 reply; 4+ messages in thread
From: Daniel A. Nobuto @ 2001-07-06 11:40 UTC (permalink / raw)
To: manfred; +Cc: linux-kernel
Hi,
> Could you try what happens without any special options? Default MAC
> address, without mii-diag.
Okay, I ripped mii-diag out of the bootup scripts.
> > I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT
> > Advertising no additional info pages.
> > IEEE 802.3 CSMA/CD protocol.
> > Link partner capability is 45e1: Flow-control 100baseTx-FD 100baseTx
> > 10baseT-FD. 10baseT. Negotiation completed.
>
> Something is wrong.
> Are you sure it's a hub? The link partner ability says FullDuplex
> capable, it's either a switch or the negotiation produced wrong results.
I just checked, it looks like a switch. Sorry for the confusion, but it was
advertised as a hub when I bought it, so I didn't check to see which it was.
(Until now).
> The natsemi nic advertises 5e1, but the speed is fixed at 100 mbps.
> Probably a forced renegotiation after mii-diag changes is missing, and
> the forced settings aren't used properly.
Yup, it was forced to 10baseT-HD during bootup. It didn't work and a few
tcpdumps later, I changed it to 100baseTx-FD via mii-diag to see if it would
make a difference. That's when I got the mii-diag output I put in my mail.
I just booted with it disabled and tried it, but I'm still getting the same
symptoms, though the first time I tried to ping, I got *one* reply from the
NetBSD box.
Anything else I can do to help?
-- DN
Daniel
==========================================================
>From the Linux box:
start continuous ping
>From the NetBSD box:
ramune@stoli:$ sudo tcpdump -enli le0
tcpdump: listening on le0
04:35:19.832480 0:a0:cc:a1:67:71 8:0:20:76:94:16 0800 98: 192.168.0.3 > 192.168.0.1: icmp: echo request (DF)
04:35:19.832657 8:0:20:76:94:16 0:a0:cc:a1:67:71 0800 98: 192.168.0.1 > 192.168.0.3: icmp: echo reply (DF)
<ad infinitum>
==========================================================
/sbin/ip -s link ls dev eth0
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:a0:cc:a1:67:71 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
158 2 0 0 0 0
TX: bytes packets errors dropped carrier collsns
2786 29 0 0 0 0
==========================================================
/var/log/kern.log:
Jul 6 04:25:06 zippo kernel: eth0: Something Wicked happened! 18000.
==========================================================
mii-diag -vvva eth0:
Using the default interface 'eth0'.
mii-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
MII PHY #1 transceiver registers:
3100 786d 2000 5c21 05e1 45e1 0005 2801
0000 0000 0000 0000 0000 0000 0000 0000
0615 0002 0000 0001 0000 0000 0000 4000
4f48 189c 0860 00b7 0010 5040 1084 0023.
Basic mode control register 0x3100: Auto-negotiation enabled.
You have link beat, and everything is working OK.
This transceiver is capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
Able to perform Auto-negotiation, negotiation complete.
Your link partner advertised 45e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT, w/ 802.3X flow control.
MII PHY #1 transceiver registers:
3100 786d 2000 5c21 05e1 45e1 0005 2801
0000 0000 0000 0000 0000 0000 0000 0000
0615 0002 0000 0001 0000 0000 0000 4000
4f48 189c 0860 00b7 0010 5040 1084 0023.
Basic mode control register 0x3100: Auto-negotiation enabled.
Basic mode status register 0x786d ... 786d.
Link status: established.
Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
Able to perform Auto-negotiation, negotiation complete.
Vendor ID is 08:00:17:--:--:--, model 2 rev. 1.
No specific information is known about this transceiver type.
I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT
Advertising no additional info pages.
IEEE 802.3 CSMA/CD protocol.
Link partner capability is 45e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
Negotiation completed.
==========================================================
dmesg with init=/bin/sh (some of it was truncated, but I think everything
needed is here):
r init, caps: 0183f9ff 00000000 00000000 00000000
CPU: After generic, caps: 0183f9ff 00000000 00000000 00000000
CPU: Common caps: 0183f9ff 00000000 00000000 00000000
CPU: Intel Pentium II (Deschutes) stepping 02
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xfb460, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router PIIX [8086/7110] at 00:07.0
PCI: Found IRQ 5 for device 00:07.2
PCI: Sharing IRQ 5 with 00:09.0
PCI: Sharing IRQ 5 with 00:11.0
Limiting direct PCI/PCI transfers.
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd v1.8
Coda Kernel/Venus communications, v5.3.14, coda@cs.cmu.edu
parport0: PC-style at 0x378 [PCSPP,TRISTATE]
parport0: cpp_daisy: aa5500ff(38)
parport0: assign_addrs: aa5500ff(38)
parport0: cpp_daisy: aa5500ff(38)
parport0: assign_addrs: aa5500ff(38)
matroxfb: Matrox Millennium G200 (AGP) detected
matroxfb: MTRR's turned on
matroxfb: 1024x768x16bpp (virtual: 1024x4094)
matroxfb: framebuffer at 0xE8000000, mapped to 0xd0805000, size 8388608
Console: switching to colour frame buffer device 128x48
fb0: MATROX VGA frame buffer device
pty: 256 Unix98 ptys configured
lp0: using parport0 (polling).
Serial driver version 5.05a (2001-03-20) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
Real Time Clock Driver v1.10d
block: queued sectors max/low 169290kB/56430kB, 512 slots per queue
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller on PCI bus 00 dev 39
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
hda: JTS Corp. PALLADIUM Model P1000-2AF, ATA DISK drive
hdb: TOSHIBA CD-ROM XM-6502B, ATAPI CD/DVD-ROM drive
hdc: Maxtor 82160D2, ATA DISK drive
hdd: Maxtor 51024U2, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 1957536 sectors (1002 MB) w/32KiB Cache, CHS=971/32/63, DMA
hdc: 4219592 sectors (2160 MB) w/256KiB Cache, CHS=4465/15/63, UDMA(33)
hdd: 20010816 sectors (10246 MB) w/2048KiB Cache, CHS=19852/16/63, UDMA(33)
Partition check:
hda: hda1 hda2
hdc: hdc1
hdd: hdd1 hdd2 hdd3 < hdd5 hdd6 hdd7 hdd8 hdd9 hdd10 >
loop: loaded (max 8 devices)
natsemi.c:v1.07 1/9/2001 Written by Donald Becker <becker@scyld.com>
http://www.scyld.com/network/natsemi.html
(unofficial 2.4.x kernel port, version 1.07+LK1.0.7, May 18, 2001 Jeff Garzik, Tjeerd Mulder)
PCI: Found IRQ 11 for device 00:0f.0
eth0: NatSemi DP83815 at 0xd1006000, 00:a0:cc:a1:67:71, IRQ 11.
eth0: Transceiver status 0x7869 advertising 05e1.
[snip -- to save bandwith, since some ppl are on metered connections.]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: natsemi.c failure in 2.4.6
[not found] ` <3B463C71.B217B275@colorfullife.com>
@ 2001-07-07 0:48 ` Daniel A. Nobuto
0 siblings, 0 replies; 4+ messages in thread
From: Daniel A. Nobuto @ 2001-07-07 0:48 UTC (permalink / raw)
To: Manfred Spraul; +Cc: linux-kernel
Hi,
On Sat, Jul 07, 2001 at 12:32:17AM +0200, Manfred Spraul wrote:
> Perhaps powermanagement causes your receive problems? You wrote you have
> a FA312. I've tested my FA311 (without mii-diag) and I didn't have any
> problems with transmit or receive.
Found out what was wrong. It was hardware-related after all. Sorry for
the confusion. Turns out my cat chewed on my cables -- replacing them
fixed it.
Thanks for the help!
-- DN
Daniel
^ permalink raw reply [flat|nested] 4+ messages in thread
* natsemi.c failure in 2.4.6
@ 2001-07-06 10:39 Daniel A. Nobuto
0 siblings, 0 replies; 4+ messages in thread
From: Daniel A. Nobuto @ 2001-07-06 10:39 UTC (permalink / raw)
To: linux-kernel
Hi all,
Found that in 2.4.6, Natsetmi card I have doesn't receive
traffic anymore. It worked in 2.4.5, though.
The natsemi card is forced to 10/half via mii-diag at boot,
and given a different MAC address (due to some problems I had with
the original MAC address and netbooting a sparc). Forcing it to
100/full didn't work, either.
A continuous ping from the Linux box to another system on the
LAN showed only outbound traffic in tcpdump, but the recieving end
(an SS4 running NetBSD) showed both incoming and outgoing packets
(i.e. icmp echo and echo-reply).
Any ideas on how I can get about tracking the problem down?
Thanks,
-- DN
Daniel
[PC Linux 2.4.6] <--> p10/100 hub] <--> [SS4 NetBSD 1.5]
PII/233, 256MiB RAM, running on Debian stable/potato.
>From /var/log/kern.log (haven't seen this since using the driver under
2.2.x with Donald Becker's version from scyld. Never figured out what's
going on, either.):
Jul 6 02:38:12 zippo kernel: eth0: Something Wicked happened! 18000.
Jul 6 02:38:43 zippo last message repeated 8 times
Jul 6 02:39:00 zippo last message repeated 17 times
Jul 6 02:39:01 zippo kernel: eth0: Promiscuous mode enabled.
Jul 6 02:39:01 zippo kernel: eth0: Something Wicked happened! 18000.
ip -s link ls dev eth0:
2: eth0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 08:00:20:10:20:30 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
138 2 0 0 0 0
TX: bytes packets errors dropped carrier collsns
278502 2859 0 0 0 0
lspci -vvv for the NIC:
00:0f.0 Ethernet controller: National Semiconductor Corporation: Unknown device 0020
Subsystem: Netgear: Unknown device f312
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 11 min, 52 max, 64 set
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at dc00 [size=256]
Region 1: Memory at ec001000 (32-bit, non-prefetchable) [size=4K]
Expansion ROM at eb000000 [disabled] [size=64K]
Capabilities: [40] Power Management version 2
Flags: PMEClk- AuxPwr- DSI- D1+ D2+ PME+
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
mii-diag -v eth0:
mii-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
MII PHY #1 transceiver registers:
2100 7849 2000 5c21 05e1 45e1 0005 2801
0000 0000 0000 0000 0000 0000 0000 0000
0004 0002 0000 0001 0000 0000 0000 4000
4f48 189c 0860 00b7 0010 5040 1084 0023.
Basic mode control register 0x2100: Auto-negotiation disabled, with
Speed fixed at 100 mbps, full-duplex.
Basic mode status register 0x7849 ... 7849.
Link status: not established.
This transceiver is capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
Able to perform Auto-negotiation, negotiation not complete.
Your link partner advertised 45e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT, w/ 802.3X flow control.
MII PHY #1 transceiver registers:
2100 7849 2000 5c21 05e1 45e1 0005 2801
0000 0000 0000 0000 0000 0000 0000 0000
0004 0002 0000 0001 0000 0000 0000 4000
4f48 189c 0860 00b7 0010 5040 1084 0024.
Basic mode control register 0x2100: Auto-negotiation disabled!
Speed fixed at 100 mbps, full-duplex.
Basic mode status register 0x7849 ... 7849.
Link status: not established.
Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
Able to perform Auto-negotiation, negotiation not complete.
Vendor ID is 08:00:17:--:--:--, model 2 rev. 1.
No specific information is known about this transceiver type.
I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT
Advertising no additional info pages.
IEEE 802.3 CSMA/CD protocol.
Link partner capability is 45e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
Negotiation completed.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2001-07-07 0:49 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-07-06 10:56 natsemi.c failure in 2.4.6 Studierende der Universitaet des Saarlandes
2001-07-06 11:40 ` Daniel A. Nobuto
[not found] ` <3B45F966.351D1C44@colorfullife.com>
[not found] ` <3B463C71.B217B275@colorfullife.com>
2001-07-07 0:48 ` Daniel A. Nobuto
-- strict thread matches above, loose matches on Subject: below --
2001-07-06 10:39 Daniel A. Nobuto
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).