3ware 6xxx-series controllers and 6.9 firmware

2002-02-18 Thread Michael Smith
--- Blind-Carbon-Copy X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: [EMAIL PROTECTED] Subject: 3ware 6xxx-series controllers and 6.9 firmware Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 18 Feb 2002 03:35:32 -0800 From: Michael Smith [EMAIL PROTECTED]

Re: OK, who broke alpha this time? :-/

2002-02-18 Thread Peter Wemm
Bernd Walter wrote: On Sun, Feb 17, 2002 at 10:07:34PM -0800, Peter Wemm wrote: ... sio0 at port 0x3f8-0x3ff irq 4 on isa0 sio0: type 16550A, console sio0: interrupting at ISA irq 4 sio1: reserved for low-level i/o vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on

Re: A quick, dumb, question...

2002-02-18 Thread Terry Lambert
George V. Neville-Neil wrote: Is there a single document, or small set of documents, that describes getting started kernel hacking on FreeBSD? How about a set of URLs? I would like something that tells me about (in no particular order) 1) debugging over the serial line, and remote

Re: OK, who broke alpha this time? :-/

2002-02-18 Thread Bruce Evans
On Mon, 18 Feb 2002, Peter Wemm wrote: Actually, it appears to be rev 1.131 of kern/vfs_vnops.c (suggested by phk, that revision panics his i386 diskless boots). I guess vrele() gets done twice. See the big comment in vn_close() about when VOP_CLOSE() does a vrele(). Bruce To Unsubscribe:

Re: OK, who broke alpha this time? :-/

2002-02-18 Thread Daniel Eischen
And when is alpha buildworld going to work again? It's been busted for well over a week. The following patch posted by drew gets around the problem for now. If we want people to test changes on on the alpha, then we should try and make sure that world isn't broken for too long on it. I know

Re: OK, who broke alpha this time? :-/

2002-02-18 Thread Andrew Gallatin
Daniel Eischen writes: And when is alpha buildworld going to work again? It's been busted for well over a week. The following patch posted by Crap. . I'd forgotten all about that. I have a fix locally that I'll commit as soon as I can power on the machine. Peter I agreed not to

Re: OK, who broke alpha this time? :-/

2002-02-18 Thread Bernd Walter
On Mon, Feb 18, 2002 at 08:55:42AM -0500, Andrew Gallatin wrote: Daniel Eischen writes: And when is alpha buildworld going to work again? It's been busted for well over a week. The following patch posted by Crap. . I'd forgotten all about that. I have a fix locally that I'll

Re: OK, who broke alpha this time? :-/

2002-02-18 Thread Dominic Mitchell
On Sun, Feb 17, 2002 at 10:07:34PM -0800, Peter Wemm wrote: ... sio0 at port 0x3f8-0x3ff irq 4 on isa0 sio0: type 16550A, console sio0: interrupting at ISA irq 4 sio1: reserved for low-level i/o vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounter i8254

Re: OK, who broke alpha this time? :-/

2002-02-18 Thread Dominic Mitchell
On Mon, Feb 18, 2002 at 02:04:57PM +, Dominic Mitchell wrote: Just to confirm, I've just seen this on my i386 laptop (sony Z600TEK), too, which has a fresh cvsup and build from about 2.5 hours ago. Attached is a dmesg from my kernel.old which I've just manage to boot and a kernel config.

Shang Personally Invites you to Urban Comedy on the High Seas... Don't Miss It

2002-02-18 Thread information
Monday, February 18, 2002 Issue #1 3 Day Baja Mexico Cruise from Los AngelesApril 5-8, 20022 Nights of Urban Comedy1 Night with a Special Show Speedy Parties aboard the EcstasyExcursions in EnsenadaShang LuenellMike Bonner Rodney Perry Also Starring: Rip Da Playa Kirk

Re: OK, who broke alpha this time? :-/

