# Missing device file (/dev/rd/c0d0p1) with DAC960

## barefootcoder

I've had a RAID-5 partition (not as my root partition) on my Linux server for ages, but it always gives me fits.  Seems like every time I reboot, I have to fiddle with it and modprobe this and that and finally I get it working again, but it's never the same thing twice.  Well, recently I rebooted and now I'm in that position again and it seems like nothing I do is working.

I seem to have gotten the DAC960 module to autoload this time, so when I lsmod, I get:

```
Module                  Size  Used by

rtc                    10568  0 

DAC960                 71720  0 

8139too                22016  0 

mii                     4352  1 8139too

ohci_hcd               19592  0 

uhci_hcd               30480  0 

usb_storage            29568  0 

usbhid                 32448  0 

ehci_hcd               29576  0 

usbcore               106872  6 ohci_hcd,uhci_hcd,usb_storage,usbhid,ehci_hcd
```

And, looking at dmesg, the relevant bits seem like they're looking good:

```
DAC960: ***** DAC960 RAID Driver Version 2.5.47 of 14 November 2002 *****

DAC960: Copyright 1998-2001 by Leonard N. Zubkoff <lnz@dandelion.com>

DAC960#0: Configuring Mylex DAC960PG PCI RAID Controller

DAC960#0:   Firmware Version: 4.06-0-08, Channels: 1, Memory Size: 8MB

DAC960#0:   PCI Bus: 0, Device: 12, Function: 1, I/O Address: Unassigned

DAC960#0:   PCI Address: 0xFA104000 mapped at 0xE0858000, IRQ Channel: 17

DAC960#0:   Controller Queue Depth: 64, Maximum Blocks per Command: 128

DAC960#0:   Driver Queue Depth: 63, Scatter/Gather Limit: 33 of 33 Segments

DAC960#0:   Stripe Size: 64KB, Segment Size: 8KB, BIOS Geometry: 255/63

DAC960#0:   SAF-TE Enclosure Management Enabled

DAC960#0:   Physical Devices:

DAC960#0:     0:0  Vendor: QUANTUM   Model: VIKING II 4.5SCA  Revision: 5520

DAC960#0:          Serial Number: 194829243889

DAC960#0:          Disk Status: Online, 8908800 blocks

DAC960#0:     0:1  Vendor: QUANTUM   Model: VIKING II 4.5SCA  Revision: 5520

DAC960#0:          Serial Number: 194829240289

DAC960#0:          Disk Status: Online, 8908800 blocks

DAC960#0:     0:2  Vendor: QUANTUM   Model: VIKING II 4.5SCA  Revision: 5520

DAC960#0:          Serial Number: 194829340246

DAC960#0:          Disk Status: Online, 8908800 blocks

DAC960#0:     0:3  Vendor: QUANTUM   Model: VIKING II 4.5SCA  Revision: 5520

DAC960#0:          Serial Number: 194829240098

DAC960#0:          Disk Status: Online, 8908800 blocks

DAC960#0:     0:4  Vendor: QUANTUM   Model: VIKING II 4.5SCA  Revision: 5520

DAC960#0:          Serial Number: 194823984108

DAC960#0:          Disk Status: Online, 8908800 blocks

DAC960#0:     0:6  Vendor: ESG-SHV   Model: SCA HSBP M5       Revision: 1.65

DAC960#0:   Logical Drives:

DAC960#0:     /dev/rd/c0d0: RAID-5, Online, 35635200 blocks, Write Thru

 rd/c0d0: p1
```

But the device that I always use to mount in my fstab:

```
/dev/rd/c0d0p1          /mnt/raid       ext3            defaults               0 0
```

just isn't there:

```
sedna /etc # ll /dev/rd

total 0

brw-rw---- 1 root disk 1,  0 Nov  9 11:15 0

brw-rw---- 1 root disk 1,  1 Nov  9 11:15 1

brw-rw---- 1 root disk 1, 10 Nov  9 11:15 10

brw-rw---- 1 root disk 1, 11 Nov  9 11:15 11

brw-rw---- 1 root disk 1, 12 Nov  9 11:15 12

brw-rw---- 1 root disk 1, 13 Nov  9 11:15 13

brw-rw---- 1 root disk 1, 14 Nov  9 11:15 14

brw-rw---- 1 root disk 1, 15 Nov  9 11:15 15

brw-rw---- 1 root disk 1,  2 Nov  9 11:15 2

brw-rw---- 1 root disk 1,  3 Nov  9 11:15 3

brw-rw---- 1 root disk 1,  4 Nov  9 11:15 4

brw-rw---- 1 root disk 1,  5 Nov  9 11:15 5

brw-rw---- 1 root disk 1,  6 Nov  9 11:15 6

brw-rw---- 1 root disk 1,  7 Nov  9 11:15 7

brw-rw---- 1 root disk 1,  8 Nov  9 11:15 8

brw-rw---- 1 root disk 1,  9 Nov  9 11:15 9
```

