Boring background
-----------------
I finally picked up a pair of hard disks to use on the Promise
controller built into my MSI K7T266 Pro2 (Version 2.0) motherboard.
This is a FastTrack 100 "Lite" according to the boot-up screens.
The first problem was upgrading the BIOS, so that it could handle disks
larger than 128 Gbyte.
The second problem was compiling the Promise
PDC202{46|62|65|67|68|69|70} IDE support into the kernel. Without this
enabled the kernel would hang on boot, during the partition check:
Partition check:
/dev/ide/host0/bus0/target0/lun0: p1 < p5 p6 > p2 p3
/dev/ide/host2/bus0/target0/lun0:
With the "hde=noprobe hdg=noprobe" options I was able to boot, and look
at /proc/pci to discover this:
Bus 0, device 12, function 0:
RAID bus controller: Promise Technology, Inc. 20265 (rev 2).
With the drivers Promise driver compiled into the kernel a glorious
boot. I also added FastTrack support:
PDC20265: IDE controller on PCI bus 00 dev 60
PDC20265: chipset revision 2
ide: Found promise 20265 in RAID mode.
I'm not running any of the distributions that the Promise closed-source
drivers support, and in any case, I'm using gcc 3.2.2 and the modules
won't load into the kernel, since they were compiled with 2.mumble.
insmod reports that this is known not to work.
So I tried to get the pdcraid module to work. It would simply not
detect the RAID.
I saw some suggestions that Linux software RAID would be fine if you
don't need compatibility with non-Linux systems. Since this is a
Linux-only box, I tried that. Unfortunately there is no way to disable
the RAID features of the Promise built-in controller, at least not
through the boot screens. Additionally, the Promise BIOS demands that
there be a RAID array defined or it will automatically create one. When
I tried to access the disks separately through /dev/hde and /dev/hdg
this at first appeared to work, but then I started getting IDE errors,
the drivers did strange things like disabling DMA, and so on.
Software RAID not appear to be an option with the Promise IDE channels
on this motherboard.
Discovery
---------
I decided I really, really wanted to use the controller, so I started
playing around with the pdcraid.c source code. I'm using the Gentoo
2.4.20-r2 kernel, but I think this is the same as the 2.4.20 vanilla
kernel for the pdcraid.[ch] and ataraid.[ch] files.
I ended up looking at the disk by opening /dev/hde and looking for
something that matched the promise_raid_conf structure. I eventually
found one that was clearly the right place, because it has the string
"Promise Technology, Inc." in the promise_id string.
A couple of printk()'s later, and I discovered that the block that was
being read on the drives is not in fact the one that the Promise
controller uses to store RAID information. The information returned by
calc_pdcblock_offset() is wrong.
The numbers that are being used are:
ideinfo->capacity:320173056
ideinfo->head:255
ideinfo->sect:63
This returns:
lba:320159322
What it *should* return is:
lba:320172992
I've hardish-coded the correct value into this function, and it seems to
work:
lba = ideinfo->capacity - 64;
I can now load the module, fdisk /dev/ataraid/disc0/disc, create a file
system on /dev/ataraid/disc0/part1, and use it without any warnings or
errors appearing in any log files. Hooray for me.
I realise this is numerology at this point. What I don't have is any
understanding of how to go the next step, and get a general solution.
Solution Space
--------------
Possibilities:
- Check both the location defined in the current calc_pdcblock_offset()
as well as ideinfo->capacity - 64.
- Check both the location defined in the current calc_pdcblock_offset()
as well as ideinfo->capacity - (ideinfo->sect + 1).
- Check the location defined in the current calc_pdcblock_offset(), and
then scan backwards "a bit" to find the "Promise Technology, Inc."
string if not valid.
- Only scan, perhaps starting at the location defined by the current
calc_pdcblock_offset().
I don't consider scanning *too* dangerous in terms of getting the wrong
data, because there is also a CRC check and certain specific fields of
the structure that get matched. Speed shouldn't be a concern, since
this will only happen when the module is loaded. But I'm not an IDE
guru (obviously), and there may other considerations.
I'm not sure who maintains this code, but I'd be willing to offer a
patch, but I don't want to waste my time if this is better solved
another way.
--
Shane
