On Wed, 18 Sep 2019, Thomas Bogendoerfer wrote: > > >> Likewise, I'm at a loss for testing with real hardware. It's hard to > > >> find such things, now. > > > How does de2104x compare to ds2142/43? I have a c3750 with ds2142/43 tulip. Helge > > > or some others might have a machine with a de2104x. > > > > The machines we could test are > > * a C240 with a DS21140 tulip chip (Sven has one), > > * a C3000 or similiar with DS21142 and/or DS21143 (me). > > > > If the patch does not show any regressions, I'd suggest to > > apply it upstream. > > 2114x chips use a different driver, so it won't help here. Asking at `linux-alpha' (cc-ed) might help; these chips used to be ubiquitous with older Alpha systems, so someone subscribed there might be able to step in and help right away. Also testing with an Alpha always has the advantage of exposing any weak ordering issues. Myself I have an AS 300 (or AS 250 really as I suspect a mismatch between the enclosure and the MB; the two systems are almost identical anyway) and it does have a real 21040 chip on its riser I/O module. However I have never got to setting up Linux on that machine and it may take me a bit to get it running suitably to get any verification done I'm afraid. NB for the original 21040 part "DECchip 21040 Ethernet LAN Controller for PCI Hardware Reference Manual", Order Number: EC-N0752-72, available here: <ftp://ftp.netbsd.org/pub/NetBSD/misc/dec-docs/ec-n0752-72.ps.gz> is probably more relevant, although in the area concerned here it seems the same. Finally I don't expect any race condition in possibly examining control bits in the transmit interrupt handler as this is what the descriptor ownership bit guards against -- only when a descriptor is owned by the host accesses from the CPU side are allowed, and then it is safe to fiddle with any field. Maciej
