Solaris / OpenSolarisThis forum is for the discussion of Solaris, OpenSolaris, OpenIndiana, and illumos.
General Sun, SunOS and Sparc related questions also go here. Any Solaris fork or distribution is welcome.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Ok, I am burnt out. Built a new pc to run Solaris 10 on. Did a great deal of research before purchasing the components. Twice now I have made bad decisions. My onboard lan and drivers with updates will not work. I purchased the D-Link DGE 560T pcie x1 adapter and after trying both Marvell and SysKonnect drivers. the driver will not attach. Contacted D-link and it appears that there card is just different enough that they only support Linux and offer no support for Solaris, they even have a paragraph on their web site that states " D-Link NICs do not support Sun Solaris, with the exception of the DFE-500TX and DE-220. "
I'd like to mention that this card is Sun Solaris verified. Go figure!
So as I package up my D-Link 560T for a refund I'm wondering does anybody no of a good pci or pcie ethernet adapter for a 64bit AMD running Solaris 10 ?
Maybe one that the drivers are already loaded or one that at least have drivers that work?
I'm considering the Intel EXPI9300PT 10/ 100/ 1000Mbps PCI-Express Gigabit. IT is Solaris 10 ready.
Having spent the better part of a day struggling with it. I have boxed it up for return. I might retry it if you thought there was a possibility of getting to work.
Googling the problem resulted in many others with the same problem.
This is what transpired that I recall from today:
scanpci -v
vendor : 0x1186
device: 0x4b00
Device Unknown
-----------------
I removed the pkg 98sol
I tried installing both of the available drivers
Marvell YUKONxsolx and SysKonnect SKGEsolx. they both error in the exact same place. Marvell even had a newer driver but that ended with the same results.
The error is:
Warning: Driver (skge) successfully added to system but failed to attach
SKGEsolx driver load failed: IP interfaces will not be configured!
pkgadd: ERROR: postinstall script did not complete successfully
Installation of <SKGEsolx> partially failed.
The post install script above this error shows about 30 lines of "Bad line in file etc/driver_aliase"
I know this isn't as much as you asked for but after 15 hours at it, well you know. What do you think ?
[B]Warning: Driver (skge) successfully added to system but failed to attach
Fred
This seems to me that the skge driver is allright.
Check with 'modinfo' to see if it's loaded.
Then you 're half way home.
The next step is, to add the proper vendor/device_id info (look at what jlliagre says!) to /etc/driver_aliases and rebuild the devicetree with devfsadm, so that the driver 'attaches' at next reboot.
Regs, C
Last edited by coolster; 12-23-2007 at 08:43 AM.
Reason: typoh
Many thanks to Jlliagre You have stayed with me through two interfaces and even though the first one was a bust this one finally works. The error that I had and everyone else had that I read about on the internet is just the two lines missing from /etc/driver_aliases in my case they are as follows:
yukonx pci"1186,4b00" and yukonx pci"1186,4b00"
I believe the reason the driver script doesn't write these is, when you use a interface not of the same manufacture that writes the driver, the driver script is written for their own interface cards and not other manufactures using their chips. The same will hold true whether using Marvell or Syskonnect drivers, they both produce their own interface cards and each has their own scripts and both scripts although similar result in the same error to us users who are trying to run there drivers on a different manufactures card, in my case D-Link DGE560T.
Why do you think Sun doesn't mention this problem, they state it is solaris verified but no explanation of procedures ?
Regs, C or Jlliagre;
I lose the driver and have to replumb after every reboot. Could you give me instructions on how to rebuild the devicetree with devfsadm, so that the driver 'attaches' at next reboot.
I lose the driver and have to replumb after every reboot. Could you give me instructions on how to rebuild the devicetree with devfsadm, so that the driver 'attaches' at next reboot.
After you 've done a succesful 'modload' of the driver "modload -p drv/skge' (or this has happened automagically), run 'devfsadm -i skge'.
But be sure that the vendor/device_id's in your /etc/driver_aliases are right; they play a big role in attaching the driver and configuring the IP stack.
Regs, C
BTW, Fred: it is not even Christmas..... :-)
Last edited by coolster; 12-23-2007 at 11:27 AM.
Reason: another typo
Distribution: Solaris 11.4, Oracle Linux, Mint, Debian/WSL
Posts: 9,789
Rep:
Quote:
Originally Posted by Fredsnet
The error that I had and everyone else had that I read about on the internet is just the two lines missing from /etc/driver_aliases in my case they are as follows:
yukonx pci"1186,4b00" and yukonx pci"1186,4b00"
They both look identical to me and their syntax is incorrect.
That should be: yukonx "pci1186,4b00"
Quote:
I believe the reason the driver script doesn't write these is, when you use a interface not of the same manufacture that writes the driver, the driver script is written for their own interface cards and not other manufactures using their chips. The same will hold true whether using Marvell or Syskonnect drivers, they both produce their own interface cards and each has their own scripts and both scripts although similar result in the same error to us users who are trying to run there drivers on a different manufactures card, in my case D-Link DGE560T.
Your analysis is correct.
Quote:
Why do you think Sun doesn't mention this problem, they state it is solaris verified but no explanation of procedures ?
Verified just means someone, likely outside Sun, has verified the card was working under Solaris. There is no commitment from either Sun or the card vendor that the card is supported. Adding a PCI card id to a driver is a common way to have it recognized, but as long as the driver developer doesn't do it itself, it is a hack done at one's own risk.
OK, let's start the procedure all over.
I presume you have this driver: Marvell Yukon Driver (SK-xxx) for Solaris of 'some' version.
First remove everything from your old installation of Marvell YUKONxsolx.
Then dive into the drivers' package, because you are gonig to modify the script ./SKGEsolx/installation/postinstallation. Edit 'add_drv' parameters list and put yours yukonx "pci1186,4b00" on the list.
Then run:
# pkgadd -d . SKGEsolx
Most likely, the installation will exit with the message that the original checksum of postinstallation script is AAAAA and differs from actual the BBBBB, or someting like that.
Edit ./SKGEsolx/pkgmap and put in postinstallation line instead of AAAAA value BBBBB.
Then, do run again:
# pkgadd -d . SKGEsolx
The script should now complete OK with the message that skge0 was plumbed and brought up.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.