Messages in this thread | | | From | (G.W. Wettstein) | Date | Fri, 21 Aug 1998 09:42:37 -0500 | Subject | 2.0.35 DPT problems or is FDISK bad? |
| |
Good morning to everyone on the list. I hope that this note finds summer winding up well for everyone.
I have been fighting for the last two days with a DPT 3334UW controller in a GW2K NS8000 server. The machine is a dual PII-300 with 256 megabyte of RAM running a modular 2.0.35 UP kernel. There are 4 9 gigabyte drives attached to the controller. The DOS based storage manager was used to create a single RAID5 array group out of these drives.
Everything starts up fine and the RAID group is recognized and no problems are encountered building a minimal root partition on the composite drive. Problems appear to occur when additional large filesystems are constructed. Here is the partition layout which causes problems:
#1 primary: 128Mbytes root #2 primary: 128Mbytes swap #3 primary: 1Gbyte var #4 extended: remainder of array #5 extpart: 20Gbyte home
When filesystems are built on the #3 or #5 partition the result is catastrophe. The entire array including the root are annihilated and the machine locks hard.
The reason I am suspicious of fdisk and the partition table is that fdisk reports back some strange numbers with respect to the partition table. Most notably the begin field tops out at 1024 regardless of what the start field indicates.
Linux views the raid array with a geometry of 26048x64x32 while the DPT reports back a geometry of 3320x255x63 before the partition table is written. I used the expert mode of fdisk to force fdisk to view the drive in the same way as the DPT controller does. Everything seems to work with the exception that things blow up again when attempts are made to work with the partitions above 1024 cyclinders.
I am writing this note while we continue to work with the problem and I can now report that RedHat fails as well. We used the Disk Druid software to partition the drive and interestingly the begin and start fields do not coincide on the partition table that is created. The installation blows up when the 20 gigabyte filesystem is built.
Any thoughts or suggestions would be much appreciated. I noticed that in the 112 patch set that an option was added to force the DPT boards into extended address translation mode. I guess one of the next steps is to try one of the development kernels to see if we are fighting a filesystem or driver problem in 2.0.35.
A wish for a pleasant weekend to everyone.
Greg
As always, Dr. G.W. Wettstein Enjellic Systems Development - Specialists in 4206 N. 19th Ave. intranet based enterprise information solutions. Fargo, ND 58102 WWW: http://www.enjellic.com Phone: 701-281-1686 EMAIL: greg@wind.enjellic.com ------------------------------------------------------------------------------ "... Doc (interviews) is closest in look&feel to a Windows word-processor. It's even slow. Very slow. Hard to set up fonts and printing in the version I have...." -- David Johnson
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
| |