Hello All!
Top-posting and replying to my own mail. Let's hope this at least is
useful for someone :-)
An update on the issue described below: The "mem=2047M" only _seemed_ to
solve the problem. The machine booted, but processes accessing the
RAID-array mount (/wrk) froze and became unkillable in a "D-state"
(immortal is the wrong word; they weren't alive).
The foolproof method of creating these processes was running bonnie++ -f,
a few seconds after "Rewriting..." all access to /wrk died. Impossible to
kill the processes with "kill -9" either (is there an even deadlier way?)
This happened on all kernels I tested, 2.4.19, 2.4.20, 2.4.21-pre4.
Unfortunately I couldn't test the -ac patches, as they needed a header
file missing on my system, sched_runqueue.h. Failed to locate it anywhere
else also.
So I now compiled the 2.2.23 kernel, and it (again) _seems_ to be running
OK. At least bonnie++ finishes. Now there's only the occasional spinlocks
that get stuck...
Anyway, if someone has a similar system, DP264/Tsunami/2*EV67, and can't
get things working with the DAC960 and 2.4, you can take some comfort in
the fact that you are not alone.
Just realized that I should have checked with a non SMP kernel, to see if
that would have made a difference.
Finally, if there are any wise persons out there who would benefit from
more precise information in efforts to solve this, I will be very glad to
help out.
Have a nice day,
Mikael J.
http://www.helsinki.fi/~mpjohans/
On Fri, 31 Jan 2003, Mikael Johansson wrote
> Hello All!
>
> After finally upgrading the 2.2 kernel on one of our alphas to the
> 2.4.21-pre4 kernel, the console got cluttered with EXT2 error messages
> from the RAID-array on the Mylex DAC960PX. First I tought it was a file
> system proble,m, but then found the following post:
>
> On Wed, 20 Nov 2002, Ivan Kokshaysky wrote:
>
> > That was it, I guess.
> > virt_to_bus() is deprecated - driver *must* be converted
> > to the DMA mapping interface (see Documentation/DMA-mapping.txt).
> >
> > virt_to_bus() on alpha works only for limited range of kernel addresses.
> > On dp264 valid range is 0x00000000-0x7fefffff (i.e. 2Gb - 1Mb).
> > Given the fact that __get_free_pages() returns highest possible
> > pages I'm not surprised that this driver doesn't work on a 2Gb machine.
> >
> > Probably "mem=2047M" boot argument would help...
>
> Actually, I first compiled the kernel as "Generic", which let the system
> boot. When I recompiled the kernel more specifically for the machine type,
> DP264/Tsunami/2*EV67, the boot process would halt when the DAC960 driver
> tried to init. (A good thing; otherwise I would still be looking at the
> problem as an ext2-problem).
>
> Anyway, the machine has 2GB mem, and the "mem=2047M" seems to help (it
> boots).
>
> A question: Is this trick safe? Or should i downgrade to an earlier
> kernel?
>
> A comment: I guess a warning/conflict message about this should also be
> printed for the "Generic" (and maybe other configs that manage to boot)
> kernel compilation, as it seems to lead to massive file system corruption
> on the RAID-array (e2fsck -y /dev/rd/c0d0 printed "a million" screens of
> errors :-)
>
> Have a nice day,
> Mikael J.
> http://www.helsinki.fi/~mpjohans/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Feb 07 2003 - 22:00:15 EST