Well, responses were one of two possibilities: 1. Fix the hostname.hme0 file - this wasn't really relevant to the original question, as the problem was that while the device was being detected, it couldn't be plumbed. 2. "Manually" plumb the device - ifconfig plumb hmeX (where X is whatever instance is detected). This was what was failing, so repeating this didn't do the trick - instead it generated an "invalid address" error message, which I took to mean an invalid SBUS address (not IP). In any case, the solution ultimately proved to have nothing to do with "software" (OS configuration), but rather with the PROM itself. Evidently the PROM was not reporting a good address (SBUS presumeably) to the kernel, so when the hme module was loaded, it wasn't able to handle the instance of the new card. The card was detected during boot with two different instance numbers: /dev/hme1 and /dev/hme2 - /dev/hme0 was preserved for the on-board - depending on which SBUS slot was used. In the end, the solution was to update the PROM. There was an update available, and that had the effect of "resetting" or clearing the existing PROM, and I believe that's what fixed it. No similar bug was reported on SunSolve that I could find. I suspect that this means that if it were possible to reset or clear the prom in some other way, you could accomplish the same thing. This was very reminiscent of PCI interrupt conflicts when new hardware was added to early PCI systems (on PCs). Thanks as always for the extra suggestions...one can never have too many eyes. Scott ================================================================== Scott Ruffner Computer Systems Senior Engineer Computer Science Department ruffner@cs.virginia.edu University of Virginia (434)982-2219 http://www.cs.virginia.edu/~jpr9cReceived on Tue Jun 12 20:01:48 2001
This archive was generated by hypermail 2.1.8 : Wed Mar 23 2016 - 16:24:56 EDT