RAID Interface Mappings with RocketRaid 2310 (rr2310_00) fail in .37

SeanM · 2011-02-13 05:43:34

EDIT: This post was originally titled:
RAID Interface Mappings (Hard {Challenge?} Question) [with edit]
It has since been changed because further investigation found it to be a completely different problem... Go figure.
Also, this post is tightly coupled with another post (link further down in the comments).

Greetings...

Alright. So I'm not new to Linux to say the least, but I swear every time I have to deal with udev and related tasks something goes funky.

So, here's the issue:

I have a RocketRAID 2310 raid adaptor (made by HighPoint) that has a RAID5 configured using four 750 GiB drives. (of 8 in the machine)

The machine dual boots both Windows and Linux, and that is the main source of the issue. It appears as thought he Linux drivers and the Windows drivers, while both functional, are not designed to be intermixed... Which I suppose from a server perspective is a perfectly reasonable limitation, even if frustrating. Anyway, I digress...

I've been working with this card for years now, accepting the limitation that I could only access it from Windows. Today, though, I made an interesting discovery. I was reconfiguring some devices and noticed something strange about the fdisk output:

Disk /dev/sde: 750.2 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders, total 1465149168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sde1               1  4294967295  2147483647+  ee  GPT

Disk /dev/sdf: 750.2 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders, total 1465149168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0046b51b

Disk /dev/sdf doesn't contain a valid partition table

Disk /dev/sdg: 750.2 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders, total 1465149168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xac7a1898

Disk /dev/sdg doesn't contain a valid partition table

Disk /dev/sdh: 750.2 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders, total 1465149168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xac3cad83

Disk /dev/sdh doesn't contain a valid partition table

The four drives showing up as individual drives is completely normal per my experience with this card... What's new since installing Arch is the GPT partition table detected on the first drive, and more importantly, the sectors! For those that didn't catch that, let me highlight:

Disk /dev/sde: 750.2 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders, total 1465149168 sectors
...
/dev/sde1 1 4294967295 2147483647+ ee GPT

Yeah... Goes to a sector about three times the max. Also known as the raid partition! Huh, would you look at that. Sadly, udev doesn't catch it, and there is no /dev/sde1 partition.

Now there are two posibilities here as far as I can tell:

First, that somehow the entire GPT partition table is smaller then the striping block size of the RAID5, and that fdisk manages to read it entirely off the first disk in the raid. Striping is set at 64k I think, so it's possible, but seems a stretch...

Second, that the raid is being detected, but udev is missing it and something funny is happening with the device/partition mappings.

Now I would love to experiment to find out what is going on here, but the raid contains critical data (that, although backed up to tape, is still something I don't want to have to restore! Rebuilding the array takes 5 hours minimum, then restoring from tape is likely another 10... 15 hours downtime is not an option). What this means is that all tests on it have to be NON-DESTRUCTIVE, read only operations. To complicate matters (just because things can't be that easy), the contents of the RAID5 is a partition level TrueCrypt volume, so no easy way to determine the contents based off of partition identifiers.

I tried using parted, but sadly it coughs up a lung and aborts all operations when it sees a partition boundry outside the scope of the disk (as is the case here). Seriously, it won't even try. Wimp...

So that's where I am. Mistery partition that only fdisk can see. If I could get a file handle to it, I could try to get TrueCrypt to decrypt it to find out if it's a striping artifact or not.

Aside:
I suppose this question also links to another, more generic question: Given a 'file' (which could be any *nix file handle) that contains a valid partition table and partitions (say a dd if=/dev/sda of=/home/user/device.bak), how does one go about accessing it's partitions? Are there udev tricks, or some other method? Edit 1a: I know how loopback mounting works, but that doesn't expose the partitions within because it doesn't flag a uevent for the udev daemon to respond to... Not sure how to manually tell it to process /dev/loop0 and look for partitions (supposedly splitting it up into /dev/loop0p1, /dev/loop0p2, etc.)

Additional notes:
- I am not sure what device driver is being used for those four drives to be visible... It's not rr2310 (the HighPoint RAID driver), but I know the card uses a resold chipset (maybe Marvel?), so it could be detected by a number of other kernel drivers. lsmod doesn't have anything useful there. Is there maybe a way to determine what device file is associated with what driver module?... So many good questions. Too many for one post!
- The RAID BIOS config is a useless piece of junk. It loads into memory too early in the BIOS operations on this board, and thus runs into a race condition for detecting it's own hardware. 90%+ of the time it will list no drives detected, but continue booting and everything is there just fine. It conflicts with the AMI (Megatrends) BIOS, but not with similar Pheonix based ones on similar boards (which detect the drives and raid properly every boot)... For those thinking of RAID cards for their servers, don't grab HighPoint! I've since stayed clear, but this server has a long life expectency, so I'm having to live with it.

So there we have it! Hit me, Arch Forums, with your best theories or hacks!

Edit 1b:
I was recently reconfiguring two other drives in another computer to use a RAID0 array and didn't bother wiping them before initialising the array... Normally I wouldn't have even bothered checking, but today I felt curious. The RAID0 was striped with 64k blocks, same as the above mentioned RAID5... And low and behold, the new RAID0 array had the old partition table of one of the original drives. What this proves is that the striping of a RAID array (and I know that a rundundant array of independent disks array is redundant... ) can leave a partition table intact and readable. That makes the first option seem more probable...

