I recently decided that I wanted to create a zone with an exclusive IP instance, so that I could run IPsec (and specifically "punchin") in it. I have lots of NICs floating around, so I thought it would be trivial.
Turns out that all my NICs were GLDv2, and that IP instances requires GLDv3.
My solution? Conversion of mxfe (which were the cards I have in my system) to GLDv3. I figured it would be easier/faster than going out and buying a new Realtek card. And it would have been if not for one really annoying problem in mcopymsg() (see my previous post for that rant.)
Anyway, mxfe is humming away nicely now as a GLDv3 NIC on my system. I even got VLANs working with full MTU frames. Yay. I filed PSARC 2007/291 today, if you're interested in it. I'll post the driver sources up somewhere shortly.
(On another note, mxfe and afe are "suboptimal" drivers... they just blindly bcopy data, do nothing to reduce tx interrupts, and basically violate all the normal rules for making performant NIC drivers. But they work pretty well, for all that.)
Tuesday, May 22, 2007
Why Side Effects Are Bad
This entry could just as easily been titled "Why Bad Documentation is Worse Than No Documentation".
I noticed that some functions from strsun.h are now part of the DDI. Great, I thought, I'll update my driver to use them as part of the general GLDv3 cleanup.
One major surprise, which I spent about 5-6 hours figuring out tonight. mcopymsg(9f) has a side effect that isn't documented!
Specifically, it does freemsg() on the buffer passed in.
Don't believe me? Check the source!
The manual page says nothing about this. And reading logically from the name, you'd not think it would do this. The side effect should never have been designed in, in the first place. But if the man page referenced this side effect, I might, just might have caught this problem a couple of hours ago.
In my particular case, it was causing hard hangs most of the time. Until I finally got a panic that pointed me into the root of the problem. (Yes, I probably should have set kmem_flags != 0. Next time.)
/me throws brick at whoever wrote and edited the man page.
/me throws pallet of bricks at whoever designed mcopymsg with this side effect in the first place
Arrgh. Well, this will probably help me figure out several problems I've run into lately.
I noticed that some functions from strsun.h are now part of the DDI. Great, I thought, I'll update my driver to use them as part of the general GLDv3 cleanup.
One major surprise, which I spent about 5-6 hours figuring out tonight. mcopymsg(9f) has a side effect that isn't documented!
Specifically, it does freemsg() on the buffer passed in.
Don't believe me? Check the source!
The manual page says nothing about this. And reading logically from the name, you'd not think it would do this. The side effect should never have been designed in, in the first place. But if the man page referenced this side effect, I might, just might have caught this problem a couple of hours ago.
In my particular case, it was causing hard hangs most of the time. Until I finally got a panic that pointed me into the root of the problem. (Yes, I probably should have set kmem_flags != 0. Next time.)
/me throws brick at whoever wrote and edited the man page.
/me throws pallet of bricks at whoever designed mcopymsg with this side effect in the first place
Arrgh. Well, this will probably help me figure out several problems I've run into lately.
Sunday, May 13, 2007
ZFS to the rescue!
So this weekend I had to do a system reinstall. Thankfully I had all my data on a pair of sata drives in a ZFS raidz. But I had to totally reinstall my system with a new motherboard, new SATA controller, etc.
I had to redo a bunch of things manually... NIS, passed, DHCP, etc.
The one thing that I didn't have to worry about: ZFS. I just plugged my SATA drives in, and did "zpool import -f data" (my dataset was called "data", which I could have figured out by just doing "zfs import" without options.)
That was it. One command only, and my raidz mirror was back in business, mounted in the right place, and even the right ZFS fileystems were NFS exported with the right options. Thank-you ZFS!
ZFS developers, I owe you a round, or three. Let me know if you want want to collect. :-)
I had to redo a bunch of things manually... NIS, passed, DHCP, etc.
The one thing that I didn't have to worry about: ZFS. I just plugged my SATA drives in, and did "zpool import -f data" (my dataset was called "data", which I could have figured out by just doing "zfs import" without options.)
That was it. One command only, and my raidz mirror was back in business, mounted in the right place, and even the right ZFS fileystems were NFS exported with the right options. Thank-you ZFS!
ZFS developers, I owe you a round, or three. Let me know if you want want to collect. :-)
Favorite things in OpenSolaris not in Solaris 10
A few things that I love about OpenSolaris, but that Solaris 10 lacks:
* Xorg default support for Intel GMA 950
* SATA ATAPI device support
* WPA (coming in build 64)
* NWAM (network auto-magic)
* DMFE is GLDv3
I'm not sure which of these will be coming to a Solaris 10 update in the future, but I can tell you I was immensely pleased with my upgrade from Solaris 10 update 4 (on a Intel mobo, with a Core 2 Duo cpu) to Solaris Nevada b62. As part of the deal, I switched to a SATA DVD drive; my system is now entirely SATA (no legacy PATA ribbon cables in the box!)
I'm sure there are lots of other useful features too, but at this point, I've put Nevada into "production" use at home, and I'm not looking back.
(And yes, I realize b62 isn't the latest, but I didn't have a copy of snv_63, and the machine I was "reinstalling" ... thanks to an unexpected mobo replacement, was my network server.)
* Xorg default support for Intel GMA 950
* SATA ATAPI device support
* WPA (coming in build 64)
* NWAM (network auto-magic)
* DMFE is GLDv3
I'm not sure which of these will be coming to a Solaris 10 update in the future, but I can tell you I was immensely pleased with my upgrade from Solaris 10 update 4 (on a Intel mobo, with a Core 2 Duo cpu) to Solaris Nevada b62. As part of the deal, I switched to a SATA DVD drive; my system is now entirely SATA (no legacy PATA ribbon cables in the box!)
I'm sure there are lots of other useful features too, but at this point, I've put Nevada into "production" use at home, and I'm not looking back.
(And yes, I realize b62 isn't the latest, but I didn't have a copy of snv_63, and the machine I was "reinstalling" ... thanks to an unexpected mobo replacement, was my network server.)
Learning to hate SMF
Some of you may recall my recent putback of the removal of in.tnamed.
Well, there has been some nasty fallout, thanks to SMF and the upgrade process. snv64 (which will have to be respun as a result of this nastiness) was hanging during upgrade, thanks to chicken and egg dependencies in the upgrade script.
I fixed the hang, but there is a warning message coming from inetd that I can't seem to locate.
Along the way, I've found references to the network/tname service in a few surprising places. The things I've had to edit, thanks to SMF:
usr/src/tools/scripts/bfu.sh
usr/src/pkgdefs/SUNWcsr/postinstall
usr/src/cmd/svc/profile/generic_net_limited.xml
usr/src/cmd/svc/prophist/prophist.SUNWcsr
usr/src/cmd/cmd-inet/usr.sbin/tname.xml (removed)
And *still* we see a warning from inetd. See 6556092 in bugster for more info.
Anyway, I'm waiting for folks to decide whether to allow the warning to stay, or to backout the change to remove in.tnamed. If the later is taken, I will run screaming from the process, and just leave in.tnamed alone.
In my opinion, removing the tname.xml should have been sufficient. But thanks to SMF's binary databases, it creates a major headache. Can someone from the SMF team please unravel this maze?
Well, there has been some nasty fallout, thanks to SMF and the upgrade process. snv64 (which will have to be respun as a result of this nastiness) was hanging during upgrade, thanks to chicken and egg dependencies in the upgrade script.
I fixed the hang, but there is a warning message coming from inetd that I can't seem to locate.
Along the way, I've found references to the network/tname service in a few surprising places. The things I've had to edit, thanks to SMF:
usr/src/tools/scripts/bfu.sh
usr/src/pkgdefs/SUNWcsr/postinstall
usr/src/cmd/svc/profile/generic_net_limited.xml
usr/src/cmd/svc/prophist/prophist.SUNWcsr
usr/src/cmd/cmd-inet/usr.sbin/tname.xml (removed)
And *still* we see a warning from inetd. See 6556092 in bugster for more info.
Anyway, I'm waiting for folks to decide whether to allow the warning to stay, or to backout the change to remove in.tnamed. If the later is taken, I will run screaming from the process, and just leave in.tnamed alone.
In my opinion, removing the tname.xml should have been sufficient. But thanks to SMF's binary databases, it creates a major headache. Can someone from the SMF team please unravel this maze?
Subscribe to:
Posts (Atom)