On Thu, Feb 03, 2011 at 02:56:35AM +, David Holland wrote:
> On Mon, Jan 31, 2011 at 05:40:20PM +0100, Matthias Drochner wrote:
> > > PR 44496 notes that COMPAT_386BSD_MBRPART is still enabled in
> > > disklabel(8), even though it was turned off by default in the kernel
> > > early in 4.99.x
On Thu, Feb 03, 2011 at 02:56:35AM +, David Holland wrote:
>
> ...also, it's not entirely clear to me what the code is supposed to be
> doing if there are multiple NetBSD partitions; it looks as if what it
> *will* do is use the label from the one it sees last and write the
> same label to all
On Mon, Jan 31, 2011 at 05:40:20PM +0100, Matthias Drochner wrote:
> > PR 44496 notes that COMPAT_386BSD_MBRPART is still enabled in
> > disklabel(8), even though it was turned off by default in the kernel
> > early in 4.99.x. The PR also notes that it's not harmless to leave it
> > on.
>
>
On Wed, Feb 02, 2011 at 11:29:47AM +0100, Stephan wrote:
> It seems that if one waits a while after writing some data the read
> speed isn?t that bad. I do a
>
> find / -exec cat {} \; > /dev/null &
>
> and monitor the read speed with "sysstat vm". It is around 60 - 70
> MB/s. This strengthens th
It seems that if one waits a while after writing some data the read
speed isn´t that bad. I do a
find / -exec cat {} \; > /dev/null &
and monitor the read speed with "sysstat vm". It is around 60 - 70
MB/s. This strengthens the suspicion that write caching isn´t working.
Hi all,
some new findings: I´ve added some debug statements to the driver
while only vaguely knowing what I am doing...
mpt0 at pci2 dev 5 function 0: vendor 0x1000 product 0x0030
mpt0: interrupting at ioapic1 pin 1
mpt0: DEBUG: Reading MPI_CONFIG_PAGETYPE_RAID_VOLUME 0 Header
mpt0: DEBUG: Secuss
