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 t
Pete French-2 wrote:
>
>> Probably it is your case, try please.
>>
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=130652&cat=
>
> 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
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 it
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 configu
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
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. Howeve
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. D
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
recom
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
h
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 a
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
2
> Date: Mon, 23 Feb 2009 16:21:17 +0100
> From: Christian Walther
> 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 hasking.alashan.nongo 7.1-ST
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 tr
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 tried
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 a
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
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 8-CU
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)
> @@ -15
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 the
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
20 matches
Mail list logo