Last edited by SeanM (2011-02-22 20:05:48)

count-corrupt · 2011-02-16 08:19:59

Your text is pretty confusing there. For one you're not telling us which driver you are using. I'm using the same card, partlyTrueCrypt, partly dm-crypt encrypted on both Windows and Linux and haven't had issues with that setup yet (other than this one since two days ago). I'm even booting my systems from it (which will change in the near future). The rr231x driver takes perfect care of the card, hides the individual disks and maps them to one single device in /dev/mapper/...

Can you tell us exactly what steps you took to install the card on linux?

Last edited by count-corrupt (2011-02-16 08:39:12)

SeanM · 2011-02-20 22:18:37

Alright!

Well I didn't expect to actually get a response to this after the first couple of days, but I'm glad someone has!

The information posted originally may be a bit out of date, as since it's posting I have done a tonne more research into to situation.

It appears as though the kernel defaults to using the sata_mv driver for the card as it detects it based on the Marvel chipset used. Cool. A lot of the mailing list discussions about sata_mv and the rr2310 reflect the problem that the raid controller writes state and configuration data to locations on the drive that are not reserved by the sata_mv driver, and how they should/should not (discussions rarely have consensus) deal with this problem. There are advisories about how everyone should use sata_mv over the rr2310 driver, but then point out that the sata_mv driver does not support raid, and using it may lead to data corruption in the blocks used by the controller to save it's state data. Really it's a much more complicated subject then I originally thought... Once you read through it, though, there really is only one conclusion to draw, and that's that for RAID to work you have to use the rr2310 driver supplied by the manufacturer.

So, following the advised steps (from the manufactuerer), I built my own version of the driver from source. During the compilation process (make) no errors were produced. I attempted to use their automated install scripts (make install, which calls install.sh), which worked for the most part but failed when they tried to use mkinitrd (depricated in Arch). Looking at the install.sh script that was throwing the error, it just has automated the process of updating initrd images for Debian, Ubuntu, Redhat, Fedora, and Suse. No big deal, as I'm not booting from the RAID I don't really need them loaded that early anyway.

So. Driver installed... Wonderful (or so I thought).

