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 r
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
> >#
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
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 p
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 P
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 I
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 hel
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
> > > he
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 inte
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 ca
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
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)
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 t
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 d
> 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
>
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 ha
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
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 basicall
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 basicall
> 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
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
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.
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 t
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
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 IPSE
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
> 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
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 effect
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 i
>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:
> > > > http://people.f
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 wo
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 a
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
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 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
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:
>
>
>
> This will help to show whether something is causing Giant starvation.
I'm currently building a
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 d
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 a
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
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
> >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
>
>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 c
>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 6-
> >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
>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
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
http://lists.freebsd.org/mailman/listinfo/freebsd-s
> 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 n
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 yo
>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 produ
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 th
> 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 sharin
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 networ
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 c
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 bei
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 p
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 t
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 to
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 networ
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 bei
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
> > >
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
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 before,
Scott Long wrote:
Well, I kinda danced around the issue before, but I'll say it now. I,
as well as a few others, have seen instances of Giant being held by
the syncer for 5 or more seconds at a time. I can't explain why, and
I've never been able to catch it in the act in a meaningful way. But
In message: <[EMAIL PROTECTED]>
Scott Long <[EMAIL PROTECTED]> writes:
: As soon as I can locate the O/U/EHCI register docs, I'll crank out a
: patch for everyone to try. If that works then I'll give the same
: treatment to ichsmb.
You might look in the //depot/user/imp/newcard/... t
On 2006-09-27 23:29, Scott Long wrote:
> Volker wrote:
[...]
>> Strange... I've seen exactly that on a (recent) RELENG_6 box but
>> using a dirty old USB 1.1 NIC (aue). I've seen DOWN and UP messages
>> (mostly while rebuilding kernel + world + ports) on the console all
>> the time (but did not car
Volker wrote:
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
David G Lawrence wrote:
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
pr
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 so
> 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
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
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 8msec
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
> >
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
>
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 some
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
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 a
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 Pyu
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 Tree
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
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
Featu
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 b
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
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
> > b
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 th
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
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
> > inter
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. Ev
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 st
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!
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 so
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... :
A
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
(bg
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 s
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 PROTECTED]
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 _suppose
Scott Long wrote:
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
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
vmsta
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 a
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
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 cbb
1 - 100 of 106 matches
Mail list logo
