Re: [SLUG] Adaptec RAID problems
Thanks for your persistence Ben, I reduced the size of the array to a 2Gb RAID 1 and experienced the same problem. I've worked out that I can load more recent firmware using a more recent version of Sun Common Array Manager. The firmware load failed in RHEL so I'll have to wait until Sun has sorted that out. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Adaptec RAID problems
On Thu, Jul 15, 2010 at 05:53:13AM +0800, Robert Barnett wrote: Thanks for your persistence Ben, I reduced the size of the array to a 2Gb RAID 1 and experienced the same problem. I've worked out that I can load more recent firmware using a more recent version of Sun Common Array Manager. The firmware load failed in RHEL so I'll have to wait until Sun has sorted that out. How about try Software RAID? Nick. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Adaptec RAID problems
Hi Nick, Actually, I originally had 5x1Tb in a LVM group and that suited me fine. The HBA didn't support RAID for some reason. The only problem was that Fedora 11 udev tended to timeout when attempting to detect the individual disks. The only way to solve the problem was to plug in the SAS cable after the Fedora had booted and the detection was successful. Here is a post on fedora forum and entry in bugzilla: http://forums.fedoraforum.org/showthread.php?t=243493highlight=J4200 https://bugzilla.redhat.com/show_bug.cgi?id=582094 We upgraded the HBA to one which supported RAID and I decided on Fedora 13 (since Fedora 11 is now EOL). In Fedora 13, udev doesn't appear to detect individual disks. I'm guessing that the default behaviour for the new Adaptec driver in this kernel is not to expose physical components of the arrays (expose_physicals=0). I can probably try to override the driver preference and see what the IO is like to individual disks. Perhaps the problem will go away once I've installed the necessary firmware. I'm very tempted to run a chroot Gentoo from within RedHat. I really need a recent version of linux for development purposes, but it needs to sit on a vendor supported OS. I brought up a chroot image as a way to distribute GEANT -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Adaptec RAID problems
Hi, Thanks for the pointers. Is it possible that the HBA driver loads the firmware onto the drives? I've tried the harddrive vendor (Hitachi), but they don't release firmware updates. I reduced the size of the array to 4x2Tb RAID10 (4Tb redundant). Perhaps I'll try a smaller size to see if I have the same problem. The easiest way to replicate the problem is to run hdparm -t /dev/sda I get about 400kB/s on the problem RAID. The aacraid driver seems to mask single disks. AFAIK This prevents the driver timingout during bootup I've removed all LVMs so I can use modprobe and rmmod to experiment with different module options without restarting. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Adaptec RAID problems
Hi Robert, I don't know about that the HBA driver loads the firmware onto the drives? I've updated HP drives firmware and fixed strange problems. Didn't know they were Hitachi drives. I've tried the harddrive vendor (Hitachi), but they don't release firmware updates. I reduced the size of the array to 4x2Tb RAID10 (4Tb redundant). Perhaps I'll try a smaller size to see if I have the same problem. The easiest way to replicate the problem is to run hdparm -t /dev/sda I get about 400kB/s on the problem RAID. Suggest doing a small raid 5 array (10gb) with 3 drives. Does this work? Could be a faulty drive or the large size has a bug. If it does not work as a small array it won't work as a large one. Ben -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] Adaptec RAID problems
Hi, I am attempting to run Fedora 13 on a SunFire X4140 with an external Sun StorageTek enclosure with 7x2Tb disks. Fedora 13 boots of a single internal SAS drive. The HBA is an Adaptec AAC-RAID (rev 09). I have successfully created a RAID array using the adaptec BIOS. I have also successfully created a logical volume which is 7.99Tb. I attempted to create a filsystem on the the 7x2Tb RAID array from Fedora 13 but it didn't work. The computer hangs periodically and generates kernel warnings. I suspected that it is an issue related to the Adaptec RAID driver, so I downloaded the supported drivers from Sun. http://www.intel.com/support/go/sunraid.htm The most recent drivers for the external HBA adapter as supplied by Sun are at the level aacraid_1.1.5_2463. I compiled these into the Fedora kernel today and recreated the filesystem, however, I had the same problem. I have installed RedHat EL5 on another partition to help with diagnosing the problem. I've rebooted into Redhat and created the filesystem using the same command. This seemed to run perfectly fine (however I stopped it early because it would take several hours to complete). The baseline version of the Adaptec driver installed by Redhat EL5 is Adaptec aacraid driver 1.1-5[2437]-mh4 It appears that there are no hardware issues with the 7x2Tb array. I would prefer not to upgrade the firmware because it seemed to cause problems with RedHat EL5. Is there anyone in Sydney who had experience with running Fedora on Sun/Oracle Hardware? Thanks Robbie. Here are the Fedora 13 errors below. Code: [r...@petfire]# mkfs.ext3 -L mars /dev/mapper/vg_mars-lv_mars mke2fs 1.41.10 (10-Feb-2009) Filesystem label=mars OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=0 blocks, Stripe width=0 blocks 536207360 inodes, 2144799744 blocks 107239987 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=4294967296 65455 block groups 32768 blocks per group, 32768 fragments per group 8192 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 2048, 23887872, 71663616, 78675968, 10240, 214990848, 51200, 550731776, 644972544, 1934917632 Writing inode tables: 811/65455 Message from sysl...@localhost at Jul 13 12:15:46 ... kernel:Stack: Message from sysl...@localhost at Jul 13 12:15:46 ... kernel:Call Trace: Message from sysl...@localhost at Jul 13 12:15:46 ... kernel: IRQ Message from sysl...@localhost at Jul 13 12:15:46 ... kernel: EOI Message from sysl...@localhost at Jul 13 12:15:46 ... kernel:Code: e8 91 ed ff ff 85 c0 74 17 49 8b 84 24 60 01 00 00 89 58 44 49 8b 84 24 60 01 00 00 44 89 68 2c 49 8b 84 24 60 01 00 00 8b 58 44 83 fb ff 75 cb b8 01 00 00 00 5b 5b 41 5c 41 5d c9 c3 55 48 89 817/65455 -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Adaptec RAID problems
Hi, is it able to make a small array across all disks? Like a 10GB array? Then progressively make larger arrays? What about making a small array using only three disks? Then add some disks? It might help in diagnosing the problem. Ben On 13/07/2010 1:18 PM, Robert Barnett wrote: Hi, I am attempting to run Fedora 13 on a SunFire X4140 with an external Sun StorageTek enclosure with 7x2Tb disks. Fedora 13 boots of a single internal SAS drive. The HBA is an Adaptec AAC-RAID (rev 09). I have successfully created a RAID array using the adaptec BIOS. I have also successfully created a logical volume which is 7.99Tb. I attempted to create a filsystem on the the 7x2Tb RAID array from Fedora 13 but it didn't work. The computer hangs periodically and generates kernel warnings. I suspected that it is an issue related to the Adaptec RAID driver, so I downloaded the supported drivers from Sun. http://www.intel.com/support/go/sunraid.htm The most recent drivers for the external HBA adapter as supplied by Sun are at the level aacraid_1.1.5_2463. I compiled these into the Fedora kernel today and recreated the filesystem, however, I had the same problem. I have installed RedHat EL5 on another partition to help with diagnosing the problem. I've rebooted into Redhat and created the filesystem using the same command. This seemed to run perfectly fine (however I stopped it early because it would take several hours to complete). The baseline version of the Adaptec driver installed by Redhat EL5 is Adaptec aacraid driver 1.1-5[2437]-mh4 It appears that there are no hardware issues with the 7x2Tb array. I would prefer not to upgrade the firmware because it seemed to cause problems with RedHat EL5. Is there anyone in Sydney who had experience with running Fedora on Sun/Oracle Hardware? Thanks Robbie. Here are the Fedora 13 errors below. Code: [r...@petfire]# mkfs.ext3 -L mars /dev/mapper/vg_mars-lv_mars mke2fs 1.41.10 (10-Feb-2009) Filesystem label=mars OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=0 blocks, Stripe width=0 blocks 536207360 inodes, 2144799744 blocks 107239987 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=4294967296 65455 block groups 32768 blocks per group, 32768 fragments per group 8192 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 2048, 23887872, 71663616, 78675968, 10240, 214990848, 51200, 550731776, 644972544, 1934917632 Writing inode tables: 811/65455 Message from sysl...@localhost at Jul 13 12:15:46 ... kernel:Stack: Message from sysl...@localhost at Jul 13 12:15:46 ... kernel:Call Trace: Message from sysl...@localhost at Jul 13 12:15:46 ... kernel:IRQ Message from sysl...@localhost at Jul 13 12:15:46 ... kernel:EOI Message from sysl...@localhost at Jul 13 12:15:46 ... kernel:Code: e8 91 ed ff ff 85 c0 74 17 49 8b 84 24 60 01 00 00 89 58 44 49 8b 84 24 60 01 00 00 44 89 68 2c 49 8b 84 24 60 01 00 00 8b 58 4483 fb ff 75 cb b8 01 00 00 00 5b 5b 41 5c 41 5d c9 c3 55 48 89 817/65455 -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Adaptec RAID problems
Hi again, another thought... I've problems in the past with disks that had various firmware versions in an array. You can update disk firmware also. Are all disks updated to the latest firmware release? Ben On 13/07/2010 1:18 PM, Robert Barnett wrote: Hi, I am attempting to run Fedora 13 on a SunFire X4140 with an external Sun StorageTek enclosure with 7x2Tb disks. Fedora 13 boots of a single internal SAS drive. The HBA is an Adaptec AAC-RAID (rev 09). I have successfully created a RAID array using the adaptec BIOS. I have also successfully created a logical volume which is 7.99Tb. I attempted to create a filsystem on the the 7x2Tb RAID array from Fedora 13 but it didn't work. The computer hangs periodically and generates kernel warnings. I suspected that it is an issue related to the Adaptec RAID driver, so I downloaded the supported drivers from Sun. http://www.intel.com/support/go/sunraid.htm The most recent drivers for the external HBA adapter as supplied by Sun are at the level aacraid_1.1.5_2463. I compiled these into the Fedora kernel today and recreated the filesystem, however, I had the same problem. I have installed RedHat EL5 on another partition to help with diagnosing the problem. I've rebooted into Redhat and created the filesystem using the same command. This seemed to run perfectly fine (however I stopped it early because it would take several hours to complete). The baseline version of the Adaptec driver installed by Redhat EL5 is Adaptec aacraid driver 1.1-5[2437]-mh4 It appears that there are no hardware issues with the 7x2Tb array. I would prefer not to upgrade the firmware because it seemed to cause problems with RedHat EL5. Is there anyone in Sydney who had experience with running Fedora on Sun/Oracle Hardware? Thanks Robbie. Here are the Fedora 13 errors below. Code: [r...@petfire]# mkfs.ext3 -L mars /dev/mapper/vg_mars-lv_mars mke2fs 1.41.10 (10-Feb-2009) Filesystem label=mars OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=0 blocks, Stripe width=0 blocks 536207360 inodes, 2144799744 blocks 107239987 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=4294967296 65455 block groups 32768 blocks per group, 32768 fragments per group 8192 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 2048, 23887872, 71663616, 78675968, 10240, 214990848, 51200, 550731776, 644972544, 1934917632 Writing inode tables: 811/65455 Message from sysl...@localhost at Jul 13 12:15:46 ... kernel:Stack: Message from sysl...@localhost at Jul 13 12:15:46 ... kernel:Call Trace: Message from sysl...@localhost at Jul 13 12:15:46 ... kernel:IRQ Message from sysl...@localhost at Jul 13 12:15:46 ... kernel:EOI Message from sysl...@localhost at Jul 13 12:15:46 ... kernel:Code: e8 91 ed ff ff 85 c0 74 17 49 8b 84 24 60 01 00 00 89 58 44 49 8b 84 24 60 01 00 00 44 89 68 2c 49 8b 84 24 60 01 00 00 8b 58 4483 fb ff 75 cb b8 01 00 00 00 5b 5b 41 5c 41 5d c9 c3 55 48 89 817/65455 -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
