Description of problem: a stock out-of-the-box install on a ATI SB600 Raid, configured with 2 Drives to a RAID0 goes wrong. from /var/log/messages: attempt to access beyond end of device sda: rw=0, want=1953278938, limit=976773168 Buffer I/O error on device sda2, logical block 1952877312 attempt to access beyond end of device sda: rw=0, want=1953278939, limit=976773168 Buffer I/O error on device sda2, logical block 1952877313 attempt to access beyond end of device sda: rw=0, want=1953278940, limit=976773168 Buffer I/O error on device sda2, logical block 1952877314 attempt to access beyond end of device sda: rw=0, want=1953278941, limit=976773168 Buffer I/O error on device sda2, logical block 1952877315 attempt to access beyond end of device sda: rw=0, want=1953278942, limit=976773168 Buffer I/O error on device sda2, logical block 1952877316 attempt to access beyond end of device sda: rw=0, want=1953278943, limit=976773168 Buffer I/O error on device sda2, logical block 1952877317 attempt to access beyond end of device sda: rw=0, want=1953278944, limit=976773168 Buffer I/O error on device sda2, logical block 1952877318 attempt to access beyond end of device sda: rw=0, want=1953278945, limit=976773168 Buffer I/O error on device sda2, logical block 1952877319 attempt to access beyond end of device sda: rw=0, want=1953278938, limit=976773168 Buffer I/O error on device sda2, logical block 1952877312 attempt to access beyond end of device sda: rw=0, want=1953278939, limit=976773168 attempt to access beyond end of device sda: rw=0, want=1953278940, limit=976773168 attempt to access beyond end of device sda: rw=0, want=1953278941, limit=976773168 attempt to access beyond end of device sda: rw=0, want=1953278942, limit=976773168 attempt to access beyond end of device sda: rw=0, want=1953278943, limit=976773168 attempt to access beyond end of device sda: rw=0, want=1953278944, limit=976773168 attempt to access beyond end of device sda: rw=0, want=1953278945, limit=976773168 Version-Release number of selected component (if applicable): dmraid-1.0.0.rc15-2.fc10.x86_64 2.6.27.9-159.fc10.x86_64 #1 SMP Tue Dec 16 14:47:52 EST 2008 x86_64 x86_64 x86_64 GNU/Linux $ lspci| grep -i raid 00:12.0 RAID bus controller: ATI Technologies Inc SB600 Non-Raid-5 SATA $ LANG=C fdisk -l Disk /dev/sda: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x000579fd Device Boot Start End Blocks Id System /dev/sda1 * 1 25 200781 83 Linux /dev/sda2 26 121586 976438732+ 8e Linux LVM Disk /dev/sdb: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x00000000 Disk /dev/sdb doesn't contain a valid partition table How reproducible: install F10 with all defaults on above hardware. (with a raid0 fakearray set in bios and brand new drives) Steps to Reproduce: 1. boot from install Media 2. anaconda shows/detect the raid as /dev/mapper/pdc_xxxxxx 3. select default layout and install 4. reboot Actual results: raid is not correctly set up, errors in /var/log/messages, possible data loss, when disk is filling up later. Expected results: Raid is detected and setup correctly. Additional info: i also got these errors on every bootup: ata1: softreset failed (device not ready) ata1: failed due to HW bug, retry pmp=0 ata2: softreset failed (device not ready) ata2: failed due to HW bug, retry pmp=0
additional info: $LANG=C cat /proc/partitions major minor #blocks name 8 0 488386584 sda 8 16 488386584 sdb 253 0 976642048 dm-0 253 1 200781 dm-1 253 2 976438732 dm-2 253 3 972783616 dm-3 253 4 3604480 dm-4 $LANG=C df Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/VolGroup00-LogVol00 957519500 3184212 905696108 1% / /dev/mapper/pdc_bcdfgchp1 194442 14253 170150 8% /boot tmpfs 899940 76 899864 1% /dev/shm best regards
I believe the problem to be the lack of support in dmraid for the metadata formats of the ati southbridges. I am affected as well, although in a debian system and with a sb750 (msotly similar). dmraid -r lists only one device, as the metadata on the second disk must be in a non-standard place. It lists it as pdc (as I believe ati controller is based on promise, which makes sense here). In fact, as of 1.0.0.rc15-2: dmraid -l asr : Adaptec HostRAID ASR (0,1,10) ddf1 : SNIA DDF1 (0,1,4,5,linear) hpt37x : Highpoint HPT37X (S,0,1,10,01) hpt45x : Highpoint HPT45X (S,0,1,10) isw : Intel Software RAID (0,1,01) jmicron : JMicron ATARAID (S,0,1) lsi : LSI Logic MegaRAID (0,1,10) nvidia : NVidia RAID (S,0,1,10,5) pdc : Promise FastTrack (S,0,1,10) sil : Silicon Image(tm) Medley(tm) (0,1,10) via : VIA Software RAID (S,0,1,10) dos : DOS partitions on SW RAIDs No ati in there :(. Have a look at http://fedoraforum.org/forum/showpost.php?s=aed2c99e4e1576b11c73b44fe5e44a4e&p=821387&postcount=2 nevertheless. It happens to me with both full and partial arrays in a disk, with HPA enabled or disabled in a 2.6.26 amd64 kernel, and in both raid0 and raid1 modes.
I solved the problem of missing sb600 /sb700 /sb750 raid detections. The problem is due to a new offset used on some sb600/700/750. After a bit of search I identified the new value to add. I already posted the details on ataraid ML https://www.redhat.com/archives/ataraid-list/2009-March/msg00005.html Although I had no reply so far. Just 3 bytes of patch and a lot of headaches will be avoided to all Fedora/RH users
switched to F11 now, it seems not an issue anymore. The "Buffer I/O Errors" are gone and the raid is detected automatical and can be configured via anaconda, without any patch. But I'm quit unsure, if the raid is "healthy" because "fdisk" says on all raid-member disks: "/dev/sdX doesn't contain a valid partition table" This may be normal and logical an a Raid0 (?) dmraid is happy with my configuration, with or without the above patch. (i tested it with dmraid-1.0.0.rc15-7.fc11.x86_64.) But i notice, that something is wrong on my single disk (non raid member), which is also configured via anaconda on install-time together with the raid: Disk /dev/sdd: 160.0 GB, 160041885696 bytes 255 heads, 63 sectors/track, 19457 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0xce52ce52 Device Boot Start End Blocks Id System /dev/sdd1 * 1 26 204800 83 Linux Partition 1 does not end on cylinder boundary. /dev/sdd2 26 18936 151895361 83 Linux /dev/sdd3 18936 19457 4188160 83 Linux But this seems maybe a complete other issue. Best regards
I think the problem is still there with fedora 11. I have a GA-MA69GM-S2H board (with F6 bios - the latest), and I tried to install a clean install on a raid 1 using two identical disks. The installer showed the array as a single device, but the installed system has major problems. First of all, the system failed to boot. The first partition of the disk although recognised during boot, cannot be mounted, as no device is created for it. The rest of the partitions are fine. This partition with no device is the /boot partition (obviously used during boot). I had to remove it from fstab to get a working system. After the system boots, if I start gparted (which scans the disks) then the device is instantly created and shows up in the desktop through automount. Really strange... The other issue of course is that the two raid 1 disks show up as two different disks in fedora 11. The raid array is not recognised. The second disk is shown as unformatted.
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
Metadata offsets have been added to dmraid in the current release in order to address this issue. Please test and open a new bug if the problem still persists.