Help with SBP-2 Drive access.

[Bryan Kilian]

I'm having a small problem with a program I'm writing. I access a SBP-2
drive over 1394 using the PhysicalDriveX device. However, I have a problem
getting the disk size (accurately, that is) I can get a DISK_GEOMETRY fairly
easily, but the numbers returned are not actually the actual number of
sectors on the disk, only an approximation.
ATA_IDENTIFY on an IDE disk returns the right numbers I'm looking for, but
there seems to be no way to extract that kind of info from the SBP-2 disk.

Te disk has no filesystem on it, it's just a raw disk.

does anyone have any info on using SCSI_PASSTHROUGH on SBP-2 and how I would
use it to get the info I need? links and/or demo source would be greatly
appreciated. I'm at my wits end already.

Thanks
Bryan Kilian

[David J. Craig]

SPTI is fairly easy, but requires admin rights. I have a question as to why
you think you need the ATA_IDENTIFY info and not the DISK_GEOMETRY that the
disk driver already provides. The variation should be fairly small and
should not exceed 63 * 255 sectors. Create a debug version of DISK.SYS and
CLASSPNP.SYS and run Winbag (for other lurkers it is NOT windbag, but Winbag
a.k.a. windbg). The old version were a bag of something, but the recent
version finally seem to have M$'s support and interest. Maybe all of the M$
complaining about the quality of drivers being written got them to realize
that they were the greatest contributors to bad drivers.

"Bryan Kilian" <br...@wuzzle.org> wrote in message
news:xbTO8.4$gN6....@news03.micron.net...

[Bryan Kilian]

This is for a company that uses the entire drive in an embedded device, so
they want to be able to get the same numbers from it in windows that they
get from their ATA_IDENTIFY in their embedded device.

DISK_GEOMETRY is close, but wrong. It has two problems:
a) for disks smaller than 130GB, it returns a number that's somewhat off,
and
b) for disks larger than 130GB, it returns a number that's significantly
off.

For instance:

60GB disk:
DISK_GEOMETRY:
total number of sectors = 0x07289C34
Actual:
total number of sectors = 0x0728A120

160GB Disk:
DISK_GEOMETRY:
total number of sectors = 0x0FFFEB04
Actual:
total number of sectors (in ATA 5) = 0x0FFFFFFF
total number of sectors (in ATA 6) = 0x13157400

Is there any information anywhere on how to communicate with SBP-2 disks?
There really is _nothing_ in the DDK and on the web.

Bryan

"David J. Craig" <Da...@yoshimuni.com> wrote in message
news:DY5P8.2231$E4.7...@twister.tampabay.rr.com...

[David J. Craig]

It looks like:

60GB: 1260 sectors is the difference. 255 * 63 is 16065 which the size of
one cylinder. Most BIOSes don't use 256 as the number of heads, I think.
Therefore the actual is reduced to the disk geometry because all partitions
must end on a cylinder boundary. Track boundary partitions don't seem to be
used since MS-DOS 2.x. Both numbers are evenly divisible by 63, but the
actual produces a remainder when divided again by 63 and then 255.

160GB: This indicates that the OS you are using doesn't support ATA 6, but
ATA 5 since it is rounded down from the ATA 5 value. You are going to need
a new disk driver to handle this drive properly.

Does your embedded device use partitions and FAT(32)? If so, you must
change the embedded logic to follow where M$ leads. You could write your
own disk driver, and possibly replace DISK.SYS and CLASSPNP.SYS, but it will
be a hard change implement in the field. You could just use SPTI and access
the drive directly if it is a data store not in FAT format. The disk driver
may need changing in that case. Make sure you have the latest drivers for
your chipset on the system you are using.

"Bryan Kilian" <br...@wuzzle.org> wrote in message

news:mL6P8.1$ba7....@news03.micron.net...

[Maxim S. Shatskih]

> may need changing in that case. Make sure you have the latest
>drivers for
> your chipset on the system you are using.

"Chipset's drivers" are usually limited to a collection of INFs and
the driver for AGP GART.
No other binaries.

Anyway the fact w2k sees the disk as being lesser-sized, thus losing
some space, does not speak good on w2k's ATA stack. NT4 is free from
this. On dual-boot machine, NT4's WINDISK sees the drive as being
larger sized then w2k's MMC tool. Even the BIOS's values for the disk
capacity is larger then w2k sees. I think that PCIIDE.SYS's CHS values
and IDENTIFY data interpretation is to blame.

Here is the picture:
ST39111A (vendor-declared capacity 9111MB)
w2k's disk management shows 8056MB physical disk capacity.
BIOS shows 9115MB
IDENTIFY_DATA::UserAddressableSectors = 17803297 (8693MB)

Where did 640MB get lost - I cannot understand. Funny thing is that
installing Intel ATA drivers leads to this "lost space" appearing
back.

Another nasty thing in w2k's ATA stack. The BIOS setting for drive's
DMA mode is relevant for w2k. Yes, the CHS values are not relevant,
but the DMA mode - is, if DMA for a disk is disabled in BIOS (or disk
not registered there at all) - then w2k's ATA stack will not be able
of running DMA on it.
It was not so with NT4SPx, ATAPI.SYS in this OS worked fine with DMA
support with a drive not registered in BIOS at all.

I cannot understand from where PCIIDE.SYS can take the BIOS setting to
refuse the DMA. I don't think it parses the BIOS data area at 0x400
physical, only long-ago-obsolete ATDISK did so. So, IDENTIFY data
seems to be the only place. Maybe the BIOS calls some SET DRIVE
PARAMETERS command for a drive, and PCIIDE later relies on these
parameters.

Max

[Karan Mehra [MS]]

"Maxim S. Shatskih" <ma...@storagecraft.com> wrote in message news:aekviv$1d3t$1...@gavrilo.mtu.ru...

|
| Another nasty thing in w2k's ATA stack. The BIOS setting for drive's
| DMA mode is relevant for w2k. Yes, the CHS values are not relevant,
| but the DMA mode - is, if DMA for a disk is disabled in BIOS (or disk
| not registered there at all) - then w2k's ATA stack will not be able
| of running DMA on it.
| It was not so with NT4SPx, ATAPI.SYS in this OS worked fine with DMA
| support with a drive not registered in BIOS at all.
|
| I cannot understand from where PCIIDE.SYS can take the BIOS setting to
| refuse the DMA. I don't think it parses the BIOS data area at 0x400
| physical, only long-ago-obsolete ATDISK did so. So, IDENTIFY data
| seems to be the only place. Maybe the BIOS calls some SET DRIVE
| PARAMETERS command for a drive, and PCIIDE later relies on these
| parameters.
|

I believe this information is obtained from ACPI which in turn gets it from the BIOS

--
karan

--
This posting is provided "AS IS" with no warranties, and confers no rights

[Maxim S. Shatskih]

>I believe this information is obtained from ACPI which in turn gets
it from the BIOS

Really? ACPI has the knowledge on IDE drive DMA settings?
A new fact for me, thanks!

Max