Problem is that the driver crashes. Next reboot I got (grep'd for clairity and relevance)

rr2310_00:RocketRAID 231x/230x controller driver v2.5 (Feb 20 2011 12:04:11)
rr2310_00:adapter at PCI 2:0:0, IRQ 16
rr2310_00:start channel [0,0]
rr2310_00:start channel [0,1]
rr2310_00:start channel [0,2]
rr2310_00:start channel [0,3]
rr2310_00:[0 0] Start channel soft reset.
rr2310_00:[0 1] Start channel soft reset.
rr2310_00:[0 2] Start channel soft reset.
rr2310_00:[0 3] Start channel soft reset.
rr2310_00:channel [0,0] started successfully
rr2310_00:channel [0,1] started successfully
rr2310_00:channel [0,2] started successfully
rr2310_00:channel [0,3] started successfully
scsi8 : rr2310_00

Alright... All going well...

scsi8 : rr2310_00
BUG: unable to handle kernel NULL pointer dereference at 0000000000000404
IP: [<ffffffffa00d2663>] hpt_queuecommand+0xd3/0xc70 [rr2310_00]
PGD 235941067 PUD 236471067 PMD 0 
Oops: 0000 [#1] PREEMPT SMP 
last sysfs file: /sys/bus/pci/drivers/ahci/uevent
CPU 0 
Modules linked in: pata_marvell pata_acpi ahci libahci rr2310_00(P+) libata scsi_mod

Pid: 462, comm: modprobe Tainted: P            2.6.37-ARCH #1 P5Q3 DELUXE/System Product Name
RIP: 0010:[<ffffffffa00d2663>]  [<ffffffffa00d2663>] hpt_queuecommand+0xd3/0xc70 [rr2310_00]
RSP: 0018:ffff880235b3b918  EFLAGS: 00010202
RAX: 0000000000000404 RBX: ffff880237f63000 RCX: ffff8802350c00f8
RDX: ffff880234a36200 RSI: 0000000000000000 RDI: ffff8802350c00e0
RBP: ffff880235b3b978 R08: 0000000000000000 R09: ffff880233a82810
R10: 0000000000000000 R11: 0000000000000000 R12: ffff880234a36000
R13: ffff8802350c0000 R14: ffff8802350c00e0 R15: ffff880236472300
FS:  00007f4e4c42c700(0000) GS:ffff8800bfc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000404 CR3: 0000000235940000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process modprobe (pid: 462, threadinfo ffff880235b3a000, task ffff880235af4c50)
Stack:
 ffff880235b3b968 ffffffff81066aed ffff880235b3a000 0000000000000086
 ffff880235b3b958 ffff880233a90000 ffff880233a82810 ffff880236472300
 0000000000000000 ffff880237f63000 ffff880233a90000 ffff880233a90390
Call Trace:
 [<ffffffff81066aed>] ? mod_timer+0x13d/0x320
 [<ffffffffa000284f>] scsi_dispatch_cmd+0xbf/0x270 [scsi_mod]
 [<ffffffffa00094c0>] scsi_request_fn+0x340/0x420 [scsi_mod]
 [<ffffffff811dd522>] __generic_unplug_device+0x32/0x40
 [<ffffffff811e15a8>] blk_execute_rq_nowait+0x68/0xb0
 [<ffffffff811e167a>] blk_execute_rq+0x8a/0x130
 [<ffffffff811ddceb>] ? blk_rq_bio_prep+0x2b/0xc0
 [<ffffffff811e1204>] ? blk_rq_map_kern+0xe4/0x170
 [<ffffffffa0008747>] scsi_execute+0xf7/0x160 [scsi_mod]
 [<ffffffffa0008859>] scsi_execute_req+0xa9/0x1b0 [scsi_mod]
 [<ffffffffa000ae41>] scsi_probe_and_add_lun+0x221/0xb80 [scsi_mod]
 [<ffffffff813a55f9>] ? mutex_unlock+0x9/0x10
 [<ffffffff812b4c3c>] ? attribute_container_add_device+0x12c/0x1f0
 [<ffffffffa000ba71>] __scsi_scan_target+0x131/0x6c0 [scsi_mod]
 [<ffffffff811f2a03>] ? ida_get_new_above+0x163/0x1e0
 [<ffffffffa000c087>] scsi_scan_channel+0x87/0xb0 [scsi_mod]
 [<ffffffffa000c421>] scsi_scan_host_selected+0x141/0x150 [scsi_mod]
 [<ffffffffa000c4b9>] do_scsi_scan_host+0x89/0x90 [scsi_mod]
 [<ffffffffa000c7d0>] scsi_scan_host+0x1a0/0x280 [scsi_mod]
 [<ffffffffa010c0b0>] init_this_scsi_driver+0xb0/0x103 [rr2310_00]
 [<ffffffffa010c000>] ? init_this_scsi_driver+0x0/0x103 [rr2310_00]
 [<ffffffff8100212f>] do_one_initcall+0x3f/0x180
 [<ffffffff81093e9b>] sys_init_module+0xbb/0x200
 [<ffffffff8100bed2>] system_call_fastpath+0x16/0x1b
Code: c3 0f 1f 80 00 00 00 00 8b b0 80 00 00 00 4c 89 f7 e8 e2 d0 00 00 48 85 c0 49 89 c4 74 25 f6 80 f0 01 00 00 01 74 1c 48 8b 43 50 <80> 38 a1 76 26 c7 83 e0 00 00 00 00 00 05 05 4c 8b bb 90 00 00
RIP  [<ffffffffa00d2663>] hpt_queuecommand+0xd3/0xc70 [rr2310_00]
 RSP <ffff880235b3b918>
CR2: 0000000000000404
---[ end trace b34ed1612642e392 ]---

D*** it.

So no device driver for me... Was there any special steps you took to compile your driver?

The only thing I can think of here is that I didn't specify ARCH=x86_64 while compiling, but that stack trace doesn't really reflect that (all addresses look appropriately padded, and the zero'd data on the stack is 64 bit), and the script did a pretty good job of detecting everything else, so that seems unlikely.

Since then I've had to disable the driver load because after if crashes udev takes the full 30 seconds+ to "wait for udev events to finish"... SIGH.

Anyway.

Any help you can offer would be AMAZING! I've tried to get this card to work in Linux for years.

count-corrupt · 2011-02-20 22:34:23

There's no special step needed to compile the driver. After my kernel problem with 2.6.37 came up, I even had to compile it from the 2010 live cd (I am booting from the raid) and it works like a charm.

I'm using this PKGBUILD to build the driver. I set the kernel version manually each time to make sure there's no error there but the `uname -r` should do just as fine. Then there's this .install file (edit kernel version again) which just performs depmod after the installation.

The only dependency I remember is base-devel, otherwise, as said, it even compiles in a vanillla arch live CD. You absolutely have to blacklist sata_mv when using the RocketRaid driver though. Even before loading it, you need to rmmod sata_mv.

My original post outlining the basic installation can be found here but it basically just says what I already listed here.

Keep us posted

SeanM · 2011-02-21 00:43:31

After following your steps as outlined in that post, as well as rebuilding the package using your PKGBUILD and .install script (which look to do the same thing that I did manually, but thought I would give it a try anyway...), I ended up with the same results.

The same null dereference at the same address.

I notice that you are running a 64 bit machine (same), and you mentioned using the .37 kernel (same).

I'm wondering what other possibility it could be... Is there any other tests you can think of?

(Also, I think it might be related to http://bugs.gentoo.org/show_bug.cgi?id=350753 )

Last edited by SeanM (2011-02-21 00:48:23)

count-corrupt · 2011-02-21 07:27:17

As I said, it doesn't work with 2.6.37. Try .36, it's the kernel I use it with atm.

SeanM · 2011-02-21 14:46:52

Hello again!

Alright, so I know I should probably fork this over to another thread at some point, because it's gotten a little off the original title, but whatever...

Here's the update! I have been digging around that link I previously posted with regards to the kernel update in .37 that changed the way the scsi host push-down locks operated (specifically to reduce needless locking and unlocking in device drivers that did not need it, as well as streamline the critical path while loading these drivers).

Anyway, all the open source drivers were patched at the same time the kernel was (go figure). That's the specific reason that the driver doesn't work. Anyway, there are two possible solutions to this problem now:

1) Downgrade to .36 (as you recommended), or
2) Patch the scsi host changes out of the system to revert functionality to the previous state.

Generally I like option 2 more, but I have a lot of controllers in this box, and I don't REALLY want to deal with potentially breaking them... I will let you know what I end up doing.

Is there an easy way to downgrade to .36?

(Also, I've already contacted HighPoint Tech to let them know about the kernel update, as well as the steps to take to fix it with relatively high level of detail. I've asked for a development release of the driver if they manage to get one out... They are still selling these cards, so I think support for them will likely continue for some time.)

count-corrupt · 2011-02-21 22:55:45

SeanM wrote:

Hello again!
Generally I like option 2 more

Agreed.

SeanM wrote:

Is there an easy way to downgrade to .36?

Depending on when you installed the system, you should have the old kernel packages in /var/lib/pacman/pkg. If you did a very recent install, I (or anyone else) can give you the packages. Arch really needs a backport repo.

SeanM wrote:

(Also, I've already contacted HighPoint Tech to let them know about the kernel update, as well as the steps to take to fix it with relatively high level of detail. I've asked for a development release of the driver if they manage to get one out... They are still selling these cards, so I think support for them will likely continue for some time.)

Tell me how you contacted them and what detail you've provided so I can do the same. I wanted to make a request for an update anyway but have been really busy the last few days. Maybe quantity will accelerate the process. It shouldn't be too hard an update since the kernel changes are well-documented and device drivers need to follow certain guidelines wo work with the kernel in the first place. The architecture should be relatively similar to the one in the in-kernel modules.

SeanM · 2011-02-22 07:59:35

Well I sent them an email at support@highpoint-tech.com and they haven't gotten back to me yet (to be fair, a lot of North America has a holiday today, so not overly surprising...)

I'll let you know what comes up if they email me back. Otherwise, I might give their support line a call and see if I can talk to an actual person. Who knows? Might work out well!

I'll post back here if I get any news.

Here's hoping!

Edit: They just opened a ticket on their bug tracker ([8048] - Linux Driver Update Required). I have been copied on all updates. I will let you know as it happens!

Edit2: /grumble... They seem to have clasified it as "low priority"... Not a good sign. The phone number listed on their old documentation (such as the 2310 user manual) has a disconected phone number, but the newer manuals have the right one.

Last edited by SeanM (2011-02-22 20:03:06)

count-corrupt · 2011-02-23 18:21:02

SeanM wrote:

Edit: They just opened a ticket on their bug tracker ([8048] - Linux Driver Update Required).

Not that I'm unable to google or anything, but I can't find that bug tracker. I even registered at their online support platform but I get an empty page with no issues once I log in. And google gives me nothing. Can you post a link to that issue please?

SeanM · 2011-02-23 21:28:31

Huh... Didn't think about that. I think it's controlled access on their bug tracker. The only issue I get when I log in is 8048. Created a second account and tried to access the URL directly and got an access denied, so it's not just blocking listing... :-(

I will do my best to monitor the ticket and keep pressure on to get it fixed (phone calls and whatnot). I'll post back here with any new information as it becomes available.

SeanM · 2011-02-25 14:21:53

Update:

It appears as though support and development personnel are located at least GMT+5 or further east, because every time they have created, changed status, or posted messages it's almost 1 am local time

I just got this very worrying update:

Support wrote:

Dear Customer,
Sorry sir.Now the driver of RR23xx can use on the Linux with 2.6.37 kernel.
I will sumbit your need.Please wait for 1-2 months.
Regards
HighPoint Global Support Center

Take from that what you will, but I believe the intention was to say "We are going to support it. Please allow 2 months for delivery.", though I suppose interpretations may vary.

In the mean time I think I'll be downgrading to .36... This, combined with general fglrx sluggishness is a giant pain. Hopefully by the .38 comes out third parties will have gotten their <expletive deleted> together and we can all just get along

count-corrupt · 2011-02-25 15:17:00

SeanM wrote:

Take from that what you will, but I believe the intention was to say "We are going to support it. Please allow 2 months for delivery.", though I suppose interpretations may vary.
In the mean time I think I'll be downgrading to .36... This, combined with general fglrx sluggishness is a giant pain. Hopefully by the .38 comes out third parties will have gotten their <expletive deleted> together and we can all just get along

Seems to be the best choice for now. Let's be hopeful they actually mean they're working on it. The current version of the driver is already years old. I'll send them an email as well to keep pushing.

niels.horn · 2011-03-20 23:24:38

For those who don't want to wait, I have a working patch for the rr232x driver.
Patching the rr231x driver should be very similar.

See my blog post: http://blog.nielshorn.net/2011/03/vhba- … -2-6-37-x/

count-corrupt · 2011-03-21 07:14:30

niels.horn wrote:

For those who don't want to wait, I have a working patch for the rr232x driver.
Patching the rr231x driver should be very similar.
See my blog post: http://blog.nielshorn.net/2011/03/vhba- … -2-6-37-x/

Very nice. I'll look into patching the 2310 tonight.

count-corrupt · 2011-03-22 16:48:39

The patch provided by niels.horn works just the same with the rr231x driver. Thank you niels! The source file in question only differs to that of the 232x one in one line and that is some debug output. I've modified the patch, updated my PKGBUILD, compiled and successfully rebooted into kernel 2.6.37 with / on the raid.

The PKGBUILD, .install and the patch can be downloaded here (zip). Right now, inside the PKGBUILD and .install I set the kernel version manually. If you don't boot from your raid drive, you should replace those lines with

`uname -r`

Maybe I'll upload this to the aur later.
Edit: Now also on AUR

Last edited by count-corrupt (2011-03-22 17:29:41)

niels.horn · 2011-03-22 23:27:21

Good to know that it worked!
I'm not a full-time Arch user really, but the Arch community has helped me in the past so It's nice I can do something in return

count-corrupt · 2011-05-11 19:06:39

It appears, the problems are back with kernel 2.6.38. I haven't looked into the details yet but it doesn't compile as-is with the new kernel headers anymore.

Resh · 2011-07-02 10:57:48

hi,

I have a solution for rr232x-driver under kernel >= 2.6.38
It compile and work well

First:
autoconf.h replace config.h, but autoconf.h is in a different directory.
run

find /usr/src -name autoconf.h

to find it.
I found it under

/usr/src/linux-2.6.39-ARCH/include/generated/autoconf.h

Then add the line

CFLAGS+=-imacros /usr/src/linux-2.6.39-ARCH/include/generated/autoconf.h

to

src/rr232x-linux-src-v1.10/inc/linux/Makefile.def

I have written a patch

--- src/rr232x-linux-src-v1.10/inc/linux/Makefile.def    2009-07-16 03:28:28.000000000 +0200
+++ src/rr232x-linux-src-v1.10/inc/linux/Makefile.def    2011-07-02 11:13:49.372160696 +0200
@@ -88,6 +88,9 @@
 
 ifeq ($(KERNEL_VER), 2.6)
 
+AUTOCONFDIR := /usr/src/linux-$(shell uname -r)/include/generated
+CFLAGS+=-imacros $(AUTOCONFDIR)/autoconf.h
+
 TARGET := $(TARGETNAME).ko
 
 $(TARGETNAME).ko: $(CURDIR)/.build/Makefile

but its fail with

patching file src/rr232x-linux-src-v1.10/inc/linux/Makefile.def
Hunk #1 FAILED at 88.
1 out of 1 hunk FAILED -- saving rejects to file src/rr232x-linux-src-v1.10/inc/linux/Makefile.def.rej

so I unpack the source, add the line manually, pack the source and update the md5sum.
Its a dirty way, but its work...
The next step is to remove the include config.h from src/rr232x-linux-src-v1.10/osm/linux/osm_linux.h.
The Patch:

--- src/rr232x-linux-src-v1.10/osm/linux/osm_linux.h    2009-07-16 03:28:28.000000000 +0200
+++ src/rr232x-linux-src-v1.10/osm/linux/osm_linux.h    2011-07-01 22:12:01.240803393 +0200
@@ -8,10 +8,6 @@
 
 /* system headers */
 
-#ifndef AUTOCONF_INCLUDED
-#include <linux/config.h>
-#endif
-
 #include <linux/version.h>
 
 #if (LINUX_VERSION_CODE < KERNEL_VERSION(2,5,0)) && defined(MODVERSIONS)

okay, after that the compile fail with

 ... os_linux.c:263:7: error: too few arguments to function blkdev_get ...

I search for the function and found http://www.kernel.org/doc/htmldocs/file … v-get.html and compare the parameter list. The API has one more argument named 'holder'
The API say: FMODE_EXCL with NULL holder is invalid
but in the Source the mode is FMODE_READ so I add a NULL for holder in the parameter list.

The Patch:

--- src/rr232x-linux-src-v1.10/osm/linux/os_linux.c    2009-07-16 03:28:28.000000000 +0200
+++ src/rr232x-linux-src-v1.10/osm/linux/os_linux.c    2011-07-01 21:41:32.587393196 +0200
@@ -260,7 +260,7 @@
                     struct block_device *bdev = bdget(MKDEV(major[i], minor));
                     if (bdev &&
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,28)
-                        blkdev_get(bdev, FMODE_READ)
+                        blkdev_get(bdev, FMODE_READ, NULL)
 #else 
                         blkdev_get(bdev, FMODE_READ, 0 __BDEV_RAW)
 #endif

And now the PKGBUILD:

pkgname=rr232x
pkgver=1.10
pkgrel=1
pkgdesc="Kernel module for Highpoint RocketRAID 232x SATA cards"
arch=('i686' 'x86_64')
url="http://www.highpoint-tech.com/USA/bios_rr2320.htm"
license=('custom')
groups=()
depends=('kernel26>=2.6.38')
makedepends=()
provides=()
conflicts=()
replaces=()
backup=()
options=()
install=rr232x.install
source=("http://www.support-highpoint-tech.com/Main/rr232x/Linux/opensrc/rr232x-linux-src-v$pkgver-090716-0928.tar.gz")
md5sums=('...')
noextract=()

_kernver=$(uname -r)

build() {
    mkdir -p $startdir/pkg/lib/modules/${_kernver}/kernel/drivers/scsi/

    cd $startdir
    patch -p0 < 2.6.37.patch
#    patch -p0 < makefile.patch
    patch -p0 < os_linux.patch
    patch -p0 < osm_linux.patch
    cd $startdir/src/rr232x-linux-src-v$pkgver/product/rr232x/linux/

    KERNELDIR=/lib/modules/${_kernver}/build make

    # Install the kernel module
    install -m 644 -D rr232x.ko $startdir/pkg/lib/modules/${_kernver}/kernel/drivers/scsi/

    mkdir -p $startdir/pkg/usr/share/licenses/$pkgname
    cp $startdir/src/rr232x-linux-src-v$pkgver/README $startdir/pkg/usr/share/licenses/$pkgname/
}

rr232x.install:

# This is a default template for a post-install scriptlet.  You can
# remove any functions you don't need (and this header).

# arg 1:  the new package version
pre_install() {
  /bin/true
}

# arg 1:  the new package version
post_install() {
  depmod -v $(uname -r) > /dev/null 2>&1
}

# arg 1:  the new package version
# arg 2:  the old package version
post_upgrade() {
  depmod -v $(uname -r) > /dev/null 2>&1
}

# arg 1:  the old package version
post_remove() {
  depmod -v $(uname -r) > /dev/null 2>&1
}

op=$1
shift
$op $*

Dont forget to add the md5sum and have fun

Last edited by Resh (2011-07-02 10:59:54)

count-corrupt · 2011-07-02 11:04:58

Meh, I have a patched version working since a month ago. I just forgot to post/upload on aur. The patch has been around for a while, the code for all the rocketraid types is essentially the same.

Still thanks for the detailed post. Good to see I'm not the only one with these problems.

Edit: I updated the AUR package.

Last edited by count-corrupt (2011-07-02 11:13:09)

LEN365 · 2011-07-26 23:16:18

Has anyone tried to patch 2.6.39 or 3.0 yet? I am on a different distro and was having compiling issues with 2.6.39 and found this topic but thought I would try in on 2.6.39 if anyone else had tried that yet.

Thanks!

count-corrupt · 2011-07-27 06:45:41

LEN365 wrote:

Has anyone tried to patch 2.6.39 or 3.0 yet? I am on a different distro and was having compiling issues with 2.6.39 and found this topic but thought I would try in on 2.6.39 if anyone else had tried that yet.

I haven't tried 3.0 yet but as I said, .39 works fine with the patch that can be found in that aur package. The changes are really marginal and not distro-specific, so you shouldn't have a problem applying the patch to a vanilla- or your distro's kernel.

count-corrupt · 2011-08-13 09:27:09

I patched the driver on AUR to compile with Kernel 3.* (linux). It should also still compile with older kernels. I would appreciate some feedback on this.

AUR package

ga01f4733 · 2011-11-25 17:25:15

Hi, I downloaded your last package, and adapted for the 232x model, using the rr232x-linux-src-v1.10-090716-0928.tar.gz from RR.
I'm not an expert in pkg building, but after some reading I considered myself enough armed, ... I thought so (sic)
So I did replace all strings related to the model and the package version in the install, PKGBUILD and patches. It patches fine except the Makefile.def that is rejected. I hope you could share some light in that issue.

Currently, the kernel is 3.1.2-1-ARCH, so might that be the problem?

that is rr232x.install

 # This is a default template for a post-install scriptlet.  You can
# remove any functions you don't need (and this header).

KERNEL_VERSION=`uname -r`

# arg 1:  the new package version
pre_install() {
  /bin/true
}

# arg 1:  the new package version
post_install() {
  depmod -v $KERNEL_VERSION > /dev/null 2>&1
  
  /bin/cat <<EOF
  
==> To use this module, sata_mv has to be unloaded or the kernel will panic
==> To unload sata_mv, please do 
==>
==> # rmmod sata_mv
==>
==> as root before loading rr232x
==>
==> If you want to use this module permanently, you should blacklist
==> sata_mv by adding 'blacklist sata_mv' to /etc/modprobe.d/modprobe.conf
EOF
}

# arg 1:  the new package version
# arg 2:  the old package version
post_upgrade() {
 post_install
}

# arg 1:  the old package version
post_remove() {
  depmod -v $KERNEL_VERSION > /dev/null 2>&1
}

the modded PKGBUILD

 # Maintainer: count-corrupt <corrupt at giggedy dot de>
pkgname=rr232x
pkgver=1.10
pkgrel=1
pkgdesc="Kernel modules for Highpoint RocketRAID 230x and 231x SATA cards. Patched for use with kernel26 =2.6.37, >=2.6.38 and kernel >= 3 (a.k.a. linux)"
arch=('i686' 'x86_64')
url="http://www.highpoint-tech.com/USA/bios_rr2320.htm"
license=('custom')
groups=()

if [[ `uname -r` == 2.6.* ]]; then
depends=('kernel26')
else
depends=('linux')
fi

makedepends=()
provides=()
conflicts=()
replaces=()
backup=()
options=()
install=$pkgname.install
source=( http://www.highpoint-tech.cn/BIOS_Driver/rr232x/Linux/new%20format/rr232x-linux-src-v1.10-090716-0928.tar.gz scsi_lck.patch kernel3.patch)
noextract=()
md5sums=()

#_kernver=`uname -r`
_kernver=`uname -r`

build() {
    mkdir -p $startdir/pkg/lib/modules/${_kernver}/kernel/drivers/scsi/

    # Apply the scsi lock patch to make the driver work with kernel26 > 2.6.37
    cd $startdir
    patch -p0 -i $startdir/scsi_lck.patch
	patch -p0 -i $startdir/kernel3.patch

    cd $startdir/src/rr232x-linux-src-v$pkgver/product/rr232x/linux/
    make KERNELDIR=/usr/src/linux-$_kernver || return 1

    # Install the kernel module
    install -m 644 -D rr2320_00.ko $startdir/pkg/lib/modules/${_kernver}/kernel/drivers/scsi/

    mkdir -p $startdir/pkg/usr/share/licenses/$pkgname
    cp $startdir/src/rr232x-linux-src-v$pkgver/README $startdir/pkg/usr/share/licenses/$pkgname/
}

patches kernel3.patch and scsi_lck.patch are modded accordingly.

To avoid dependencies,

  makepkg -i --skipinteg

so I get those results ...

 
┌─17:40 joan@WS01  ~/src/rr232x_mod 
└─>>>  makepkg -i --skipinteg
==> S'està fent el paquet: rr232x 1.10-1 (dv nov 25 17:44:16 CET 2011)
==> Comprovant les dependències en temps d'execució ...
==> Comprovant de dependències per l'assemblatge ...
==> S'estan recuperant les fonts...
  -> S'ha trobat rr232x-linux-src-v1.10-090716-0928.tar.gz
  -> S'ha trobat scsi_lck.patch
  -> S'ha trobat kernel3.patch
==> AVÍS: S'està ometent la comprovació de la integritat.
==> S'està extraient el codi font...
  -> S'està extraient  rr232x-linux-src-v1.10-090716-0928.tar.gz amb bsdtar
==> S'està eliminant el directori pkg/ existent...
==> S'està entrant en l'entorn fakeroot...
==> Iniciant build()...
patching file src/rr232x-linux-src-v1.10/osm/linux/os_linux.c
patching file src/rr232x-linux-src-v1.10/osm/linux/osm_linux.c
patching file src/rr232x-linux-src-v1.10/osm/linux/osm_linux.h
patching file src/rr232x-linux-src-v1.10/inc/linux/Makefile.def
Hunk #1 FAILED at 74.
Hunk #2 FAILED at 119.
2 out of 2 hunks FAILED -- saving rejects to file src/rr232x-linux-src-v1.10/inc/linux/Makefile.def.rej
==> ERROR: S'ha produït un error en build().
    S'està cancel·lant...

so I guess the scsi_lck.patch is fine, and the issue must be in the adressing of the kernel version.

the rejected Makefile

--- src/rr232x-linux-src-v1.10/inc/linux/Makefile.def.orig	2011-08-13 10:13:37.000000000 +0200
+++ src/rr232x-linux-src-v1.10/inc/linux/Makefile.def	2011-08-13 11:15:53.000000000 +0200
@@ -74,19 +74,39 @@
 KERNELDIR := /lib/modules/$(shell uname -r)/build
 endif
 
-KERNEL_VER := 2.$(shell expr `grep LINUX_VERSION_CODE $(KERNELDIR)/include/linux/version.h | cut -d\  -f3` / 256 % 256)
+KERNEL_MAJ_VER := $(shell expr `grep LINUX_VERSION_CODE /usr/src/$(uname -r)/include/linux/version.h | cut -d\  -f3` / 65536 % 65536)
+
+KERNEL_VER := $(KERNEL_MAJ_VER).$(shell expr `grep LINUX_VERSION_CODE $(KERNELDIR)/include/linux/version.h | cut -d\  -f3` / 256 % 256)
 
 ifeq ($(KERNEL_VER),)
 $(error Cannot find kernel version. Check $(KERNELDIR)/include/linux/version.h.)
 endif
 
+
 ifneq ($(KERNEL_VER), 2.6)
 ifneq ($(KERNEL_VER), 2.4)
-$(error Only kernel 2.4/2.6 is supported but you use $(KERNEL_VER))
+ifneq ($(KERNEL_MAJ_VER), 3)
+$(error Only kernel 2.4/2.6/3 is supported but you use $(KERNEL_VER))
 endif
 endif
+endif
+
+ifeq ($(KERNEL_VER), 2.4)
+
+HPT_LIB := $(HPT_LIB)-regparm0
+_TARGETMODS := $(addprefix $(HPT_LIB)/,$(TARGETMODS))
+
+VPATH := .. $(HPT_ROOT)/osm/linux
+TARGET := $(TARGETNAME).o
+
+C_INCLUDES += -I$(HPT_ROOT)/osm/linux -I$(KERNELDIR)/include -I$(KERNELDIR)/drivers/scsi
+
+$(TARGET): $(TARGETOBJS) $(_TARGETMODS)
+	@echo $(if $V,,[LD] $@)
+		$(if $V,,@)$(CROSS_COMPILE)$(LD) -r -o $@ $^
+
 
-ifeq ($(KERNEL_VER), 2.6)
+else # for kernel >= 2.6
 
 TARGET := $(TARGETNAME).ko
 
@@ -119,20 +139,6 @@
 	@echo '$$(addprefix $$(obj)/,$$(TARGETMODS)): $$(obj)/%.o: $$(HPT_LIB)/%.o' >>$@
 	@echo '	@cp -f $$< $$@' >>$@
 
-else # for kernel 2.4 modules
-
-HPT_LIB := $(HPT_LIB)-regparm0
-_TARGETMODS := $(addprefix $(HPT_LIB)/,$(TARGETMODS))
-
-VPATH := .. $(HPT_ROOT)/osm/linux
-TARGET := $(TARGETNAME).o
-
-C_INCLUDES += -I$(HPT_ROOT)/osm/linux -I$(KERNELDIR)/include -I$(KERNELDIR)/drivers/scsi
-
-$(TARGET): $(TARGETOBJS) $(_TARGETMODS)
-	@echo $(if $V,,[LD] $@)
-	$(if $V,,@)$(CROSS_COMPILE)$(LD) -r -o $@ $^
-
 endif # KERNEL_VER
 
 endif # KMOD

Had tried already several days without success, and I'm runnin' out of ideas, so I ask for some guidance to find back the path.

Thanks in advance

Last edited by ga01f4733 (2011-11-25 17:27:13)

count-corrupt · 2011-11-26 17:20:30

ga01f4733 wrote:

...

Try this. It's a source package. For some reason the aur won't let me "overwrite" the rr232x package.

Anyway, in principle you did everything right. Only the patch files didn't match exactly. I downloaded the package, made the changes by hand and recreated the patch files. I also fixed a mistake I made while creating the patches last time as outlined in the comments for the rr231x package in aur. I can't test the package because I don't have the card, but it compiles fine. Let me know if it worked.

Arch Linux

#1 2011-02-13 05:43:34

RAID Interface Mappings with RocketRaid 2310 (rr2310_00) fail in .37

#2 2011-02-16 08:19:59

Re: RAID Interface Mappings with RocketRaid 2310 (rr2310_00) fail in .37

#3 2011-02-20 22:18:37

Re: RAID Interface Mappings with RocketRaid 2310 (rr2310_00) fail in .37

#4 2011-02-20 22:34:23

Re: RAID Interface Mappings with RocketRaid 2310 (rr2310_00) fail in .37

#5 2011-02-21 00:43:31

Re: RAID Interface Mappings with RocketRaid 2310 (rr2310_00) fail in .37

#6 2011-02-21 07:27:17

Re: RAID Interface Mappings with RocketRaid 2310 (rr2310_00) fail in .37

#7 2011-02-21 14:46:52

Re: RAID Interface Mappings with RocketRaid 2310 (rr2310_00) fail in .37

#8 2011-02-21 22:55:45

Re: RAID Interface Mappings with RocketRaid 2310 (rr2310_00) fail in .37

#9 2011-02-22 07:59:35

Re: RAID Interface Mappings with RocketRaid 2310 (rr2310_00) fail in .37

#10 2011-02-23 18:21:02

Re: RAID Interface Mappings with RocketRaid 2310 (rr2310_00) fail in .37

#11 2011-02-23 21:28:31

Re: RAID Interface Mappings with RocketRaid 2310 (rr2310_00) fail in .37

#12 2011-02-25 14:21:53

Re: RAID Interface Mappings with RocketRaid 2310 (rr2310_00) fail in .37

#13 2011-02-25 15:17:00

Re: RAID Interface Mappings with RocketRaid 2310 (rr2310_00) fail in .37

#14 2011-03-20 23:24:38

Re: RAID Interface Mappings with RocketRaid 2310 (rr2310_00) fail in .37

#15 2011-03-21 07:14:30

Re: RAID Interface Mappings with RocketRaid 2310 (rr2310_00) fail in .37

#16 2011-03-22 16:48:39

Re: RAID Interface Mappings with RocketRaid 2310 (rr2310_00) fail in .37

#17 2011-03-22 23:27:21

Re: RAID Interface Mappings with RocketRaid 2310 (rr2310_00) fail in .37

#18 2011-05-11 19:06:39

Re: RAID Interface Mappings with RocketRaid 2310 (rr2310_00) fail in .37

#19 2011-07-02 10:57:48

Re: RAID Interface Mappings with RocketRaid 2310 (rr2310_00) fail in .37

#20 2011-07-02 11:04:58

Re: RAID Interface Mappings with RocketRaid 2310 (rr2310_00) fail in .37

#21 2011-07-26 23:16:18

Re: RAID Interface Mappings with RocketRaid 2310 (rr2310_00) fail in .37

#22 2011-07-27 06:45:41

Re: RAID Interface Mappings with RocketRaid 2310 (rr2310_00) fail in .37

#23 2011-08-13 09:27:09

Re: RAID Interface Mappings with RocketRaid 2310 (rr2310_00) fail in .37

#24 2011-11-25 17:25:15

Re: RAID Interface Mappings with RocketRaid 2310 (rr2310_00) fail in .37

#25 2011-11-26 17:20:30

Re: RAID Interface Mappings with RocketRaid 2310 (rr2310_00) fail in .37

Board footer