> On 04/20/2008 01:16 AM, Steven Jones wrote: (>> Mumia W.. wrote: >>> [...] >>> Each patch is designed to be used against a particular version of the >>> Linux kernel. You might have an incompatible group of patches. For >>> example, if [the] Asus board patch is for 2.4.27, but the sk98lin patch >>> is >>> for 2.4.32, you have a problem because you won't be able to get both >>> patches into a single kernel. >> >> yes...I have found I can compile 2.4.36 but not .27 or .30....I seem to >> be in a mess....or 2.6.8, anything new like 36 has the buggy megaraid >> driver so I can boot... >> >> :( >> >> The patches say 2.4.20+ >> [...] > > The patches /should/ apply then. Exactly what are the patches that you > are trying to apply?
I will be applying lots! My motherboard is an Asus P5K premium Wi-fi....with two on-board NICS, one is on the pci-e bus (yukon) the other the pci bus (realtek). The chipset for the sata is the ICH9-R and I have a wi-fi NIC. The raid card is an old Perc 3CDL. Other misc notes (if this helps anyone), the cd boot device is a LG DVD SATA unit, I initially installed it on SATA channel 4 and the debian netinst cd would boot but at the cd detection stage it locked up (went to 8% and nothing happened). Moving it to the first sata channel and it booted, detected and installed fine. I also tried an Asus IDE DVD unit on the ide channel and that also failed at the cd detection stage (also 8%). Networking. Marvel Yukon patch sk98lin, the one in 2.4.27.deb didnt work (using modconf, failed to detect) but this one as a separate module now compiles, and works...next job is to patch a kernel with it and build it in one go (and not as a (M) but a (*). The realtek inbuilt 8110SC / 8169 didnt work either, the r1000 v1.05 module from asus didnt compile, it now compiles but does not work. (NB. I think you? mentioned a GCC mis-match? I think you were right, I rebuilt as a sarge box and it now compiles, before I had a sarge upgraded to etch and found it couldn't compile any kernel). I went to Realtek's website and found that Asus appear to be supplying the wrong patch for the chipset. It needs a different one at least for my version of the board. So I downloaded and compiled, it now works as a separate build, but it is not in a format that can be used to patch a kernel like the Yukon one can be....at least not for a simpleton like me! In that respect I recommend the Yukon one, it allows you to do an install (compiles stand alone and patches your ready running kernel) or generates a patch for you to apply to a kernel source and then compile all of it, very good instructions making it easy. WI-fi Ive yet to look at this patch, I will be though. ICH9R Ive yet to look at this patch, I will be though. Audio I wont be bothering as its a server... > How do you know that megaraid_mbox is failing? How does it fail (lockup, > reboot, panic)? lockup...for rhas5.1 it got to loading the megraid_mbox module and no further, if I set the raid controller to I2O and not mass storage it goes until the install, but cant see any disk to partition, if it was a conflict I'd expect either way to lock up, but I could be wrong. Ditto debian 4.0r3 netinst cd....it gets to detecting hardware and no longer responds. No issue with a netinst or 3.1r3. For a 2.6 kernel off a running install it boots to the raid controller and either no longer responds, or goes into a loop saying its resetting and waiting 300secs....just does this over and over....yet images 2.4.27-3 and -4 boot fine... > > Perhaps a single kernel command line parameter is all you need to boot. > The megaraid driver might be using the wrong I/O ports or IRQ's or > memory ranges. It is possible...however I have no idea how to address this....since 2.4 kernels work the iomem/interrupts would seem to be Ok...I'd suspect it is a bug. If I can/could I'd like to search against the changelogs? of 2.4 and 2.6 sources looking for a change in the megaraid module. Then compile a kernel before and after that change(s). If the one before works but the later does not it would strongly suggest an introduced bug. There maybe a better way? but my skills around compiling kernels are very limited.... regards Steven regards Steven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
