I'll look into this... it certainly sounds like an unfortunate bug. I bet the problem is conflicting subsystem ids vs. vendor ids. Unfortunately, the two numbering spaces are supposed to be distinct, but Solaris treats them as a single space (per IEEE 1275, which is mis-specified, IMO.)
So the main problem is that "Solaris treats them as a single space"
If you can get yourself a 82578DC I could supply a PRO/100+ Dual Port so that you can plug both ids into a single machine and see which driver gets loaded.
November 25, 2009 at 1:11 AM
So there was some fallout from my mii push. Elxl devices had a nasty panic, which I fixed in time for build 119. Some older i82557 (iprb) devices had problems as well. The push for this fix went into build 120. To everyone affected, please accept my apologies. Build 120 should be stable for these devices.
posted by Garrett D'Amore at 9:07 PM on Jul 9, 2009
"mii related fallout"
3 Comments -
I've noticed another "fall out" when I upgraded to snv_126. the pci8086:10f0 was stolen from the iprb driver by e1000g.
Someone at intel thought it would be cool to have
pci8086:10f0 EtherExpress PRO/100+ Dual Port Adapter
and
pciex8086:10f0 82578DC Gigabit Network Connection
could you please get pci8086:10f0 back to iprb in /etc/driver_aliases?
Thanks
November 24, 2009 at 9:28 AM
I'll look into this... it certainly sounds like an unfortunate bug. I bet the problem is conflicting subsystem ids vs. vendor ids. Unfortunately, the two numbering spaces are supposed to be distinct, but Solaris treats them as a single space (per IEEE 1275, which is mis-specified, IMO.)
November 24, 2009 at 10:00 AM
In my driver_aliases I have changed the lines to
e1000g "pciex8086,10f0"
iprb "pci8086,10f0"
you sound as if this is unsupported.
So the main problem is that "Solaris treats them as a single space"
If you can get yourself a 82578DC I could supply a PRO/100+ Dual Port so that you can plug both ids into a single machine and see which driver gets loaded.
November 25, 2009 at 1:11 AM