Hi,
We have a Dell 1950 with the same problem (bce). We tried
debug.mpsafenet=0, but to no avail. It's a very frustrating show-stopper
for us as well, we're moving all 1950 out of the production environment.
Any help would be greatly appreciated.
See mail to freebsd-current mail attached.
Kind
Scott Long ([EMAIL PROTECTED]) on 04/10/2006 at 14:49 wrote:
#*default release=cvs tag=RELENG_6 date=2006.08.08.09.12.56
# OK
#
#*default release=cvs tag=RELENG_6 date=2006.08.08.09.21.00
# BROKEN
...
#*default release=cvs tag=RELENG_6
# BROKEN
From
Craig Boston ([EMAIL PROTECTED]) on 29/09/2006 at 20:19 wrote:
One thing this patch definitely did do though, is break the nvidia
driver pretty badly. Couldn't keep the X server running for more than a
minute before it froze solid. Lots of Xid: blah blah blah messages.
Yes I remembered to
In response to Scott Long [EMAIL PROTECTED]:
Corrected patch is at:
http://people.freebsd.org/~scottl/usb_fastintr_RELENG_6.diff
I have a Dell 1950 here that's been dedicated to helping solve this
problem. I can reliably reproduce the watchdog timeout by doing
the following steps:
1) Mount
In response to Bill Moran [EMAIL PROTECTED]:
In my case, it's a bce driver that's doing it. I also have some em
cards in this machine that I can test if the information will be
helpful.
Note that I can _not_ reproduce the problem with an em interface (a
PCI NIC). As mentioned earlier, I can
On Wed, Oct 04, 2006 at 10:40:25AM -0400, Bill Moran wrote:
In response to Scott Long [EMAIL PROTECTED]:
Corrected patch is at:
http://people.freebsd.org/~scottl/usb_fastintr_RELENG_6.diff
I have a Dell 1950 here that's been dedicated to helping solve this
problem. I can reliably
At 12:27 PM 10/4/2006, Bill Moran wrote:
In response to Bill Moran [EMAIL PROTECTED]:
In my case, it's a bce driver that's doing it. I also have some em
cards in this machine that I can test if the information will be
helpful.
Note that I can _not_ reproduce the problem with an em
In response to Mike Tancsa [EMAIL PROTECTED]:
At 12:27 PM 10/4/2006, Bill Moran wrote:
In response to Bill Moran [EMAIL PROTECTED]:
In my case, it's a bce driver that's doing it. I also have some em
cards in this machine that I can test if the information will be
helpful.
Note
In response to Kris Kennaway [EMAIL PROTECTED]:
This is quite a show-stopper for us, if there's any other testing/etc
I can do, _please_ let me know. I might even be able to get remote
console access to this machine approved for a developer.
Remote console access would be a help. I
Guy Brand wrote:
Craig Boston ([EMAIL PROTECTED]) on 29/09/2006 at 20:19 wrote:
One thing this patch definitely did do though, is break the nvidia
driver pretty badly. Couldn't keep the X server running for more than a
minute before it froze solid. Lots of Xid: blah blah blah messages.
Yes
Hi,
What about with just the first change and not the second? Anyways, I'm
starting to see a trend here. Problem reports are clustering around UP
systems, not SMP systems. I don't know if that's just coincidence or not.
We've got also about twenty SMP Systems, seven of them now with 6.1
I also have been using em (on-board NIC) with SMP without any problems, I just
upgraded to check and all is still fine:
New kernel : FreeBSD 6.2-PRERELEASE #7: Mon Oct 2 15:15:47 PDT 2006
Old kernel : FreeBSD 6.1-STABLE #4: Wed Sep 6 16:01:23 PDT 2006
I also have nvidia and use firefox with
Martin Blapp wrote:
Hi,
What about with just the first change and not the second? Anyways,
I'm starting to see a trend here. Problem reports are clustering
around UP
systems, not SMP systems. I don't know if that's just coincidence or
not.
We've got also about twenty SMP Systems, seven
Are you enabling an option, like IPv6, that puts Giant over the network
stack?
Am not enabling anything, but if INET6 is part of GENERIC (which I think it is
isn't it?) then I would have that in my kernels as they basically look
like this:
include GENERIC
options SMP
On Sun, Oct 01, 2006 at 01:37:38PM +0100, Pete French wrote:
Are you enabling an option, like IPv6, that puts Giant over the network
stack?
Am not enabling anything, but if INET6 is part of GENERIC (which I think it is
isn't it?) then I would have that in my kernels as they basically look
On Sun, Oct 01, 2006 at 01:37:38PM +0100, Pete French wrote:
Are you enabling an option, like IPv6, that puts Giant over the network
stack?
Am not enabling anything, but if INET6 is part of GENERIC (which I think it is
isn't it?) then I would have that in my kernels as they basically look
Just an observation.
All the boxes I've had this problem on have _two_ em interfaces. I have
never seen it on my boxes with just one em NIC.
The error is always em0 timeout - never em1 (I haven't seen any!)
Yesterday my local network got completely wacky, the gateway had em0
timeouts on the
Martin Nilsson wrote:
Just an observation.
All the boxes I've had this problem on have _two_ em interfaces. I have
never seen it on my boxes with just one em NIC.
The error is always em0 timeout - never em1 (I haven't seen any!)
Yesterday my local network got completely wacky, the gateway
Just an observation.
All the boxes I've had this problem on have _two_ em interfaces. I have
never seen it on my boxes with just one em NIC.
The error is always em0 timeout - never em1 (I haven't seen any!)
Yesterday my local network got completely wacky, the gateway had em0
timeouts
Just to add a data point: I just upgraded feral.com to the latest
RELENG_6 branch. I have a dual port em for internal networks and I've
never seen the problems reported.
Also, for -current, things have now been stable again for the last
week or so for em on multiple machines (most of which have
From Kris Kennaway [EMAIL PROTECTED], Fri, Sep 29, 2006 at 09:42:42PM -0400:
On Fri, Sep 29, 2006 at 08:34:39PM -0500, Craig Boston wrote:
On Fri, Sep 29, 2006 at 08:19:04PM -0500, Craig Boston wrote:
On Thu, Sep 28, 2006 at 01:48:42PM -0600, Scott Long wrote:
Craig Boston wrote:
On Thu, Sep 28, 2006 at 01:48:42PM -0600, Scott Long wrote:
http://people.freebsd.org/~scottl/usb_fastintr_RELENG_6.diff
At first glance it appeared to work, but I'm about to do some more
testing since I just discovered that I have to kldload something
(anything) first
David G Lawrence wrote:
Attached is a simple user program that will immediately cause pretty much
all of the network drivers (at least the ones I own) to stop working and
get watchdog timeouts.
I am runnign this on a single processor machine with an SMP kernel and
it does not have any
Are you enabling an option, like IPv6, that puts Giant over the network
stack?
From dmesg:
WARNING: debug.mpsafenet forced to 0 as ipsec requires Giant
WARNING: MPSAFE network stack disabled, expect reduced performance.
...the kernel has IPSEC.
-DG
David G. Lawrence
President
Download
On Sat, 30 Sep 2006, Scott Long wrote:
David G Lawrence wrote:
Attached is a simple user program that will immediately cause pretty
much
all of the network drivers (at least the ones I own) to stop working and
get watchdog timeouts.
I am runnign this on a single processor machine with an
On Fri, 29 Sep 2006, David G Lawrence wrote:
Are you enabling an option, like IPv6, that puts Giant over the network
stack?
From dmesg:
WARNING: debug.mpsafenet forced to 0 as ipsec requires Giant
WARNING: MPSAFE network stack disabled, expect reduced performance.
...the kernel has
On Fri, Sep 29, 2006 at 11:05:35PM -0700, Paul Allen wrote:
From Kris Kennaway [EMAIL PROTECTED], Fri, Sep 29, 2006 at 09:42:42PM
-0400:
On Fri, Sep 29, 2006 at 08:34:39PM -0500, Craig Boston wrote:
On Fri, Sep 29, 2006 at 08:19:04PM -0500, Craig Boston wrote:
On Thu, Sep 28, 2006 at
On Sat, Sep 30, 2006 at 12:14:17AM -0600, Scott Long wrote:
One thing this patch definitely did do though, is break the nvidia
driver pretty badly. Couldn't keep the X server running for more than a
minute before it froze solid. Lots of Xid: blah blah blah messages.
Yes I remembered to
On Sat, Sep 30, 2006 at 02:39:06PM -0400, Kris Kennaway wrote:
Which is odd since the hypothesis Scott was working on should have
shown up clearly in the mutex trace, but did not.
But it is consistent with there being a beat-frequency problem with
respect to the scheduler. I think
I wonder if this is related to the breakage of the Rocketport driver (PR is
open, but it appears that nobody has looked at it.)
It breaks specifically when I use a piece of software that does a lot of
SELECTs on a terminal line to do pretty much what poll does but it
is not specific
Attached is a simple user program that will immediately cause pretty much
all of the network drivers (at least the ones I own) to stop working and
get watchdog timeouts.
WARNING: This program will kill the network on your 6.x server. Do not run
this on a production machine unless you are on
Attached is a simple user program that will immediately cause pretty much
all of the network drivers (at least the ones I own) to stop working and
get watchdog timeouts.
Oh, one more thing - I've only tried this on uni-processor machines. The
only MP machine that I have here is a
On Fri, Sep 29, 2006 at 12:27:41AM -0700, David G Lawrence wrote:
Attached is a simple user program that will immediately cause pretty much
all of the network drivers (at least the ones I own) to stop working and
get watchdog timeouts.
WARNING: This program will kill the network on your
On Fri, Sep 29, 2006 at 12:27:41AM -0700, David G Lawrence wrote:
Attached is a simple user program that will immediately cause pretty much
all of the network drivers (at least the ones I own) to stop working and
get watchdog timeouts.
WARNING: This program will kill the network on
On Fri, Sep 29, 2006 at 01:16:47AM -0700, David G Lawrence wrote:
Is this a UP machine or MP machine?
Dualcore AMD64.
sysadm:~sysctl hw.ncpu
hw.ncpu: 2
___
freebsd-stable@freebsd.org mailing list
Attached is a simple user program that will immediately cause pretty much
all of the network drivers (at least the ones I own) to stop working and
get watchdog timeouts.
I am runnign this on a single processor machine with an SMP kernel and
it does not have any effect. I dont tink I have
Attached is a simple user program that will immediately cause pretty much
all of the network drivers (at least the ones I own) to stop working and
get watchdog timeouts.
I am runnign this on a single processor machine with an SMP kernel and
it does not have any effect. I dont tink I
Do you have any history of seeing the watchdog timeout problem on your
machine?
On this machine no - but it's the only one running em0. On other
machines running bge0 then, yes, I see it a lot. But those are all
SMP machines, aside from one. On that one I am currently building
the latest
Do you have any history of seeing the watchdog timeout problem on your
machine?
O.K., I just finished compiing up a uniprocessor kenel for the machine
on which I had been seeing bge0 timeouts, and the lopppoll.c code
has no effect there. The kerenl I am running is the latest STABLE from
a
Do you have any history of seeing the watchdog timeout problem on your
machine?
On this machine no - but it's the only one running em0. On other
machines running bge0 then, yes, I see it a lot. But those are all
SMP machines, aside from one. On that one I am currently building
the
I've been experiencing this problem too, along with my USB keyboard
acting 'wonky' (stuttering from time to time). For me at least it seems
to be tied to CPU usage, meaning it's probably related to the taskqueue
or maybe even the scheduler. I can also reproduce the problem on a much
bigger scale
Doesn't seem to have any effect for me (other than high sys% times).
qemu is really good at provoking my em0 to timeout.
On Fri, Sep 29, 2006 at 12:27:41AM -0700, David G Lawrence wrote:
Attached is a simple user program that will immediately cause pretty much
all of the network drivers (at
On Friday 29 September 2006 06:37, Pete French wrote:
Attached is a simple user program that will immediately cause pretty
much
all of the network drivers (at least the ones I own) to stop working and
get watchdog timeouts.
I am runnign this on a single processor machine with an SMP
On Fri, Sep 29, 2006 at 04:21:55PM -0500, Craig Boston wrote:
Doesn't seem to have any effect for me (other than high sys% times).
qemu is really good at provoking my em0 to timeout.
What might be useful for someone who can provoke this, is to configure
your kernel with MUTEX_PROFILING, then do
On Fri, Sep 29, 2006 at 05:37:40PM -0400, Kris Kennaway wrote:
What might be useful for someone who can provoke this, is to configure
your kernel with MUTEX_PROFILING, then do the following:
snip
This will help to show whether something is causing Giant starvation.
I'm currently building a
On Fri, Sep 29, 2006 at 05:37:40PM -0400, Kris Kennaway wrote:
and provide access to that file.
This will help to show whether something is causing Giant starvation.
http://www.gank.org/freebsd/stats.out
That's after about 25 seconds of the em0 interface being unable to
receive because of an
On Thu, Sep 28, 2006 at 01:48:42PM -0600, Scott Long wrote:
http://people.freebsd.org/~scottl/usb_fastintr_RELENG_6.diff
At first glance it appeared to work, but I'm about to do some more
testing since I just discovered that I have to kldload something
(anything) first in order to reproduce the
On Fri, Sep 29, 2006 at 08:19:04PM -0500, Craig Boston wrote:
On Thu, Sep 28, 2006 at 01:48:42PM -0600, Scott Long wrote:
http://people.freebsd.org/~scottl/usb_fastintr_RELENG_6.diff
At first glance it appeared to work, but I'm about to do some more
testing since I just discovered that I
On Fri, Sep 29, 2006 at 08:03:29PM -0500, Craig Boston wrote:
On Fri, Sep 29, 2006 at 05:37:40PM -0400, Kris Kennaway wrote:
and provide access to that file.
This will help to show whether something is causing Giant starvation.
http://www.gank.org/freebsd/stats.out
That's after about
On Fri, Sep 29, 2006 at 08:34:39PM -0500, Craig Boston wrote:
On Fri, Sep 29, 2006 at 08:19:04PM -0500, Craig Boston wrote:
On Thu, Sep 28, 2006 at 01:48:42PM -0600, Scott Long wrote:
http://people.freebsd.org/~scottl/usb_fastintr_RELENG_6.diff
At first glance it appeared to work, but
To add another twist to this: I added options POLLING to the kernel, moved
the fireware and USB drivers from the kernel and loaded them as modules. I
have NOT enabled polling on the em-interface but this new kernal, built on
the same sources as the failing one works without a hitch.
As
All,
Attached is my first cut at addressing the problems described in this
thread. As I discussed earlier, the VM syncer thread is likely starving
the USB interrupt thread. This causes the shared usb+network interrupt
to remain masked, preventing network interrupts from being delivered,
and
On Wednesday, 27 September 2006 at 9:40:52 -0700, Jeremy Chadwick wrote:
On Wed, Sep 27, 2006 at 06:32:59PM +0200, Patrick M. Hausen wrote:
On Wed, Sep 27, 2006 at 05:59:04PM +0200, Oliver Brandmueller wrote:
I don't think it has to especially with ichsmb here, but only with the
fact,
Scott Long wrote:
All,
Attached is my first cut at addressing the problems described in this
thread. As I discussed earlier, the VM syncer thread is likely starving
the USB interrupt thread. This causes the shared usb+network
interrupt to remain masked, preventing network interrupts from
O. Hartmann wrote:
Scott Long wrote:
All,
Attached is my first cut at addressing the problems described in this
thread. As I discussed earlier, the VM syncer thread is likely starving
the USB interrupt thread. This causes the shared usb+network
interrupt to remain masked, preventing
At 03:15 PM 9/28/2006, O. Hartmann wrote:
/usr/src/sys/dev/usb/usb.c:282: error: for each function it appears in.)
/usr/src/sys/dev/usb/usb.c: At top level:
/usr/src/sys/dev/usb/usb.c:863: warning: 'usb_intr_task' defined but not used
*** Error code 1
Are you sure the patch applied cleanly
Additional data point: On 6.1-RELEASE I've observed the same sort of
behavior, but without any noticeable consistency. It affects bge(4) and
em(4) systems. In the case of the bge(4)-equipped system, there's a
very weak correlation between heavy disk activity and watchdog timeouts.
However, on
Mike Tancsa wrote:
At 03:15 PM 9/28/2006, O. Hartmann wrote:
/usr/src/sys/dev/usb/usb.c:282: error: for each function it appears in.)
/usr/src/sys/dev/usb/usb.c: At top level:
/usr/src/sys/dev/usb/usb.c:863: warning: 'usb_intr_task' defined but
not used
*** Error code 1
Are you sure the
Scott Long wrote:
All,
Attached is my first cut at addressing the problems described in this
thread. As I discussed earlier, the VM syncer thread is likely starving
the USB interrupt thread. This causes the shared usb+network
interrupt to remain masked, preventing network interrupts from
Hi!
On Thu, Sep 28, 2006 at 02:47:09PM -0500, Alan Amesbury wrote:
Additional data point: On 6.1-RELEASE I've observed the same sort of
behavior, but without any noticeable consistency. It affects bge(4) and
em(4) systems. In the case of the bge(4)-equipped system, there's a
very weak
Mike Jakubik wrote:
Scott Long wrote:
All,
Attached is my first cut at addressing the problems described in this
thread. As I discussed earlier, the VM syncer thread is likely starving
the USB interrupt thread. This causes the shared usb+network
interrupt to remain masked, preventing
On many of our servers, we have bge cards and I can see a lot of
watchdog timeouts. We always disable USB in the bios and they didn't
share irq.
I see the same thing - we have a number of HP blades which use bge interfaces
and I get many watchdog timeouts on them. These are also not sharing
mailbox# uname -a
FreeBSD mailbox 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #0: Fri Sep 22
00:31:29 CEST 2006
[EMAIL PROTECTED]:/usr/obj-local/usr/src/sys/SMP amd64
I get tons of these:
em0: watchdog timeout -- resetting
em0: link state changed to DOWN
em0: link state changed to UP
mailbox#
Hi,
On Wed, Sep 27, 2006 at 08:00:21AM +0200, Martin Nilsson wrote:
I get tons of these:
em0: watchdog timeout -- resetting
em0: link state changed to DOWN
em0: link state changed to UP
mailbox# pciconf -lv
[EMAIL PROTECTED]:0:0: class=0x02 card=0x108c15d9 chip=0x108c8086
rev=0x03
Oliver Brandmueller wrote:
Hi,
On Wed, Sep 27, 2006 at 08:00:21AM +0200, Martin Nilsson wrote:
I get tons of these:
em0: watchdog timeout -- resetting
em0: link state changed to DOWN
em0: link state changed to UP
mailbox# pciconf -lv
[EMAIL PROTECTED]:0:0: class=0x02 card=0x108c15d9
Hello!
Well, the best I can say at the moment is, Wow. =-( I guess the
thing to do here is to figure out if the problem lies with the em
interrupt handler not getting run, or the taskqueue not getting run.
I helped Pyun with some debugging by providing ssh access to
a machine showing the
On 9/27/06, Martin Nilsson [EMAIL PROTECTED] wrote:
mailbox# uname -a
FreeBSD mailbox 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #0: Fri Sep 22
00:31:29 CEST 2006
[EMAIL PROTECTED]:/usr/obj-local/usr/src/sys/SMP amd64
I get tons of these:
em0: watchdog timeout -- resetting
em0: link state changed
Hello!
On -stable occasionally other people complained about very similar
looking problems with bge and other drivers. My guess is, though
I'm not a kernel developer, just an experienced admin, that
em stands out as problematic just by coincidence. Certain onboard
network components tend to
I have seen the watchdog and reset problem on a -STABLE laptop, both em
and iwi. It only occur when I try to connect using Mulberry e-mail
client so I thought it could be a problem with the linuxilator.
The load on the box is normally low but both driver have shared
interrupts, either with
On Wed, 27 Sep 2006 13:24:15 +0200 glz [EMAIL PROTECTED]
wrote about Re: 6.2 SHOWSTOPPER - em completely unusable on 6.2:
G I have seen the watchdog and reset problem on a -STABLE laptop, both em
G and iwi. It only occur when I try to connect using Mulberry e-mail
G client so I thought it could
Hi,
it's just a me too. On our ftp server (ftp8.fr.freebsd.org), sometimes
we see some watchdog timeout in the log with a bge card, but maybe it's
not the same problem... :
/var/log/messages:Sep 23 02:47:06 anubis kernel: bge1: watchdog timeout --
resetting
/var/log/messages:Sep 23 02:47:06
Me Too(tm).
FreeBSD jacinta.home.cacheboy.net 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #0:
Mon Sep 18 07:59:50 UTC 2006
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
i386
Lots of this in dmesg:
em0: watchdog timeout -- resetting
em0: link state changed to DOWN
em0: link state changed to UP
Hi!
On Wed, Sep 27, 2006 at 02:42:30PM +0200, Philippe Pegon wrote:
it's just a me too. On our ftp server (ftp8.fr.freebsd.org), sometimes
we see some watchdog timeout in the log with a bge card, but maybe it's
not the same problem... :
As far as I know the watchdog timeouts are _supposed_
s/is on the bus/is alone on the irq/.
(And it shows up when I'm running polygraph and apachebench tests.)
On 9/27/06, Adrian Chadd [EMAIL PROTECTED] wrote:
Me Too(tm).
FreeBSD jacinta.home.cacheboy.net 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE#0: Mon
Sep 18 07:59:50 UTC 2006
[EMAIL
On Wed, Sep 27, 2006 at 03:25:55PM +0200, Patrick M. Hausen wrote:
On Wed, Sep 27, 2006 at 02:42:30PM +0200, Philippe Pegon wrote:
it's just a me too. On our ftp server (ftp8.fr.freebsd.org), sometimes
we see some watchdog timeout in the log with a bge card, but maybe it's
not the same
On Wed, Sep 27, 2006 at 09:06:09PM +0800, Adrian Chadd wrote:
Me Too(tm).
Me three -- and the interesting part (in my case) is that em0
shares an IRQ with the ATA controller.
http://www.freebsd.org/cgi/query-pr.cgi?pr=103435
Because people are reporting this on more than just the em driver
At 09:25 AM 9/27/2006, Patrick M. Hausen wrote:
Hi!
On Wed, Sep 27, 2006 at 02:42:30PM +0200, Philippe Pegon wrote:
it's just a me too. On our ftp server (ftp8.fr.freebsd.org), sometimes
we see some watchdog timeout in the log with a bge card, but maybe it's
not the same problem... :
As
Hi!
On Wed, Sep 27, 2006 at 06:52:51AM -0700, Jeremy Chadwick wrote:
On Wed, Sep 27, 2006 at 03:25:55PM +0200, Patrick M. Hausen wrote:
On Wed, Sep 27, 2006 at 02:42:30PM +0200, Philippe Pegon wrote:
it's just a me too. On our ftp server (ftp8.fr.freebsd.org), sometimes
we see some
Hi.
On Wed, Sep 27, 2006 at 04:19:55PM +0200, Patrick M. Hausen wrote:
You'll still see impact -- that is, no packets flowing. The
reason things are recoverable is solely because of the retry
functionality for layer 2 packets...
You are, of course, right. What I meant is: these
Hi Scott,
On Wed, Sep 27, 2006 at 03:16:57AM -0600, Scott Long wrote:
Well, the best I can say at the moment is, Wow. =-( I guess the
thing to do here is to figure out if the problem lies with the em
interrupt handler not getting run, or the taskqueue not getting run.
Since you've stated
On Wed, Sep 27, 2006 at 09:56:22AM -0400, Mike Tancsa wrote:
If it up / downs the interface, it can be painful depending on your
setup. In one of the colos I dont have control over, the switch port
will block for 15 seconds for Spanning Tree when the interface
transitions like that. Even
On Wed, Sep 27, 2006 at 05:28:24PM +0200, Oliver Brandmueller wrote:
Hi Scott,
On Wed, Sep 27, 2006 at 03:16:57AM -0600, Scott Long wrote:
Well, the best I can say at the moment is, Wow. =-( I guess the
thing to do here is to figure out if the problem lies with the em
interrupt
On Wed, Sep 27, 2006 at 05:28:24PM +0200, Oliver Brandmueller wrote:
Disk activity does not trigger the problem, I hammered the disk with
around 85 MB/s (dd) for about half an hour without seeing any effect. A
CPU bound thing like a buildworld triggered the problem.
The SMBus Interface is
Hi,
On Wed, Sep 27, 2006 at 10:50:55AM -0500, Brooks Davis wrote:
Disk activity does not trigger the problem, I hammered the disk with
around 85 MB/s (dd) for about half an hour without seeing any effect. A
CPU bound thing like a buildworld triggered the problem.
I'm not sure that's a
Hi,
On Wed, Sep 27, 2006 at 08:55:53AM -0700, Jeremy Chadwick wrote:
The SMBus Interface is not used at all (it's not even really usable).
Anyway, as soon as I unload the ichsmb module I cannot triger the
problem anymore. If I load it again, the problem cann again be triggered
by a
Hi!
On Wed, Sep 27, 2006 at 05:59:04PM +0200, Oliver Brandmueller wrote:
I don't think it has to especially with ichsmb here, but only with the
fact, that ichsmb is for me exactly the thing that shares the interrupt
with the em interface that shows the problems.
I can confirm that making
Oliver Brandmueller wrote:
Hi,
On Wed, Sep 27, 2006 at 08:55:53AM -0700, Jeremy Chadwick wrote:
The SMBus Interface is not used at all (it's not even really usable).
Anyway, as soon as I unload the ichsmb module I cannot triger the
problem anymore. If I load it again, the problem cann again
Well, HTH - I don't have *any* problems with this configuration:
FreeBSD 6.2-PRERELEASE #6: Wed Sep 20 18:52:56 CEST 2006 [EMAIL
PROTECTED]:/usr/obj/usr/src/sys/MAILSMP
CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2793.20-MHz K8-class CPU)
Origin = GenuineIntel Id = 0xf48 Stepping = 8
On Wed, Sep 27, 2006 at 06:32:59PM +0200, Patrick M. Hausen wrote:
On Wed, Sep 27, 2006 at 05:59:04PM +0200, Oliver Brandmueller wrote:
I don't think it has to especially with ichsmb here, but only with the
fact, that ichsmb is for me exactly the thing that shares the interrupt
with the
On Sep 27, 2006, at 11:50 AM, Jeremy Chadwick wrote:
On Wed, Sep 27, 2006 at 09:56:22AM -0400, Mike Tancsa wrote:
If it up / downs the interface, it can be painful depending on your
setup. In one of the colos I dont have control over, the switch port
will block for 15 seconds for Spanning
Hi, Scott!
On Wed, Sep 27, 2006 at 10:32:49AM -0600, Scott Long wrote:
1. Revert the em driver to its 6.1 form, ask people to test if the
problem persists. If it doesn't, leave it at that for now.
For me the problem manifested itself some time between 6.0
and 6.1. I did the testing with Pyun
As an optional data point you might wish to consider the Intel
driver I am about to release, it has everything that 6.2 does
EXCEPT the interrupt changes. I kept those out because I
didn't want to break backward compatibility. If someone that
has repro'd this problem wants to check this speak up
On Wed, Sep 27, 2006 at 12:44:04PM -0400, Javier Henderson wrote:
You could enable port fast and still have spanning tree in place.
What many reasons do you and others have to shun STP?
Rather than ramble off all the things I've experienced with STP,
most of them are covered in this caveat
At 12:32 PM 9/27/2006, Scott Long wrote:
My theory here is that something in the kernel, likely VM/VFS, is
holding the Giant lock for an inordinate amount of time. During this
time, an interrupt fires on the shared em/ichsmb interrupt. The em
Hi Scott,
Do you think this issue is
On Wed, Sep 27, 2006 at 03:25:55PM +0200, Patrick M. Hausen wrote:
Hi!
On Wed, Sep 27, 2006 at 02:42:30PM +0200, Philippe Pegon wrote:
it's just a me too. On our ftp server (ftp8.fr.freebsd.org), sometimes
we see some watchdog timeout in the log with a bge card, but maybe it's
not the
On Thu, Sep 28, 2006 at 06:32:16AM +1200, Jonathan Chen wrote:
On Wed, Sep 27, 2006 at 03:25:55PM +0200, Patrick M. Hausen wrote:
Hi!
On Wed, Sep 27, 2006 at 02:42:30PM +0200, Philippe Pegon wrote:
it's just a me too. On our ftp server (ftp8.fr.freebsd.org), sometimes
we see some
On Wed, 2006-Sep-27 10:32:49 -0600, Scott Long wrote:
My theory here is that something in the kernel, likely VM/VFS, is
holding the Giant lock for an inordinate amount of time.
In the past (RELENG_5) I've had major problems with syncer delaying
interrupt threads for long periods (I've seen
Peter Jeremy wrote:
On Wed, 2006-Sep-27 10:32:49 -0600, Scott Long wrote:
My theory here is that something in the kernel, likely VM/VFS, is
holding the Giant lock for an inordinate amount of time.
In the past (RELENG_5) I've had major problems with syncer delaying
interrupt threads for long
In the past (RELENG_5) I've had major problems with syncer delaying
interrupt threads for long periods (I've seen 8msec). See
http://lists.freebsd.org/pipermail/freebsd-stable/2005-February/012346.html
I'm not sure if this is still a problem (but I am still having some
problems which may be
On 37378-12-23 20:59, Patrick M. Hausen wrote:
Hello!
Well, the best I can say at the moment is, Wow. =-( I guess the
thing to do here is to figure out if the problem lies with the em
interrupt handler not getting run, or the taskqueue not getting run.
I helped Pyun with some
1 - 100 of 105 matches
Mail list logo
