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
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
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'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
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: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
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
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
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
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
30 matches
Mail list logo
