[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: compiling a 2.4 kernel

> 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%).


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.

Ive yet to look at this patch, I will be though.

Ive yet to look at this patch, I will be though.

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





Reply to: