Although it sounds silly, could you try recompiling 6.1 and 7.0 with a
non-SMP kernel and see how they perform? That would at least tell us if
it's a general performance problem in 6.x and 7.x, or if SMP is somehow
hurting performance in this case.
Mike "Silby" Silbersack
_
I just merged a change to the busdma implementation which tightens up how
busdma aligns memory and warns when busdma fails to align memory properly.
This allows the bfe driver to work properly on machines of all memory
sizes, but it also caused machines with the mpt driver to trip the same
ch
r fix, just add hw.mem = "1000M" to your
loader.conf and reboot. :)
Mike "Silby" Silbersack
-- Forwarded message --
Date: Fri, 28 Apr 2006 05:39:58 + (UTC)
From: Mike Silbersack <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED], cvs-all@FreeBSD
If you're running a -stable machine and using a dc-supported NIC, I'd
appreciate it greatly if you could try out the new if_dc.c and if_dcreg.h
available from http://www.silby.com/patches/if_dc/
This is a direct MFC of -current's if_dc driver, bringing back PAE
support, some minor fixes, and perh
On Wed, 27 Aug 2003, Mike Silbersack wrote:
> Ah, that's a good idea!
>
> I'll try setting hw.physmem down to 12M or so and see if that causes the
> panics to occur over here.
>
> Mike "Silby" Silbersack
Ok, I booted with hw.physmem="16M", and
On Sat, 23 Aug 2003, Erik Trulsson wrote:
> I have had problems with weird panics on post-PAE RELENG_4 kernels, on
> machines that previously had been rock stable (so hardware problems are
> unlikely.)
>
> Your patch does appear to restore stability for me. (I would have to
> run the systems for
On Tue, 28 Jan 2003, Kipp Holger wrote:
> Hello,
>
> I am experiencing the same Problems as are described in PRs
> 30952, 42597, 43396.
>
> Hardware is HP Vectra VL 400 MT, D9862E.
>
> The problem is sudden trap 12 after some network traffic, eg copying onto a local
>disk via nfs-mount (copying
At the request of Thomas Nystrom, I have now committed his patches to fix
the hanging problems of some rhine chipsets and his fixes to allow 6105
(Rhine III) chips to work properly to -current. Naturally, I'm going to
wait at least a week before MFCing this change to 4-stable. In the
meantime, I
Just so everyone knows, I've MFC'd a bunch of changes to the if_xl driver
in the last few days. Most of these changes will have no functional
effect, and serve merely to synchronize the -current and -stable versions
of the driver. However, if your xl nic suddenly stops working, but it
worked fi
Stop using them.
2. Patch or cvsup and rebuild your kernel.
Mike "Silby" Silbersack
-- Forwarded message --
Date: Tue, 30 Apr 2002 20:27:35 -0700 (PDT)
From: Mike Silbersack <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: cvs commit: src/s
On Wed, 3 Apr 2002, Garance A Drosihn wrote:
> What I don't see is why this must be made to -stable at all.
> What would be the consequences if we simply left RELENG_4
> with the same port-range that it's always had? Note that
> this is not a complaint on my part, it is only a request for
> mor
On Tue, 5 Feb 2002, Mike Silbersack wrote:
> LINT says, and I quote:
>
> #
> # The `maxusers' parameter controls the static sizing of a number of
> # internal system tables by a formula defined in subr_param.c. Setting
> # maxusers to 0 will cause the system to auto
On Tue, 5 Feb 2002, Daniel Lang wrote:
> Hi,
>
> (sorry for posting this to two lists, Reply-To: is set.)
>
> I've just built a new kernel for a just upgraded box to
> 4.5-STABLE. I've included
>
> NMBCLUSTERS=0 and
> NBUF=0
>
> to try the auto-sizing feature as documented in LINT
>
> Any advice
On Fri, 28 Dec 2001, Søren Schmidt wrote:
> I know that change as well, but so far I havn't been able to verify
> that it does what it intends to do, VIA's docs are very vague on this.
>
> There is alot about this on the net, but *lots* of it are just notes
> scribbled together by nerds^H^H^H^H^
On Fri, 28 Dec 2001, Matthew Dillon wrote:
> Ok, I have more information on Nils problem. First of all, Soren's
> patch greatly reduced the rate of corruption. It took 25 loops of
> Nils 'cp' test to generate the corruption.
>
> However, Soren's patch did not fiix the corruptio
; make.
Anyone with a better knowledge of the buildworld process have any ideas?
Mike "Silby" Silbersack
On Thu, 6 Jul 2000, Mike Silbersack wrote:
> The problem seems to stem from a corrupt
> /usr/obj/usr/src/lib/libfetch/fetch_err.h
>
> If I manually delete it and
The problem seems to stem from a corrupt
/usr/obj/usr/src/lib/libfetch/fetch_err.h
If I manually delete it and make from the libfetch directory, it seems
to be created properly.
So, I have two lingering questions:
1. Did the tools used to create the file change? As far as I can tell,
libfetc
17 matches
Mail list logo