My /proc/rd looks okay (to me):

```
sedna /etc # cat /proc/rd/status

OK           

sedna /etc # cat /proc/rd/c0/current_status

***** DAC960 RAID Driver Version 2.5.47 of 14 November 2002 *****

Copyright 1998-2001 by Leonard N. Zubkoff <lnz@dandelion.com>

Configuring Mylex DAC960PG PCI RAID Controller

  Firmware Version: 4.06-0-08, Channels: 1, Memory Size: 8MB

  PCI Bus: 0, Device: 12, Function: 1, I/O Address: Unassigned

  PCI Address: 0xFA104000 mapped at 0xE0858000, IRQ Channel: 17

  Controller Queue Depth: 64, Maximum Blocks per Command: 128

  Driver Queue Depth: 63, Scatter/Gather Limit: 33 of 33 Segments

  Stripe Size: 64KB, Segment Size: 8KB, BIOS Geometry: 255/63

  SAF-TE Enclosure Management Enabled

  Physical Devices:

    0:0  Vendor: QUANTUM   Model: VIKING II 4.5SCA  Revision: 5520

         Serial Number: 194829243889

         Disk Status: Online, 8908800 blocks

    0:1  Vendor: QUANTUM   Model: VIKING II 4.5SCA  Revision: 5520

         Serial Number: 194829240289

         Disk Status: Online, 8908800 blocks

    0:2  Vendor: QUANTUM   Model: VIKING II 4.5SCA  Revision: 5520

         Serial Number: 194829340246

         Disk Status: Online, 8908800 blocks

    0:3  Vendor: QUANTUM   Model: VIKING II 4.5SCA  Revision: 5520

         Serial Number: 194829240098

         Disk Status: Online, 8908800 blocks

    0:4  Vendor: QUANTUM   Model: VIKING II 4.5SCA  Revision: 5520

         Serial Number: 194823984108

         Disk Status: Online, 8908800 blocks

    0:6  Vendor: ESG-SHV   Model: SCA HSBP M5       Revision: 1.65

  Logical Drives:

    /dev/rd/c0d0: RAID-5, Online, 35635200 blocks, Write Thru

  No Rebuild or Consistency Check in Progress
```

I can't help but feel like I'm missing something ... maybe I need to load one of these modules?

```
sedna /etc # ls /lib/modules/2.6.11-gentoo-r8/kernel/drivers/md/

linear.ko  md.ko  multipath.ko  raid0.ko  raid1.ko  raid5.ko  xor.ko
```

Except that I've tried loading each one individually, and even all of them together, and it doesn't seem to make any difference.

