Ticket #358 (Open)Sun Sep 15 13:28:19 UTC 2013
Boot sequence doesn't handle NICs that might vanish
Reported by: | Sprow (202) | Severity: | Minor |
Part: | RISC OS: Boot sequence | Release: | |
Milestone: | Status | Open |
Details by Sprow (202):
Migrated from the Cortex-A8 status page:
“Fix the boot sequence/network stack so it doesn’t fail if EtherUSB is in use but no NIC is connected.”
The boot sequence assumes NICs are baked in, like a podule or PCI card, but EtherUSB’s NIC might get unplugged over a reboot.
Changelog:
Modified by Sprow (202) Sun, September 15 2013 - 13:28:32 GMT
- Severity changed from Normal to Minor
- Part changed from Unspecified to RISC OS: Boot sequence
Modified by Sprow (202) Wed, November 05 2014 - 23:38:32 GMT
While I remember, there’s also a small niggle with !InetSetup with regards to virtual interfaces.
Since there’s no standard mechanism of figuring out if a virtual interface is enabled or not, the two that do support virtual interfaces immediately to hand are EtherB and EtherH, and they both use different CMOS bits to describe the option.
The result is if you had two cards, say podule 0 and 1, then that would be scanned by InetSetup and assigned unit numbers eh0 and eh1 which then appear in the setup dialogue. If you then enable the virtual interface on (say) eh0 and rerun InetSetup you end up with units eh0 and eh1 in the setup dialogue, when in fact eh0 is real/eh1 is virtual/eh2 is real but not shown.
The table of known podules is pretty small, so it might be easier to just add custom detection code for the subset that support virtual interfaces. Everything else uses an AutoSense file, again this can know the card specific virtual config bits too.