-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello Everyone,
The branches supported by the FreeBSD Security Officer have been
updated to reflect recent EoL (end-of-life) events. The new list is
below and at http://security.freebsd.org/ >. FreeBSD 5.3 and
FreeBSD 5.4 have `expired' and are no l
BETA3 for the FreeBSD 6.2 release is now available on most of the FTP
mirror sites. There have been a lot of fixes to many things since
BETA2. The most important of the things that have been worked on is the
driver for em(4). We are hoping people who had been reporting problems
with em(4) can t
On Tue, Oct 31, 2006 at 07:20:41PM -0700, Scott Long wrote:
> Pyun YongHyeon wrote:
> >On Tue, Oct 31, 2006 at 03:28:37PM +0200, Conrad Burger wrote:
> > > On 31/10/06, Conrad Burger <[EMAIL PROTECTED]> wrote:
> > > >On 31/10/06, Scott Long <[EMAIL PROTECTED]> wrote:
> > > >> Pyun YongHyeon wr
Pyun YongHyeon wrote:
On Tue, Oct 31, 2006 at 03:28:37PM +0200, Conrad Burger wrote:
> On 31/10/06, Conrad Burger <[EMAIL PROTECTED]> wrote:
> >On 31/10/06, Scott Long <[EMAIL PROTECTED]> wrote:
> >> Pyun YongHyeon wrote:
> >> > On Mon, Oct 30, 2006 at 08:06:28PM -0700, Scott Long wrote:
> >
On Tue, Oct 31, 2006 at 03:28:37PM +0200, Conrad Burger wrote:
> On 31/10/06, Conrad Burger <[EMAIL PROTECTED]> wrote:
> >On 31/10/06, Scott Long <[EMAIL PROTECTED]> wrote:
> >> Pyun YongHyeon wrote:
> >> > On Mon, Oct 30, 2006 at 08:06:28PM -0700, Scott Long wrote:
> >> > > Pyun YongHyeon wr
On 2006-10-31, Robert Blayzor wrote:
> Greg Black wrote:
> > Fair enough. In my defence, I'm fully committed at present and
> > I have only one amd64 machine which I need for my real work. I
> > can't afford to run it in amd64 mode, because so much of what I
> > need is currently broken in a 64-b
Greg Black wrote:
> Fair enough. In my defence, I'm fully committed at present and
> I have only one amd64 machine which I need for my real work. I
> can't afford to run it in amd64 mode, because so much of what I
> need is currently broken in a 64-bit world. That much of that
> broken software
On 10/31/06, Joerg Pernfuss <[EMAIL PROTECTED]> wrote:
On Tue, 31 Oct 2006 16:46:10 -0800
"Jack Vogel" <[EMAIL PROTECTED]> wrote:
> So like :
>
> options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time
> extensions
>
> Looks like a special option that most probably dont have [...]
On Tue, 31 Oct 2006 16:46:10 -0800
"Jack Vogel" <[EMAIL PROTECTED]> wrote:
> So like :
>
> options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time
> extensions
>
> Looks like a special option that most probably dont have [...]
This option is in GENERIC, so it is something most pe
On 10/31/06, Jack Vogel <[EMAIL PROTECTED]> wrote:
On 10/31/06, Mikhail Teterin <[EMAIL PROTECTED]> wrote:
> Actually, it stalls even with polling disabled. It just takes A LOT longer, as
> I just found out.
>
> Instead of minutes, it takes hours of heavey traffict to stall, but it still
> happen
On 10/31/06, Mikhail Teterin <[EMAIL PROTECTED]> wrote:
Actually, it stalls even with polling disabled. It just takes A LOT longer, as
I just found out.
Instead of minutes, it takes hours of heavey traffict to stall, but it still
happens. Pressing a key still wakes it up...
-mi
This
Actually, it stalls even with polling disabled. It just takes A LOT longer, as
I just found out.
Instead of minutes, it takes hours of heavey traffict to stall, but it still
happens. Pressing a key still wakes it up...
-mi
___
freebsd-stable@f
As I said in private email, you need the battery in order to restore
performance. Linux and Windows get by because they can send larger
I/O's to the controller than FreeBSD can. The larger I/O's aren't
terribly useful for most real-world applications, though.
Scott
Fredrik Widlund wrote:
256
On Wed, Nov 01, 2006 at 12:34:22AM +0100, Fredrik Widlund wrote..
> Yes, it forces writeback even when the controller has no BBU. Choosing
> WBack itself will default back to WThru. It's dangerous, but I guess it
> should be much less dangerous than using for example softupdates. We
> have littl
On Sat, 28 Oct 2006 03:44:37 +0200, Jack Vogel <[EMAIL PROTECTED]> wrote:
After a conference call today, it was decided that a merge of
my Intel driver base and the STABLE code would take place.
This code undoes the INTR_FAST/taskqueue approach for right
now. Work will continue to get that to w
On Mon, Oct 23, 2006 at 07:01:38PM -0400, Mike Jakubik wrote:
> Greetings,
>
>I am in the process of implementing a fairly large mysql server for
> an even larger company, and naturally i want to use FreeBSD. The
> hardware will be an HP DL385, 2 x dual-core Opterons, 16GB RAM, 7 x 15k
> r
On 2006-10-31, Mark Linimon wrote:
> On Wed, Nov 01, 2006 at 06:52:27AM +1000, Greg Black wrote:
> > I found that a very large number of ports that mattered to me were marked
> > i386 only.
>
> In some cases these designations are obsolete. They will require people-
> power to work through them a
Yes, it forces writeback even when the controller has no BBU. Choosing
WBack itself will default back to WThru. It's dangerous, but I guess it
should be much less dangerous than using for example softupdates. We
have little choice until our order of BBUs get here, since the
performance degradat
On 10/31/06, Kris Kennaway <[EMAIL PROTECTED]> wrote:
On Tue, Oct 31, 2006 at 04:34:59PM +0200, Vlad Galu wrote:
>Yes, but for objective reasons I can't publish it :(
> The only
> debugging option that I didn't use was INVARIANTS.
Which is coincidentally the most useful one ;-)
Also turn o
Fredrik Widlund wrote:
> Solved my issue with LSI 8480E without BBU. With "write: BadBBU",
> "cache: enabled", and "io: cached", performance rose to around 200MB/s
> from 20MB/s.
I don't know what "BadBBU" is, but from some Googling it seems to be a
setting that overrides BBU detection, and enable
On Wed, Nov 01, 2006 at 06:52:27AM +1000, Greg Black wrote:
> I found that a very large number of ports that mattered to me were marked
> i386 only.
In some cases these designations are obsolete. They will require people-
power to work through them and see if they are overused.
In particular, ma
On 2006-10-31, Bill Moran wrote:
> In response to Greg Black <[EMAIL PROTECTED]>:
> > On 2006-10-31, Robert Blayzor wrote:
> >
> > > Is there a way to upgrade/move an already installed i386 installed 6.1
> > > machine to amd64 without completely reinstalling? Is there a procedure
> > > to do so?
On Tue, Oct 31, 2006 at 03:31:34PM -0500, Bill Moran wrote:
> In response to Greg Black <[EMAIL PROTECTED]>:
> > The state of the software out there is disgracefully far from
> > being ready for 64-bit platforms -- after wasting weeks in a
> > vain attempt to get a workable development environment
In response to Greg Black <[EMAIL PROTECTED]>:
> On 2006-10-31, Robert Blayzor wrote:
>
> > Is there a way to upgrade/move an already installed i386 installed 6.1
> > machine to amd64 without completely reinstalling? Is there a procedure
> > to do so?
>
> Having just gone through the migration
On 2006-10-31, Robert Blayzor wrote:
> Is there a way to upgrade/move an already installed i386 installed 6.1
> machine to amd64 without completely reinstalling? Is there a procedure
> to do so?
Having just gone through the migration in the opposite
direction, I would ask why you want to do this
On Tue, Oct 31, 2006 at 04:34:59PM +0200, Vlad Galu wrote:
>Yes, but for objective reasons I can't publish it :(
> The only
> debugging option that I didn't use was INVARIANTS.
Which is coincidentally the most useful one ;-)
Also turn on DEBUG_LOCKS and DEBUG_VFS_LOCKS then report the output
вівторок 31 жовтень 2006 14:14, Jeremy Chadwick написав:
> On Tue, Oct 31, 2006 at 01:57:54PM -0500, Mikhail Teterin wrote:
> > Nothing -- the screen (console) is not updated. If I leave top(1)
> > running, I'll see INSANE amounts of CPU-time (1300% each, for example)
> > getting attributed to the
On Tue, Oct 31, 2006 at 01:57:54PM -0500, Mikhail Teterin wrote:
> Nothing -- the screen (console) is not updated. If I leave top(1) running,
> I'll see INSANE amounts of CPU-time (1300% each, for example) getting
> attributed to the compressing programs -- after that top stops refreshing.
What
вівторок 31 жовтень 2006 13:49, Jack Vogel написав:
> Scott's question still hasnt been answered, or if so I dont understand it.
> If everything was working why were you trying to turn on polling?
Because it was working poorly -- over 50% of the (combined) CPU time was spent
in the kernel ("sys")
On 10/31/06, Mikhail Teterin <[EMAIL PROTECTED]> wrote:
понеділок 30 жовтень 2006 23:23, Mikhail Teterin написав:
> Ok. I rebooted and restarted the heavy traffic dump (DEVICE_POLLING in
> kernel, but without polling actialy enabled). The dump got underway,
> although the amount of "sys" load was
понеділок 30 жовтень 2006 23:23, Mikhail Teterin написав:
> Ok. I rebooted and restarted the heavy traffic dump (DEVICE_POLLING in
> kernel, but without polling actialy enabled). The dump got underway,
> although the amount of "sys" load was rather high -- way above 70%
> most of the time (on a dua
I've had no difficulty with 1950/2950 installs, as long as the disk
controller is the PERC 5/I. I don't know if this holds for Vivek's
experience as well.
However, with the SAS5 controller (LSILogic SAS) AMD64 won't boot without
either:
- ACPI / APIC disabled, killing SMP
- Any BCE interfaces d
On Tue, Oct 31, 2006 at 10:22:43AM -0600, Bruce Burden wrote:
> On Tue, Oct 31, 2006 at 08:41:44AM -0500, Robert Blayzor wrote:
> >
> > Is there a way to upgrade/move an already installed i386 installed 6.1
> > machine to amd64 without completely reinstalling? Is there a procedure
> > to do so?
I
On Oct 27, 2006, at 1:00 PM, Travis Pugh wrote:
Is there something I'm missing with regards to ACPI on the AMD64
platform? I've read here that i386 boots fine on the same hardware.
I have one piece of dell equipment which insists on disabling ACPI
timer and then everything works. Disabli
Solved my issue with LSI 8480E without BBU. With "write: BadBBU",
"cache: enabled", and "io: cached", performance rose to around 200MB/s
from 20MB/s.
With BadBBU/enabled cache/io cached:
[root@ ~/bench]# ./bench /dev/mfid0p1 65536
file /dev/mfid0p1, bs 65536
rate: 228130816 Bps, write: 285 us
rat
In response to Vivek Khera <[EMAIL PROTECTED]>:
>
> On Oct 27, 2006, at 1:00 PM, Travis Pugh wrote:
>
> > Is there something I'm missing with regards to ACPI on the AMD64
> > platform? I've read here that i386 boots fine on the same hardware.
>
> I have one piece of dell equipment which insi
On Saturday, 28 October 2006 at 10:10:26 -0700, Jack Vogel wrote:
> On 10/28/06, Nikolay Pavlov <[EMAIL PROTECTED]> wrote:
> >On Friday, 27 October 2006 at 18:44:37 -0700, Jack Vogel wrote:
> >> After a conference call today, it was decided that a merge of
> >> my Intel driver base and the STABLE c
On Tue, Oct 31, 2006 at 08:41:44AM -0500, Robert Blayzor wrote:
>
> Is there a way to upgrade/move an already installed i386 installed 6.1
> machine to amd64 without completely reinstalling? Is there a procedure
> to do so?
>
There is a way to "upgrade" from i386 to amd64 on an installed
On 10/31/06, Eric Anderson <[EMAIL PROTECTED]> wrote:
On 10/31/06 08:03, Vlad Galu wrote:
> On 10/1/06, Cy Schubert <[EMAIL PROTECTED]> wrote:
>> In message <[EMAIL PROTECTED]>,
>> "Vlad
>> GALU" writes:
>>> On 9/30/06, Martin Blapp <[EMAIL PROTECTED]> wrote:
Hi,
1.) Bad ram ? Hav
On 10/31/06 08:03, Vlad Galu wrote:
On 10/1/06, Cy Schubert <[EMAIL PROTECTED]> wrote:
In message <[EMAIL PROTECTED]>,
"Vlad
GALU" writes:
On 9/30/06, Martin Blapp <[EMAIL PROTECTED]> wrote:
Hi,
1.) Bad ram ? Have you run some memory tester ?
Yes, memtest86 didn't show anything weird.
On 10/1/06, Cy Schubert <[EMAIL PROTECTED]> wrote:
In message <[EMAIL PROTECTED]>,
"Vlad
GALU" writes:
> On 9/30/06, Martin Blapp <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > 1.) Bad ram ? Have you run some memory tester ?
>
>Yes, memtest86 didn't show anything weird.
>
> > 2.) Have you ba
The adapter won't allow me to do so since there's no BBU.
Fredrik
Tom Judge wrote:
> Have you tried setting the write cache policy to write back rather
> than write thru?
>
> Tom
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org
On 31/10/06, Conrad Burger <[EMAIL PROTECTED]> wrote:
On 31/10/06, Scott Long <[EMAIL PROTECTED]> wrote:
> Pyun YongHyeon wrote:
> > On Mon, Oct 30, 2006 at 08:06:28PM -0700, Scott Long wrote:
> > > Pyun YongHyeon wrote:
> > > >On Mon, Oct 30, 2006 at 04:17:00PM +0200, Conrad Burger wrote:
> >
Is there a way to upgrade/move an already installed i386 installed 6.1
machine to amd64 without completely reinstalling? Is there a procedure
to do so?
--
Robert Blayzor, BOFH
INOC, LLC
rblayzor\@(inoc.net|gmail.com)
PGP: 0x66F90BFC @ http://pgp.mit.edu
Key fingerprint = 6296 F715 038B 44C1 2720
256MB cache, no BBU. Tried a lot of different combinations of settings.
fbsd 6.2pre writes 220MB/s with raid-0
If I boot windows server 2003 instead, it writes at around 180MB/s with
raid-5 (same configs).
With fbsd6.2pre, I get the "best" performance with BadBBU/direct
io/disabled cache and 8 d
Fredrik Widlund wrote:
Ivan Voras wrote:
Several:
- are there cache differences between the controllers (amount of
memory, cache policy)?
Default settings on both.
- how does writing directly to the device (bypassing file system)
compare?
Drives are four seagate 7200.10 400GB
On 31/10/06, Scott Long <[EMAIL PROTECTED]> wrote:
Pyun YongHyeon wrote:
> On Mon, Oct 30, 2006 at 08:06:28PM -0700, Scott Long wrote:
> > Pyun YongHyeon wrote:
> > >On Mon, Oct 30, 2006 at 04:17:00PM +0200, Conrad Burger wrote:
> > > > I am trying to get FreeBSD to work on a Dell 1955 blade.
Fredrik Widlund wrote:
Ivan Voras wrote:
Several:
- are there cache differences between the controllers (amount of
memory, cache policy)?
Default settings on both.
Maybe you should check what the defaults are :) Especially the amount of
memory and is there a battery to back the cache.
-
Ivan Voras wrote:
> Several:
>
> - are there cache differences between the controllers (amount of
> memory, cache policy)?
Default settings on both.
> - how does writing directly to the device (bypassing file system)
> compare?
Drives are four seagate 7200.10 400GB in a Raid-5 configuration.
[/mnt
Fredrik Widlund wrote:
setups but hit the same limitation again and again. The strange part is
that a Dell raid adapter based on the same chipset, the Perc 5/I, works
well with writes achieving 200MB/s.
Any ideas would be greatly appreciated.
Several:
- are there cache differences between th
Hi,
We have a problem with the MFI raid-driver under FreeBSD 6.1 and 6.2-PRE.
Hardware: Dell 1850
Raid adapter: LSI 8480E
There is no problem to detect, initialize and configure, but there is a
serious problem with performance with Raid-5. Read performance is good,
but write performance bottlene
51 matches
Mail list logo
