On Thu, Nov 02, 2006 at 09:27:14PM -0600, Mark Linimon wrote:
> On Thu, Nov 02, 2006 at 02:09:29PM -0800, Jack Vogel wrote:
> > Yes, this is the second report I've had, other came to me personally.
>
> There is already a PR about it.
Ah, thanks, guess I should have searched there first...
Craig
On Thu, Nov 02, 2006 at 02:09:29PM -0800, Jack Vogel wrote:
> Yes, this is the second report I've had, other came to me personally.
There is already a PR about it.
mcl
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo
> Is it causing stuck connections or other messy problems? Also, is it
> any worse than 6.1?
No. It's not causing lock-ups or anything else sinister. The network
activity resumes happily a couple of seconds after the reset.
Nov 3 00:33:07 rwsrv05 kernel: bge0: watchdog timeout -- resetting
Nov
Is it causing stuck connections or other messy problems? Also, is it
any worse than 6.1?
Scott
John Marshall wrote:
rwsrv05> dmesg | grep bge
bge0: mem 0xe820-0xe820
irq 17 at device 4.0 on pci4
miibus1: on bge0
bge0: Ethernet address: 00:0b:cd:e7:70:19
bge0: link state changed to
rwsrv05> dmesg | grep bge
bge0: mem 0xe820-0xe820
irq 17 at device 4.0 on pci4
miibus1: on bge0
bge0: Ethernet address: 00:0b:cd:e7:70:19
bge0: link state changed to UP
bge0: watchdog timeout -- resetting
bge0: link state changed to DOWN
bge0: link state changed to UP
bge0: watchdog timeo
I have updated to 6.2-PRERELEASE, still experiencing the same problem.
Dmesg output is as follows :
Copyright (c) 1992-2006 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
Fr
Yes, this is the second report I've had, other came to me personally.
I'm looking into it.
Jack
On 11/2/06, Craig Boston <[EMAIL PROTECTED]> wrote:
Don't have much time right now, but wanted to report that the new em
driver in -STABLE breaks jumbo frame support for me. With it in the
kernel a
Don't have much time right now, but wanted to report that the new em
driver in -STABLE breaks jumbo frame support for me. With it in the
kernel and this card:
em1: port 0xe8c0-0xe8ff
mem 0xfe18-0xfe19 irq 18 at device 12.0 on pci2
I'm unable to send an ethernet frame bigger than 2034 b
Hi!
> drwxr-xr-x ... lib32
> drwxr-xr-x ... lib64
> lrwxr-xr-x ... lib -> lib${ARCH_BITS}
>
> ARCH_BITS would be set to "64" globally, and it would be
> set to "32" for i386 applications. Then every program
> would find the correct libs automagically.
> PS: For those who are not fa
On 10/31/06, Robert Blayzor <[EMAIL PROTECTED]> 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 spent all of last weekend trying to do this, with no solution
determined. I read a
On Thu, Nov 02, 2006 at 10:39:16AM -0800, Jack Vogel wrote:
> So, is that somewhat clearer?
Very much so! Thank you for the concise answer. This makes much
more sense. (The description, I mean -- the actual problem is
still a mystery.)
--
| Jeremy Chadwick jdc
Hi, Jack!
On Thu, Nov 02, 2006 at 10:39:16AM -0800, Jack Vogel wrote:
> So why do I say what we see is bogus... because the watchdog is
> firing even though we DON'T have tx hangs or descriptor shortages.
>
> I have a hack that rechecks the number of free descriptors in the
> watchdog code and r
On 11/2/06, Jeremy Chadwick <[EMAIL PROTECTED]> wrote:
On Thu, Nov 02, 2006 at 09:43:34AM -0800, Jack Vogel wrote:
> Yes, I know this is still happening. I also have pretty good data now
> that its a bogus problem, meaning due to scheduling issues the
> watchdog does not get reset even though the
Peter Jeremy wrote:
> Mark Linimon wrote:
> > - certain ports have i386 binaries (can't be fixed)
> > - certain ports have i386 asm code (can be fixed if there is fallback
> > C code)
>
> A partial solution to this is to get the i386 emulation and cross-
> building into better shape. If
Greg Black wrote:
> Mark Linimon wrote:
> > 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
On Thu, Nov 02, 2006 at 09:43:34AM -0800, Jack Vogel wrote:
> Yes, I know this is still happening. I also have pretty good data now
> that its a bogus problem, meaning due to scheduling issues the
> watchdog does not get reset even though the system is just fine
> as far as transmit descriptors is
Yes, I know this is still happening. I also have pretty good data now
that its a bogus problem, meaning due to scheduling issues the
watchdog does not get reset even though the system is just fine
as far as transmit descriptors is concerned. I have a patch that
detects this and keeps the watchdog
Do your performance test on Linux using 32k or 64k i/o blocks, then do
it on FreeBSD using the same. You'll seem similar performance between
the two. Unless your application is bypassing the filesystem to do
raw I/O that is larger than that, you won't see any benefit from the
larger i/o sizes t
Yes I received it, and no I'm not saying it's a driver bug. However I
did assume this would be the driver specific.
Do I understand you correctly; you're saying that it's FreeBSD's
controller I/O framework in general that cause this performance gap to
Windows and Linux, and it's not driver specifi
Pawel Jakub Dawidek wrote:
> On Sun, Oct 29, 2006 at 06:48:18PM +0100, Christian Laursen wrote:
>> Christian Laursen <[EMAIL PROTECTED]> writes:
>>
>>> Kazuaki ODA <[EMAIL PROTECTED]> writes:
>>>
I tried to find what broke ggated, and finally found that it works fine
when I backout sys/ke
You seem convinced that this is a driver bug. Did you receive my series
of emails 2 days ago that explained why it is not?
Scott
Fredrik Widlund wrote:
Please don't direct this to me as I've already pointed out that I'm not
asking about this. Fyi. the cards were shipped in a hurry mistakenly
Please don't direct this to me as I've already pointed out that I'm not
asking about this. Fyi. the cards were shipped in a hurry mistakenly
without bbus, we have to wait until next week for them to arrive, and
until then we will use cache without batteries since the performance
degradation using w
On Thu, 2 Nov 2006, Michael Butler wrote:
> Ian Smith wrote:
> > On Thu, 2 Nov 2006, Michel Talon wrote:
> >
> > > acpi_throttle0: on cpu0
> > > cpu1: on acpi0
> > > acpi_throttle1: on cpu1
> > > acpi_throttle1: failed to attach P_CNT
> > > device_attach: acpi_throttle1 attach ret
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ian Smith wrote:
> On Thu, 2 Nov 2006, Michel Talon wrote:
>
> [..]
>
> > I am joining the dmesg for reference.
>
> Just skimming through, tongue hanging out ..
>
> > cpu0: on acpi0
> > acpi_perf0: on cpu0
> > acpi_throttle0: on cpu0
> > cp
On Thu, 2006-11-02 at 09:02 -0500, Michael Butler wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Joel Dahl wrote:
> > On Thu, 2006-11-02 at 14:49 +0100, Michel Talon wrote:
> >> By the way another minor problem is that the audio does not
> >> work. According to the mobo manual, it is
I am wondering what CPUTYPE and CFLAGS are appropriate when using
Intel's Conroe based Xeons, since GCC 3 is not aware of this CPU, afaik.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscri
On Thu, 2 Nov 2006, Michel Talon wrote:
[..]
> I am joining the dmesg for reference.
Just skimming through, tongue hanging out ..
> cpu0: on acpi0
> acpi_perf0: on cpu0
> acpi_throttle0: on cpu0
> cpu1: on acpi0
> acpi_throttle1: on cpu1
> acpi_throttle1: failed to attach P_CNT
> d
The battery unit should not be considered optional. It's not about
performance on silly 'dd' tests, it's about data safety. Way back when,
all enterprise RAID cards were sold with an integrated battery because
it was the right thing to do. These days, when you're shopping for RAID
cards, you sh
On Nov 1, 2006, at 3:48 PM, spoggle wrote:
You can prove it by running boot0cfg with the "-o nopacket" option on
the CF card.
Whee - that worked, thank you!
- ask
--
http://askask.com/ - http://develooper.com/
___
freebsd-stable@freebsd.org m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joel Dahl wrote:
> On Thu, 2006-11-02 at 14:49 +0100, Michel Talon wrote:
>> By the way another minor problem is that the audio does not
>> work. According to the mobo manual, it is a Realtek ALC882 audio chip.
None
>> of the sound modules have recogni
On Thu, 2006-11-02 at 14:49 +0100, Michel Talon wrote:
>
> By the way another minor problem is that the audio does not
> work. According to the mobo manual, it is a Realtek ALC882 audio chip. None
> of the sound modules have recognized the chip. Sound works under Linux.
HDA sound is only supported
Hello,
today i have installed FreeBSD-6.2 BETA2 amd-64 on a Core 2 Duo machine with
an ASUS P5LD2-VM mobo. I have encountered the following bug from the
installer:
it wrote an fstab file with all the disk entries on ad4, while
the disk is on ad8. Hence when i rebooted, after install, root fil
To quote the original post:
Hi,
I have a script where we start a nttcp for some 500 nttcp client in back
ground. After some time I could see the nttcp clients are listed in the
TOP command as "Zoneli" state. Can any one please let me know what is
meant by Zoneli state?
Test Script:
=
cou
-Original Message-
From: LI Xin [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 02, 2006 6:26 PM
To: SIVAKUMAR SUBRAMANI (WT01 - Computing Systems & Storage)
Subject: Re: Zoneli State / Nttcp client.
Hi,
[EMAIL PROTECTED] wrote:
> Hi,
>
> I have a script where we start a nttcp for s
With a freshly checked-out tree from yesterday I still get the same
error when running "make buildworld" on sparc64 6.1-RELEASE-p7.
mkdep -f .depend -a-I/usr/src/sbin/gbde/../../sys -DRESCUE
/usr/src/sbin/gbde/gbde.c template.c
/usr/src/sbin/gbde/../../sys/crypto/rijndael/rijndael-alg-fst.c
/
Because the card itself will deal with the buffered writes independently
of the kernel activity the risk should be less than using softupdates.
Words like "screwed" seems to me to be exaggerated in the generic case.
I our case specific you would need to understand the nature of what we
are doing to
Hello!
Our central backup server is still experiencing the same
random problems. The timouts occur every other night or so,
when the server has got high CPU load (compressing the
backups) and transfers large amounts of data at the same
time.
Nov 2 02:19:34 datatomb kernel: em1: watchdog timeout
37 matches
Mail list logo
