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
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 it
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
