I know that this is boring and a number of my earlier reports was
apparently ignored but a tulip driver "0.9.15-pre10 (Mar 8, 2002)"
as used in 2.4.19-pre4 still does not really work. I know that it is
fine with various clones like "Davicom" and "Lite-On PNIC", for example,
but with a real tulip from DEC, PCI id 1011:0019, not a single ethernet
packet is getting through.
Luckily 'de4x5' allows me to use a network but maybe this "tulip" driver
should be renamed onto "anything-but-tulip"?
Michal
On Thu, Mar 28, 2002 at 05:47:24PM -0700, Michal Jaegermann wrote:
> I know that this is boring and a number of my earlier reports was
> apparently ignored but a tulip driver "0.9.15-pre10 (Mar 8, 2002)"
> as used in 2.4.19-pre4 still does not really work. I know that it is
> fine with various clones like "Davicom" and "Lite-On PNIC", for example,
> but with a real tulip from DEC, PCI id 1011:0019, not a single ethernet
> packet is getting through.
There is a tulip specific discussion list, which may explain why you
get ignored on this forum.
List-Id: Linux Tulip device driver list. <tulip.scyld.com>
List-Help: <mailto:[email protected]?subject=help>
--
Brian Litzinger <[email protected]>
Copyright (c) 2002 By Brian Litzinger, All Rights Reserved
On Thu, Mar 28, 2002 at 06:40:21PM -0800, [email protected] wrote:
> On Thu, Mar 28, 2002 at 05:47:24PM -0700, Michal Jaegermann wrote:
> > I know that this is boring and a number of my earlier reports was
> > apparently ignored
>
> There is a tulip specific discussion list, which may explain why you
> get ignored on this forum.
Well, in a due time I filed pretty detailed bug reports, with dumps
of PCI space from older working and non-working drivers and what not,
on sourceforge where presumably a development of this driver was going.
This was ignored there as well.
Michal
Michal Jaegermann wrote:
>On Thu, Mar 28, 2002 at 06:40:21PM -0800, [email protected] wrote:
>
>>On Thu, Mar 28, 2002 at 05:47:24PM -0700, Michal Jaegermann wrote:
>>
>>>I know that this is boring and a number of my earlier reports was
>>>apparently ignored
>>>
>>There is a tulip specific discussion list, which may explain why you
>>get ignored on this forum.
>>
>
>Well, in a due time I filed pretty detailed bug reports, with dumps
>of PCI space from older working and non-working drivers and what not,
>on sourceforge where presumably a development of this driver was going.
>This was ignored there as well.
>
Currently the tulip driver is very stable for a large number of
chipsets, but not all of them. And there are some problems like,
"calling this function with 1 as argument, and some chipsets work.
calling this function with 0 as argument, and that breaks some chipsets
but then other chipsets are fixed."
The temporary solution is to use the latest _stable_ version of the
driver, on http://sf.net/projects/tulip/ or use the de4x5 driver. I am
working on the long term solution, which is fixing the link state
machine in the driver to actually be (a) sane and (b) workable for all
chipsets.
This work is going to be merged into 2.5.x series _first_, then after
it's proven stable merged back into 2.4.x as a solution for all. But
this takes time... in the meantime, there are the temporary solutions
mentioned to get you by.
Jeff
"Me too" however I managed to get mine to work by swaping PCI cards
in/out and doing power off reboots. It is working on this particular
boot up so I'm leaving it running.
Jeff Garzik, if you want the lspci, register dump, etc, please speak up.
David
Michal Jaegermann wrote:
>I know that this is boring and a number of my earlier reports was
>apparently ignored but a tulip driver "0.9.15-pre10 (Mar 8, 2002)"
>as used in 2.4.19-pre4 still does not really work. I know that it is
>
David Ford wrote:
> "Me too" however I managed to get mine to work by swaping PCI cards
> in/out and doing power off reboots. It is working on this particular
> boot up so I'm leaving it running.
>
> Jeff Garzik, if you want the lspci, register dump, etc, please speak up.
Yes, please do.
The more bug reports I can receive (in private or CC'd to lkml), the
better picture I get. If you have multiple tulips, feel free to email
reports on those too :)
Best output is:
lspci -vvvn
dmesg, after updating drivers/net/tulip/tulip.h TULIP_DEBUG to 5,
and recompiling
tulip-diag -mmaavvveef
tulip-diag was written by Donald Becker, and is available from
ftp://http://www.scyld.com/pub/diag/ Compiling instructions are at the end of
tulip-diag.c. You should grab libmii.c as well.
Jeff
>>>>> "Jeff" == Jeff Garzik <[email protected]> writes:
Jeff> David Ford wrote:
>> "Me too" however I managed to get mine to work by swaping PCI cards
>> in/out and doing power off reboots. It is working on this
>> particular boot up so I'm leaving it running.
>>
>> Jeff Garzik, if you want the lspci, register dump, etc, please
>> speak up.
Jeff> Yes, please do.
Hi Jeff,
I have a Digital Tulip card that fails to work in recent kernels.
There seems to be a problem with normal-sized packets.
On 2.5.7, this is what I see:
>From the machine with the tulip card,
ping -s 70 works;
ping -s 71 gives
`wrong data byte #70 should be 0x46 but was 0x0'
ping -s 79 doesn't work.
>From another machine:
ping -s 70 works
ping -s 71 does not work.
Here's the lspci -vvvn output
00:0a.0 Class 0200: 1011:0014 (rev 11)
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: 32
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at 6100 [size=128]
Region 1: Memory at e2000000 (32-bit, non-prefetchable) [size=128]
Expansion ROM at <unassigned> [disabled] [size=256K]
Here's the messages from the kernel:
Apr 2 10:26:08 crash kernel: de2104x PCI Ethernet driver v0.5.4 (Jan 1, 2002)
Apr 2 10:26:08 crash kernel: de0: SROM leaf offset 30, default media 10baseT auto
Apr 2 10:26:08 crash kernel: de0: media block #0: BNC
Apr 2 10:26:08 crash kernel: de0: media block #1: AUI
Apr 2 10:26:08 crash kernel: de0: media block #2: 10baseT-FD
Apr 2 10:26:08 crash kernel: de0: media block #3: 10baseT-HD
Apr 2 10:26:08 crash kernel: eth0: 21041 at 0xc2820000, 00:80:48:ea:27:7a, IRQ 11
Apr 2 10:26:27 crash kernel: eth0: set link 10baseT auto
Apr 2 10:26:27 crash kernel: eth0: mode 0x7ffc0040, sia 0x10c4,0xffffef01,0xffffffff,0xffff0008
Apr 2 10:26:27 crash kernel: eth0: set mode 0x7ffc0000, set sia 0xef01,0xffff,0x8
Apr 2 10:26:29 crash kernel: eth0: link up, media 10baseT auto
Apr 2 10:38:03 crash kernel: sending pkt_too_big to self
Apr 2 10:38:16 crash last message repeated 14 times
And here's the output of tulip_diag -mmaavvveef
tulip-diag.c:v2.10 3/08/2002 Donald Becker ([email protected])
http://www.scyld.com/diag/index.html
Index #1: Found a Digital DC21041 Tulip adapter at 0x6100.
Digital DC21041 Tulip chip registers at 0x6100:
0x00: ffe00000 ffffffff ffffffff 0195c000 0195c400 fc660000 7ffc2002 ffffb0d5
0x40: fffe0000 ffff03ff ffffffff fffe0000 45e1d1c8 ffffef01 ffffffff ffff0008
Port selection is half-duplex.
Transmit started, Receive started, half-duplex.
The Rx process state is 'Waiting for packets'.
The Tx process state is 'Idle'.
The transmit unit is set to store-and-forward.
The NWay status register is 45e1d1c8.
EEPROM 64 words, 6 address bits.
PCI Subsystem IDs, vendor 0000, device 0000.
CardBus Information Structure at offset 00000000.
Ethernet MAC Station Address 00:80:48:EA:27:7A.
EEPROM transceiver/media description table.
Leaf node at offset 30, default media type 0800 (Autosense).
4 transceiver description blocks:
21041 media index 00 (10baseT).
21041 media index 01 (10base2).
21041 media index 02 (AUI).
21041 media index 04 (10baseT-Full Duplex).
EEPROM contents (64 words):
0x00: 0000 0000 0000 0000 0000 0000 0000 0000
0x08: 0000 0101 8000 ea48 7a27 1e00 0000 0800
0x10: 0004 0201 0004 0000 0000 0000 0000 0000
0x18: 0000 0000 0000 0000 0000 0000 0000 0000
0x20: 0000 0000 0000 0000 0000 0000 0000 0000
0x28: 0000 0000 0000 0000 0000 0000 0000 0000
0x30: 0000 0000 0000 0000 0000 0000 0000 0000
0x38: 0000 0001 0000 0000 0000 0000 0000 08f5
ID block CRC 0xe3 (vs. 00).
Full contents CRC 0x08f5 (read as 0x08f5).
mdio_read(0x6100, 1, 1).. mdio_read(0x6100, 2, 1).. mdio_read(0x6100, 3, 1).. mdio_read(0x6100, 4, 1).. mdio_read(0x6100, 5, 1).. mdio_read(0x6100, 6, 1).. mdio_read(0x6100, 7, 1).. mdio_read(0x6100, 8, 1).. mdio_read(0x6100, 9, 1).. mdio_read(0x6100, 10, 1).. mdio_read(0x6100, 11, 1).. mdio_read(0x6100, 12, 1).. mdio_read(0x6100, 13, 1).. mdio_read(0x6100, 14, 1).. mdio_read(0x6100, 15, 1).. mdio_read(0x6100, 16, 1).. mdio_read(0x6100, 17, 1).. mdio_read(0x6100, 18, 1).. mdio_read(0x6100, 19, 1).. mdio_read(0x6100, 20, 1).. mdio_read(0x6100, 21, 1).. mdio_read(0x6100, 22, 1).. mdio_read(0x6100, 23, 1).. mdio_read(0x6100, 24, 1).. mdio_read(0x6100, 25, 1).. mdio_read(0x6100, 26, 1).. mdio_read(0x6100, 27, 1).. mdio_read(0x6100, 28, 1).. mdio_read(0x6100, 29, 1).. mdio_read(0x6100, 30, 1).. mdio_read(0x6100, 31, 1).. mdio_read(0x6100, 0, 1).. No MII transceivers found!
Internal autonegotiation state is 'Negotiation complete'.
Jeff> The more bug reports I can receive (in private or CC'd to lkml),
Jeff> the better picture I get. If you have multiple tulips, feel
Jeff> free to email reports on those too :)
Jeff> Best output is: lspci -vvvn dmesg, after updating
Jeff> drivers/net/tulip/tulip.h TULIP_DEBUG to 5, and recompiling
Jeff> tulip-diag -mmaavvveef
Jeff> tulip-diag was written by Donald Becker, and is available from
Jeff> ftp://http://www.scyld.com/pub/diag/ Compiling instructions are at the
Jeff> end of tulip-diag.c. You should grab libmii.c as well.
Jeff> Jeff
Jeff> - To unsubscribe from this list: send the line "unsubscribe
Jeff> linux-kernel" in the body of a message to
Jeff> [email protected] More majordomo info at
Jeff> http://vger.kernel.org/majordomo-info.html Please read the FAQ
Jeff> at http://www.tux.org/lkml/