Messages in this thread | | | Date | Tue, 4 Feb 2003 21:49:25 +0200 (EET) | From | Mikael Johansson <> | Subject | Re: DAC960, Alpha, 2.4.21-pre4 (Was: DAC960, 2.4.19 alpha problems) |
| |
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/
| |