2002-02-18 Thread Robert Watson
Oops. Mis-merge. Thanks to Ian for fixing this. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services On Sun, 17 Feb 2002, Peter Wemm wrote: ... sio0 at port 0x3f8-0x3ff irq 4 on isa0 sio0: type 16550A, console

Hangs with today's -CURRENT

2002-02-18 Thread David Wolfskill
Not entirely sure whether these hangs are related. First one (which I have been able to reproduce, and from which I invoked the debugger) is on my build machine, which is an SMP box: Mounting root from ufs:/dev/ad0s4a ad0s1: type 0xa5, start 63, end = 4192964, size 4192902 : OK ad0s2: type

Patch to improve mutex collision performance

2002-02-18 Thread Matthew Dillon
While testing some Giant removal stuff I noticed that my current system sometimes got into an extremely non-optimal flip-flop situation between two processes contesting Giant on an SMP system which halved the syscall performance in the test. In my getuid test, for example,

Re: Patch to improve mutex collision performance

2002-02-18 Thread David O'Brien
On Mon, Feb 18, 2002 at 11:12:16AM -0800, Matthew Dillon wrote: While testing some Giant removal stuff I noticed that my current system sometimes got into an extremely non-optimal flip-flop situation between two processes contesting Giant on an SMP system which halved the

Re: Patch to improve mutex collision performance

2002-02-18 Thread Matthew Dillon
:I request that you give say a 3 day review period for this. :I know JHB still has limited email access (no DSL yet). :This may be something he should review. Sigh. Are you intending to ask me to have JHB review every single change I make to -current? Because if you are the answer is:

Re: Patch to improve mutex collision performance

2002-02-18 Thread Julian Elischer
On Mon, 18 Feb 2002, Matthew Dillon wrote: [...] It turns out that the two processes got into an extremely non-optimal contested/sleep/wakeup situation, even though they do not actually have to sleep on Giant in this situation. The solution is to allow

Re: Patch to improve mutex collision performance

2002-02-18 Thread Bosko Milekic
On Mon, Feb 18, 2002 at 11:51:44AM -0800, Matthew Dillon wrote: :I request that you give say a 3 day review period for this. :I know JHB still has limited email access (no DSL yet). :This may be something he should review. Sigh. Are you intending to ask me to have JHB review every

Patch sets to date and timing tests with Giant out of userret.

2002-02-18 Thread Matthew Dillon
Here are my giant related patches to date. These are NOT all commit candidates. Some are just hacks to test Giant removal. Julian is responsible for the td_ucred persistance stuff. The hack in userret() is just a hack to remove Giant when no signals are present in order to

Re: Patch to improve mutex collision performance

2002-02-18 Thread Jake Burkholder
Apparently, On Mon, Feb 18, 2002 at 11:51:44AM -0800, Matthew Dillon said words to the effect of; :I request that you give say a 3 day review period for this. :I know JHB still has limited email access (no DSL yet). :This may be something he should review. I second this request.

Re: Patch to improve mutex collision performance

2002-02-18 Thread Matthew Dillon
: :I can't see any major problem with this but I can't help thinking that :there must be one.. on UP the question is: who is going to :release the lock if no-one is runnable? An interrupt, of course. Wakeups don't happen out of thin air! This is true of 1.x, 2.x, 3.x, 4.x, 5.x, UP,

Re: Patch to improve mutex collision performance

2002-02-18 Thread Matthew Dillon
: I've looked at it and I think it's OK. There are a few minor things I :could think of, but they are only related to the context-borrowing :interrupt stuff I'm working on in parallel (notably, when it goes in, :I'll modify the if () statement in there to add a check and only :perform the lazy

Re: Patch to improve mutex collision performance

2002-02-18 Thread Matthew Dillon
:What John's patch does is spin while the lock owner is running on another cpu. :Spinning while there are no other processes on the run queues as well makes sense :but you'll also be doing a lot of acquires and releases of sched_lock. : :The only thing that jumped out at me looking at the patch

Re: Patch to improve mutex collision performance

