[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: partitioning >2TB?
Okay, I have more information.
First, the crash. I booted with the raidframe disks in place (so raid0
exists this time). Then:
# dkctl raid0 addwedge dumps 128 1565607168 4.2BSD
This says it works, and it appears to; dkctl raid0 listwedges shows
/dev/rraid0d: 1 wedge:
dk0: dumps, 1565607168 blocks at 128, type: 4.2BSD
I have a program probepartsize, which figures out a partition's size by
doing binary search, reading single blocks at assorted offsets to see
which ones work. When I sic that on my manually-created /dev/rdk0a
(character special 168 0, this based on /usr/src/sys/conf/majors), I
get an instant panic. Here's a ten-finger copy:
uvm_fault(0xcc59c384, 0, 1) -> 0xe
kernel: supervisor trap page fault, code = 0
Stopped in pid 2495.1 (probepartsize) at netbsd:dkread+0x39: movl 0x4(%eax),
A ddb stack trace shows dkread+0x39, spec_read+0x214, VOP_READ+0x31,
vn_read+0xae, dofileread+0xc6, sys_read+0x7f, syscall_plain+0x149.
Looking at the source to dkread() and comparing it to disassembly, it
appears dkwedge_lookup returned a real pointer, but one of the
pointer-follows involved in sc->sc_parent->dk_driver->d_minphys failed.
I have a kernel coredump in case there's something useful that can be
done with it.
Comparing dkopen and dkread between 4.0 and current, I don't see
anything that would explain this working in current but not 4.0.
Second, the problem with gpt(8). THe message is being misleading.
ktrace reveals that it's opening /dev/rraid0d just fine; what's failing
is opening /dev/drvctl, and the problem here is that the message
printed (incorrectly) implies that it's rraid0d that it couldn't open.
(There's also the question of _why_ it couldn't open /dev/drvctl, but
that's a separate problem; vide infra.)
/dev/drvctl is character special 167 0, which looks correct based on
/usr/src/etc/MAKEDEV.tmpl and /usr/src/sys/conf/majors - so, while
/dev/ may be a 3.x remnant, and while drvctl looks like what
/dev/MAKEDEV would create, it appears to match the 4.0 kernel in use.
For the moment, I'm just using newfs -I -F on /dev/rraid0d with a -s
value obtained from raidframe, avoiding the gpt and wedge issues.
In passing, every first-open on raid0, I get a kernel message
raid0: WARNING: raid0: total sector size in disklabel (1565607296) != the size
of raid (1565607296)
which looks totally bizarre, complaining that two obviously equal
numbers are unequal.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Main Index |
Thread Index |