First attempt at vendor RAID support in 2.6

RFC PATCH In review Carl-Daniel Hailfinger 4 participants 6 messages Apr 15, 2004 – May 1, 2004

Subsystems (3)

SCSI Kbuild MD RAID

lore

Share & tools

lore

Carl-Daniel Hailfinger

author

2004-04-15 00:24 UTC #0 lore raw

RFC PATCH 1/1 First attempt at vendor RAID support in 2.6

Hi,

some time ago, I started to work on a 2.6 kernel compatible successor for ATARAID.

Since this project is becoming bigger and bigger and I would like some input, the current version of my raiddetect program is attached for criticism.

The fact that I did not extend Wilfried Weissmann's EVMS plugin is not meant to discredit his work, however I found it easier to implement something outside EVMS. I made the structure of my program as generic as possible so integration into EVMS should be really easy if you want that.

What works:
- SilicomImage/Promise/Highpoint RAIDs are recognized and a list of disks belonging to an ATARAID is output if you call "raiddetect -s"

What doesn't work:
- Distinguishing between disks that are part of an ATARAID array and those that are not if both have an ATARIAD superblock. (Well, it should work
for Highpoint)
- Setting up the ATARAID devices via device-mapper

What I need:
- People looking at the *_sb_helper functions to tell me if there is more magic I can check for
- Criticism of coding style/ missing abstraction
- People checking the numerous FIXMEs
- More data about Medley/Highpoint vendor superblocks (can I check for bogus values?)
- Help with sorting out who owns which copyrights

A few words about my implementation:
The hasraidmagic bitfield in struct harddisk is probably a misnomer. If a bit is set it means that we found a superblock of the corresponding type and the disk can not be accessed as a plain disk (i.e. we need to setup something).
raiddetect is a patch against udev-023 and should compile cleanly against klibc and glibc.
Executing "raiddetect" will show nearly all info gathered about the block devices present in the system, whereas "raiddetect -s" should give you only a list of devices currently suspected to be part of an ATARAID array.

Regards,
Carl-Daniel

Signature · 1 line

http://www.hailfinger.org/

bios_hpt.h +132 -0

