kernel-2.6.17-1.2145_FC5 still won't boot Promise Raid 0 LVM Set

[Zoltan Boszormenyi]

Zoltan Boszormenyi írta:
> Zoltan Boszormenyi írta:
>> Hi,
>>
>> Andrew Gray írta:
>>> Under kernel-2.6.16-1.2133 my system boots a raid 0 volume on a Promise
>>> PDC 20376 that looks like:-
>>>
>>> [root at www ~]# dmraid -s
>>> *** Active Set
>>> name   : pdc_fiagfhab
>>> size   : 625163264
>>> stride : 128
>>> type   : stripe
>>> status : ok
>>> subsets: 0
>>> devs   : 2
>>> spares : 0
>>>
>>> All FC5 kernel-2.6.17's including 2145  won't boot on my system. The
>>> boot volume is a raid
>>> 0 array on a Promise PDC20376 (FastTrak) :-
>>>
>>> #Loading jbd.ko module
>>> #Loading ext3.ko module
>>> #Locading dm-mod.ko module
>>> #device-mapper: 4.6.0-ioctl (2006-02-17) initialised:
>>> dm-devel at redhat.com
>>> #Loading dm-mirror.ko module
>>> #Loading dm-zero.ko module
>>> #Loading dm-snapshot.ko module  #Making device-mapper control mode
>>> Kernel 2.6.17-2145_FC5 Then hangs !!
>>>
>>> I am presuming kernel-2.6.17 kernels doesn't boot because it is not
>>> recognising my LVM volume setup with 2.6.16 kernel
>>> using /dev/mapper/pdc_fiagfhabp2 on the Promise PDC20376. Maybe it has
>>> changed the device mapper name for this device? :-
>>>   
>>
>> I don't know, I may have the same problem.
>> I upgraded to RawHide from my FC5/x86-64
>> about the same time as kernel-2.6.17-1.2139_FC5
>> came out so I don't know which change caused it.
>
> I  think I wasn't clear. I have tried both the FC5 kernel
> and the Rawhide kernel.

2.6.17-1.2356.fc6 works for me although I get this on boot:

device-mapper: ioctl: 4.7.0-ioctl (2006-06-24) initialised: 
dm-devel at redhat.com
device-mapper: multipath: version 1.0.4 loaded
device-mapper: multipath round-robin: version 1.0.0 loaded

=============================================
[ INFO: possible recursive locking detected ]
---------------------------------------------
init/1 is trying to acquire lock:
 (&bdev->bd_mutex){--..}, at: [<ffffffff802692e0>] mutex_lock+0x2a/0x2e

but task is already holding lock:
 (&bdev->bd_mutex){--..}, at: [<ffffffff802692e0>] mutex_lock+0x2a/0x2e

other info that might help us debug this:
1 lock held by init/1:
 #0:  (&bdev->bd_mutex){--..}, at: [<ffffffff802692e0>] mutex_lock+0x2a/0x2e

stack backtrace:

Call Trace:
 [<ffffffff80271910>] show_trace+0xaa/0x23d
 [<ffffffff80271ab8>] dump_stack+0x15/0x17
 [<ffffffff802aa816>] __lock_acquire+0x135/0xa54
 [<ffffffff802ab6d6>] lock_acquire+0x4b/0x69
 [<ffffffff80269103>] __mutex_lock_slowpath+0xec/0x29f
 [<ffffffff802692e0>] mutex_lock+0x2a/0x2e
 [<ffffffff80343bae>] blkdev_ioctl+0x571/0x6b7
 [<ffffffff802e55fc>] block_ioctl+0x1b/0x1f
 [<ffffffff802456a8>] do_ioctl+0x2a/0x77
 [<ffffffff80233404>] vfs_ioctl+0x25a/0x277
 [<ffffffff80250805>] sys_ioctl+0x5f/0x82
 [<ffffffff80262d8e>] system_call+0x7e/0x83
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
audit(1152293480.440:2): enforcing=1 old_enforcing=0 auid=4294967295
security:  3 users, 6 roles, 1457 types, 156 bools, 1 sens, 256 cats

Best regards,
Zoltán Böszörményi