Hardware :: Disks Seen In Same Order Than Slot Numbers

A linux box equipped with LSI MegaRAID SAS1078 controller has 4 SAS disks slots. Slots 1+2 holds disks that have been configured (using the LSI bios interface at boot time) as raid-mirror array (hence exported by the controller as one unique LUN). Slots 3 & 4 each holds disks that are not configured as RAID ("direct attached devices" or "raw devices"). The "scan order" numbers for each disk, as reported by the controller interface, are in the same order than the "slot numbers".

Grub (installed on MBR of slot 1+2 LUN) sees:
* slot 1+2 LUN as hd0
* slot 3 disk as hd1
* slot 4 disk as hd2

The Grub boot command says:
root (hd0,1)
kernel /vmlinuz-2.6.16 root=/dev/sda3
initrd /initrd-2.6.16.img
(hd0,0) is swap
(hd0,1) is /boot
(hd0,2) is /

The linux distro is SUSE (SLES10 SP2). Grub boots correctly (disks in slots 3 & 4 are empty, even no partitions; and as expected, grub tab-auto-completes hd0 with available partitions; on the other hand, grub also sees hd1 and hd2 with the the tab completion, but eventually without partitions behind).

Now the problem: The kernel loads, initrd as well with its bunch of modules, and then harddrives are detected by the scsi driver and there I see: ...
SCSI device sda: ...
sda: unknown partition table ...
SCSI device sdb: ...
sdb: unknown partition table ...
SCSI device sdc: ...
sdc: sdc1 sdc2 sdc3 sdc4 < sdc5 sdc6 sdc7 sdc8 sdc9 > ...

Indeed, shortly after, the sysinit fails mounting FS (because FSTAB addresses directly /dev/sdaN and not UUIDs nor UDEV persistent names). Please note that I do not want to use UUIDs nor LABELs (for personal reasons it's no use to detail here). I tried to change the disk order at the LSI raid bios level, but:
* this interface cannot change priority for LUNs, only for raw devices (and these raw device priorities are set according to slot numbering)
* Grub indeed sees disks correctly, so I think the problem happens only at the linux stage, not earlier.

I tried to look at UDEV persistent rules (in the /etc as well as in the initrd.img/etc after a cpio extract), but there is nothing human readable (nor any obvious aliases, like those we can find for eth cards for instance). It seems that linux sees hardware raid arrays after raw disks, though raw disks are in farther physical slots (and with higher ordering number on the controler) and hence orders them incorrectly. And that's not the behaviour I expect, since I thought the hardware RAID LUNs were seen exactly as raw devices at the linux level, so raid or not should not make any difference in the disks order.

All this story is rigorously reproductible after several boot attempts (i.e. no random discovery here). Is it related to existing udev rules (default rules from SLES10 SP2) I did not find? Or to some missing udev rules (explicit aliases) I should have added? Or to some other udev mechanism I should get rid of (or even get rid of udev completely!)? Or to something else (not udev related... perhaps the fact I also have LVMs and software raid management...)?