diff -urN udev-023-orig/bios_hpt.h udev-023/bios_hpt.h
@@ -0,0 +1,132 @@
+#ifndef __BIOS_HPT_H__
+#define __BIOS_HPT_H__ 1
+
+/*
+ *   Copyright (c) 2003,2004 Wilfried Weissmann
+ *   Copyright (c) 2000,2001 S�ren Schmidt (see also notice below)
+ *
+ *   This program is free software;  you can redistribute it and/or modify
+ *   it under the terms of the GNU General Public License as published by
+ *   the Free Software Foundation; either version 2 of the License, or
+ *   (at your option) any later version.
+ *
+ *   This program is distributed in the hope that it will be useful,
+ *   but WITHOUT ANY WARRANTY;  without even the implied warranty of
+ *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See
+ *   the GNU General Public License for more details.
+ *
+ *   You should have received a copy of the GNU General Public License
+ *   along with this program;  if not, write to the Free Software
+ *   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+/*-
+ * Copyright (c) 2000,2001 S�ren Schmidt <[email protected]>
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer,
+ *    without modification, immediately at the beginning of the file.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. The name of the author may not be used to endorse or promote products
+ *    derived from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR `AS IS'' AND ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ */
+                            
+struct highpoint_raid_conf
+{
+       int8_t  filler1[32];
+       u_int32_t       magic;
+#define HPT_MAGIC_OK   0x5a7816f0
+#define HPT_MAGIC_BAD  0x5a7816fd  
+
+       u_int32_t       magic_0;
+       u_int32_t       magic_1;
+       u_int32_t       order;  
+#define HPT_O_MIRROR   0x01  
+#define HPT_O_STRIPE   0x02
+#define HPT_O_OK       0x04
+
+       u_int8_t        raid_disks;
+       u_int8_t        raid0_shift; 
+       u_int8_t        type;
+#define HPT_T_RAID_0   0x00 
+#define HPT_T_RAID_1   0x01
+#define HPT_T_RAID_01_RAID_0   0x02
+#define HPT_T_SPAN             0x03
+#define HPT_T_RAID_3           0x04   
+#define HPT_T_RAID_5           0x05
+#define HPT_T_SINGLEDISK       0x06
+#define HPT_T_RAID_01_RAID_1   0x07
+
+       u_int8_t        disk_number;
+       u_int32_t       total_secs; 
+       u_int32_t       disk_mode;  
+       u_int32_t       boot_mode;
+       u_int8_t        boot_disk; 
+       u_int8_t        boot_protect;
+       u_int8_t        error_log_entries;
+       u_int8_t        error_log_index;  
+       struct
+       {
+               u_int32_t       timestamp;
+               u_int8_t        reason;   
+#define HPT_R_REMOVED          0xfe      
+#define HPT_R_BROKEN           0xff      
+
+               u_int8_t        disk;
+               u_int8_t        status;
+               u_int8_t        sectors;
+               u_int32_t       lba;
+       } errorlog[32];
+       u_int8_t        filler[60];
+};
+
+#ifndef O_DIRECT
+#define O_DIRECT	0
+#endif
+
+#define BLKGETSIZE64	_IOR(0x12,114,size_t)
+#define BLKSSZGET	_IO(0x12,104)
+#define BLKBSZGET	_IOR(0x12,112,size_t)
+#define BLKBSZSET	_IOW(0x12,113,size_t)
+#define HDIO_GETGEO	0x0301
+#define HDIO_GETGEO_BIG	0x0330
+
+#define HPT_SUPERBLOCKOFFSET (4096+512)
+
+/* HPT IDs from http://pciids.sf.net */
+#define PCI_VENDOR_ID_TTI		0x1103
+#define PCI_DEVICE_ID_TTI_HPT343	0x0003
+#define PCI_DEVICE_ID_TTI_HPT366	0x0004
+#define PCI_DEVICE_ID_TTI_HPT372	0x0005
+#define PCI_DEVICE_ID_TTI_HPT302	0x0006
+#define PCI_DEVICE_ID_TTI_HPT371	0x0007
+#define PCI_DEVICE_ID_TTI_HPT374	0x0008
+
+static struct biospci_s hptpci[] = {
+	{ PCI_VENDOR_ID_TTI, PCI_DEVICE_ID_TTI_HPT343 },
+	{ PCI_VENDOR_ID_TTI, PCI_DEVICE_ID_TTI_HPT366 },
+	{ PCI_VENDOR_ID_TTI, PCI_DEVICE_ID_TTI_HPT372 },
+	{ PCI_VENDOR_ID_TTI, PCI_DEVICE_ID_TTI_HPT302 },
+	{ PCI_VENDOR_ID_TTI, PCI_DEVICE_ID_TTI_HPT371 },
+	{ PCI_VENDOR_ID_TTI, PCI_DEVICE_ID_TTI_HPT374 },
+};
+
+#endif

bios_pdc.h +96 -0

96 lines not on this page · raw message

bios_sil.h +58 -0

58 lines not on this page · raw message

Makefile +10 -2

diff -urN udev-023-orig/Makefile udev-023/Makefile
@@ -30,6 +30,7 @@
 DAEMON =	udevd
 SENDER =	udevsend
 INFO =		udevinfo
+RAID =		raiddetect
 TESTER =	udevtest
 STARTER =	udevstart
 RULER =		udevruler

@@ -172,7 +173,7 @@
 
 CFLAGS += -I$(PWD)/libsysfs
 
-all: $(ROOT) $(SENDER) $(DAEMON) $(INFO) $(TESTER) $(STARTER)
+all: $(ROOT) $(SENDER) $(DAEMON) $(INFO) $(RAID) $(TESTER) $(STARTER)
 	@extras="$(EXTRAS)" ; for target in $$extras ; do \
 		echo $$target ; \
 		$(MAKE) prefix=$(prefix) \

@@ -250,6 +251,7 @@
 $(ROOT).o: $(GEN_HEADERS)
 $(TESTER).o: $(GEN_HEADERS)
 $(INFO).o: $(GEN_HEADERS)
+$(RAID).o: $(GEN_HEADERS)
 $(DAEMON).o: $(GEN_HEADERS)
 $(SENDER).o: $(GEN_HEADERS)
 $(STARTER).o: $(GEN_HEADERS)

@@ -266,6 +268,10 @@
 	$(LD) $(LDFLAGS) -o $@ $(CRT0) udevinfo.o udev_lib.o udev_config.o udevdb.o $(SYSFS) $(TDB) $(LIB_OBJS) $(ARCH_LIB_OBJS)
 	$(STRIPCMD) $@
 
+$(RAID): $(RAID).o $(OBJS) $(HEADERS) $(LIBC)
+	$(LD) $(LDFLAGS) -o $@ $(CRT0) raiddetect.o $(SYSFS) $(LIB_OBJS) $(ARCH_LIB_OBJS)
+	$(STRIPCMD) $@
+
 $(DAEMON): $(DAEMON).o udevd.h $(LIBC)
 	$(LD) $(LDFLAGS) -o $@ $(CRT0) udevd.o $(LIB_OBJS) $(ARCH_LIB_OBJS)
 	$(STRIPCMD) $@

