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
dmsetup not working for Promise FastTrak 20376 controller after upgrading fro...
Status: CLOSED DUPLICATE of bug 232600
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-16 11:02 EDT by Need Real Name
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-03-16 13:31:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg for kernel 2.6.19 (22.04 KB, text/plain)
2007-03-16 11:50 EDT, Need Real Name
no flags Details
dmesg for kernel 2.6.20 (23.05 KB, text/plain)
2007-03-16 11:52 EDT, Need Real Name
no flags Details
lsmod for kernel 2.6.19 (2.99 KB, text/plain)
2007-03-16 11:54 EDT, Need Real Name
no flags Details
lsmod for kernel 2.6.20 (7.60 KB, text/plain)
2007-03-16 11:54 EDT, Need Real Name
no flags Details

  None (edit)
Description Need Real Name 2007-03-16 11:02:33 EDT
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 :(
Comment 1 Chuck Ebbert 2007-03-16 11:16:57 EDT
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

Comment 2 Need Real Name 2007-03-16 11:27:09 EDT
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!
Comment 3 Need Real Name 2007-03-16 11:50:57 EDT
Created attachment 150241 [details]
dmesg for kernel 2.6.19
Comment 4 Need Real Name 2007-03-16 11:52:14 EDT
Created attachment 150243 [details]
dmesg for kernel 2.6.20
Comment 5 Need Real Name 2007-03-16 11:54:11 EDT
Created attachment 150244 [details]
lsmod for kernel 2.6.19
Comment 6 Need Real Name 2007-03-16 11:54:57 EDT
Created attachment 150245 [details]
lsmod for kernel 2.6.20
Comment 7 Need Real Name 2007-03-16 11:56:18 EDT
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!
Comment 8 Need Real Name 2007-03-16 11:59:40 EDT
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
Comment 9 Chuck Ebbert 2007-03-16 12:39:15 EDT
(In reply to comment #6)
> Created an attachment (id=150245) [edit]
> lsmod for kernel 2.6.20

That is not lsmod, it's lspci
Comment 10 Chuck Ebbert 2007-03-16 13:31:13 EDT

*** This bug has been marked as a duplicate of 232600 ***

Note You need to log in before you can comment on or make changes to this bug.