On Wed, 18 Feb 2009, Karl Denninger wrote:
KD I have been able to come up with a procedure that works.
KD
KD 1. Load a new hard disk with the 64-bit code. Perform a buildworld and
KD buildkernel, and installkernel and installworld to this disk to verify that
KD it will install and run. You now
On Sun, 22 Feb 2009, Maxim Sobolev wrote:
Hi Jeff,
I have a single-CPU system with P4 HTT-enabled processor (7.1-RELEASE-p3),
kernel compiled with SCHED_ULE.
This is because machdep.hlt_logical_cpus doesn't do what you think it does.
It causes HTT cores to invoke the hlt instruction in
Hi,
On Fri, Feb 13, 2009 at 08:39:55PM +0900, Pyun YongHyeon wrote:
Ok, try attached patch.
Index: sys/dev/re/if_re.c
===
--- sys/dev/re/if_re.c(revision 187352)
+++ sys/dev/re/if_re.c(working copy)
@@ -158,6
Already dealt with, I was merging a change by hand whilst hungover after
a good party. ;^)
Sorry for the churn.
A lot of this stuff gets utterly demolished and rebuilt in the IGMPv3 snap.
I don't plan to backport the multicast work ongoing in p4 to 7-STABLE
without testers, and air-out in
Robert Watson wrote:
On Sun, 22 Feb 2009, Maxim Sobolev wrote:
Hi Jeff,
I have a single-CPU system with P4 HTT-enabled processor
(7.1-RELEASE-p3), kernel compiled with SCHED_ULE.
This is because machdep.hlt_logical_cpus doesn't do what you think it
does. It causes HTT cores to invoke the
Hello,
I have an amd64 laptop on which I did a fresh csup to RELENG_7. I did
the canonical buildworld, buildkernel, installkernel and so far
so good.
However, when I attempt to installworld, I get:
=== share/syscons/scrnmaps (install)
./armscii8-2haik8.mk armscii8-2haik8.tmp
uuencode
Hi,
after some time without FreeBSD I installed 7.1 on an IBM Thinkpad T30
(with ZFS root on encrypted geli, works great).
Config is:
FreeBSD hasking.alashan.nongo 7.1-STABLE FreeBSD 7.1-STABLE #3: Thu
Feb 5 21:10:45 CET 2009
r...@hasking.alashan.nongo:/usr/obj/usr/src/sys/HASKING i386
I
Hi
Im running FreeBSD 7.0-RELEASE on my gateway and for the last week or
so it cant renew its dhcp-lease.
At boot-time it sends a request to broadcast: DHCPREQUEST on fxp0 to
255.255.255.255 port 67
And then it gets an DHCPACK from the gateway. (not 172.21.248.127)
But then the machine
Date: Mon, 23 Feb 2009 16:21:17 +0100
From: Christian Walther cptsa...@gmail.com
Sender: owner-freebsd-sta...@freebsd.org
Hi,
after some time without FreeBSD I installed 7.1 on an IBM Thinkpad T30
(with ZFS root on encrypted geli, works great).
Config is:
FreeBSD
On Feb 23, 2009, at 7:08 PM, Brooks Davis wrote:
On Mon, Feb 23, 2009 at 06:40:15PM +0100, Peter Ankerst?l wrote:
Hi
Im running FreeBSD 7.0-RELEASE on my gateway and for the last week
or so it
cant renew its dhcp-lease.
At boot-time it sends a request to broadcast: DHCPREQUEST on fxp0 to
On Mon, Feb 23, 2009 at 06:40:15PM +0100, Peter Ankerst?l wrote:
Hi
Im running FreeBSD 7.0-RELEASE on my gateway and for the last week or so it
cant renew its dhcp-lease.
At boot-time it sends a request to broadcast: DHCPREQUEST on fxp0 to
255.255.255.255 port 67
And then it gets an
Robert Watson wrote:
In the mean time, it sounds like the sysctl does need to be
reimplemented or removed, but one question is how far to take it --
caches are shared to varying degrees at varying levels of the topology.
However, I believe the recommendation has generally moved to disabling
On Mon, 23 Feb 2009, Maxim Sobolev wrote:
Robert Watson wrote:
In the mean time, it sounds like the sysctl does need to be reimplemented
or removed, but one question is how far to take it -- caches are shared to
varying degrees at varying levels of the topology. However, I believe the
On Mon, 23 Feb 2009, Robert Watson wrote:
It's not quite that simple -- in a world of device drivers pinning threads to
CPUs for workload distribution, callout threads and sched_bind()/sched_pin()
for crypto load distribution, etc, you need a whole infrastructure for
software-disabled CPUs.
Robert Watson wrote:
On Mon, 23 Feb 2009, Maxim Sobolev wrote:
Robert Watson wrote:
In the mean time, it sounds like the sysctl does need to be
reimplemented or removed, but one question is how far to take it --
caches are shared to varying degrees at varying levels of the
topology.
On Mon, 23 Feb 2009, Maxim Sobolev wrote:
Unfortunately access to BIOS is not always an option and also some BIOSes
don't even provide a feature to turn HTT off.
It's not quite that simple -- in a world of device drivers pinning threads
to CPUs for workload distribution, callout threads and
Hi Kevin,
lets say it this way: Right now the DWL-G650 works.
I'm not sure why, but I did reset the BIOS configurations to its
default and started manually configuration some of the used
interrupts. This is why the snippets of the logfiles I sent in my
previous mail don't match the current
Robert Watson wrote:
So, are you suggesting that we should disable
machdep.hyperthreading_allowed with ULE in 7.x and current to avoid
confusion?
Possibly even without ULE.
I've verified - the tunable/sysctl works just fine with SCHED_4BSD in
7.1, so that I am not sure it's worth ripping
Pete French-2 wrote:
Probably it is your case, try please.
http://www.freebsd.org/cgi/query-pr.cgi?pr=130652cat=
OK, will give this a try, unless anyone else wants any traces from
this locked machine ? Is there a known way to tickle this bug
when I've rebooted, to make sure it's fixed
Lately I've installed a couple of test systems from 7.1-RELEASE CDs,
then csupped to RELENG_7 from cvsup9:
*default host=cvsup9.FreeBSD.org
*default base=/var/db
*default prefix=/usr
*default release=cvs tag=RELENG_7
*default delete use-rel-suffix
mergemaster adds a *lot* of old files in /etc
20 matches
Mail list logo