@@ -285,7 +291,7 @@
 clean:
 	-find . \( -not -type d \) -and \( -name '*~' -o -name '*.[oas]' \) -type f -print \
 	 | xargs rm -f 
-	-rm -f core $(ROOT) $(GEN_HEADERS) $(GEN_CONFIGS) $(INFO) $(DAEMON) $(SENDER) $(TESTER) $(STARTER) $(RULER)
+	-rm -f core $(ROOT) $(GEN_HEADERS) $(GEN_CONFIGS) $(INFO) $(RAID) $(DAEMON) $(SENDER) $(TESTER) $(STARTER) $(RULER)
 	$(MAKE) -C klibc clean
 	@extras="$(EXTRAS)" ; for target in $$extras ; do \
 		echo $$target ; \

@@ -361,6 +367,7 @@
 	$(INSTALL_PROGRAM) -D $(DAEMON) $(DESTDIR)$(sbindir)/$(DAEMON)
 	$(INSTALL_PROGRAM) -D $(SENDER) $(DESTDIR)$(sbindir)/$(SENDER)
 	$(INSTALL_PROGRAM) -D $(INFO) $(DESTDIR)$(usrbindir)/$(INFO)
+	$(INSTALL_PROGRAM) -D $(RAID) $(DESTDIR)$(sbindir)/$(RAID)
 	$(INSTALL_PROGRAM) -D $(TESTER) $(DESTDIR)$(usrbindir)/$(TESTER)
 	$(INSTALL_PROGRAM) -D $(STARTER) $(DESTDIR)$(sbindir)/$(STARTER)
 	$(INSTALL_DATA) -D udev.8 $(DESTDIR)$(mandir)/man8/udev.8

@@ -396,6 +403,7 @@
 	- rm $(sbindir)/$(DAEMON)
 	- rm $(sbindir)/$(SENDER)
 	- rm $(usrbindir)/$(INFO)
+	- rm $(usrbindir)/$(RAID)
 	- rmdir $(hotplugdir)
 	- rmdir $(configdir)
 	- rmdir $(dev_ddir)default

raiddetect.c +734 -0

734 lines not on this page · raw message

raiddetect.h +40 -0

diff -urN udev-023-orig/raiddetect.h udev-023/raiddetect.h
@@ -0,0 +1,40 @@
+#ifndef __RAIDDETECT_H__
+#define __RAIDDETECT_H__ 1
+
+#define PCI_HPTRAID 0
+#define PCI_PDCRAID 1
+#define PCI_SILRAID 2
+#define RAIDTYPE_COUNT 3
+
+struct harddisk {
+	char devname[SYSFS_PATH_MAX];
+	char devdevname[PATH_MAX];
+	char controllerid[SYSFS_PATH_MAX];
+	int controller;
+	char controllertype;
+	char claimed;
+	char hasraidmagic;
+	dev_t device;
+	unsigned long long devsize;
+	unsigned int hardsectorsize;
+	unsigned int blocksize;
+	unsigned int vendorid;
+	unsigned int deviceid;
+	unsigned int subsystem_vendorid;
+	unsigned int subsystem_deviceid;
+};
+
+        /* list of the pci ids of the supported controllers */
+struct biospci_s {
+	u_int16_t vendor;
+	u_int16_t device;
+};
+
+struct hd_geometry {
+	unsigned char heads;
+	unsigned char sectors;
+	unsigned short cylinders;
+	unsigned long start;
+};
+
+#endif

Thomas Horsten

2004-04-15 14:08 UTC #1 lore raw

Hi Carl-Daniel,

Quoted 8 lines · Carl-Daniel Hailfinger

What I need:
- People looking at the *_sb_helper functions to tell me if there is more magic I can check for
- Criticism of coding style/ missing abstraction
- People checking the numerous FIXMEs
- More data about Medley/Highpoint vendor superblocks (can I check for bogus values?)
- Help with sorting out who owns which copyrights

I'm on holiday in New York right now so I don't have time to give you a complete breakdown. But I can give you a couple of comments on Medley RAID and get back to you when I return next week.

First: It should not be called "SIL", "SII", or "Silicon Image" RAID in the parts of the code exposed to the user. This is because other vendors than Silicon Image use the Medley RAID specification (such as the CMD680R SATA controller and others). When refering specifically to Silicon Image, SII is the correct abbreviation, not "SIL".

