[250] in linux-scsi channel archive
Re: Pentium/Neptune, NCR 53C810, Fujitsu M2915S-512 Slackware 2.3
daemon@ATHENA.MIT.EDU (Drew Eckhardt)
Thu Jun 15 20:24:11 1995
To: Jeremy Anderson <jsa@TranSend.com.tw>
cc: linux-scsi@vger.rutgers.edu
In-reply-to: Your message of "Thu, 15 Jun 1995 16:13:46 +0800."
<Pine.SUN.3.91.950615120118.18547A-100000@transend.com.tw>
Date: Thu, 15 Jun 1995 17:49:19 -0600
From: Drew Eckhardt <drew@poohsticks.org>
In message <Pine.SUN.3.91.950615120118.18547A-100000@transend.com.tw>, jsa@tran
send.com.tw writes:
>Problem report:
>
>(This is not a bug report. I believe the Slackware code is OK. I need
>to know what I'm doing wrong, or if what I am doing is doable):
>
>Hardware:
>
>GigaByte GA-586ID dual Pentium mainboard
>Generic NCR53C810 SCSI/PCI card.
>Fujitsu M2915S-512 SCSI HDD
>
>Software:
>Slackware 2.1/2.3 (will explain)
>
>Problem on installation:
>
>Boot from Slackware 2.3 stock SCSI 1.44 boot disk:
>
>Result:
>
>SCSI: 0 devices detected
No idea what's going on there; like the SCSI-HOWTO says, you
should include the kernel revision when you're having a problem since
there's no way for the developers to keep track of what Slackware
revision X.Y corresponds to.
>Boot from Slackware 2.1 stock SCSI 1.44 boot disk:
>
>Result:
>...
>scsi-ncr53c7,8xx : at PCI bus 0, device 3, function 0
>scsi-ncr53c7,8xx : warning : revision of 2 is greater than 1.
>scsi-ncr53c7,8xx : NCR53c810 at memory 0xf1000000, io 0x6000, irq 10
>scsi0 : using io mapped access
>scsi0 : using initiator ID 7
>scsi0 : using level active interrupts
>scsi0 : burst length 8
>scsi0 : using 40MHz SCSI clock
>scsi0 : NCR code relocated to 0x2302f0
>scsi0 : test 1 started
>scsi0 : NCR53c{7,8}xx (rel 4)
>scsi : 1 host.
> Vendor: FUJITSU Model: M2915S-512 Rev: 0127
> Type: Direct-Access ANSI SCSI revision: 02
>Detected scsi disk sda at scsi0, id 0, lun 0
>scsi : detected 1 SCSI disk total.
>SCSI Hardware sector size is 512 bytes on device sda
>...
>
>OK. So far, so good. However, when I enter fdisk to a partition setup,
>fdisk reports that /dev/sda has 1023 cylinders, 67 heads, and 62
>sectors. (the Fujitsu has 3012 cylinders, 15 heads, and 89 sectors). The
>system will install and boot as long as I set up the disk as One Giant
>Partition, and add a LILO boot option of:
>
>hd=3012,15,89
Note that hd=x,x,x will force detection of an IDE hard drive; probably
not what you want. Also, whatever the physical parameters are are
irelevant - we're interested in a BIOS compatable mapping. If you
partition the drive with the ones provided by the NCR driver, you will
be able to make one big honkin partition that spans up to 8G and still
be able to run LILO on it.
>Any other combinations I've tried result in failure. (And this one
>doesn't work very well).
You should qualify "Doesn't work very well".
>Has anyone had experience with this or a similar problem? I frankly
>suspect the problem is with the mainboard (a very new and exotic device),
>but have no way to verify this. Is there a solution? I have source,
>and am willing to try a custom-built kernel if it will help solve the
>problem.
The NCR BIOS conforms with Annex-A of the SCSI-CAM specification with
respect to the H/C/S mapping used. Specifically
If there appears to be a valid partition table, we can guess that
the disk was partitioned with a number of sectors equal to the ending
sector of any partition, number of heads equal to ending head of a
partition, and number of cylinders = total sectors divided by the product
of the two.
If the partition table looks right, we do one final sanity check.
physical_end = end_cyl * (end_head + 1) * end_sector +
end_head * end_sector + end_sector;
/* This is the actual _sector_ number at the end */
logical_end = largest->start_sect + largest->nr_sects;
if (logical_end == physical_end) {
*secs = end_sector;
*hds = end_head + 1;
*cyls = capacity / ((end_head + 1) * end_sector);
return 0;
}
Some people have old drives which were partiioned on a 1542 or
something, so we should probably disable this additional sanity
check which will allways fail in that case, since we'll get cylinders
wrapping at the 10 bit boundary in the H/C/S partition table fields.
If you have a drive that would have over 1024 cylinders using whatever
head / sector mapping was used, the code decides that it's invalid
and falls back to the next method which tries to find an OK fit for
any drive up to 8G.
See what's returned by the dparam program under DOS. If it doesn't
match what the NCR driver says, make the body of the if statement
unconditional and you should be happy.
If it does agree, use what the NCR driver says. It will let you
access the whole drive, and boot kernels with LILO even if you've
made one big honkin 8G partition on it...