What do I need to do to get my /dev/rd/c0d0p1 back?  Remember, this has been working before (for years, even), and there is a perfectly valid file system (with data I'd rather not lose, even) on that device ... that doesn't exist. :-(  Can anyone provide any insight?

----------

## godish

Try cating /proc/partitions. That should list all the disk/partitions on your system.

This is mine

```
godish@UberLinuxBox /proc $ cat /proc/partitions 

major minor  #blocks  name

   3     0  156290904 hda

   3     1      40131 hda1

   3     2    1004062 hda2

   3     3  155244127 hda3

   8     0  312571224 sda

   8     1  312568641 sda1
```

I used to have a card that used the 960 driver and the only issues i had were that they place of mounting would change from the live cd to "regular" boot.

[mind dump]

Very weird however, it says that the virtual/logical disk does exist @

/dev/rd/c0d0

and yet nothing is there... hrm lol

[/mind dump]

When was the last time you updated your kernel?

----------

## barefootcoder

 *godish wrote:*   

> Try cating /proc/partitions. That should list all the disk/partitions on your system.

 

Okay, good call.

```
sedna /etc # cat /proc/partitions 

major minor  #blocks  name

  22     0   14944410 hdc

  22     1     499936 hdc1

  22     2     999936 hdc2

  22     3   13444200 hdc3

  22    64   39082680 hdd

  22    65   39078081 hdd1

  48     0   17817600 rd/c0d0

  48     1   17816053 rd/c0d0p1
```

Which is even more confusing ...

 *godish wrote:*   

> Very weird however, it says that the virtual/logical disk does exist @
> 
> /dev/rd/c0d0
> 
> and yet nothing is there... hrm lol

 

Yeah, that's irking me too.

 *godish wrote:*   

> When was the last time you updated your kernel?

 

Good question ... not since May of '05, looks like.  Current kernel is 2.6.11-r8.  Obviously I've had the partition mounted since then.

I'm on udev (as opposed to devfs), did I mention that?  At least, I'm pretty sure I am ... I have several different Gentoo boxen, but I'm pretty sure they're all on udev now.  Actually, yes, it specifically says "udev" in my grub.conf, and I see it in dmesg as well.

Not that I know much about udev ... how should that dev file be getting there anyway?  Is there some manual way I could try to recreate it?  I tried MAKEDEV, but that didn't seem to do anything ...

Thanx for the reply.

----------

## godish

Maybe you should try booting to a livecd and see if it "appears". I'm thinking something in udev got messed up. If it does, then something in your base system got messed (eg etc-update borked a file).

----------

## barefootcoder

Sorry; got distracted by Real Life.  Now, where were we ...

 *godish wrote:*   

> Maybe you should try booting to a livecd and see if it "appears". I'm thinking something in udev got messed up. If it does, then something in your base system got messed (eg etc-update borked a file).

 

That's a really good idea, but unfortunately not practical, as I am in California and my server is in Virginia (don't ask; long story).  Certainly it's possible that etc-update (well, technically dispatch-conf, but same principle) borked something up.  I have been trying to bring the server into the latest century bit by bit.  I've been a bit cautious to try to keep from breaking anything, since it's a working server, and even when I was in VA, it wasn't particularly convenient to get to it, but that's the kind of thing that could have gotten messed up and I never noticed till the next time I rebooted.

Can anyone think of any way to check the udev stuff out without having to reboot?

----------

## linuxtuxhellsinki

```
$ mount |grep udev

udev on /dev type tmpfs (rw,nosuid)

$ apropos udev

AuDeviceAttributes   (3x)  - device attributes structure

ata_id               (8)  - udev callout to read product/serial number from ATA drives

cdrom_id             (8)  - udev callout to determine the capabilities of cd/dvd drives

dasd_id              (8)  - udev callout to read label from s390 block device

edd_id               (8)  - udev callout to identify BIOS disk drives via EDD

udev                 (7)  - dynamic device management

udevd                (8)  - event managing daemon

udevinfo             (8)  - query device information from the udev database

udevmonitor          (8)  - print the kernel and udev event sequence to the console

udevsend             (8)  - send the current environment to the udev daemon

udevstart            (8)  - populate initial device directory

udevtest             (8)  - simulate a udev run and print the action to the console
```

----------

## barefootcoder

 *linuxtuxhellsinki wrote:*   

> 
> 
> ```
> $ mount |grep udev
> 
> ...

 

Yep, mine says the exact same thing.

 *linuxtuxhellsinki wrote:*   

> 
> 
> ```
> $ apropos udev
> 
> ...

 

Hmmm ... well, I dunno how much I'm getting out of that.  I did try this:

```
sedna /etc # udevinfo --path=/dev/rd/c0d0p1 --query=all

no record for '/dev/rd/c0d0p1' in database
```

but that doesn't seem to be helping much.

I glanced at /etc/udev/udev.conf and the files in /etc/udev/rules.d, but none of that makes any sense to me, and none of those man pages were particularly helpful in deciphering them.  Now, going back to godish's theory that an update borked things, I took a look at my dispatch-conf RCS files for the /etc/udev directory.  Perhaps this sheds some light on things (to someone who actually knows what they're looking at):

```
sedna /etc/portage/config-archive/etc/udev/rules.d # rlog 50-udev.rules,v       

 

RCS file: 50-udev.rules,v

Working file: 50-udev.rules

head: 1.2

branch:

locks: strict

access list:

symbolic names:

keyword substitution: o

total revisions: 4;     selected revisions: 4

description:

Archived config file.

----------------------------

revision 1.2

date: 2007/03/07 17:36:06;  author: root;  state: Exp;  lines: +221 -154

dispatch-conf update.

----------------------------

revision 1.1

date: 2006/02/05 04:15:07;  author: root;  state: Exp;

branches:  1.1.1;

dispatch-conf update.

----------------------------

revision 1.1.1.2

date: 2007/03/07 17:36:06;  author: root;  state: Exp;  lines: +68 -73

dispatch-conf update.

----------------------------

revision 1.1.1.1

date: 2006/02/05 04:19:47;  author: root;  state: Exp;  lines: +221 -154

dispatch-conf update.

=============================================================================

sedna /etc/portage/config-archive/etc/udev/rules.d # rcsdiff -r1.1 -r1.2 50-udev.rules,v  | egrep '\<rd\>'

===================================================================

RCS file: 50-udev.rules,v

retrieving revision 1.1

retrieving revision 1.2

diff -r1.1 -r1.2

< KERNEL="rd*",         PROGRAM="/etc/udev/scripts/raid-devfs.sh %k", NAME="%c{1}", SYMLINK="%k"

> KERNEL=="rd*",                PROGRAM="raid-devfs.sh %k", NAME="%c{1}", SYMLINK+="%k"

< KERNEL="ram[0-9]*",   NAME="rd/%n", SYMLINK="%k"

> KERNEL=="ram[0-9]*",  NAME="rd/%n", SYMLINK+="%k"
```

Is any of that helpful to anyone?  Thanx to everyone who's tried to help out so far (and to anyone else who wants to jump in!).

----------

## barefootcoder

Bump.

Anyone who knows anything about udev?  Even a wild guess would be helpful at this point. :)

----------

## barefootcoder

Bump again.

Still trying to find an answer for this one.

----------

