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, 20480000, 23887872, 71663616, 78675968,
         102400000, 214990848, 512000000, 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

Reply via email to