Monday, October 3, 2011
Wanted: Broken Garmin Nuvi 295w
Just looking for a Broken Garmin Nuvi 295w that I can pull apart to see how it looks. I am looking at hacking on the code Garmin provided, but don't want to take the chance on breaking my working Garmin 295w.
Thursday, January 13, 2011
Foxconn Small Form Factor R10-D2 WinXP experience
So one of the online retailers had a SFF Foxconn (R10-D2) box on sale in December with 4GB of ram and I added a sata DVD-RW into the mix for another $18. Not bad for $145 shipped.
A dual core Atom 1.6Ghz with Hyperthreading. I wasn't expecting much, but it had to better than the Dell Celeron my mom's been complaining about. Get around to it, enable AHCI (native SATA) and install Ubuntu-10.10 on it. Wow. This is not bad.
Let's try Windows XP, since that's what the Dell is running. No Go. Course, I am a bit of a Windows idiot, having done Solaris for nearly 20 years. Try a couple of times, No Go. Eventually email Foxconn support, and they say they've installed WinXP on that box. I then realize that I've enabled AHCI support in the bios, and it dawns on me that the drivers probably aren't found, especially for Windows XP.
It doesn't help that Foxconn didn't put the Intel Raid Drivers up in the driver area for the R10-D2, or even indicate what kind of motherboard was in the R10-D2 unit.
Eventually go back to IDE emulation for SATA and WinXP installs. Hmm. Email Foxconn support again. Finally, they point me at the Intel Raid Drivers up in the D51S motherboard section.
I use something called nlite to drop all the drivers into a slipstream'd WinXPSP3 disk and off I went. Last thing I needed was my USB floppy, with the 32-bit drivers extracted from the Intel Raid driver disk (the Foxconn Motherboard is called the D51S) in the top level directory with the magic oemsetup.txt file, and WinXPSP3 is happily installing. This was worth the effort and frustration, to learn that the Intel Raid Drivers is where they hide the native SATA (AHCI) drivers for WindowsXP, and that I no longer have to install in IDE mode, then do some very convoluted procedure to get AHCI working after an IDE install.
A dual core Atom 1.6Ghz with Hyperthreading. I wasn't expecting much, but it had to better than the Dell Celeron my mom's been complaining about. Get around to it, enable AHCI (native SATA) and install Ubuntu-10.10 on it. Wow. This is not bad.
Let's try Windows XP, since that's what the Dell is running. No Go. Course, I am a bit of a Windows idiot, having done Solaris for nearly 20 years. Try a couple of times, No Go. Eventually email Foxconn support, and they say they've installed WinXP on that box. I then realize that I've enabled AHCI support in the bios, and it dawns on me that the drivers probably aren't found, especially for Windows XP.
It doesn't help that Foxconn didn't put the Intel Raid Drivers up in the driver area for the R10-D2, or even indicate what kind of motherboard was in the R10-D2 unit.
Eventually go back to IDE emulation for SATA and WinXP installs. Hmm. Email Foxconn support again. Finally, they point me at the Intel Raid Drivers up in the D51S motherboard section.
I use something called nlite to drop all the drivers into a slipstream'd WinXPSP3 disk and off I went. Last thing I needed was my USB floppy, with the 32-bit drivers extracted from the Intel Raid driver disk (the Foxconn Motherboard is called the D51S) in the top level directory with the magic oemsetup.txt file, and WinXPSP3 is happily installing. This was worth the effort and frustration, to learn that the Intel Raid Drivers is where they hide the native SATA (AHCI) drivers for WindowsXP, and that I no longer have to install in IDE mode, then do some very convoluted procedure to get AHCI working after an IDE install.
Monday, January 10, 2011
4 systems, built same way, patch outcome different
Built a clustered system, 4 nodes, with Solaris 10 months ago. Finally hit enough problems that it's decided that finally we get our patch upgrade. zfs root rocks again, lucreate, lumount, pca, luactivate, init 6 and we're on the patched OS.
1) system 1 - /usr/java still pointing at jdk/jdk_1.6.0_14, appearently patch install failed. logs disagree... Reinstall patches and fix /usr/java *again*.
2) system 2 - /usr/java now pointing at jdk/jdk_1.5.0_27, huh? 1.5 now? Fix link.
3) system 3 - /usr/java now pointing at jdk/jdk_1.6.0_23, expected
4) system 4 - /usr/java now pointing at jdk/jdk_1.5.0_27. sheesh
You'd expect that 4 systems, built exactly the same way, patched exactly the same way, would have the same outcome from *deterministic* code from the patch install. The law on unintended consequences strikes again.
1) system 1 - /usr/java still pointing at jdk/jdk_1.6.0_14, appearently patch install failed. logs disagree... Reinstall patches and fix /usr/java *again*.
2) system 2 - /usr/java now pointing at jdk/jdk_1.5.0_27, huh? 1.5 now? Fix link.
3) system 3 - /usr/java now pointing at jdk/jdk_1.6.0_23, expected
4) system 4 - /usr/java now pointing at jdk/jdk_1.5.0_27. sheesh
You'd expect that 4 systems, built exactly the same way, patched exactly the same way, would have the same outcome from *deterministic* code from the patch install. The law on unintended consequences strikes again.
Subscribe to:
Posts (Atom)