You are asking for more magic to detect Medley RAID. The probe function for Medley in my patch (medley_probe_drive()) first calls medley_get_metadata() which uses the checksum to determine if it is a Medley superblock. In my version, it also checks the PCI vendor ID/product ID against that stored in the Medley superblock. This is consistent with how the Medley BIOS verifies a valid Medley superblock and you should rely on this for automatic detection. But since users might want to move the RAID set to a different controller, e.g. if their on-board controller breaks down, there should be an option to force detection to bypass the PCI ID verification.

After you have a correct checksum there are several other things you can check for, which I do in my medley_probe_drive() after obtaining the superblock:

- Check raid_type, it should be 0 for striped sets (RAID0) - I will get you the values for RAID1 and RAID1+0 when I return from NY.

- Check major_ver, it should be 1 or 2 (other major versions may have a different superblock and can not be supported).

- Check that the chunk_size looks reasonable, that there is more than 1 drive in the set (drives_per_striped_set), and that the drive_number is within the range 0-(drives_per_striped_set-1).

If you do all these checks and still come out with a valid candidate, it's probably safe to assume that the drive belongs to a set if all the disks are present.

I'll have a closer look when I return home.

// Thomas

Quoted 13 lines

A few words about my implementation:
The hasraidmagic bitfield in struct harddisk is probably a misnomer. If a bit is set it means that we found a superblock of the corresponding type and the disk can not be accessed as a plain disk (i.e. we need to setup something).
raiddetect is a patch against udev-023 and should compile cleanly against klibc and glibc.
Executing "raiddetect" will show nearly all info gathered about the block devices present in the system, whereas "raiddetect -s" should give you only a list of devices currently suspected to be part of an ATARAID array.

Quoted 5 lines

Regards,
Carl-Daniel
--
http://www.hailfinger.org/

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Carl-Daniel Hailfinger

author

2004-04-16 20:04 UTC #2 lore raw

Hi,

