Requesting the inclusion of the latest LSI MegaRAID driver as a patch to the kernel used on the LiveCD. As of 2004.2, this driver is not included. For details, see the HOW-TO at: http://forums.gentoo.org/viewtopic.php?p=1489918#1489918 Reproducible: Always Steps to Reproduce: 1. 2. 3.
Get the driver added to gentoo-dev-sources and it'll go on the CD. We do not use any custom kernels other than what is available in portage simply because we do not want to have support on the CD for hardware which will not be supported on the instaleld system.
*** Bug 25856 has been marked as a duplicate of this bug. ***
Hm, is this the promised "compatibility with dell server class machines" from release 2004.2? (gwn 20040802) ;-) I ran today in this problem too, with a new poweredge 1850. I would patch and compile the kernel for myself, but this is sadly our first 64 bit machine.. And i have no time (and experience) to setup a cross-compile environment. Any news about this issue? P.S: The 2004.2 release for hppa based on a 2.4.26 kernel, and therefore the megaraid2 driver is included. And in 2.6.9 the driver is included too.
Great, inclusion in the kernel is the easiest way to go. I'll leave this bug around for now, but if the 2004.3 deadline comes close and we don't have a stable gentoo-dev-sources-2.6.9 release then I'll backport the driver from 2.6.9 into 2.6.8.
No... for one, the 1850 wasn't released when 2004.2 was... and second... GRR Dell... that's all I have to say. Daniel: the cut-off date for inclusion in 2004.3 is October 15th, so we have to have it in the "stable" gentoo-dev-sources by then.
Nathan and/or Henning, could you do me a huge favour and test this patch (applies against gentoo-dev-sources-2.6.8-r4) : http://dev.gentoo.org/~dsd/megaraid-gentoo.patch It's basically a backport of the new megaraid driver from 2.6.9, so hopefully it will just work :) If it does, I'll get it into the next gentoo-dev-sources release. Thanks!
I put it in gentoo-dev-sources-2.6.8-r5 anyway. I'd really appreciate it if someone with this hardware could test it.
Sorry, i didn
Sorry, i didn´t found the time to test it until now. I had some other issues at work to solve.. But thank you for the patch! Tomorrow i build the kernel from gentoo-dev-sources-2.6.8-r5, and on Saturday i would be able to test it on my dell 1850 machine.
Sadly i didn
Sadly i didn´t had much luck with catalyst at the weekend, the build process break short before the iso image creation. But i managed to build a x86 (32 Bit) kernel with your driver. The modules (megaraid_mm and megaraid_mbox) insmod process show no error, and the driver recognise correctly the raid type and size. Unfortunally i was not able to setup and mount the partition, as my boot cds fdisk don´t work. But i need a 64 Bit kernel anyway.. Perhaps there exist a 2004.3 livecd prerelease, that i can try?
Watch out..theres a data corruption bug in the new megaraid driver. Applying a fix right now.
Data corruption fixed in gentoo-dev-sources-2.6.8-r7. Thanks for the testing, if the module is loading alright and seeing your disks then I think its working. As long as its not oopsing/freezing.. Once test CD's are available, confirmation would be appreciated.
Reassigning back to LiveCD... thanks Daniel
I should have a test CD out shortly.
This has been fixed in my kernel configs for 2004.3 and now that we're using the latest and greatest gentoo-dev-sources, I'm going to mark this one as RESOLVED.
Yesterday i tested the experimental snapshot "install-amd64-minimal-20041026.iso". This livecd contain a gentoo-2.6.9 kernel. Unfortunally the megaraid driver is not included in this test release. Could you please activate the following options in the 2004.3 kernel config: CONFIG_MEGARAID_NEWGEN=y CONFIG_MEGARAID_MM=m CONFIG_MEGARAID_MAILBOX=m
jhuebel: read comment #15
users of the older and much more popular MegaRAID controllers (418, 428, 438, 466, 467, 490 and 762) suffer from the decision to only include the new generation MegaRAID driver. I am one of those, using a MegaRAID 1200 (428) controller, I can no more use the installcd for this machine. the bad thing [tm] is that the new driver cannot be compiled as a module (why the heck?!) and cannot coexist with the old one. what options do we have in order to make both work? well, I guess the only solution is to build 2 different kernels :-(
is this still an issue with the 2005.0 livecd?
Yes
Kernel team: is there any way we can enabe both the old and new magaraid drivers at the same time?
I have emailed the new-gen megaraid maintainer to ask what the technicalities are preventing including both in the same kernel. (There is a small overlap of device support, hopefully this is the only issue..?)
Created attachment 61486 [details, diff] Possible solution This will allow you to select both drivers and they compile together just fine. If we could get an legacy driver user to apply this and test a kernel with both drivers included, plus a new-generation driver user to do the same, then we'd be a step closer to solving this. However it might be a good idea to wait for the maintainers response first. I'm pretty sure this couldn't break anything but its always shaky ground when modifying storage drivers...
Comment on attachment 61486 [details, diff] Possible solution Patch is wrong. This is slightly harder to cope with but after finding a discussion I'm more certain that hardware support conflict is the only thing preventing these going together.
*** Bug 94628 has been marked as a duplicate of this bug. ***
Created attachment 61725 [details, diff] Driver support I did a better investigation of the issue and sent another mail with some more specific questions. I got a response saying its been forwarded to the lead engineer. Attaching my investigation here for future reference. Correct as of 2.6.12-mm1.
If LSI-hardware owners could test gentoo-sources-2.6.12-r4 while building both the old and the new drivers it would be appreciated. I've had no luck getting information out of LSI, but we now compile the drivers in such a way that we take all of the support from the new driver (like we did previously), _plus_ the non-conflicting parts of the legacy driver. (The entire legacy driver will be compiled as usual if you don't also select the new one...) This solution is definately going to be better than what we had previously, because we now support at least some of the older hardware too. I'd be interested to know if there is any hardware which is *not* supported when both drivers are compiled in together (its perfectly possible that there will be, but hard to say without wide user testing, while LSI aren't giving me the info I need). Thanks.
This should be resolved as of 2005.1's release. Feel free to REOPEN this bug if there is still an issue.
