> I think you should add "device da" or "device ada" option to have some
> disks available.
indeed. confirmed.
randy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "
The trouble is that there's lots of anecdotal evidence, but noone's
really gone digging deep into _their_ example of why it's broken. The
developers who know this stuff don't see anything wrong. That hints to
me it may be something a little more creepy - as an example, the
interplay between netisr/
Thanks.
My request for the person documenting the tunings also runs = the
benchmark to ensure expected behaviour.
The installation, execut= ion and comparison against the benchmarks in
the article is fairly simple.<= br>
Note that some tuning may not be relevant or recommended (i
I have a question. Perhaps soeone can point me to a solution.
I have a server running FreeBSD 7.4-STABLE with one network card running ezjail
My network has two gateways.
The host is running as 10.10.10.10 netmask 255.255.255.0 with gateway 10.10.10.1
The jail must be running 192.168.178.10 netma
> I would like to see better documentation on labeling file systems and
> disks, though. It can be rather confusing between gpart labels,
> glabels, and such.
been making me crazy on some systems. and i have one hpt where i used
labels but the controller is s smart it moves dev nums under me.
On Sun, Dec 18, 2011 at 1:49 PM, Jeremy Chadwick
wrote:
> On Sun, Dec 18, 2011 at 04:43:13PM -0500, Randy Bush wrote:
>> >> # ATA/SCSI peripherals
>> >> device scbus # SCSI bus (required for ATA/SCSI)
>> >> #device ch # SCSI media changers
>> >> #devic
> With the introduction of FreeBSD 9.x, all ATA devices now use a
> translation layer (ATA->CAM), and this is especially so with anything
> SATA. I imagine this needs to be documented (in red, bold, etc.) in the
> official 9.0-RELEASE documentation, because it's probably going to trip
> up others.
On Sun, Dec 18, 2011 at 04:43:13PM -0500, Randy Bush wrote:
> >> # ATA/SCSI peripherals
> >> device scbus # SCSI bus (required for ATA/SCSI)
> >> #devicech # SCSI media changers
> >> #deviceda # Direct Access (disks)
> >> #devi
>> # ATA/SCSI peripherals
>> device scbus # SCSI bus (required for ATA/SCSI)
>> #device ch # SCSI media changers
>> #device da # Direct Access (disks)
>> #device sa # Sequential Access (tape etc)
>
Hi,
What Attilllo and others need are KTR traces in the most stripped down
example of interactive-busting workload you can find.
Eg: if you're doing 32 concurrent buildworlds and trying to test
interactivity - fine, but that's going to result in a lot of KTR
stuff.
If you can reproduce it using a
On 17.12.2011 22:47, Randy Bush wrote:
>
> # ATA/SCSI peripherals
> devicescbus # SCSI bus (required for ATA/SCSI)
> #device ch # SCSI media changers
> #device da # Direct Access (disks)
> #device sa
On 12/18/11 03:37, Bruce Cran wrote:
> On 13/12/2011 09:00, Andrey Chernov wrote:
>> I observe ULE interactivity slowness even on single core machine
>> (Pentium 4) in very visible places, like 'ps ax' output stucks in the
>> middle by ~1 second. When I switch back to SHED_4BSD, all slowness is
>>
On Sun Dec 18 11, Alexander Best wrote:
> On Sun Dec 18 11, Andrey Chernov wrote:
> > On Sun, Dec 18, 2011 at 05:51:47PM +1100, Ian Smith wrote:
> > > On Sun, 18 Dec 2011 02:37:52 +, Bruce Cran wrote:
> > > > On 13/12/2011 09:00, Andrey Chernov wrote:
> > > > > I observe ULE interactivity slo
On Sun Dec 18 11, Andrey Chernov wrote:
> On Sun, Dec 18, 2011 at 05:51:47PM +1100, Ian Smith wrote:
> > On Sun, 18 Dec 2011 02:37:52 +, Bruce Cran wrote:
> > > On 13/12/2011 09:00, Andrey Chernov wrote:
> > > > I observe ULE interactivity slowness even on single core machine
> > (Pentium
>
14 matches
Mail list logo
