ACPI horrors

Probably as a result of the old motherboard: Disabling ACPI seems to stop OpenSolaris crashing (with my recompiled kernel) when ls'ing /dev. This is done by adding acpi-user-options=2 to the boot environment variables. Attempted to force UDMA 5. dmesg still pops up Multiword DMA at various points, but no longer complains about ACPI.

Rebuilding the boot_archive

And when you've broken the boot-archive, repair it thusly.


touch /a/etc/system

and now re-create the boot_archive with the commands

cd /a [*]
bootadm update-archive -R /a

[*] The "cd /a" shouldn't be necessary, but there has been a problem
in the past with bootadm creating currupt boot archives when using
the -R option [**]. The "cd /a" works around that bug.

[**] http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6353553

Problems with the Promise IDE controller

So the problems still exist. It hung on ls'ing /dev.

I have a suspicion that the cause is the following bug. forceload: drv/ata didn't help. Am recompiling the kernel with the patch applied.

The following 2 links (1 & 2) provide an introduction to kernel debugging on bootup.

Promise IDE Ultra133 TX2 and OpenSolaris

Previously I had difficulties getting my Promise IDE PCI card working with OpenSolaris, even though others had success. However, having reinstalled and BFU'd to archives-20070101 I thought I'd have another go.

prtconf -pv

...
compatible: 'pci105a,4d69.105a.4d68.2' + 'pci105a,4d69.105a.4d68' + 'pci105a,4d68' + 'pci105a,4d69.2' + 'pci105a,4d69' + 'pciclass,018085' + 'pciclass,0180'
model: 'Unknown class of pci/pnpbios device'
power-consumption: 00000001.00000001
66mhz-capable:
devsel-speed: 00000002
interrupts: 00000001
max-latency: 00000012
min-grant: 00000004
subsystem-vendor-id: 0000105a
subsystem-id: 00004d68
unit-address: 'd'
class-code: 00018085
revision-id: 00000002
vendor-id: 0000105a
device-id: 00004d69
name: 'pci105a,4d68'
...


eeprom pci-ide=pci105a,4d68
reboot
+ *fingers crossed*

prtconf now shows:

device_type: 'pci-ide'
compatible: 'pci105a,4d69.105a.4d68.2' + 'pci105a,4d69.105a.4d68' + 'pci105a,4d68' + 'pci105a,4d69.2' + 'pci105a,4d69' + 'pciclass,018085' + 'pciclass,0180'
model: 'Unknown class of pci/pnpbios device'
power-consumption: 00000001.00000001
66mhz-capable:
devsel-speed: 00000002
interrupts: 00000001
max-latency: 00000012
min-grant: 00000004
subsystem-vendor-id: 0000105a
subsystem-id: 00004d68
unit-address: 'd'
class-code: 00018085
revision-id: 00000002
vendor-id: 0000105a
device-id: 00004d69
name: 'pci-ide'


Magic!

Reinstall

With issues building ON from source, and corruption in some of the base system packages (~500 pkgs as reported by pkgchk) I decided the easiest thing was to reinstall.

Quite quick to set up having done it once :). For users using DHCP, if opensolaris gives a hostname of "unknown" after reboot you need to poke the following files:
/etc/nodename -- your system hostname (the important one)
/etc/hostname. -- hostname for the interface
/etc/defaultdomain -- your domain

Monkeys in the DMA

So there were in fact Monkeys in the system.

The corruption didn't stop. Simply cp'ing a file would cause both the destination and source file to have different checksums. I memtest86'd the memory, ran format->analyze on the hd, and pulled my hair out -- to no avail.

However I noticed that corruption occurred when multiple disk accesses were taking place -- DMA seemed to be a likely cause.
# eeprom ata-dma-enabled=0
seemed to fix the problem at the cost of system speed.

It seems that Solaris has issues with IWill KK266's on board IDE controller. Restoring the BIOS to failsafe defaults seems to have had the desired effect. I suppose this is likely the cause of my original problem with boot corruption.

Installing Sun Studio 11 Compiler -- a nightmare

Getting started hacking on OpenSolaris requires a working copy of Sun Studio 11. Unfortunately gtar/tar refused to play ball.

At first I thought the archive was corrupt on the local akamai mirror. (Sun Download Manager said so...) However the folks on #opensolaris confirmed SDM is broken. Having downloaded the file under OS X, the md5sum was:

openssl md5 sunstudio11-ii-20060829-sol-x86.tar.Z
MD5(sunstudio11-ii-20060829-sol-x86.tar.Z)= b7c5ca71acb7a7a82dc4abcc4c04a355

Now things get odd:
scp'ing the file to my opensolaris machine, and the file sometimes doesn't md5sum to that value. Retry and it works.

Following the instructions, I should untar the file like so:
# mkdir /opt/SUNWspro
# cd /opt/SUNWspro
# /usr/sfw/bin/gtar -zxvf DOWNLOAD-DIRECTORY/sunstudio11-ii-DATE-PLATFORM.tar.Z
Unfortunately gtar dies with:
./contrib/xemacs-21.4.12/lib/xemacs/xemacs-packages/etc/jde/java/lib/
./contrib/xemacs-21.4.12/lib/xemacs/xemacs-packages/etc/jde/java/lib/bsh.jar
/usr/sfw/bin/gtar: Skipping to next header
/usr/sfw/bin/gtar: Archive contains obsolescent base-64 headers
/usr/sfw/bin/gtar: Error exit delayed from previous errors

and more worryingly:
openssl md5 /export/home/james/sunstudio11-ii-20060829-sol-x86.tar.Z
MD5(/export/home/james/sunstudio11-ii-20060829-sol-x86.tar.Z)= 6706958fe49af73a9c6a14c4fcf38e23
(yes the md5sum was correct before).

After banging my head on a brick wall #opensolaris suggested using tar (with an uncorrputed version of the file).

# zcat /export/home/james/sunstudio11-ii-20060829-sol-x86.tar.Z | tar -xvf -

Un-tarred without errors. Unfortunately the md5sum has once again changed. Are there monkeys in my system?
-bash-3.00$ openssl md5 sunstudio11-ii-20060829-sol-x86.tar.Z
MD5(sunstudio11-ii-20060829-sol-x86.tar.Z)= 19fb560e0f47c9ba9e7f2f1d055ac607

*worried*