Steven Jones wrote:
[EMAIL PROTECTED] wrote:
8><------
I just compiled a 2.4.36-3 kernel using the 2.4.27's config file, locks
up at the megaraid module, so somewhere between .27 and .36 there was a
change that broke the megaraid module.
I am compiling a 2.4.30 but I think that's broken as well as it didnt
work last time. So I will then try a .28 and a .29.
Hopefully then I will know which kernel and be able to spot it in the
changlog?
2.4.30 died at the megaraid module, found this in the chnagelog,
Summary of changes from v2.4.30-pre1 to v2.4.30-pre2
============================================
<krzysztof.h1:wp.pl>:
o [SPARC32]: Need to clear PSR_EF in psr of childregs on fork() on SMP
<marcelo:dmt.cnet>:
o Changed VERSION to v2.4.30-pre2
<temnota+kernel:kmv.ru>:
o megaraid2 reorder inline functions
<vvs:sw.ru>:
o megaraid2 update 2.10.8.2
nothing in 2.4.29 so that's next.
regards
Steven
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]