Recently I had to re-install an OpenSuse on a box a co-worker had installed about two years ago. After his native Linux installation had managed to shred a little data (roughly 1TB loss) on an external raid, I decided to put something decent on the box ;-)
Ok to be fair it was kind of a bad combination that the raid box had a failure on one of the ports and Linux kept writing happily to the drives despite the errors it must have encountered (at least there where log entries about write errors). Seems OpenSuse's default settings for Ext3 are a really *BAD* idea. It is set to "on error continue". Looks like a safe way to lose data.
Luckily not a real loss in data, raw data are in a safe place, but some guys have to re-run their compute jobs (and hopefully keep in mind to make a copy to our HSM once they're finished).
Well after all it is a Sun Box (x4600), so it is now running SXCE (b112 at the moment). ZFS handling the attached disks (now the raid box is down to simply a JBOD) just makes me sleep better ;-)
The Suse installation is now running as a xVM pvm domU. Solaris doing the disk I/O and sharing the data to the domU, Suse running Matlab.
domU installation was a bit trickier than the Fedora 8 install I did a while ago for a few other domUs. It took me a while to find the right combination to make the Suse domU boot off the virtual disk.
After that I decided to try out the crossbow stuff. Especially the etherstubs looked interesting. So two dladm commands later I had an etherstub (kind of a virtual network switch within Solaris) and a virtual nic setup. Plumb the vnic, set an IP address, ping the "switch" works just fine. So next thing I attached another nic to my domU and brigded it over the etherstub. The new vnic gets created by xVM and shows up in the domU.
Assign an IP address, send a ping and wait... and wait... and wait... I did expect an answer. Well, seems like something went wrong.
A little snooping on the Solaris instance and I see packets coming and going. They just never make it into the Linux world.
The only thing that made me wonder was the different MTU on Solaris and Linux. Solaris quite happily set the MTU to 9000, while Linux had it set to 1500. After ditching the vnics, setting the MTU on the etherstub to 1500 and recreating the vnic with MTU 1500 ping finally got an answer.
Not sure if this is a Solaris problem, a feature or something completely different. Though I tend to blame Linux for not supporting jumbo frames ;-)
Well maybe it does. But at least not for the xen-provided virtual network card.
So if you come to a point where you want to make a Linux domU talk to a Solaris box over an etherstub and lose the packets you may want to check the MTU setting.
Thursday, May 7, 2009
Monday, March 16, 2009
Thanks Igor (or how to get VT-x on a Sony notebook)
I already ranted about Sony disabling VT-x in all notebooks (except for the BZ line). They also don't want to release a BIOS were one could actually change settings other than boot device order. There have been tutorials about patching the NVRAM on models with a phoenix bios for quite some time. Unfortunately mine uses an UEFI based AMI Aptio bios so until now I was out of luck.
Checking for news on this issue again I came across a thread in an notebook related forum. That guy - Igor (an Intel Black Belt btw) - did an awesome job of reverse engineering on the bios structure and came up with a program that utilizes AMI's afudos to first dump the current bios, parse the resulting file for the pattern which disable VT-x, patch that to something more desirable ;-) and use afudos again to write back the patch bios image.
The challenge was to get a DOS bootdisk onto the usb pendrive, the rest worked just like a charm.
You can also go to his website directly and visit the download section.
Just phantastic work. For me it's now off to play xVM with hvms on the notebook!
Thanks a lot Igor!
Checking for news on this issue again I came across a thread in an notebook related forum. That guy - Igor (an Intel Black Belt btw) - did an awesome job of reverse engineering on the bios structure and came up with a program that utilizes AMI's afudos to first dump the current bios, parse the resulting file for the pattern which disable VT-x, patch that to something more desirable ;-) and use afudos again to write back the patch bios image.
The challenge was to get a DOS bootdisk onto the usb pendrive, the rest worked just like a charm.
You can also go to his website directly and visit the download section.
Just phantastic work. For me it's now off to play xVM with hvms on the notebook!
Thanks a lot Igor!
Tuesday, January 6, 2009
LCD panel backlight control vs Sony Vaio AW11Z part 2
Heureka!
Finished. The port of NVClock/SmartDimmer to OpenSolaris is complete. It works nicely on my notebook (and I only crashed it once on the way *g*)
A little reading, browsing source code and learning how to access PCI stuff was... ummm... interesting :-) Thankfully there exists a nice thing called libpciaccess which makes life a lot easier.
NVClock now has a Solaris backend that gives me the ability to control the backlight on my notebook.
For now the source code can be found here
Have a go and try it if you have a notebook with an NVidia graphics card. Please report if you have any issues with the Solaris specific part. Any comments are welcome. But please don't sue me if it blows your box into pieces ;-)
Mind you - smartdimmer and nvclock need to be run as priviledged user to set the registers on the graphics card.
I hope the author of NVClock accepts my patch so OpenSolaris gets supported out of the box.
The really amazing thing is how much battery time the backlight actually sucks. With the 'big' battery runtime went up by 1hour just by dimming from 100% down to 15%. PowerTop reports 40Watts vs 26.5Watts. That is just impressive!
Finished. The port of NVClock/SmartDimmer to OpenSolaris is complete. It works nicely on my notebook (and I only crashed it once on the way *g*)
A little reading, browsing source code and learning how to access PCI stuff was... ummm... interesting :-) Thankfully there exists a nice thing called libpciaccess which makes life a lot easier.
NVClock now has a Solaris backend that gives me the ability to control the backlight on my notebook.
For now the source code can be found here
Have a go and try it if you have a notebook with an NVidia graphics card. Please report if you have any issues with the Solaris specific part. Any comments are welcome. But please don't sue me if it blows your box into pieces ;-)
Mind you - smartdimmer and nvclock need to be run as priviledged user to set the registers on the graphics card.
I hope the author of NVClock accepts my patch so OpenSolaris gets supported out of the box.
The really amazing thing is how much battery time the backlight actually sucks. With the 'big' battery runtime went up by 1hour just by dimming from 100% down to 15%. PowerTop reports 40Watts vs 26.5Watts. That is just impressive!
Monday, January 5, 2009
LCD panel backlight control vs Sony Vaio AW11Z part 1
As mentioned in an earlier post, the backlight control on the Vaio doesn't work out of the box with OpenSolaris. A lot of googling and reading revealed that the backlight isn't controlled via ACPI but via the NVidia graphics card. A lot of more googling and reading lead me to a nifty little tool called nvclock / smartdimmer. It features a number of options to tweak some settings. One of the options is the brightness level of the panel backlight. Now there was just one problem. OpenSolaris isn't (yet) supported.
A little more reading and digging around the code...
Heureka!
I now have a first version which can dim the backlight of the panel. Still a lot of things hardcoded (only one graphics card, fixed base mem address). Still... it's the first step.
Battery time on the default battery went up by 35mins by dimming from 100% down to 15%.
Off to part two... and make the beast auto-detect the graphics card, fetch the base mem address etc.
As soon as I'm done with that I'll post it here and on the relevant list.
A little more reading and digging around the code...
Heureka!
I now have a first version which can dim the backlight of the panel. Still a lot of things hardcoded (only one graphics card, fixed base mem address). Still... it's the first step.
Battery time on the default battery went up by 35mins by dimming from 100% down to 15%.
Off to part two... and make the beast auto-detect the graphics card, fetch the base mem address etc.
As soon as I'm done with that I'll post it here and on the relevant list.
Subscribe to:
Posts (Atom)