maintainers/users of de(4), lmc(4) ?

[...] de(4) or lmc(4) [...]
Do these drivers have maintainers? Users?

Users, well, I've got some de hardware, and at least one machine that's
got one in routine use (used to be two, but the hardware broke in one,
and what I grabbed to replace it wasn't a de).

Maintainers, I can't speak to, except to say that I don't consider
myself competent to maintain either. (This is independent of whether I
could become competent quickly; I haven't looked.)

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Thor Lancelot Simon

2009-08-24 20:07:27 UTC

Post by der Mouse

[...] de(4) or lmc(4) [...]
Do these drivers have maintainers? Users?

Users, well, I've got some de hardware, and at least one machine that's
got one in routine use (used to be two, but the hardware broke in one,
and what I grabbed to replace it wasn't a de).

This is hardware that doesn't work with tlp?

Thor

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

der Mouse

2009-08-24 20:17:20 UTC

[...] de(4) or lmc(4) [...]
Do these drivers have maintainers? Users?

Users, well, I've got some de hardware, [...]

This is hardware that doesn't work with tlp?

That's a good question; I don't recall ever trying it under
circumstances that would support tlp but not de. I'll have to
experiment.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

David Young

2009-08-24 20:27:49 UTC

Post by der Mouse

[...] de(4) or lmc(4) [...]
Do these drivers have maintainers? Users?

Users, well, I've got some de hardware, and at least one machine that's
got one in routine use (used to be two, but the hardware broke in one,
and what I grabbed to replace it wasn't a de).

This is hardware that doesn't work with tlp?

I would like to know, too, whether anybody who is using de(4) cannot use
tlp(4), instead. If not, why not?

Dave

Izumi Tsutsui

2009-08-24 23:42:09 UTC

Post by David Young

Post by der Mouse
Users, well, I've got some de hardware, and at least one machine that's
got one in routine use (used to be two, but the hardware broke in one,
and what I grabbed to replace it wasn't a de).

This is hardware that doesn't work with tlp?

I would like to know, too, whether anybody who is using de(4) cannot use
tlp(4), instead. If not, why not?

http://mail-index.netbsd.org/port-cats/2003/02/08/msg000114.html
http://mail-index.netbsd.org/port-cats/2005/06/04/msg000196.html
http://mail-index.netbsd.org/port-cats/2005/06/07/msg000197.html
etc?

On the other hand, autonegothication of 21143-PC with SIA doesn't
work with tlp(4), though I have not tried it with de(4).
---
Izumi Tsutsui

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

David Young

2009-08-25 00:15:35 UTC

Post by David Young

This is hardware that doesn't work with tlp?

I would like to know, too, whether anybody who is using de(4) cannot use
tlp(4), instead. If not, why not?

My reading of this discussion is that a minor patch is necessary to make
Chris Gilbert's device work satisfactorily with tlp(4). The same patch
helped Richard Earnshaw's device to work with tlp(4) where previously it
had not. However, Richard's device does not work very well. It seems
that his machine had other problems ("PCI/ISA malaise") that may have
been related.

The CVS history of sys/dev/mii/mii_bitbang.c indicates that the patch
still needs some work if it is not going to break other NICs:

revision 1.9
date: 2005/08/09 19:26:24; author: chris; state: Exp; lines: +2 -8
Remove changes to bitbang code for de devices to work as tlps on cats.

I need to investigate a proper fix that doesn't break other platforms, eg:
PR kern/30952
----------------------------
revision 1.8
date: 2005/08/07 17:47:22; author: chris; state: Exp; lines: +5 -10
Following feedback from thorpej, remove the #ifdef cats block, and update
comment.

All platforms will now send a change in direction, then the 32 MDO bits
when synchronising with the phy. Rather than sending the change in
direction with the first MDO bit.
----------------------------
revision 1.7
date: 2005/08/06 23:40:39; author: chris; state: Exp; lines: +13 -2
Check in cats specific tweak to make older de cards work as tlp devices.

With this tweak I've completed a full install from NFS of 3.99.7, using a
card the previously didn't work as a tlp device.

BTW, kern/30952 describes stalls on vr(4). vr(4) is a notoriously
problematic driver that has had at least one fix for Tx stalls applied
in the mean time. Maybe it is time to try it again with Chris's patch
in place?

Dave

List Mail User

2009-08-24 22:34:35 UTC

Many Macronics chips will not run at 100MBs w/ tlp - de is
still needed for these (though I retired _my_ last a few years ago).

Anyone want some for testing? (specifically MX98715AEC's don't
work except at 10baseT with tlp. de works at 100baseTX-FDX including
auto-negotiation, which leaves them chips unusable with a variety of
vendors switches). I have at least 2, maybe a half dozen on some shelf.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Izumi Tsutsui

2009-08-25 13:18:07 UTC

Post by List Mail User
Many Macronics chips will not run at 100MBs w/ tlp - de is
still needed for these (though I retired _my_ last a few years ago).
Anyone want some for testing? (specifically MX98715AEC's don't
work except at 10baseT with tlp. de works at 100baseTX-FDX including
auto-negotiation, which leaves them chips unusable with a variety of
vendors switches). I have at least 2, maybe a half dozen on some shelf.

Does de(4) on NetBSD ever support non-DEC clones?
I don't think so.
---
tulip_pci_probe(
struct device *parent,
cfdata_t match,
void *aux)
{
struct pci_attach_args *pa = (struct pci_attach_args *) aux;

/* Don't match lmc cards */
if (PCI_VENDOR(pci_conf_read(pa->pa_pc, pa->pa_tag,
PCI_SUBSYS_ID_REG)) == PCI_VENDOR_LMC)
return 0;
if (PCI_VENDORID(pa->pa_id) != DEC_VENDORID)
return 0;
if (PCI_CHIPID(pa->pa_id) == CHIPID_21040
|| PCI_CHIPID(pa->pa_id) == CHIPID_21041
|| PCI_CHIPID(pa->pa_id) == CHIPID_21140
|| PCI_CHIPID(pa->pa_id) == CHIPID_21142)
return 1;

return 0;
}
---

Anyway, I've tried my MX98715AEC with several kernels:

1.5.3:
auto: tlp driver didn't support it (yet)
manual 10baseT: works
manual 100baseTX: works

1.6.2:
2.1:
5.0:
auto: doesn't get proper speed
manual 10baseT: works
manual 100baseTX: doesn't work

So we should check diff between 1.5 and 1.6?

---
Izumi Tsutsui

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

List Mail User

2009-08-25 15:27:40 UTC

Yes, the use of DE on these cards dates back to at least '95,
which is the oldest built kernel I can see in an old disk image (from
a Pentium-Pro box's archives). The last used was a 4.99.x built in June
2007 (for a different box). IIRC, most of these were bought/sold as "DEC
compatible" cards by Linksys (and at Fry's).

I'm fairly certain that I built a 4-port "OSPF" box at $work
using these (or some Linksys labeled Macronics) back around '94 or '95.
It ran whatever was NetBSD-current back then (as did all the non-Solaris
servers).

Just pulled one from a Asus P2T4 (which _may_ actually work, but
was turned off years ago) - so I have three in my hands now.

Ah ha.... Did you check a xx715AEC or a xx715AEC-C? I have a
single AEC-C, and It works with tlp in 100Mbs mode, but automegotiation is
broken (at least with a variety of consumer grade switches). From memory,
the earlier xx715A and maybe even rarer xx715C (memory is fading after ...)
did work with tlp (never personally seen anything labeled xx715B).

Macronics kept changing the chip revs and the chips (_without_
changing revs) - Only Davicom seemed worse documented at the time. The
few "real" '441s and '443s, any 100Mbs Intels (except multiport '550s)
and lots more old stuff are currenly in the junk pile and scheduled to go
to an e-waste center this weekend, so if you'd like any of these stuff,
please ask quickly.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Izumi Tsutsui

2009-08-25 16:39:03 UTC

Post by List Mail User
I'm fairly certain that I built a 4-port "OSPF" box at $work
using these (or some Linksys labeled Macronics) back around '94 or '95.
It ran whatever was NetBSD-current back then (as did all the non-Solaris
servers).

According to MX98715A manual, it was released in 1998
(and NetBSD's de(4) driver first appeared on June 1995)
so maybe you are talking about some other cards.

Anyway, de(4) never supports clones so it's a different problem
from the topic of this thread.

Post by List Mail User
Ah ha.... Did you check a xx715AEC or a xx715AEC-C?

tlp0 at pci0 dev 14 function 0: Macronix MX98715A Ethernet, pass 2.0

I guess AEC-C should have pass 2.5 or later.

Post by List Mail User
Macronics kept changing the chip revs and the chips (_without_
changing revs)

There is an interesting log message ;-)
http://mail-index.NetBSD.org/source-changes/1999/09/29/0053.html
---
Izumi Tsutsui

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

List Mail User

2009-08-25 17:38:36 UTC

According to MX98715A manual, it was released in 1998
(and NetBSD's de(4) driver first appeared on June 1995)
so maybe you are talking about some other cards.

Probably, but _definitely_ a "brand-name" card with
some Macronics in it. It could have been as late as early '96,
but not (much) after ("we" sold the start-up, and hired a "real"
IT department before that - so I wasn't doing infrastructure stuff
after late '95)

Post by Izumi Tsutsui
Anyway, de(4) never supports clones so it's a different problem
from the topic of this thread.

_Supported_, or worked with the PCI IDs added? I long ago
lost count of drivers I "hacked" like that but never pr'd (and also
HW where I changed PCI IDs and other bits in EEPROM so they would
"work" - e.g. ath chips w/ the "closed" HAL).

Post by List Mail User
Ah ha.... Did you check a xx715AEC or a xx715AEC-C?

tlp0 at pci0 dev 14 function 0: Macronix MX98715A Ethernet, pass 2.0

I guess AEC-C should have pass 2.5 or later.

I'd have to plug these in to see - Hmm... One "busted" one from
just a couple years ago (booted in a ancient machine):

fetched from the scrap pile :-)
This card hangs on auto-negotiation, and drops the majority of packets
at any 100Mbs media setting. Looks like it was run about 2 years ago.
Anything older, or actually using de, would probably mean reading old
DAT tapes, which I haven't even tried in years :-(

chip is labeled xx715AEC - last known boot (note: 4.99.20 was unstable
on this hardware and it was reverted to 4.99.3 for the remaining week
or so during which I was running).

NetBSD 4.99.20 (NEPAL-$Revision: 1.1 $) #0: Thu Jun 21 20:39:29 PDT 2007
...
tlp0 at pci0 dev 12 function 0: Macronix MX98715A Ethernet, pass 2.0
tlp0: broken MicroWire interface detected; setting SROM size to 1Kb
intr_establish(legacy_irq 15 pin 15 type 3 level 7)
tlp0: interrupting at irq 15
tlp0: Ethernet address 00:80:ad:xx:xx:xx
tlp0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto

NOTE: The OUI says the vendor was "CNET", but the retail box for this
particular card was NetGear (not Linksys as some/most of the others).

Post by List Mail User
Macronics kept changing the chip revs and the chips (_without_
changing revs)

There is an interesting log message ;-)
http://mail-index.NetBSD.org/source-changes/1999/09/29/0053.html

Yes, and it seems to properly reflect the actual level of
functionality. I suspect FreeBSD kern/18526 was the same issue I saw
on NetBSD. This URL _may_ hint at part of the cause:
http://markmail.org/message/mx6raztubfli5yp6

Post by Izumi Tsutsui
---
Izumi Tsutsui

BTW. IIRC, All of mine say "broken MicroWire" - both those with and without
ROM sockets.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Thor Lancelot Simon

2009-08-25 17:45:10 UTC

Post by List Mail User
_Supported_, or worked with the PCI IDs added? I long ago
lost count of drivers I "hacked" like that but never pr'd (and also
HW where I changed PCI IDs and other bits in EEPROM so they would
"work" - e.g. ath chips w/ the "closed" HAL).

Well, if the hardware didn't work with NetBSD as we shipped it, I
don't think it's much worth worrying about. If someone cared enough
to modify 'de' rather than fixing 'tlp', they can, I suppose, keep
their modified de driver alive as a local patch...

Thor

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

List Mail User

2009-08-25 18:08:00 UTC

Post by Thor Lancelot Simon
...
Well, if the hardware didn't work with NetBSD as we shipped it, I
don't think it's much worth worrying about. If someone cared enough
to modify 'de' rather than fixing 'tlp', they can, I suppose, keep
their modified de driver alive as a local patch...
Thor

I can fully agree with this - seems reasonable to me.
Though I do believe that at some point the _unmodified_ de driver
did work with *someone's* MX 713 card (I definitely was using MX
chips with the de driver _before_ the tlp was written - I remember
well that initially none of the clones I had (dozens) worked with
the tlp driver at first) - but AFAICR, MX '713s & '715As work fine
with tlp now (and the MX '8xx chips probably never worked even on MS).

Besides, I'm currently sitting on HW from 2005 that stopped
working in 2007 (with the _previous_ ACPI update during 4.99.x), and
that isn't really worth any effort either (time often costs more than
simply spending $$s and replacing HW).

i.e. Don't think I'm arguing for keeping the de driver, just
giving one datapoint of what I believe was once common equipment. that
doesn't work with tlp (and I don't really care, anymore :-)

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Thor Lancelot Simon

2009-08-25 18:21:41 UTC

Post by List Mail User
I can fully agree with this - seems reasonable to me.
Though I do believe that at some point the _unmodified_ de driver
did work with *someone's* MX 713 card (I definitely was using MX
chips with the de driver _before_ the tlp was written - I remember
well that initially none of the clones I had (dozens) worked with
the tlp driver at first) - but AFAICR, MX '713s & '715As work fine
with tlp now (and the MX '8xx chips probably never worked even on MS).

The one that's a harder call, to me, is lmc. The hardware is very clever
and it would in a way be a shame to lose a driver for it, but I suspect
it's now very, very uncommon.

It doesn't seem feasible to me to produce some kind of horrible beast with
two heads which used the guts of tlp but worked with the lmc hardware and
was still maintainable. But we were at some point in the not too distant
past in contact with the lmc author, so maybe he has some ideas.

Thor

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

OS mailing lists

2009-08-25 15:42:58 UTC

I forgot to mention - Using the Macronics xx715AEC with media
set manually may _seem_ to work, but the error rate (mostly input errors)
is around 85% in full duplex and 50% half-duplex. Please don't just assume
because the link-lights at both ends power-up that the crad _really_ works
with the tlp driver.

P.S. I was using these before there was a tlp driver (the tlp driver never
did work correctly on most of these, those the xx713's did work fine).

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

David Young

2009-08-25 18:53:54 UTC

Post by OS mailing lists
I forgot to mention - Using the Macronics xx715AEC with media
set manually may _seem_ to work, but the error rate (mostly input errors)
is around 85% in full duplex and 50% half-duplex. Please don't just assume
because the link-lights at both ends power-up that the crad _really_ works
with the tlp driver.
P.S. I was using these before there was a tlp driver (the tlp driver never
did work correctly on most of these, those the xx713's did work fine).

I wonder if/how many of these problems with tlp(4) are fixed by
re-applying Chris Gilbert's patches to mii_bitbang.c, or else by making
analogous changes to tlp(4)'s bitbang routines?

Dave

Izumi Tsutsui

2009-08-26 11:13:14 UTC

Post by David Young
I wonder if/how many of these problems with tlp(4) are fixed by
re-applying Chris Gilbert's patches to mii_bitbang.c, or else by making
analogous changes to tlp(4)'s bitbang routines?

IMO, we should refer specifications of MII and I2C before putting
random fixes.

I wonder if the problem on cats also happend on other machines like i386.
As I wrote in the thread in port-cats archive, my 21140A worked fine
without problem on cats.
(unfortunately my cats board was dead six years ago)

I had a trouble when I tried fxp(4) on cats while it worked fine on i386,
and adding a more delay fixed the problem.
http://cvsweb.NetBSD.org/bsdweb.cgi/src/sys/dev/ic/i82557.c#rev1.33

mii_bitbang.c also uses delay(9) to generate clock plus,
so I wonder how delay(9) is/was implemented on cats.

From the viewpoint of hardware design, if the board has improper
pull up registers on I2C bus lines, it might also require
more delay for clock plus.
---
Izumi Tsutsui

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

David Laight

2009-08-30 16:01:48 UTC

Post by Izumi Tsutsui
mii_bitbang.c also uses delay(9) to generate clock plus,
so I wonder how delay(9) is/was implemented on cats.

Hmmm... 'posted writes' (etc) mean the delay(9) is rather inappropriate
for generating the signal delays required for bit-banging.

Adding adequate loop delay also spins the kernel for significant periods
(especially if multiple registers are being accessed).

One possibility is to write each signal value multiple times - using
the bus timings to control the bit-bang rate. For 33MHz PCI that is
60ns per extra write, but I can't remember the bit-band rate needed.

For polling for link status change, it ought to be possible to do
one transition per timer tick! This might mean it takes 1 second to
detect media change ...

The big fubar with the MII interface, is that none of the standard
registers (0..7 of 15 IIRC) contain the actual operating mode!
(In particular FDX v HDX - where the MAC has to agree with the PHY.)

David

--
David Laight: ***@l8s.co.uk

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

Thor Lancelot Simon

2009-08-31 01:09:19 UTC