On Fri, 4 Aug 2006, John-Mark Gurney wrote:
User Freebsd wrote this message on Mon, Jul 31, 2006 at 22:44 -0300:
For those that haven't been following the discussion on this, the iir(4)
driver in FreeBSD 6.x appears to have a deadlock issue under medium to
heavy load, where the 'blocked' state
Any status on this patch being merged in?
On Mon, 10 Jul 2006, Atanas wrote:
Pyun YongHyeon said the following on 7/7/06 8:32 PM:
On Fri, Jul 07, 2006 at 10:38:01PM +0100, Robert Watson wrote:
Yes -- basically, there are two problems:
(1) A little problem, in which an arp
On Tue, 1 Aug 2006, Patrick M. Hausen wrote:
Hi!
On Mon, Jul 31, 2006 at 10:49:27PM -0300, User Freebsd wrote:
Official word from Adaptec is that FreeBSD is no longer a supported
platform, so, I either live with the deadlocks, or try and figure out a
suitable replacement for the card
On Tue, 1 Aug 2006, Christian Brueffer wrote:
On Mon, Jul 31, 2006 at 10:49:27PM -0300, User Freebsd wrote:
I have a remote server, running the above RAID controller, that, as most
ppl here have seen over the past few weeks, is causing endless headaches
...
Official word from Adaptec
as such ...
On Mon, 31 Jul 2006, User Freebsd wrote:
'k, I finally got ahold of someone @ adaptec, and the official word seems to
be:
FreeBSD 6 is not officially supported for the GDT based ICP RAID
controllers. Nevertheless the inbox driver should work.
Great, well, the inbox driver doesn't work
On Tue, 1 Aug 2006, Patrick M. Hausen wrote:
Hello!
On Tue, Aug 01, 2006 at 09:51:59AM +0200, Patrick M. Hausen wrote:
That's really really bad news. Oddly, ICP Vortex Germany told me
the opposite wr/t to their new line of cards. They said, they
were working on full FreeBSD support. I'll
On Tue, 1 Aug 2006, Scott Long wrote:
Ok guys, time for a small breather here. All these claims about
EoE and orphanage and whatnot are a bit premature and underinformed.
First, the iir driver is being worked on when the need arises. Several
bugs were fixed in it a few months ago, and until
I have a remote server, running the above RAID controller, that, as most
ppl here have seen over the past few weeks, is causing endless headaches
...
Official word from Adaptec is that FreeBSD is no longer a supported
platform, so, I either live with the deadlocks, or try and figure out a
'k, I finally got ahold of someone @ adaptec, and the official word seems
to be:
FreeBSD 6 is not officially supported for the GDT based ICP RAID
controllers. Nevertheless the inbox driver should work.
Great, well, the inbox driver doesn't work with FreeBSD 6.x, and support
doesn't exist
On Wed, 19 Jul 2006, Kostik Belousov wrote:
On Wed, Jul 19, 2006 at 01:31:17AM -0300, User Freebsd wrote:
Kostik/Robert ... does this provide enough (any?) information concerning
the deadlock situation(s) that are being reported? is there anything else
I should do the next time it happens
On Wed, 19 Jul 2006, Kostik Belousov wrote:
You did not provided the output of show lockedbufs,
Added to my debug list ...
but, even without that data, I doubt that the buf subsystem deadlocked by
itself.
I make an conjecture that the problem is either with you disk hardware (i.e.,
actual
On Wed, 19 Jul 2006, Robert Watson wrote:
On Wed, 19 Jul 2006, User Freebsd wrote:
Also note that under FreeBSD 4.x, all three of these machines were pretty
much my more solid machines, with even more vServers running on them then
I'm able to run with 6.x ... once I got rid of using unionfs
On Wed, 19 Jul 2006, Kostik Belousov wrote:
On Wed, Jul 19, 2006 at 11:23:21AM -0300, User Freebsd wrote:
On Wed, 19 Jul 2006, Robert Watson wrote:
On Wed, 19 Jul 2006, User Freebsd wrote:
Also note that under FreeBSD 4.x, all three of these machines were pretty
much my more solid
On Wed, 19 Jul 2006, Robert Watson wrote:
On Wed, 19 Jul 2006, User Freebsd wrote:
Yes, this was going to be my next question -- if you're seeing wedges
under load and there's a common controller in use, maybe we're looking at
a driver bug. Bugs of those sort typically look a lot like what
On Wed, 19 Jul 2006, Scott Long wrote:
Now, uranus has all the various kernel debugging enabled right now, and a
serial console, so we're good for the debugging side of things ... and I
believe that I can fairly easily recreate the issue by just moving a
whack of vServers onto that machine to
:(
On Tue, 18 Jul 2006, User Freebsd wrote:
'k, had a bunch of fun tonight, but one of the results is that I was able to
achieve file system deadlock, or so it appears ...
Using the following from DDB:
set $lines=0
show pcpu
show allpcpu
ps
trace
alltrace
show locks
show alllocks
show uma
show
On Wed, 5 Jul 2006, Robert Watson wrote:
If you can get into DDB when the hang has occurred, output via serial console
for the following commands would be very helpful:
show pcpu
show allpcpu
ps
trace
traceall
show locks
show alllocks
show uma
show malloc
show lockedvnods
'k, after 16
On Sat, 15 Jul 2006, User Freebsd wrote:
On Wed, 5 Jul 2006, Robert Watson wrote:
If you can get into DDB when the hang has occurred, output via serial
console for the following commands would be very helpful:
show pcpu
show allpcpu
ps
trace
traceall
show locks
show alllocks
show uma
show
On Sat, 15 Jul 2006, Kostik Belousov wrote:
On Sat, Jul 15, 2006 at 12:10:29AM -0300, User Freebsd wrote:
On Wed, 5 Jul 2006, Robert Watson wrote:
If you can get into DDB when the hang has occurred, output via serial
console for the following commands would be very helpful:
show pcpu
show
On Mon, 10 Jul 2006, Patrick M. Hausen wrote:
Mornin'!
On Mon, Jul 10, 2006 at 12:11:36AM -0400, Mike Tancsa wrote:
Not sure what STP is
Spanning Tree Protocol. Having the link go up and down would cause
the switch port to block traffic for a period of time.
Of course, any reasonable
On Mon, 10 Jul 2006, Mike Tancsa wrote:
At 01:20 PM 08/07/2006, Ruslan Ermilov wrote:
Ah, I see. Thanks for the insight.
How about the attached patch?
I've been working on this problem for Mike Tancsa about a year ago,
and my fix was naive. I ended up not committing it because I found
On Sat, 8 Jul 2006, Michael Vince wrote:
I thought I remember a developer working on the em driver saying just
before 6.1 was released that this reset was needed and couldn't be
avoided to ensure performance of the device to work at its best, I can't
remember his explanation, but this topic
On Fri, 7 Jul 2006, Atanas wrote:
Robert Watson said the following on 7/7/06 7:17 AM:
I just left a tcpdump -n arp host 10.10.64.40 on a third machine
sniffing around and tested all em module versions I had (the stock 6.1,
6-STABLE and 6-STABLE with your patch), but got silence on all
On Wed, 5 Jul 2006, Robert Watson wrote:
On Wed, 5 Jul 2006, Danny Braniss wrote:
In my case our main servers are NetApp, and the problems are more related
to am-utils running into some race condition (need more time to debug this
:-) the other problem is related to throughput, freebsd is
On Wed, 5 Jul 2006, Michel Talon wrote:
So it may be relevant to say that i have kernels without IPV6 support.
Recall that i have absolutely no problem with the client in FreeBSD-6.1.
Tomorrow i will test one of the 6.1 machines as a NFS server and the other as
a client, and will make you know
On Wed, 5 Jul 2006, Francisco Reyes wrote:
Scott Long writes:
For what it's worth, I recently spent a lot of time putting FreeBSD 6.1
to the test as both an NFS client and server in a mixed OS environment.
I have a few debugging settings/suggestions that have been sent my way and I
plan to
machines.. as we loose customers
because of current problems with the 6.X line.
Since nobody except you experience that problems (at least, only you
notified
about the problem existence)
Did you miss the part of:
User Freebsd writes:
Since there are several of us experiencing what looks
This is the same issue that I've been hitting, and that requires the
serial console / DDB stuff described in the debugging deadlocks web page
that I pointed you at ...
So far *knock on wood* since adding all of the debugging to one of my
server, none of mine have done it ... but the more
On Sat, 1 Jul 2006, Francisco Reyes wrote:
John Hay writes:
I only started to see the lockd problems when upgrading the server side
to FreeBSD 6.x and later. I had various FreeBSD clients, between 4.x
and 7-current and the lockd problem only showed up when upgrading the
server from 5.x to
On Fri, 30 Jun 2006, Atanas wrote:
A workaround is to power both of the systems down and then power them up.
This however cannot be done remotely and in case there were IP aliases, they
still don't get any traffic.
see 'arping' ... great little tool, solved all my problems as far as
moving
On Thu, 29 Jun 2006, Robert Watson wrote:
On Wed, 28 Jun 2006, User Freebsd wrote:
On Wed, 28 Jun 2006, Robert Watson wrote:
On Wed, 28 Jun 2006, User Freebsd wrote:
Instead of changing your kernel config, edit the sio1 entries in
/boot/device.hints. (This assumes you left device sio
On Thu, 29 Jun 2006, Peter Jeremy wrote:
On Thu, 2006-Jun-29 17:30:07 +1000, Michael Vince wrote:
For me its IP alias additions take 1 or maybe 2secs, but it is
noticeable, but really isn't an issue for me.
But it obviously is for Atanas, who has 100's of aliases.
In my case, it isn't
On Thu, 29 Jun 2006, Francisco Reyes wrote:
Kostik Belousov writes:
Approved by:pjd (mentor)
Revision ChangesPath
1.156.2.3 +16 -0 src/sys/nfsserver/nfs_serv.c
1.136.2.3 +4 -0 src/sys/nfsserver/nfs_srvsubs.c
The above files are what I have.
Yes from a 6.1
On Thu, 29 Jun 2006, Francisco Reyes wrote:
Michel Talon writes:
Strange, since i upgraded to FreeBSD-6.1 and the NFS server to Fedora Core
5,
my machine, NFS client is happy, and lockd works.
What volume are we talking about?
My own problems and other reports I see are all under heavy
On Fri, 30 Jun 2006, Michael Vince wrote:
The thing that have to ask is if Atanas has 100's why can't he just boot
Freebsd have have them all prebound to the interface at startup, why
would you need to add and remove them constantly by the hundreds during
normal server uptime?
I do restart
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
'k, now that I'm up to 3 6-STABLE servers that are deadlocking, I'm
spending time with the remote tech today to get a serial console put
online ... how do I drop into DDB remotely, where the serial console is
going through a Portmaster Terminal server? issuing CTL-ALT-ESC, I doubt,
will
has anyone figured out why the em device 'hangs' for about 30-45 seconds
whenever you ifconfig alias a new IP on to the device?
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED]
Yahoo
Following hte instructions in the Handbook, I've added the following line
to my kernel config:
device sio1 at isa? port IO_COM2 flags 0x10 irq 3
but, when I try to build it:
config: /usr/src/sys/i386/conf/kernel:71: syntax error
*** Error code 1
so, obviously that is wrong for
On Wed, 28 Jun 2006, Robert Watson wrote:
On Wed, 28 Jun 2006, User Freebsd wrote:
'k, now that I'm up to 3 6-STABLE servers that are deadlocking, I'm
spending time with the remote tech today to get a serial console put online
... how do I drop into DDB remotely, where the serial console
On Wed, 28 Jun 2006, Robert Watson wrote:
On Wed, 28 Jun 2006, User Freebsd wrote:
Following hte instructions in the Handbook, I've added the following line
to my kernel config:
device sio1 at isa? port IO_COM2 flags 0x10 irq 3
but, when I try to build it:
config: /usr/src/sys/i386/conf
Just got this on the console of one of hte servers that has been causing
problems ...
Expensive timeout(9) function: 0xc0520e18(0xc8b223a0) 0.296959250 s
not a very informative error, and that is all that was there, nothing
before, nothing after ...
Marc G. Fournier Hub.Org
Oh, wait, does this have something to do with the Deadlock options I just
added to the kernel?
On Wed, 28 Jun 2006, User Freebsd wrote:
Just got this on the console of one of hte servers that has been causing
problems ...
Expensive timeout(9) function: 0xc0520e18(0xc8b223a0) 0.296959250
On Wed, 28 Jun 2006, Robert Watson wrote:
On Wed, 28 Jun 2006, User Freebsd wrote:
Instead of changing your kernel config, edit the sio1 entries in
/boot/device.hints. (This assumes you left device sio in your kernel --
if not, you need to re-add it).
'k, re-adding ... and I take
On Wed, 28 Jun 2006, Jonathan Noack wrote:
Please don't top-post...
User Freebsd wrote:
On Wed, 28 Jun 2006, User Freebsd wrote:
Just got this on the console of one of hte servers that has been causing
problems ...
Expensive timeout(9) function: 0xc0520e18(0xc8b223a0) 0.296959250 s
On Wed, 28 Jun 2006, Atanas wrote:
I have some newer machines with 2 Broadcom chips on-board. I plan to
give them a try at some point in the future, but I'm not sure how stable
the bge driver is when compared to fxp and em.
I'm using the bge driver on our new HP servers, and haven't noticed
46 matches
Mail list logo