2002-02-18 Thread David O'Brien
On Mon, Feb 18, 2002 at 11:51:44AM -0800, Matthew Dillon wrote: :I request that you give say a 3 day review period for this. :I know JHB still has limited email access (no DSL yet). :This may be something he should review. Sigh. Are you intending to ask me to have JHB review every

Re: Patch to improve mutex collision performance

2002-02-18 Thread David O'Brien
On Mon, Feb 18, 2002 at 12:32:31PM -0800, Matthew Dillon wrote: People like to bitch and moan about my commits but, frankly, there isn't much to really bitch and moan about if you actually look at the commits. I really did not think I was bitching about your commit. I just thought

Re: Patch to improve mutex collision performance

2002-02-18 Thread Jake Burkholder
Apparently, On Mon, Feb 18, 2002 at 12:43:18PM -0800, Matthew Dillon said words to the effect of; :What John's patch does is spin while the lock owner is running on another cpu. :Spinning while there are no other processes on the run queues as well makes sense :but you'll also be

two panics with recent -CURRENT

2002-02-18 Thread Daniel Rock
Hi, during a make release run I got two panics in -CURRENT (from Feb 16). Both panics occured during high I/O rates. The first one occured while mkisofs'ing the resulting release CD tree, The second one while rm -rf RELEASEDIR. I am now running a kernel from Feb 08, which I believe is OK. I

Re: Patch to improve mutex collision performance

2002-02-18 Thread Julian Elischer
On Mon, 18 Feb 2002, Matthew Dillon wrote: : :I can't see any major problem with this but I can't help thinking that :there must be one.. on UP the question is: who is going to :release the lock if no-one is runnable? An interrupt, of course. Wakeups don't happen out of thin air!

Re: Patch to improve mutex collision performance

2002-02-18 Thread Matthew Dillon
: :Thanks. : : Ah, critnest... you are right. I should be checking for : critnest 1. : :I think you should just leave it alone, don't check critnest at all. :critnest != 1 is illegal because you can't acquire a sleep lock while :in an enclosing critical section. : :Jake Hmm. It locks

Re: Patch to improve mutex collision performance

2002-02-18 Thread Matthew Dillon
: : :can you detail in more clarity the flip-flopping you were seeing? : : Basically what is happening is that switch/wakeup overhead is being : imposed unnecessarily. There is no need to switch if there is nothing : to switch to, and this also causes the other process to not have

/bin/sh: Argument list too long when compiling LINT ...

2002-02-18 Thread Luigi Rizzo
Hi, I am getting a /bin/sh: Argument list too long error message when doing env MKDEP_CPP=cc -E CC=cc mkdep -a -f .newdep ... while compiling LINT on a -current tree. Sources are in /home/xorpc/u2/homes/rizzo/HEAD/src/sys which contributes a bit to the size of the argument

Re: /bin/sh: Argument list too long when compiling LINT ...

2002-02-18 Thread M. Warner Losh
In message: [EMAIL PROTECTED] Luigi Rizzo [EMAIL PROTECTED] writes: : Any idea on how to fix this ? Use a smaller path. Or dig up bde's fixes to config from the archives. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the

Re: Patch sets to date and timing tests with Giant out of userret.

2002-02-18 Thread Peter Wemm
Matthew Dillon wrote: - mtx_lock(Giant); - td-td_retval[0] = p-p_ucred-cr_ruid; + s = mtx_lock_giant(kern_giant_ucred); + td-td_retval[0] = td-td_ucred-cr_ruid; #if defined(COMPAT_43) || defined(COMPAT_SUNOS) - td-td_retval[1] = p-p_ucred-cr_uid; + td-td_retval[1]

Re: Patch sets to date and timing tests with Giant out of userret.