[this is not only a reply to Thomas' mail, but also an update about the current state of my vendor RAID support]

Greg: Would you accept this patch into your udev package?

Quoted 8 lines · Thomas Horsten

Hi Carl-Daniel,
Quoted 3 lines · Carl-Daniel Hailfinger
What I need:
- People looking at the *_sb_helper functions to tell me if there is more magic I can check for

Partly solved, check below.

Quoted 1 line

Quoted 1 line
- Criticism of coding style/ missing abstraction

I got a mail from Barlomiej Zolnierkiewicz where he suggested to split the vendor dependent code out of raiddetect.c. This will happen in one of the next revisions.

Quoted 1 line

Quoted 1 line
- People checking the numerous FIXMEs

I now have the following FIXMEs (aka "I have no idea about it"):
- 5 FIXMEs in the Medley RAID code. Thomas, could you comment once you're back?
- 3 FIXMEs in the Highpoint RAID code. Wilfried, could you please take a look at them?
- 2 FIXMEs in the Promise RAID code. I will on those myself.
- some generic FIXMEs:
- Is the sector size of a harddisk always 512 bytes?
- Is /sys/block/*/size always in 512-byte units?
- Are there controllers out there which occupy more than one PCI device?
- How can I find out if a block device under /sys/block is a disk?

Quoted 2 lines

Quoted 2 lines
- More data about Medley/Highpoint vendor superblocks (can I check for bogus values?)

Wilfried, is there any consistency check I can add for Highpoint?

Quoted 1 line

Quoted 1 line
- Help with sorting out who owns which copyrights

This is still a _big issue_.

Quoted 3 lines

I'm on holiday in New York right now so I don't have time to give you a complete breakdown. But I can give you a couple of comments on Medley RAID and get back to you when I return next week.

Thanks!

Quoted 5 lines

First: It should not be called "SIL", "SII", or "Silicon Image" RAID in the parts of the code exposed to the user. This is because other vendors than Silicon Image use the Medley RAID specification (such as the CMD680R SATA controller and others). When refering specifically to Silicon Image, SII is the correct abbreviation, not "SIL".

Changed.

Quoted 10 lines

You are asking for more magic to detect Medley RAID. The probe function for Medley in my patch (medley_probe_drive()) first calls medley_get_metadata() which uses the checksum to determine if it is a Medley superblock. In my version, it also checks the PCI vendor ID/product ID against that stored in the Medley superblock. This is consistent with how the Medley BIOS verifies a valid Medley superblock and you should rely on this for automatic detection. But since users might want to move the RAID set to a different controller, e.g. if their on-board controller breaks down, there should be an option to force detection to bypass the PCI ID verification.

medley_sb_helper now has a parameter ignore_vendorid (default off).

Quoted 6 lines

After you have a correct checksum there are several other things you can check for, which I do in my medley_probe_drive() after obtaining the superblock:
- Check raid_type, it should be 0 for striped sets (RAID0) - I will get you the values for RAID1 and RAID1+0 when I return from NY.

Will be added as soon as I get the data.

Quoted 2 lines

- Check major_ver, it should be 1 or 2 (other major versions may have a different superblock and can not be supported).

Will be added once I have more info about the expected checksum value for different superblock versions (see FIXME there).

Quoted 1 line

- Check that the chunk_size looks reasonable, that there is more than

The chunk_size>0 check is now in. Can I do better chunk_size checking?

Quoted 2 lines

1 drive in the set (drives_per_striped_set), and that the drive_number is within the range 0-(drives_per_striped_set-1).

Done.

Quoted 3 lines

If you do all these checks and still come out with a valid candidate, it's probably safe to assume that the drive belongs to a set if all the disks are present.

Attached is my current version of raiddetect.

Regards,
Carl-Daniel

Signature · 1 line

http://www.hailfinger.org/

bios_hpt.h +132 -0

diff -urN udev-023-orig/bios_hpt.h udev-023/bios_hpt.h
@@ -0,0 +1,132 @@
+#ifndef __BIOS_HPT_H__
+#define __BIOS_HPT_H__ 1
+
+/*
+ *   Copyright (c) 2003,2004 Wilfried Weissmann
+ *   Copyright (c) 2000,2001 S�ren Schmidt (see also notice below)
+ *
+ *   This program is free software;  you can redistribute it and/or modify
+ *   it under the terms of the GNU General Public License as published by
+ *   the Free Software Foundation; either version 2 of the License, or
+ *   (at your option) any later version.
+ *
+ *   This program is distributed in the hope that it will be useful,
+ *   but WITHOUT ANY WARRANTY;  without even the implied warranty of
+ *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See
+ *   the GNU General Public License for more details.
+ *
+ *   You should have received a copy of the GNU General Public License
+ *   along with this program;  if not, write to the Free Software
+ *   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+/*-
+ * Copyright (c) 2000,2001 S�ren Schmidt <[email protected]>
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer,
+ *    without modification, immediately at the beginning of the file.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. The name of the author may not be used to endorse or promote products
+ *    derived from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR `AS IS'' AND ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ */
+                            
+struct highpoint_raid_conf
+{
+       int8_t  filler1[32];
+       u_int32_t       magic;
+#define HPT_MAGIC_OK   0x5a7816f0
+#define HPT_MAGIC_BAD  0x5a7816fd  
+
+       u_int32_t       magic_0;
+       u_int32_t       magic_1;
+       u_int32_t       order;  
+#define HPT_O_MIRROR   0x01  
+#define HPT_O_STRIPE   0x02
+#define HPT_O_OK       0x04
+
+       u_int8_t        raid_disks;
+       u_int8_t        raid0_shift; 
+       u_int8_t        type;
+#define HPT_T_RAID_0   0x00 
+#define HPT_T_RAID_1   0x01
+#define HPT_T_RAID_01_RAID_0   0x02
+#define HPT_T_SPAN             0x03
+#define HPT_T_RAID_3           0x04   
+#define HPT_T_RAID_5           0x05
+#define HPT_T_SINGLEDISK       0x06
+#define HPT_T_RAID_01_RAID_1   0x07
+
+       u_int8_t        disk_number;
+       u_int32_t       total_secs; 
+       u_int32_t       disk_mode;  
+       u_int32_t       boot_mode;
+       u_int8_t        boot_disk; 
+       u_int8_t        boot_protect;
+       u_int8_t        error_log_entries;
+       u_int8_t        error_log_index;  
+       struct
+       {
+               u_int32_t       timestamp;
+               u_int8_t        reason;   
+#define HPT_R_REMOVED          0xfe      
+#define HPT_R_BROKEN           0xff      
+
+               u_int8_t        disk;
+               u_int8_t        status;
+               u_int8_t        sectors;
+               u_int32_t       lba;
+       } errorlog[32];
+       u_int8_t        filler[60];
+};
+
+#ifndef O_DIRECT
+#define O_DIRECT	0
+#endif
+
+#define BLKGETSIZE64	_IOR(0x12,114,size_t)
+#define BLKSSZGET	_IO(0x12,104)
+#define BLKBSZGET	_IOR(0x12,112,size_t)
+#define BLKBSZSET	_IOW(0x12,113,size_t)
+#define HDIO_GETGEO	0x0301
+#define HDIO_GETGEO_BIG	0x0330
+
+#define HPT_SUPERBLOCKOFFSET (4096+512)
+
+/* HPT IDs from http://pciids.sf.net */
+#define PCI_VENDOR_ID_TTI		0x1103
+#define PCI_DEVICE_ID_TTI_HPT343	0x0003
+#define PCI_DEVICE_ID_TTI_HPT366	0x0004
+#define PCI_DEVICE_ID_TTI_HPT372	0x0005
+#define PCI_DEVICE_ID_TTI_HPT302	0x0006
+#define PCI_DEVICE_ID_TTI_HPT371	0x0007
+#define PCI_DEVICE_ID_TTI_HPT374	0x0008
+
+static struct biospci_s hptpci[] = {
+	{ PCI_VENDOR_ID_TTI, PCI_DEVICE_ID_TTI_HPT343 },
+	{ PCI_VENDOR_ID_TTI, PCI_DEVICE_ID_TTI_HPT366 },
+	{ PCI_VENDOR_ID_TTI, PCI_DEVICE_ID_TTI_HPT372 },
+	{ PCI_VENDOR_ID_TTI, PCI_DEVICE_ID_TTI_HPT302 },
+	{ PCI_VENDOR_ID_TTI, PCI_DEVICE_ID_TTI_HPT371 },
+	{ PCI_VENDOR_ID_TTI, PCI_DEVICE_ID_TTI_HPT374 },
+};
+
+#endif

bios_medley.h +58 -0

58 lines not on this page · raw message

bios_pdc.h +96 -0

96 lines not on this page · raw message

Makefile +10 -2

diff -urN udev-023-orig/Makefile udev-023/Makefile
@@ -30,6 +30,7 @@
 DAEMON =	udevd
 SENDER =	udevsend
 INFO =		udevinfo
+RAID =		raiddetect
 TESTER =	udevtest
 STARTER =	udevstart
 RULER =		udevruler

@@ -172,7 +173,7 @@
 
 CFLAGS += -I$(PWD)/libsysfs
 
-all: $(ROOT) $(SENDER) $(DAEMON) $(INFO) $(TESTER) $(STARTER)
+all: $(ROOT) $(SENDER) $(DAEMON) $(INFO) $(RAID) $(TESTER) $(STARTER)
 	@extras="$(EXTRAS)" ; for target in $$extras ; do \
 		echo $$target ; \
 		$(MAKE) prefix=$(prefix) \

@@ -250,6 +251,7 @@
 $(ROOT).o: $(GEN_HEADERS)
 $(TESTER).o: $(GEN_HEADERS)
 $(INFO).o: $(GEN_HEADERS)
+$(RAID).o: $(GEN_HEADERS)
 $(DAEMON).o: $(GEN_HEADERS)
 $(SENDER).o: $(GEN_HEADERS)
 $(STARTER).o: $(GEN_HEADERS)

@@ -266,6 +268,10 @@
 	$(LD) $(LDFLAGS) -o $@ $(CRT0) udevinfo.o udev_lib.o udev_config.o udevdb.o $(SYSFS) $(TDB) $(LIB_OBJS) $(ARCH_LIB_OBJS)
 	$(STRIPCMD) $@
 
+$(RAID): $(RAID).o $(OBJS) $(HEADERS) $(LIBC)
+	$(LD) $(LDFLAGS) -o $@ $(CRT0) raiddetect.o $(SYSFS) $(LIB_OBJS) $(ARCH_LIB_OBJS)
+	$(STRIPCMD) $@
+
 $(DAEMON): $(DAEMON).o udevd.h $(LIBC)
 	$(LD) $(LDFLAGS) -o $@ $(CRT0) udevd.o $(LIB_OBJS) $(ARCH_LIB_OBJS)
 	$(STRIPCMD) $@

@@ -285,7 +291,7 @@
 clean:
 	-find . \( -not -type d \) -and \( -name '*~' -o -name '*.[oas]' \) -type f -print \
 	 | xargs rm -f 
-	-rm -f core $(ROOT) $(GEN_HEADERS) $(GEN_CONFIGS) $(INFO) $(DAEMON) $(SENDER) $(TESTER) $(STARTER) $(RULER)
+	-rm -f core $(ROOT) $(GEN_HEADERS) $(GEN_CONFIGS) $(INFO) $(RAID) $(DAEMON) $(SENDER) $(TESTER) $(STARTER) $(RULER)
 	$(MAKE) -C klibc clean
 	@extras="$(EXTRAS)" ; for target in $$extras ; do \
 		echo $$target ; \

@@ -361,6 +367,7 @@
 	$(INSTALL_PROGRAM) -D $(DAEMON) $(DESTDIR)$(sbindir)/$(DAEMON)
 	$(INSTALL_PROGRAM) -D $(SENDER) $(DESTDIR)$(sbindir)/$(SENDER)
 	$(INSTALL_PROGRAM) -D $(INFO) $(DESTDIR)$(usrbindir)/$(INFO)
+	$(INSTALL_PROGRAM) -D $(RAID) $(DESTDIR)$(sbindir)/$(RAID)
 	$(INSTALL_PROGRAM) -D $(TESTER) $(DESTDIR)$(usrbindir)/$(TESTER)
 	$(INSTALL_PROGRAM) -D $(STARTER) $(DESTDIR)$(sbindir)/$(STARTER)
 	$(INSTALL_DATA) -D udev.8 $(DESTDIR)$(mandir)/man8/udev.8

@@ -396,6 +403,7 @@
 	- rm $(sbindir)/$(DAEMON)
 	- rm $(sbindir)/$(SENDER)
 	- rm $(usrbindir)/$(INFO)
+	- rm $(usrbindir)/$(RAID)
 	- rmdir $(hotplugdir)
 	- rmdir $(configdir)
 	- rmdir $(dev_ddir)default

raiddetect.c +750 -0

750 lines not on this page · raw message

raiddetect.h +44 -0

44 lines not on this page · raw message

Carl-Daniel Hailfinger

author

2004-04-17 17:35 UTC #3 lore raw

[crossposting this to hopefully relevant lists]
Hi,

since on one side ATARAID support has vanished from 2.6 and on the other side some parties are pushing for an enhanced MD driver in the kernel, why
don't we do the setup and metadata handling of all those types of RAID in
userspace?

I got positive feedback by private mail from several kernel developers for the last incarnations of raiddetect, so if you disagree, speak up now.

Raiddetect is a program to find vendor software RAID superblocks, analyze them for validity, group them by RAID vendor and (later on) set them up via MD/DM. It is small (~35kB compiled statically against klibc) and designed to be run from initrd/initramfs.

raiddetect now supports the following metadata formats:
-Promise RAID
-Highpoint RAID
-Medley RAID
-Intel RAID

If you want support for another metadata format, please tell me which and I'll try to add it. Patches are preferred ;-) My current wishlist is:
- Adaptec ASR HostRAID
- DDF RAID

Hot-add and hot-remove features can be added easily if raiddetect is called by an udev rule on block device removal/insertion. If raiddetect stays loaded into memory or is allowed to save its state, hotplug events will not trigger any access to devices not related to that particular RAID array.

It seems that there are some host adapter drivers out there implementing their own RAID engine which could be consolidated into a single RAID "library" instead. If you know about such drivers, please speak up.

The following issues remain still to be sorted out:

Quoted 7 lines · Carl-Daniel Hailfinger

Greg: Would you accept this patch into your udev package?
Quoted 3 lines · Thomas Horsten
On Thu, 15 Apr 2004, Carl-Daniel Hailfinger wrote:

Quoted 7 lines

Quoted 2 lines
Quoted 2 lines
What I need:
- Criticism of coding style/ missing abstraction
I got a mail from Barlomiej Zolnierkiewicz where he suggested to split the vendor dependent code out of raiddetect.c. This will happen in one of the next revisions.

This is on hold until I receive feedback from Greg K-H whether this will be accepted into udev or not.

Quoted 10 lines

Quoted 1 line
Quoted 1 line
- People checking the numerous FIXMEs
I now have the following FIXMEs (aka "I have no idea about it"):
- 5 FIXMEs in the Medley RAID code. Thomas, could you comment once you're back?
- 3 FIXMEs in the Highpoint RAID code. Wilfried, could you please take a look at them?
- 2 FIXMEs in the Promise RAID code. I will work on those myself.

Quoted 5 lines

- some generic FIXMEs:
- Is the sector size of a harddisk always 512 bytes?
- Is /sys/block/*/size always in 512-byte units?
- Are there controllers out there which occupy more than one PCI device?
- How can I find out if a block device under /sys/block is a disk?

Do you have an idea about the generic FIXMEs listed above?

Quoted 3 lines

Quoted 1 line
Quoted 1 line
- Help with sorting out who owns which copyrights
This is still a _big issue_.

Since the patch is already too big (~42kB) for some mailing lists, please get the latest version from
http://www.hailfinger.org/carldani/linux/patches/raiddetect/

The patch is against the latest udev bitkeeper tree and applies fine to udev-024 if you prefer working with officially released versions.

Regards,
Carl-Daniel

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Jeff Garzik

2004-04-21 17:34 UTC #4 lore raw

Quoted 14 lines · Carl-Daniel Hailfinger

since on one side ATARAID support has vanished from 2.6 and on the other side some parties are pushing for an enhanced MD driver in the kernel, why
don't we do the setup and metadata handling of all those types of RAID in
userspace?
I got positive feedback by private mail from several kernel developers for the last incarnations of raiddetect, so if you disagree, speak up now.
Raiddetect is a program to find vendor software RAID superblocks, analyze them for validity, group them by RAID vendor and (later on) set them up via MD/DM. It is small (~35kB compiled statically against klibc) and designed to be run from initrd/initramfs.
raiddetect now supports the following metadata formats:

Review

Quoted 4 lines

(quoted diff) +0 -4

-Promise RAID
-Highpoint RAID
-Medley RAID
-Intel RAID

Yeah, it's pretty spiffy. I like it.

My personal preference for raiddetect would be as a simple helper that examines the system, and outputs some information.

Then, someone using device mapper could use that in a script that takes the information generated by raiddetect, and uses it to configure DM-based raid0 and raid1 arrays.

Small and purpose-specific, and even usable for someone in a 2.4.x kernel that wrote a small MD-based plugin for "userspace-configured vendor raid [01]"

Quoted 10 lines

If you want support for another metadata format, please tell me which and I'll try to add it. Patches are preferred ;-) My current wishlist is:
- Adaptec ASR HostRAID
- DDF RAID
Hot-add and hot-remove features can be added easily if raiddetect is called by an udev rule on block device removal/insertion. If raiddetect stays loaded into memory or is allowed to save its state, hotplug events will not trigger any access to devices not related to that particular RAID array.

Well, hotplug and hotremove are more interrupt-context type events these days. It's feasible to send "device just appeared" or "device is already gone, nyah nyah" messages to /sbin/hotplug after that fact, mainly.

Failover and hotplug/hotremove callbacks are definitely in-kernel things, IMO. Userspace drives the policy behind that, of course.

Quoted 3 lines

It seems that there are some host adapter drivers out there implementing their own RAID engine which could be consolidated into a single RAID "library" instead. If you know about such drivers, please speak up.

In the kernel long term, I would definitely like to see just a single piece of code for each raid flavor -- RAID0, 1, 5, 6, etc.

Jeff

-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg297
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Wilfried Weissmann

2004-05-01 16:31 UTC #5 lore raw

In reply to Carl-Daniel Hailfinger

Hi,

I just returned from my vacation and checked my emails. That's why the response is so late.

Quoted 8 lines · Carl-Daniel Hailfinger

Quoted 1 line
Quoted 1 line
- People checking the numerous FIXMEs
I now have the following FIXMEs (aka "I have no idea about it"):
- 5 FIXMEs in the Medley RAID code. Thomas, could you comment once you're back?
- 3 FIXMEs in the Highpoint RAID code. Wilfried, could you please take a look at them?

1) FIXME: Does "no array defined" correspond to HPT_T_SINGLEDISK? I have to check this but I believe it is so.

2) FIXME: Is HPT_T_RAID_01_RAID_1 a value that can ever be found? I think this is the new style raid-10 format that is supported by hpt374 and upwards. I do not have such a controller so I cannot verify this.

3) FIXME: what does HPT_MAGIC_BAD mean?
You get this if you pull one disk out of a raid-0 array for example. The HPT-BIOS detects that the raid is not operational and marks the array as bad (writes the HPT_MAGIC_BAD to the remaining disks).

[snip]

Quoted 5 lines

Quoted 2 lines
Quoted 2 lines
- More data about Medley/Highpoint vendor superblocks (can I check for bogus values?)
Wilfried, is there any consistency check I can add for Highpoint?

I have not found any crc or so. But since HPT marks any disks that is not in an array as HPT_T_SINGLEDISK or HPT_MAGIC_BAD we should be fine unless someone writes some garbage to the superblock.

Quoted 7 lines

Quoted 4 lines
Quoted 4 lines
- Help with sorting out who owns which copyrights
This is still a _big issue_.

The HPT copyrights look fine.

I am looking forward to see the part that writes the dm configuration so that I can integrate it into the evms plugin.

bye,
wilfried

PS: add_disk_to_raidlists() does never return retval!

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id�66&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel