Hello Pyun,
On this new server, I cannot get more than ~280kByte/s up/downstream out of
re(4) without any tweaking.
re0: flags=8843 metric 0 mtu 1500
options=389b
ether 00:21:85:63:74:34
inet6 fe80::221:85ff:fe63:7434%re0 prefixlen 64 scopeid 0x1
inet 46.4.12.147
on 05/11/2010 23:27 Kostik Belousov said the following:
> I agree that the fix a right fix for real issue. It should only
> affect the filesystems that do support VFS_VGET(). In other words,
> it is relevant for e.g. UFS exports, but not for ZFS, that is the
> Andrey case.
Actually ZFS does implem
On Sat, 06.11.2010 at 10:37:00 +0100, Ulrich Spörlein wrote:
> Hello Pyun,
>
> On this new server, I cannot get more than ~280kByte/s up/downstream out of
> re(4) without any tweaking.
>
> re0: flags=8843 metric 0 mtu 1500
>
> options=389b
> ether 00:21:85:63:74:34
> inet
> Hello Pyun,
>
> On this new server, I cannot get more than ~280kByte/s up/downstream
>
I have been working on a similar problem with Pyun's help. Not yet
resolved and no idea if it is the same problem, but see below...
>
> Any ideas?
I have been chasing a similar problem w.r.t. re(4) { slow NF
Am 06.11.2010 um 10:37 schrieb Ulrich Spörlein:
> On this new server, I cannot get more than ~280kByte/s up/downstream out of
> re(4) without any tweaking.
>
> re0: flags=8843 metric 0 mtu 1500
>
> options=389b
>ether 00:21:85:63:74:34
>inet6 fe80::221:85ff:fe63:7434%re0 p
On Fri, Nov 5, 2010 at 20:54, C. P. Ghost wrote:
> Have you tried 'dmidecode' (as run), from the port sysutils/dmidecode?
I have actually, but the output is somewhat unexpected (besides the
fact that there are cases in which its report do not match reality.
The manpage says "often".).
In my box
On Fri, Nov 5, 2010 at 22:21, John Baldwin wrote:
>> During POST, die BIOS also tells me that ECC memory is installed, so
>> far so good. But I was a little surprised that the FreeBSD kernel
>> tells me absolutely nothing about it. Or do I have to tune loader.conf
>> variables?
>
> I think the ED
On Sat, Nov 6, 2010 at 9:09 AM, Thomas Zander
wrote:
> This means for now I have to trust the BIOS that ECC is enabled and I
> should see MCA reports in the dmesg output once a bit error is
> detected?
Well, you don't have to take BIOS' word for that and test whether ECC
really works. All you nee
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
SVN rev 214875 on 2010-11-06 13:03:33Z breaks buildworld on releng_7.
It introduces "siis.4" to /usr/src/share/man/man4/Makefile which doesn't
exist (yet?)
imb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (FreeBSD)
iEYEARECAAYFAkzV2t
On 7 November 2010 01:46, Michael Butler wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> SVN rev 214875 on 2010-11-06 13:03:33Z breaks buildworld on releng_7.
>
> It introduces "siis.4" to /usr/src/share/man/man4/Makefile which doesn't
> exist (yet?)
I guess that's rather due to SIFT
Artem Belevich wrote:
> All you need is intentionally make one data bit bad. Put some
> tape on one of the data pads on the DIMM and run memtest ...
and then spend the next couple of hours cleaning the gunk off of
the DIMM and out of the slot :(
___
f
On 11/07/10 09:54, Sergey Kandaurov wrote:
> On 7 November 2010 01:46, Michael Butler wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> SVN rev 214875 on 2010-11-06 13:03:33Z breaks buildworld on releng_7.
>>
>> It introduces "siis.4" to /usr/src/share/man/man4/Makefile which doesn'
TB --- 2010-11-07 01:27:03 - tinderbox 2.6 running on freebsd-stable.sentex.ca
TB --- 2010-11-07 01:27:03 - starting RELENG_7 tinderbox run for amd64/amd64
TB --- 2010-11-07 01:27:03 - cleaning the object tree
TB --- 2010-11-07 01:27:41 - cvsupping the source tree
TB --- 2010-11-07 01:27:41 - /usr/
I would agree with you if one would try to use electrical tape. It
would be unsuitable for this purpose because of it's thickness and
because of the residue it tends to leave.
I believe there are better options. For what it's worth, at home
scotch tape ("invisible" matte kind) worked well enough f
On 10/31/2010 15:53, Rumen Telbizov wrote:
> Hi Artem, everyone,
>
> Here's the latest update on my case.
> I did upgrade the system to the latest stable: 8.1-STABLE FreeBSD 8.1-STABLE
> #0: Sun Oct 31 11:44:06 PDT 2010
> After that I did zpool upgrade and zfs upgrade -r all the filesystems.
> Cur
On Sat, Nov 6, 2010 at 2:37 AM, Ulrich Spörlein wrote:
> Hello Pyun,
>
> On this new server, I cannot get more than ~280kByte/s up/downstream out of
> re(4) without any tweaking.
>
> re0: flags=8843 metric 0 mtu 1500
>
> options=389b
> ether 00:21:85:63:74:34
> inet6 fe80::22
16 matches
Mail list logo