2002-02-18 Thread Matthew Dillon
: -mtx_lock(Giant); : -td-td_retval[0] = p-p_ucred-cr_ruid; : +s = mtx_lock_giant(kern_giant_ucred); : +td-td_retval[0] = td-td_ucred-cr_ruid; : #if defined(COMPAT_43) || defined(COMPAT_SUNOS) : -td-td_retval[1] = p-p_ucred-cr_uid; : +td-td_retval[1] = td-td_ucred-cr_uid;

Re: Patch sets to date and timing tests with Giant out of userret.

2002-02-18 Thread Peter Wemm
Matthew Dillon wrote: : - mtx_lock(Giant); : - td-td_retval[0] = p-p_ucred-cr_ruid; : + s = mtx_lock_giant(kern_giant_ucred); : + td-td_retval[0] = td-td_ucred-cr_ruid; : #if defined(COMPAT_43) || defined(COMPAT_SUNOS) : - td-td_retval[1] = p-p_ucred-cr_uid; : + td-td_retval[1] =

Re: Patch sets to date and timing tests with Giant out of userret.

2002-02-18 Thread Peter Wemm
Peter Wemm wrote: Matthew Dillon wrote: : -mtx_lock(Giant); : -td-td_retval[0] = p-p_ucred-cr_ruid; : +s = mtx_lock_giant(kern_giant_ucred); : +td-td_retval[0] = td-td_ucred-cr_ruid; : #if defined(COMPAT_43) || defined(COMPAT_SUNOS) : -

Re: Patch sets to date and timing tests with Giant out of userret.

2002-02-18 Thread Matthew Dillon
: :So, John's last few months of work is junk then, is it? : :Cheers, :-Peter :-- :Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] I'll tell you what is junk... patches for things like getuid() sitting in P4 (whether instrumented or not). That's junk. I'll tell

Re: Patch sets to date and timing tests with Giant out of userret.

2002-02-18 Thread Matthew Dillon
:Regarding the instrumentation of Giant for *trivial* stuff like this: I'm :one of the people you called bozos that disagrees with you about the :usefulness of bloating the source with this stuff that only needs to be :removed again later. : :Cheers, :-Peter :-- :Peter Wemm - [EMAIL PROTECTED];

Re: Patch sets to date and timing tests with Giant out of userret.

2002-02-18 Thread Peter Wemm
Matthew Dillon wrote: : :So, John's last few months of work is junk then, is it? : :Cheers, :-Peter :-- :Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] I'll tell you what is junk... patches for things like getuid() sitting in P4 (whether instrumented or

Re: Patch sets to date and timing tests with Giant out of userret.

2002-02-18 Thread Julian Elischer
The fully safe version of this code is: td-td_retval[0] = td-td_ucred-cr_ruid; td-td_retval[1] = td-td_ucred-cr_uid; return (0); because td-td_ucred is read-only for it's whole existance. Also, it's not worth arguing about this when Jouhn's not here.. and when he is it's better offline..

Re: Patch sets to date and timing tests with Giant out of userret.

2002-02-18 Thread Julian Elischer
I'd prefer to be working on a branch of CVS if it weren't for the people that would scream whenever I moved my merged tag up. (eek eek cvsup bloat). That way i would have a dozen people helping me but with my code in P4 I have me and occasionally Peter. P4 is ok but it's strangling me because

Re: Patch sets to date and timing tests with Giant out of userret.

2002-02-18 Thread Peter Wemm
Julian Elischer wrote: I'd prefer to be working on a branch of CVS if it weren't for the people that would scream whenever I moved my merged tag up. (eek eek cvsup bloat). That way i would have a dozen people helping me but with my code in P4 I have me and occasionally Peter. Everybody who

Re: Patch sets to date and timing tests with Giant out of userret.

2002-02-18 Thread Terry Lambert
Julian Elischer wrote: The fully safe version of this code is: td-td_retval[0] = td-td_ucred-cr_ruid; td-td_retval[1] = td-td_ucred-cr_uid; return (0); because td-td_ucred is read-only for it's whole existance. ??? Are you sure that td-td_ucred can't change in the middle, to point to a