NetBSD-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Disks w/non-512-byte sectors?
First, can anyone point me to message threads about how modern 4K-sector
disks are to be handled? I must admit some confusion when reading about
4K native sectors, but having to deal with a 512-byte emulation mode.
At what point does the emulation get out of the way and allow one to address
the native 4K sectors?
Second, and the real point of this message: Some time ago I was given
several 18GB 10k-rpm SCA SCSI disks that had been removed from an IBM
AS400. I knew they had strange native sector sizes (522 bytes in the
case of the drives I have). When I hooked one up to one of my NetBSD
boxes, it was probed and reported reasonable data except for the message
"preposterous sector size 0x20a bytes". The test machine netboots and
otherwise operates via NFS--the disk is just connected for testing.
It is running a recent build of i386-7.99.4.
I'd read that one can reformat such disks to 512 byte sectors. The BIOS
utility in my Advansys 9xx card was not up to the task. It simply ran
the format with the exact same parameters the disk reported, so it still
had 522-byte sectors.
Looking at 'scsictl', I took a chance on its format directive and it seems
to have sucessfully reformatted the drive to 512-byte sectors. At the
same time, I installed "sysutils/sformat" from pkgsrc since 'scsictl' didn't
offer any kind of verification, although one could do simple testing
with 'dd' and use the "reassign" subcomand of 'scsictl' to deal with
bad blocks.
I discovered that I could reformat the disk with 1K sectors, although
the total capacity drops noticably with that sector size.
With the disk set to 1K sectors, on the next reboot (netboot/NFS root),
following the load of the kernel, the scsi disk's activity light went
on and the machine sat for about 10 minutes before finally loading modules
and proceeding with booting. It would do this on every reboot while
the disk was formatted with 1K sectors.
It also did that while the disk was formatted with its original 522-byte
sectors. Once re-formatted with 512-byte sectors, there was no delay and
booting proceeded directly. I wonder what causes the delay when the disk
has non-512-byte sectors--even if it has a power-of-two sector size?
I've been unable to complete a "-wrveri" (write verification) with
'sformat'. At some point, the kernel crashes with (10-finger screen
grab):
sd0(adv1:0:0:0): timed out
adv1: exiting ccb not allocated!
fatal breakpoint trap in supervisor mode
trap type 1 code 0 eip c02a4074 cs 8 eflags 200292 cr2 bbbae8c4 ilevel 6 esp dad22ee8
curlwp 0xc35652a0 pid 0 lid 6 lowest kstack 0xdaf062c0
Stopped in pid 0.6 (system) at netbsd:breakpoint+0x4: popl %ebp
db{0}> bt
breakpoint() at netbsd:breakpoint+0x4
AscIsrQDone() at netbsd:AscIsrQDone+0x27a
AscISR() at netbsd:AscISR+0x2ee
adv_intr() at netbsd:adv_intr+0x11
intr_biglock_wrapper() at netbsd:intr_biglock_wrapper+0x1f
--- switch to interrupt stack ---
Xintr_ioapic_level7() at netbsd:Xintr_ioapic_level7+0xb5
--- interrupt ---
vcons_update_screen() at netbsd:vcons_update_screen+0x10c
vcons_softintr() at netbsd:vcons_softintr+0x88
softint_dispatch() at netbsd:softint_dispatch+0xc1
Bad frame pointer: 0xdaf05f58
db{0}>
Once I was present during one of these events and the disk spun itself
down and then immediately spun itself up again. It is not clear if
the disk's behavior cause the crash or the crash cause the disk behavior.
Up to this point, the drive had gone through 10 write-verify passes
without errors.
(Later, while reading the disk, I interrupted the reading application
(hexdump) and the drive behaved as described above, but there was no
crash and a subsequent operation (writing 1MB of 00 bytes with 'dd')
succeeded.)
I just now tried the 'sformat -wrveri -noformat dev=/dev/rsd0d' again
with a serial console and it crashed with:
[...]
Do you want to force write/verify? y
Capacity: 35843670 Blocks = 17921835 kBytes = 17501 MBytes = 18351 prMB
Sectorsize: 512 Bytes
Verify pass 0 Test Pattern: C6DEC6DE
0sformat: Cannot set geometry to driver (cannot map disk name).
sformat: Notice: Too many defects for SUN defect list format.
sformat: Notice: This is not a problem with SCSI disks.
3420480
sd0(adv1:0:0:0): timed out
panic: kernel diagnostic assertion "(c->c_flags & CALLOUT_PENDING) == 0" failed: file "/x/current/src/sys/kern/kern_timeout.c", line 314 callout 0xc3a96ecc: c_func (0xc012d018) c_flags (0x3) destroyed from 0xc08f0190
cpu0: Begin traceback...
vpanic(c0e29d0c,dc728b4c,dc728b70,c06a8760,c0e29d0c,c0db2021,c0e29ce8,c0e29c2c,13a,c3a96ecc) at netbsd:vpanic+0x121
kern_assert(c0e29d0c,c0db2021,c0e29ce8,c0e29c2c,13a,c3a96ecc,c012d018,3,c08f0190,c3a96ebc) at netbsd:kern_assert+0x23
callout_destroy(c3a96ecc,51a85bf8,c3a96ebc,0,c3a76a74,dc728bc8,c08f1d9e,c3a96ebc,0,c0e5b652) at netbsd:callout_destroy+0xf0
scsipi_put_xs(c3a96ebc,0,c0e5b652,0,c3a96ebc,0,0,0,c3c62e8c,c3a76a74) at netbsd:scsipi_put_xs+0x36
scsipi_execute_xs(c3a96ebc,c42e9f34,a,dad3a000,f000,0,4e20,c42e9e54,a010,a000000) at netbsd:scsipi_execute_xs+0x118
scsistrategy(c42e9e54,f000,f000,1,c3523400,c40b38b4,0,0,0,0) at netbsd:scsistrategy+0xf3
physio(c08f2340,c42e9e54,d03,0,0,c012cea0,c42e9f08,dc728eb0,dc728eb0,c42e9f2c) at netbsd:physio+0x27a
scsipi_do_ioctl(c3c62e8c,d03,0,c0605101,dc728eb0,3,c3df1d20,3,0,0) at netbsd:scsipi_do_ioctl+0x19a
sdioctl(d03,0,c0605101,dc728eb0,3,c3df1d20,c3df1d20,c0605101,c0d86300,3) at netbsd:sdioctl+0x7a4
cdev_ioctl(d03,0,c0605101,dc728eb0,3,c3df1d20,d03,c3f10f30,c3dcd2c0,c3f10f30) at netbsd:cdev_ioctl+0xbe
spec_ioctl(dc728da0,1,c3df1d20,c0da1650,c3f10f30,c0605101,dc728eb0,3,c44fb480,c0605101) at netbsd:spec_ioctl+0x91
VOP_IOCTL(c3f10f30,c0605101,dc728eb0,3,c44fb480,20002,c46538f8,dc728e0c,c0aaeec1,c46538f8) at netbsd:VOP_IOCTL+0x5c
vn_ioctl(c3dcd2c0,c0605101,dc728eb0,dc728e94,c03d5fbb,dc728ea0,c10e1f50,dc728ea4,60,0) at netbsd:vn_ioctl+0x93
sys_ioctl(c3df1d20,dc728f68,dc728f60,7ecf2000,c1005880,c105cde8,dc728f68,0,0,3) at netbsd:sys_ioctl+0x198
syscall() at netbsd:syscall+0x83
--- syscall (number 54) ---
bbb37237:
cpu0: End traceback...
rebooting...
Hints, thoughts?
--
|/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X
|\ / jdbaker[snail]mylinuxisp[flyspeck]com OpenBSD FreeBSD
| X No HTML/proprietary data in email. BSD just sits there and works!
|/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Home |
Main Index |
Thread Index |
Old Index