Red Hat Bugzilla – Bug 232656
dmsetup not working for Promise FastTrak 20376 controller after upgrading from kernel 2.6.19-1.2911.6.5 to 2.6.20-1.2925
Last modified: 2007-11-30 17:11:59 EST
Description of problem: Specifically, I have a Promise FastTrak 376 controller (20376) controller with a Parallel IDE hard drive connected using the PATA/IDE port of this otherwise SATA controller. The controller is in the 'sda' position with a logical partition in sda5. Prior to upgrading from kernel 2.6.19 to 2.6.20, the rc.sysinit script was able to setup the device [though as indicated in the bug I reported (216078) back in November, I needed to manually add the line 'dmraid.static -ay -i' to rc.sysinit to set up the partition (pdc_ccdejaib5)]. Now not only is the partition not created but the device itself is not recognized so I cannot mount the disk. Specifically, BEFORE (kernel 2.6.19) 1] ls -al /dev/mapper, returns: crw------- 1 root root 10, 63 Mar 15 17:36 control brw-rw---- 1 root disk 253, 0 Mar 15 21:36 pdc_ccdejaib brw-rw---- 1 root disk 253, 1 Mar 15 21:36 pdc_ccdejaib5 2]Running: /sbin/dmsetup ls --target multipath --exec "/sbin/kpartx -a -p p" executes without error 3]Running: /sbin/dmraid.static -ay -i -v returns: RAID set "pdc_ccdejaib" already active INFO: Activating stripe RAID set "pdc_ccdejaib" RAID set "pdc_ccdejaib5" already active INFO: Activating partition RAID set "pdc_ccdejaib5" NOW (kernel 2.6.20): 1] ls -al /dev/mapper, returns: crw------- 1 root root 10, 63 Mar 15 16:18 control 2]Running: /sbin/dmsetup ls --target multipath --exec "/sbin/kpartx -a -p p" returns: No devices found 3]Running: /sbin/dmraid.static -ay -i -v returns: No RAID disks Of course 'fdisk -l' then no longer recognizes the /dev/sda device and I am not able to mount that drive anymore. Note that in both kernel 2.6.19 and 2.6.20, the kernel itself seems to recognize the Promise 20376 controller since lspci -v gives in both cases: 02:04.0 RAID bus controller: Promise Technology, Inc. PDC20376 (FastTrak 376) (rev 02) Subsystem: ASUSTeK Computer Inc. A7V8X motherboard Flags: bus master, 66MHz, medium devsel, latency 96, IRQ 19 I/O ports at b400 [size=64] I/O ports at b000 [size=16] I/O ports at a800 [size=128] Memory at eb800000 (32-bit, non-prefetchable) [size=4K] Memory at eb000000 (32-bit, non-prefetchable) [size=128K] Capabilities: [60] Power Management version 2 Also, not sure if this is relevant, but both before under kernel 2.6.19 and now under 2.6.20, the kernel logs the following error message: kernel: device-mapper: ioctl: 4.x.0-ioctl (2006-mm-dd) initialised: dm-devel@redhat.com kernel: device-mapper: table: 253:0: linear: dm-linear: Device lookup failed kernel: device-mapper: ioctl: error adding target to table I also noticed that under kernel 2.6.19, the version was 4.10.0, while the version under 2.6.20 is 4.11.0 -- did anything change here? So, in summary, any idea what happened between 2.6.19 and 2.6.20 that 'broke' dmraid for me? How reproducible: Every time :(
Can you post: - output of "lspci -vxn" for the controller - kernel boot logs for both 2.6.19 and 2.6.20 - output of "lsmod" command for each kernel
Just as some more detail: lsmod shows that the kernel has loaded the 'sata_promise' module Also, 'dmsetup -C info' returns: No devices found Again this all works on the same system if I just boot into the old kernel, so something must have changed in the new kernel so that somehow it still recognizes the controller but dmsetup no longer sees any devices on it!
Created attachment 150241 [details] dmesg for kernel 2.6.19
Created attachment 150243 [details] dmesg for kernel 2.6.20
Created attachment 150244 [details] lsmod for kernel 2.6.19
Created attachment 150245 [details] lsmod for kernel 2.6.20
Note that for consistency in creating the above attachments, I introduced a spurious line into my /etc/fstab file so that the kernel 2.6.19 boot kicks-out at the same point as 2.6.19 does (do to the unrecognized device on my promise controller). Since everything that happens after this is irrelevant to the problem this should reduce the size of the dmesg and lsmod files. Also, both 2.6.19 and 2.6.20 give the SAME results for lspci -vxn for the promise controller part: 02:04.0 0104: 105a:3376 (rev 02) Subsystem: 1043:809e Flags: bus master, 66MHz, medium devsel, latency 96, IRQ 19 I/O ports at b400 [size=64] I/O ports at b000 [size=16] I/O ports at a800 [size=128] Memory at eb800000 (32-bit, non-prefetchable) [size=4K] Memory at eb000000 (32-bit, non-prefetchable) [size=128K] Capabilities: [60] Power Management version 2 00: 5a 10 76 33 17 00 30 02 02 00 04 01 08 60 00 00 10: 01 b4 00 00 01 b0 00 00 01 a8 00 00 00 00 80 eb 20: 00 00 00 eb 00 00 00 00 00 00 00 00 43 10 9e 80 30: 00 00 00 00 60 00 00 00 00 00 00 00 0b 01 04 12
(In reply to comment #6) > Created an attachment (id=150245) [edit] > lsmod for kernel 2.6.20 That is not lsmod, it's lspci
*** This bug has been marked as a duplicate of 232600 ***