Re: Install problem w. RocketRaid 1720.
"Erik P. Olsen" <[email protected]>
| Newsgroups | gmane.linux.ataraid |
|---|---|
| Message-ID | <[email protected]> |
Richard Creighton wrote: > Erik P. Olsen wrote: >> Hi, >> >> I have installed two sata II disks via a RocketRaid 1720 controller. >> They run Fedora 7 in a hardware raid1 configuration. I have >> experienced certain problems wich seems to be related to kernel >> 2.6.21-1.3194.fc7, see bugzilla issue 240982. >> >> The driver from hightech only works with this kernel and the socalled >> open source driver compiles with errors. This is too much of a pita so >> I would prefer to skip the proprietary driver and run software raid1 >> instead. >> >> First of all I would like to know if linux supports drivers for >> RocketRaid 1720? Secondly, is it possible to convert the hardware >> raid1 to software raid1 (dmraid) without touching the already running >> OS? Or do I have to create a new system from scratch? >> > I had the same problem with a RR1740x controller with that kernel. I > was able to successfully compile the driver when I upgraded the kernel > to 2.6.22.... being sure to get the correct syms. Since then, I've > been able to run the controller just fine. My problems started with > >2.6.18.... until .22+ It is continuing to work with .17 and .25 in > the alpha 11 of SuSE. It is a pita, to be sure, but I am no happily > running a 2.5TB raid5 with that controller under SuSE 10.3. > As to conversion: I suspect that it is a real PITA to try. The > formats are entirely different and you have to have a small boot > partition in order to load the drivers for the software raid. I tried > and gave up on that idea, at least until RR decides to actually support > their controllers under Linux the way they do for Microsloth. > > I suspect the 172x controller will play out the same way as the 174x > controller did as I believe they use the same chipset, the main > difference being how they handle the physical interface, eg, number of > ports, etc. Well, there are differences but I do believe the basic functions are the same. The README file in the source directory talks about running "make oldconfig" and "make dep" under the kernel source directory. I am compiling the driver against kernel 2.6.23.15-80.fc7 and "make oldconfig" went OK but "make dep" did not saying: *** Warning: make dep is unnecessary now. Further I should check modversions.h for a certain line. However, this file is not found in the kernel source. Nevertheless I ran make under the driver source and got: [root@epohost linux]# make KERNELDIR=/usr/src/kernels/2.6.23.15-80.fc7-i686 ARCH=i386 make[1]: Entering directory `/usr/src/kernels/2.6.23.15-80.fc7-i686' CC [M] /downloads/RocketRaid/source/rr172x-linux-src-v1.0/product/rr1720/linux/.build/os_linux.o /downloads/RocketRaid/source/rr172x-linux-src-v1.0/product/rr1720/linux/.build/os_linux.c: In function ‘os_sd_changed’: /downloads/RocketRaid/source/rr172x-linux-src-v1.0/product/rr1720/linux/.build/os_linux.c:315: error: implicit declaration of function ‘scsi_device_cancel’ make[2]: *** [/downloads/RocketRaid/source/rr172x-linux-src-v1.0/product/rr1720/linux/.build/os_linux.o] Error 1 make[1]: *** [_module_/downloads/RocketRaid/source/rr172x-linux-src-v1.0/product/rr1720/linux/.build] Error 2 make[1]: Leaving directory `/usr/src/kernels/2.6.23.15-80.fc7-i686' make: *** [rr172x.ko] Error 2 So clearly the compile procedure does not work. Have you had the same bad experience and been clever enough to overcome the problem? I'll be happy to hear if you have a way out otherwise I'll have to work with highpoint to get the problem resolved. > > Once I got the RR1740x to compile under Linux with a less buggy kernel, > I have had zero problems with the card other than lack of any real > support, though the driver source did not need modifications once the > kernel issues were resolved. > -- Erik.