You will need the "plus1tb" support which was integrated into Nevada
build 99. The S10 backport is in progress, likely part of S10U8.
Grant
On 12/23/08 14:02, Michael McKnight wrote:
> Hello everyone,
>
> The following is a copy of a plea for help I have posted in other
> Solaris-centric forums. Answers have been elusive and it was recommended
> that I come here since most Solaris changes originate or are fixed with
> OpenSolaris first. Please read the following, understand that it is with
> Solaris 10, not OpenSolaris, and if possible, please provide any input you
> think may help...
>
> I am trying to upgrade my system with the Seagate 1.5TB drives (model
> ST31500341AS firmware SD1A). Windows XP seems to work fine with these
> drives, but Solaris doesn't like them at all.
>
> I have tried using them on both of the following versions of Solaris:
> Solaris 10 8/07 s10x_u4wos_12b X86 -- 64bit
> Solaris 10 10/08 s10x_u6wos_07b X86 -- 32bit
>
> Both systems show the same kinds of problems...
>
> I tried to replace an older (smaller) drive with the new one, when I tried
> this, I got the following message (zpool replace c3d0):
> "cannot replace c3d0 with c3d0: new device must be a single disk"
>
> The 1.5TB drive is a single disk -- I have no idea what this message
> means. That prompted me to look at the partition info. It showed something
> very odd...
> * First Sector Last
> * Partition Tag Flags Sector Count Sector Mount Directory
> 0 4 00 34 18446744072344831711 18446744072344831966
> 8 11 00 18446744072344831967 16384 18446744072344848350
>
> You'll notice that the sector ranges are way too high. I tried to manually
> correct these, but I could only get it to work if I made partitions that were
> less that 1TB in size using the VTOC labels. I know VTOC has a 1TB limit,
> but I am unable to get EFI labels written...
>
> #zpool create testpool c3d0
> cannot create 'testpool': invalid argument for this pool operation
>
> #fdisk -v -E /dev/rdsk/c3d0
> /dev/rdsk/c3d0p0: Cannot get virtual disk geometry.
>
> The use of the format utility and then selecting the fdisk menu item simply
> returns:
> "This disk must use an EFI label."
>
> The failures occur if I specify c3d0 or c3d0p0.
>
> When performing operations on these drives, syslog fills up with the
> following messages. You will notice that the block numbers are negative;
> which seems to indicate an overflow of some sort:
>
> Sense Key: ID not found
> Vendor 'Gen-ATA ' error code: 0x5
> WARNING: /p...@0,0/pci-...@f/i...@0/c...@0,0 (Disk4):
> Error for command 'read sector' Error Level: Fatal
> Requested Block -1364718641, Error Block: -1364718641
>
> These repeated over and over. My guess is that it's failing on block
> lookups because it doesn't have a good definition of the geometry of the
> drive. I could be way off since I don't have a lot of knowledge in that
> area.
>
> With a brand new drive, the format command segfaults. Only after fdisk'ing
> the drive in WinXP, was I able to address it with Solaris.
>
> After fdisk'ing in WinXP, the Solaris format utility seems to recognize the
> drive and is reported as:
> c3d0 <ST315003- 9VS0AA4-0001-16777215.>
> /p...@0,0/pci-...@f/i...@0/c...@0,0
>
> The System BIOS reports the correct model number and size.
>
> I have tried several of these drives, on two separate systems and get
> the same behavior. This makes me think it's a Solaris problem since
> WinXP and the BIOS seem to work fine with them.
>
> It looks like zpool, format, fdisk, etc are all trying to work but they
> end up with a number of sectors (18446744072344848350) that is
> unfathomable and crash when they don't know what to do with it.
>
> I trussed the fdisk program and noticed the following at the end of the
> output. Notice the ioctl call and the ENOTSUP failure...
>
> 1390: xstat(2, "/dev/rdsk/c3d0", 0x08047BF8) = 0
> 1390: d=0x04600000 i=53477906 m=0020640 l=1 u=0 g=3
> rdev=0x01980107
> 1390: at = Dec 21 17:56:12 EST 2008 [ 1229900172 ]
> 1390: mt = Dec 21 17:56:12 EST 2008 [ 1229900172 ]
> 1390: ct = Dec 21 17:56:12 EST 2008 [ 1229900172 ]
> 1390: bsz=8192 blks=0 fs=devfs
> 1390: open("/dev/rdsk/c3d0", O_RDWR|O_CREAT, 0666) = 3
> 1390: ioctl(3, 0x0421, 0x0806B768) Err#48 ENOTSUP
>
> The question is, why does it think there are 18446744072344848350
> sectors on the drive? What is the ioctl call that fails trying to do
> and could it be failing for the same reason?
>
> I have tried everything I can come up with to force an EFI label onto these
> drives, but nothing works (format, fdisk, zpool). I have attached the core
> file from the format command, and the truss output from both fdisk and zpool.
> If you need more data, please let me know.
>
> If there is any help you can offer, it would be greatly appreciated.
>
> Thank you,
> -Michael
>
_______________________________________________
storage-discuss mailing list
storage-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
