On 22/10/20 1:08 pm, Lee Nelson wrote: > The same sort of thing happened to me with me PCI cards, but it was > another edge case. I had two identical 2-port NIC's representing > em0-em3. The card with em0 and em1 died and brought the syste down with > a kernel panic. Upon rebooting the card that had been em2 and em3 was > now em0 and em1. The server could have still functioned on half the > ports but now the configuration was wrong for the surviving ports so the > server was unreachable.
Yeah, the thing that's in PCI's favour is that it all gets power at the same time, whereas in USB, the bus gets powered up one hub at a time as each downstream hub is detected in the tree and powered up. Also the PCI bus is synchronised to a common clock, whereas USB is entirely asynchronous. Thus it's a lot easier to enforce some sort of order in PCI than USB. > And Theo's hint was spot on. I'm experimenting with arm64 on an RPI 4. > Stability is not one of my expectations. This is the normally standby > half of the fw pair of my home network. Even if it bursts into flames, > it will still be a learning experience. Yes well, it was in the back of my mind that this might be some sort of interface-challenged device. PCIe devices _can_ be connected to a Raspberry Pi 4, but it's a rather hap-hazard process that's not recommended unless you _really_ like re-working high-speed data links on printed circuit boards. Closest you get on a 'Pi is maybe some of the SPI Ethernet ICs that you might be able to hook to the GPIO header, but then you'd have to hack the OpenBSD kernel to support it, and it won't support gigabit speeds. A standard x86 machine and a multi-port network card is looking pretty good at this point. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
