Disable X; Corruption on the Promise controller

To disable X:
dtconfig -d (man)

Used the now "working" Promise IDE controller to create a 5-disk RAID-Z. Unfortunately, all is not well in Promise-land. Copying data to the RAID works, however a scrub shows corruption on all disks hanging off the Promise controller. A quick zpool scrub corrects the problem however.

# zpool status -v
pool: tank
state: ONLINE
status: One or more devices has experienced an unrecoverable error. An
attempt was made to correct the error. Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
using 'zpool clear' or replace the device with 'zpool replace'.
see: http://www.sun.com/msg/ZFS-8000-9P
scrub: scrub completed with 0 errors on Sat Jan 13 09:22:07 2007
config:

NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz1 ONLINE 0 0 0
c1d0 ONLINE 0 0 0
c2d0 ONLINE 0 0 6
c2d1 ONLINE 0 0 3
c3d0 ONLINE 0 0 5
c3d1 ONLINE 0 0 2

errors: No known data errors

Thankfully(?!) corruption seems to be limited to the Promise Ultra133 TX2 controller. Monkeys in the DMA?

Also, with disk activity taking place, the system is perceptibly less interactive (than under UFS).

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.