Re: Fixing, reestoring DEC FDDI (DEFPA/DEFEA/DEFTA/DEFQA) in 8.2, 9.2; restore to -current?
In case it wasn't clear: when there's a known-to-crash device driver (e.g., DEC PDQ w/ varrious bus attachments), and no-one to support it,, then IMHO removing it from -current is the right thing to do. However, now that there's an (obviously required) one-line fix, and someone actively using it, willing to maintain, (even improve!) handling of Etnernet-like multicast addresses, and even willing to ship a pair of thin-client systems with DEFPA interfaces to someone if the volunteer isn't suitable then also IMHO restoring the code (and required FDDI machinery), then restoring said driver in -current also seems, IMHO, the right thing to do. (See earlier in thread for why faster-than-10Mbit Ethernet cannot replace FDDI on a number of buses and arches, where Ethernet faster than 10Mbit were either never implemented, or no longer available, or not affordable.)
Re: Fixing, reestoring DEC FDDI (DEFPA/DEFEA/DEFTA/DEFQA) in 8.2, 9.2; restore to -current?
On Monday, February 12, 2024 at 04:24:44 PM PST, Jason Thorpe wrote: > On Feb 11, 2024, at 1:29 PM, Jonathan Stone wrote: >> Turns out that fddi_ifattach() is broken in 8.2 and 9.2. [...] > Right, it was removed from -current before netbsd-10 branched after some > discussion. Same with Token Ring, for the same reason ... a bunch of > apparently unused code that had no work done to make MP-safe improvements > like the Ethernet code received, and the work hadn't been done > because, well, no one was apparently using it. Looks like I was right, > because (a) no one screamed when it disappeared, Huh? I did, as soon as I noticed it was gone. It's taken me that long to phsyically get set up. After Long Covid, I have difficulties carrying the Turbochannel machines that i used to pick up with one hand. If it's unclear: yes, I'm volunteering to revive the PDQ and FDDI code, maintain it, and to do better than the prior (ab)use of "struct ethercom" in FDDI and 802.11 driver(s). I even acquired a DEFZA-AA), with hopes of writing a driver. (I got a copper DEFZA years ago, but never found anything compatible for the other end). > and (b) when someone > tried an older version that was still around, it blew up in their face. :-) I'm pretty sure that was me. if it wasn't me, I also hit a crash, and IIRC, I emailed you about it. Either way, I have the FDDI hardware set up; it's now working in 8.2 and 9.2 (working on 9.3). And I see ways to refactor "struct ethercom" and "FDDI" handling. I fundamentally disagree with removal of FDDI on the basis that FDDI has been supplanted by Ethernet. Yes, FDDI clearly *has* been supplanted by 100base-TX (and faster) Ethernet. However, NetBSD supports several arch's for which Fast Ethernet has never been available. But some of those architectures _do_ have extant FDDI NICs. Thus, for that subset of architectures, FDDI is not redundant and not "supplanted". > [ pdq code a twisty mase [sic] of #idefs ] Yes, the pdq is a nasty case of #ifdef's. But if Matt Thomas isn't maintaining it, I seen no value in retaining those #ifdef's. I'm volunteering to strip out those #ifdef's, if that's a (entirely reasonable) pre-requsite to reestoring PDQ support. And I've set up a couple of spare "thin clients" with PCI expansion slots, which I can ship, with FDDI cards, to anyone else who wants to help support FDDI, or in case I'm not available
Re: Fixing, reestoring DEC FDDI (DEFPA/DEFEA/DEFTA/DEFQA) in 8.2, 9.2; restore to -current?
On Sunday, February 11, 2024 at 10:54:31 PM PST, Martin Husemann wrote: >We have a simmilar problem with net80211, where we are required to have a > (mostly unused) struct ethercom for each virtual interface (in the new stack) >just because of initialization and to be able to use vlan(4) on a > wifi interface, [...] https://mail-index.netbsd.org/tech-net/2022/09/28/msg008338.html > Now I don't know if vlan(4) is important for FFDI and probably bpf(4) users > are not expecting ethernet frames from it, so things might be easier. My recollection is that FDDI was "mature techology" (development stoped, effectively legacy) when 100Mbit Ethernet became available. Plus, it's a ring topology, so VLANs didn't give as much utility as with switched Ethernet. Curiously enough, the use-case of "struct ethercom" which the "pdq" (fpa, etc) FDDI driver hit, was adding multicast addresses when an interface comes up. How much of the "struct ethecom" pain would be fixed by having a common struct containing _just_ the "multicast" data structures? That still leaves vlan; and separating vlan from multicast would (I assume) require separate locks. Or more ugly struct overlaying...
Fixing, reestoring DEC FDDI (DEFPA/DEFEA/DEFTA/DEFQA) in 8.2, 9.2; restore to -current?
[[cc'ed to thropejj as the lst person I know whotouched the PDQ code. tech-net for discussion of refactoring ether_ifattach ]] I'm nearing the end of reviving some DECstations and a few Vaxes. One of the things I need/want for them is FDDI. FDDI -- from the DEC "pdq"-based boards -- is the fastest, cheapest, and most readily available 100Mbit tecnoligy for Turbochannel and EISA. Turns out that fddi_ifattach() is broken in 8.2 and 9.2. It never initialises sc_ec.ec_lock, which causes a panic the fisrt time the kernel tries to add a multicast address to the interface. If you're using IPv6 (I don't; I comment out "options INET6"), the panic occurs soon after boot when ipv6 discovery starts. A minimal-touch fix is straightfoward; see attached diff against NetBSD-8.2. (Should work against 9.2, haven't tested yet). After applying this to 8.2 kernel source and rebuilding, I have a pair of back-to-back, dual-attach DEFPAs (PCI FDDI). I statically configure IP (v4) via /etc/ifconfig.fpa. They happily ping each other, I can ssh across the FDDi interface, etc. I would like to restore "pdq" (fpa, fea, fta, whatever a qbus attachment is; or write one if none) to -current. However, 10_RC4. doesn't even have if_fddisubr.c. I don;t want to re-create the hack of having two different initialisers for the IEE 802 (sic) [*] portions of "struct ethercom'. A cleaner solution is to declare a new struct with all the members of 'struct ethercom', except the 'struct ifnet ec_if; 'struct ethercom' then becomes a struct with two members: a struct ifnet, and the new struct (struct iee802_common?). That allows clean separation of code which manipulates the additions in today's "struct ethercom', from code which also manipulates struct ifnet. Thoughts? Anyone actively against PR'ing and (hopefully) minimal patches NetBSD-8 and NetBSD-9? Or against restoring FDDI to -current. (and perhaps backporting to NetBSD-10)? If I have to, I can probably ship a pair of DEFTAs to an interested contributor, if support from me is too tenuous. [*] FDDI is not IEEE 802. But it's derived from Token Ring,, 802.5, which is. And I suppose the refactoring I'm proposing here could add supporing Token Ring, if anyone actively wanted to... --Jonathan fix-8.2-pdq.diff Description: Binary data
Re: PSA: Clock drift and pkgin
On Saturday, December 30, 2023 at 10:43:34 AM PST, Martin Husemann wrote: > Kernels on that machines just would not run fully tickless. That makes sense. I personallly would call that "tickless where possible", not "fullly tickless".
Re: PSA: Clock drift and pkgin
On Saturday, December 23, 2023 at 10:19:53 PM PST, Simon Burge wrote: > I have a grotty hack that attempted to spin if the requested timeout > was less than a tick based on what DragonflyBSD does. It mostly > worked for simple tests but I haven't tested it seriously. It's at > https://www.NetBSD.org/~simonb/pollfixhack.diff . is that really viable on uniprocessor machines? > This is potentially >another direction until we get a pure tickless kernel... You can only do tickless if you can track how much time is elapsing when no ticks fire, or none are pending. I don't see how to do that without a high-res timer like a CPU cycle counter, or I/O bus cycle counter, or what-have-you. Gong fully tickless would therefore end support for machines without such a timer. Is NetBSD ready to do that?
Re: PSA: Clock drift and pkgin
On Sunday, December 24, 2023 at 02:43:55 AM PST, Johnny Billquist wrote: > Oh? So we are actually not POSIX compliant on that one? Interesting. > (POSIX explicitly says that the timeout should be for an absolute time, > which means that if you for example update the clock, moving it > backwards, the timeout should still only happen when that time arrives, > and not after some precomputed number of ticks.) one could keep track, for every timeout, whether it's relative or absolute; and when the time is changed, walk the list of a-yet-unfired timeouts, updating all the "absolute" timeouts by the clock-change delta. Anyway .. I wonder if the "clock drift" is related to the clock drift I've heard about, on machines which don't have a hardware cycle-counter-style clock, and rely on clock-tick interrupts to track time. (for example, pmax 2100/3100; decstation 5000/200; (most) vax). I'd really like to help out with clock-drift', if I can do anything to help.
Re: Regarding the ULTRIX and OSF1 compats
On Sat, 3/16/19, Jason Thorpe wrote: Subject: Re: Regarding the ULTRIX and OSF1 compats To: "Jonathan Stone" Cc: "Jaromír Doleček" , "Robert Elz" , "Maxime Villard" , "Tech-kern" , port-p...@netbsd.org, port-al...@netbsd.org Date: Saturday, March 16, 2019, 12:49 PM >though your comment about the practically of > actually using one of these machines is telling ... [...] Anyone got a DEFTA they'd donate/long-term loan?
Re: Regarding the ULTRIX and OSF1 compats
Hello all, I don't see anyone asking to keep COMPAT_OSF1. It was never useful enough to run "real" (arbitrary) OSF/1 binaries. Please just remove it, and remove "and OSF1" from the Subject: line. COMPAT_ULTRIX, is complete enough to run commercial apps; vendor X-servers for all commonly-available pmax graphics boards; and to routinely go multi-user from an Ultrix root partition. Thorpej was far from the only person to use that, when pmaxes and VAXes were practical production machines. Lots of academic users who had pmax hardware, shifted from Ultrix to NetBSD: better performance (from shared libraries). Some even said "better support". (No support for DEcsystem 5400s, but those weren't actually "pmax'.) As noted, Ultrix was derived from 4BSD, somewhere between 4.2BSD and 4.3BSD, with 4.3ish features back-ported, and an in-house NFS port (gnodes). So COMPAT_ULTRIX is a very thin layer on top of NetBSD. If NetBSD-current supports compatibility for NetBSD-4 or NetBSD-6, or even SunOS 4.x on Sparc, then supporting COMPAT_ULTRIX should be trivial, modulo testing. Testing is a real issue. Anyone want to host a pmax or three?I could be persuaded to fire one up for specific testing, but it'll take a couple of weekends, maybe more. (It's been years since I had thinwire (BNC) connectivity)
Re: ixg(4) performances
Thor, The NetBSD TCP stack can't handle 8K payload by page-flipping the payload and prepending an mbuf for XDR/NFS/TCP/IP headers? Or is the issue the extra page-mapping for the prepended mbuf? On Tue, 8/26/14, Thor Lancelot Simon t...@panix.com wrote: Subject: Re: ixg(4) performances To: Emmanuel Dreyfus m...@netbsd.org Cc: tech-kern@netbsd.org Date: Tuesday, August 26, 2014, 6:56 PM [...] MTU 9000 considered harmful. Use something that fits in 8K with the headers. It's a minor piece of the puzzle but nonetheless, it's a piece. Thor
Re: Snapshots in tmpfs
I think you mean halves the write rate. --- On Thu, 2/23/12, Thor Lancelot Simon t...@panix.com wrote: From: Thor Lancelot Simon t...@panix.com Subject: Re: Snapshots in tmpfs To: David Holland dholland-t...@netbsd.org Cc: tech-kern@netbsd.org Date: Thursday, February 23, 2012, 5:04 PM On Fri, Feb 24, 2012 at 12:45:32AM +, David Holland wrote: On Thu, Feb 23, 2012 at 11:20:18PM +, David Holland wrote: Is CHFS really suitable for CompactFlash? Is LFS even usable? No I thought the whole point of chfs was to be able to operate on raw flash devices that don't have their own flash translation layer. Oh, my mistake, since there was concern about filesystem type I thought you were talking about raw flash, but apparently CompactFlash is not raw flash, same as USB sticks aren't. In that case, just use wapbl. That doubles the write rate for the common create new version of file and rename into place pattern... Translation layer or not, doubling the write rate to any type of flash is not a great idea. -- Thor Lancelot Simon t...@panix.com All of my opinions are consistent, but I cannot present them all at once. -Jean-Jacques Rousseau, On The Social Contract
