In message <[EMAIL PROTECTED]>, Scott Long writes:
>You're correct that dumping is meant to be done with interrupts and task
>switching disabled. The first thing that the umass driver is missing is
>a working CAM poll handler. Without this, there is no way for command
>completions to be seen when
I built an Asus A8N SLI Deluxe based system and installed
FreeBSD-6.1-BETA1 on it. This works well enough. Now I am
looking for a decent RAID5 solution. This motherboard has
two SATA RAID controllers. But one does only RAID1. The
other supports RAID5 but seems to require s/w assistance from
wi
> Theoretically the sequential write rate should be same or
> higher than the sequential read rate. Given an N+1 disk
Seq write rate for the whole RAID5 array will always be lower
than the write rate for it's single disk.
See 'http://en.wikipedia.org/wiki/RAID#RAID_5'
"
Traditional RAID5
A1
>
> > Theoretically the sequential write rate should be same or
> > higher than the sequential read rate. Given an N+1 disk
>
> Seq write rate for the whole RAID5 array will always be lower
> than the write rate for it's single disk.
You compute max data rates by considering the most optimistic
I heard from Chiharu Shibata <[EMAIL PROTECTED]> about kern/60163.
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/60163
(He knew that this pr was closed, recently)
I cannot believe sos's close reason.
***
Ian Dowse wrote:
>
> The USB stack supports polled operations, so it's actually not to
> hard to make this work. Below is a patch I had in one of my local
> trees that adds a CAM poll handler to the umass driver. I've just
> tested this and it does seem to make kernel dumping work, but I
> guess i
Jacques Fourie wrote:
>
> I have installed 6.0-RELEASE and the behaviour is still the same. If I try
> to pre-load an md_image of 64M with 4G of RAM installed, the kernel panics
> early in the boot cycle. Here is the panic on 6.0-RELEASE:
>
> 131072K of memory above 4GB ignored
This is a kind of
7 matches
Mail list logo
