Steven Hartland wrote:
> With the patch things are MUCH better. No problems to report and
> the server is under major load including some heavy disk access as
Yeah, no problems here either, so far.
mkb.
___
freebsd-stable@freebsd.org mailing list
http:
- Original Message -
From: "Kris Kennaway" <[EMAIL PROTECTED]>
Jeff said he'll merge it in a week or two after it's been well-tested.
Been running it here on our ftp which was getting major issues with
disk access spiking "system" usage to 90+% making the server totally
unresponsive fo
On Sat, Jun 11, 2005 at 09:52:13PM +0200, Matthias Buelow wrote:
> I wrote:
> > Kris Kennaway wrote:
> >> http://www.chesapeake.net/~jroberson/flushbuf.diff
> >>Does it work for you on 5.4?
> > The patch seems to work. Cool, that makes a difference like between
>
> BTW., is that change being incl
I wrote:
> Kris Kennaway wrote:
>> http://www.chesapeake.net/~jroberson/flushbuf.diff
>>Does it work for you on 5.4?
> The patch seems to work. Cool, that makes a difference like between
BTW., is that change being included in 5-STABLE or just for 6-CURRENT?
mkb.
_
Kris Kennaway wrote:
> http://www.chesapeake.net/~jroberson/flushbuf.diff
> Does it work for you on 5.4?
The patch seems to work. Cool, that makes a difference like between
night and day. I can't determine any observable effect of untarring the
firefox source anymore to interactive response tim
On Thu, May 26, 2005 at 02:15:54AM +0200, Matthias Buelow wrote:
>
> >>Others don't see this though, and in other cases it was *definitively
> >>proven* to be caused by the issue I mentioned. I'll have to think
> >>more about what to try next..thanks for running the tests.
> >
> >Perhaps it's som
On 5/26/05, Matthias Buelow <[EMAIL PROTECTED]> wrote:
>
> >> Others don't see this though, and in other cases it was *definitively
> >> proven* to be caused by the issue I mentioned. I'll have to think
> >> more about what to try next..thanks for running the tests.
> >
> > Perhaps it's something
Others don't see this though, and in other cases it was *definitively
proven* to be caused by the issue I mentioned. I'll have to think
more about what to try next..thanks for running the tests.
Perhaps it's something SATA-related?
Before restoring my 5.4 dumps after testing -current, I ins
On Wed, May 25, 2005 at 04:02:58PM -0700, Jon Dama wrote:
> It's different, yes. But the trouble is that you need a controlled
> interrupt source--i.e., you have to have some concept of when an "event"
> might have been handled (were it not for such and such activity).
>
> I posit that without th
It's different, yes. But the trouble is that you need a controlled
interrupt source--i.e., you have to have some concept of when an "event"
might have been handled (were it not for such and such activity).
I posit that without that counterfactual talking about PREEMPTION is
meaningless.
The tech
On Wed, May 25, 2005 at 03:33:39PM -0700, Jon Dama wrote:
> Could this be quantified by setting up a synthetic experiement:
>
> 1) one machine uses dummynet to generate a uniform packet/sec stream
> 2) another machine has a process receiving those packets and recording
>their arrival relative
Could this be quantified by setting up a synthetic experiement:
1) one machine uses dummynet to generate a uniform packet/sec stream
2) another machine has a process receiving those packets and recording
their arrival relative to the local TSC. afaik, the TSC is the only
source of wall-time
On Thu, May 26, 2005 at 12:14:35AM +0200, Bjarne Wichmann Petersen wrote:
> On Wednesday 25 May 2005 23:45, Kris Kennaway wrote:
> > On Wed, May 25, 2005 at 11:42:01PM +0200, Bjarne Wichmann Petersen wrote:
> > > I've had PREEMTION enabled in 5-STABLE for at couple of month and had the
> > > opposi
On Wednesday 25 May 2005 23:45, Kris Kennaway wrote:
> On Wed, May 25, 2005 at 11:42:01PM +0200, Bjarne Wichmann Petersen wrote:
> > I've had PREEMTION enabled in 5-STABLE for at couple of month and had the
> > opposite experience. Eg. when clicking on a file in a fileselector (I'm
> > using KDE) i
On Wed, May 25, 2005 at 11:42:01PM +0200, Bjarne Wichmann Petersen wrote:
> On Monday 23 May 2005 23:36, Kris Kennaway wrote:
>
> > Also try defining PREEMPTION in your kernel on 5.x and above (if you
> > are running i386 or amd64). There have been very occasional reports
> > of panics with this
On Monday 23 May 2005 23:36, Kris Kennaway wrote:
> Also try defining PREEMPTION in your kernel on 5.x and above (if you
> are running i386 or amd64). There have been very occasional reports
> of panics with this option enabled (although I use it everywhere and
> have not seen problems on my heav
Kris Kennaway wrote:
Others don't see this though, and in other cases it was *definitively
proven* to be caused by the issue I mentioned. I'll have to think
more about what to try next..thanks for running the tests.
Perhaps it's something SATA-related?
mkb.
__
On Wed, May 25, 2005 at 06:44:37PM +0200, Matthias Buelow wrote:
> Kris Kennaway wrote:
>
> >>interrupt total rate
> >>irq1: atkbd0 586 0
> >>irq13: npx01 0
> >>irq14: ata0
somehow? Maybe I should try and see if the problem persists with the
ULE scheduler?
No difference with ULE, with the default parameters:
kern.sched.name: ule
kern.sched.slice_min: 10
kern.sched.slice_max: 142
kern.sched.preemption: 1
mkb.
___
freebs
Kris Kennaway wrote:
interrupt total rate
irq1: atkbd0 586 0
irq13: npx01 0
irq14: ata0 94 0
irq17: wi054 0
irq20: fxp0 ata
Krzysztof Kowalik [EMAIL PROTECTED] wrote:
> [...]
> cvsup-ing current 6.0-CURRENT right now, to check the giantless VFS once
> again. It will probably take an hour to get it up and running.
Unfortunately, 6.0-CURRENT didn't help at all.
FreeBSD 6.0-CURRENT #0: Wed May 25 13:24:30 CEST 2005
[...
Krzysztof Kowalik [EMAIL PROTECTED] wrote:
> [...]
> I will try to put my hands on the mentioned AMD box once again, to run
> some current 6.0 on it.
OK, got the box. I ran a 5.4-RELEASE, identical (as I just restored
dumps of my current workstation on it) as the one not giving problems on
Intel-
Kris Kennaway wrote:
I wonder if USB is causing the problem all on its own..since that was
the culprit in other situations when it was being triggered by virtue
of interrupt sharing. Any chance you can try a non-USB mouse and
remove USB from your kernel?
Yes, I'll try that later.
mkb.
__
On Wed, May 25, 2005 at 07:26:31AM +0200, Matthias Buelow wrote:
> Kris Kennaway wrote:
>
> >Show me vmstat -i now.
>
> interrupt total rate
> irq1: atkbd0 586 0
> irq13: npx01 0
> irq14: ata0
Kris Kennaway wrote:
Show me vmstat -i now.
interrupt total rate
irq1: atkbd0 586 0
irq13: npx01 0
irq14: ata0 94 0
irq17: wi054
On Wed, May 25, 2005 at 07:17:53AM +0200, Matthias Buelow wrote:
> Kris Kennaway wrote:
>
> >>I've now disabled the sound chip in the BIOS, no change.
> >But is the driver still attaching?
>
> No, and I now have disabled loading the module at boot aswell. Still no
> difference. I would also th
Kris Kennaway wrote:
I've now disabled the sound chip in the BIOS, no change.
But is the driver still attaching?
No, and I now have disabled loading the module at boot aswell. Still no
difference. I would also think that if that were the cause, the
situation would be a lot worse on the no
On Wed, May 25, 2005 at 06:51:52AM +0200, Matthias Buelow wrote:
> Kris Kennaway wrote:
>
> >>irq11: cbb0 cbb1++* 373638 12
> >What else is on irq11?
>
> Hmm.. uhm!
>
> uhci0, pcm0, fxp0 and wi0... :-}
>
> Is the "++*" thing notation for "there's more stuff but I won't sh
On Wed, May 25, 2005 at 06:55:40AM +0200, Matthias Buelow wrote:
> Kris Kennaway wrote:
>
> >I think it's your mouse fighting with your sound card for Giant.
>
> I've now disabled the sound chip in the BIOS, no change.
But is the driver still attaching?
Kris
pgp55i58bFJOT.pgp
Description: PGP
Kris Kennaway wrote:
I think it's your mouse fighting with your sound card for Giant.
I've now disabled the sound chip in the BIOS, no change.
mkb.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
Kris Kennaway wrote:
irq11: cbb0 cbb1++* 373638 12
What else is on irq11?
Hmm.. uhm!
uhci0, pcm0, fxp0 and wi0... :-}
Is the "++*" thing notation for "there's more stuff but I won't show you"?
mkb.
___
freebsd-stable@free
On Wed, May 25, 2005 at 06:38:59AM +0200, Matthias Buelow wrote:
> Kris Kennaway wrote:
>
> >I think it's your mouse fighting with your sound card for Giant.
>
> And why does it also happen (if not as badly but still) on my notebook
> where there's no such conflict?
>
> interrupt
Kris Kennaway wrote:
I think it's your mouse fighting with your sound card for Giant.
And why does it also happen (if not as badly but still) on my notebook
where there's no such conflict?
interrupt total rate
irq0: clk2959195 9
On Wed, May 25, 2005 at 06:20:55AM +0200, Matthias Buelow wrote:
> Joseph Koshy wrote:
>
> >You may want to try without options WITNESS, INVARIANTS and
> >INVARIANT_SUPPORT.
>
> Ok, I've done this. Symptoms are now about equal to 5.4-STABLE.
I think it's your mouse fighting with your sound card
Joseph Koshy wrote:
You may want to try without options WITNESS, INVARIANTS and
INVARIANT_SUPPORT.
Ok, I've done this. Symptoms are now about equal to 5.4-STABLE.
mkb.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/l
Kris Kennaway wrote:
pcm0 and uhci3 share an interrupt on your system, and both are under
Giant, so they'll fight over it when one receives an interrupt, and
nothing else can run in the kernel when that is happening. Do you
need USB support? If not, get rid of it.
Well.. the USB mouse needs
On Wed, May 25, 2005 at 05:45:29AM +0200, Matthias Buelow wrote:
Once you remove the debugging options..
> uhci3: [GIANT-LOCKED]
> pcm0: [GIANT-LOCKED]
> interrupt total rate
> irq1: atkbd01856 1
> irq13: npx0
On Wed, May 25, 2005 at 05:45:29AM +0200, Matthias Buelow wrote:
> Kris Kennaway wrote:
>
> >OK, thanks for confirming. The next step is for you to try 6.0 with
> >debug.mpsafevfs=1 on a machine that exhibits the problem under 5.4, so
> >we can test whether the problem is caused by VFS being unde
> FreeBSD 6.0-CURRENT #0: Wed May 25 05:00:48 CEST 2005
> [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
> WARNING: WITNESS option enabled, expect reduced performance.
WITNESS will cause terrible slowdowns.
You may want to try without options WITNESS, INVARIANTS and
INVARIANT_SUPPORT.
--
Kris Kennaway wrote:
OK, thanks for confirming. The next step is for you to try 6.0 with
debug.mpsafevfs=1 on a machine that exhibits the problem under 5.4, so
we can test whether the problem is caused by VFS being under Giant on
5.4.
I have now built 6.0-current from yesterday's source, veri
On Tue, May 24, 2005 at 11:50:07PM +0200, Matthias Buelow wrote:
> Kris Kennaway wrote:
>
> >>Hmm... atapci1 is shared with fxp0 on irq 20.. does fxp0 also require
> >>the giant lock?
> >
> >I don't think so..but the shared interrupt might still be causing some
> >other problem. Try compiling a k
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, May 24, 2005 at 05:23:59PM -0400, Lowell Gilbert wrote:
> Scott Robbins <[EMAIL PROTECTED]> writes:
>
> > True, but in general, having gotten used to LINT, usually, I would just
> > check notes for syntax--for instance, I might see something a
Kris Kennaway wrote:
Hmm... atapci1 is shared with fxp0 on irq 20.. does fxp0 also require
the giant lock?
I don't think so..but the shared interrupt might still be causing some
other problem. Try compiling a kernel without fxp support and see if
you still have the interactive problems under
Matthias Buelow wrote:
Scott Robbins wrote:
Judging from the forums and various other things, it seems that a lot of
people aren't aware of the second NOTES file. (Of course, you can do
make LINT while in /conf, which I blush to admit, is what I did
before I realized the existance of the seco
Scott Robbins <[EMAIL PROTECTED]> writes:
> True, but in general, having gotten used to LINT, usually, I would just
> check notes for syntax--for instance, I might see something about
> PREEMPTION and just do (while in i386/conf) grep PREEMPT NOTES.
Don't forget sys/conf/NOTES, either. [which
Kris Kennaway [EMAIL PROTECTED] wrote:
> > I didn't see any visible difference, in the given scenario of
> > uncompressing firefox's sources, when tried mpsafevfs's patches when
> > they got announced on [EMAIL PROTECTED]
> There have been a *lot* of changes in this area since the initial
> patches
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, May 24, 2005 at 12:27:21PM -0700, Freddie Cash wrote:
> On May 24, 2005 12:14 pm, Scott Robbins wrote:
>
> > > The other is for items that apply to all CPU architectures, and is
> > > located at /usr/src/sys/conf/NOTES.
>
> > > You have to re
On Tue, May 24, 2005 at 10:23:28PM +0200, Matthias Buelow wrote:
> Kris Kennaway wrote:
>
> > But are any IRQs shared?
>
> Hmm... atapci1 is shared with fxp0 on irq 20.. does fxp0 also require
> the giant lock?
I don't think so..but the shared interrupt might still be causing some
other problem.
Kris Kennaway wrote:
> But are any IRQs shared?
Hmm... atapci1 is shared with fxp0 on irq 20.. does fxp0 also require
the giant lock?
mkb.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscri
On Tue, May 24, 2005 at 10:18:54PM +0200, Matthias Buelow wrote:
> Max Laier wrote:
>
> > I have seen this on my box. Disabling one of the USB-ports solved the
> > problem. I was seeing very high IRQ-rates. Check $vmstat -i during the
> > process to see if you have abnormal high rate jumps.
Max Laier wrote:
> I have seen this on my box. Disabling one of the USB-ports solved the
> problem. I was seeing very high IRQ-rates. Check $vmstat -i during the
> process to see if you have abnormal high rate jumps. It might be that we
> must investigate some of our drivers to play nice wi
On Tue, May 24, 2005 at 09:41:29PM +0200, Max Laier wrote:
> On Monday 23 May 2005 23:21, Matthias Buelow wrote:
> > Kris Kennaway wrote:
> > > One thing that probably confuses and misleads a lot of people is when
> > > they build world or a kernel and notice that it's taking much longer
> > > than
On Monday 23 May 2005 23:21, Matthias Buelow wrote:
> Kris Kennaway wrote:
> > One thing that probably confuses and misleads a lot of people is when
> > they build world or a kernel and notice that it's taking much longer
> > than it did under 4.x, so they assume this means that 5.x is slower
> > t
On May 24, 2005 12:14 pm, Scott Robbins wrote:
> On Tue, May 24, 2005 at 12:07:35PM -0700, Freddie Cash wrote:
> > There are two NOTES files for each CPU architecture.
> > One is for the CPU architecture dependent items and is located
> > at /usr/src/sys//conf/NOTES Just replace with the CPU
> >
Scott Robbins wrote:
> Judging from the forums and various other things, it seems that a lot of
> people aren't aware of the second NOTES file. (Of course, you can do
> make LINT while in /conf, which I blush to admit, is what I did
> before I realized the existance of the second NOTES file. :)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, May 24, 2005 at 12:07:35PM -0700, Freddie Cash wrote:
>
> There are two NOTES files for each CPU architecture.
>
> One is for the CPU architecture dependent items and is located
> at /usr/src/sys//conf/NOTES Just replace with the CPU
> ar
On Tue, May 24, 2005 at 08:39:23PM +0200, martinko wrote:
> Kris Kennaway wrote:
> >
> >Also try defining PREEMPTION in your kernel on 5.x and above (if you
> >are running i386 or amd64). There have been very occasional reports
> >of panics with this option enabled (although I use it everywhere an
On May 24, 2005 11:39 am, martinko wrote:
> Kris Kennaway wrote:
> > Also try defining PREEMPTION in your kernel on 5.x and above (if you
> > are running i386 or amd64). There have been very occasional reports
> > of panics with this option enabled (although I use it everywhere and
> > have not se
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It's in /usr/src/sys/conf/NOTES.
I think this is due to it being an architecture independent option.
- --
Regards, Pedro.
martinko wrote:
> Kris Kennaway wrote:
>
>>
>> Also try defining PREEMPTION in your kernel on 5.x and above (i
Kris Kennaway wrote:
Also try defining PREEMPTION in your kernel on 5.x and above (if you
are running i386 or amd64). There have been very occasional reports
of panics with this option enabled (although I use it everywhere and
have not seen problems on my heavily loaded machines), but interacti
On May 24, 2005 09:32 am, you wrote:
> Freddie Cash wrote:
> > The laptop has an ATI IXP chipset, which means the HD is detected and
> > run as a generic UDMA33 device. The kernel is using the 4BSD
> > scheduler with PREEMPTION enabled, all debugging hints disabled, and
> > all the mpsafe sysctls
On Tue, May 24, 2005 at 06:32:28PM +0200, Matthias Buelow wrote:
> Freddie Cash wrote:
>
> > The laptop has an ATI IXP chipset, which means the HD is detected and run
> > as a generic UDMA33 device. The kernel is using the 4BSD scheduler with
> > PREEMPTION enabled, all debugging hints disabled
Freddie Cash wrote:
> The laptop has an ATI IXP chipset, which means the HD is detected and run
> as a generic UDMA33 device. The kernel is using the 4BSD scheduler with
> PREEMPTION enabled, all debugging hints disabled, and all the mpsafe
> sysctls enabled.
Hmm.. maybe the disk (interface)
On May 23, 2005 02:31 pm, Kris Kennaway wrote:
> On Mon, May 23, 2005 at 11:21:13PM +0200, Matthias Buelow wrote:
> > Another thing might be that interactive response time seems to be
> > worse. While I (or rather ports) unpack the firefox/thunderbird
> > source, the machine is pretty much bogged d
On Tue, May 24, 2005 at 04:37:26PM +0200, Krzysztof Kowalik wrote:
> Kris Kennaway [EMAIL PROTECTED] wrote:
> > [...] One obvious guess is that it's due to VFS being under Giant,
> > which causes lots of contention with other subsystems that also
> > require Giant, and therefore introduces latency
Kris Kennaway [EMAIL PROTECTED] wrote:
> [...] One obvious guess is that it's due to VFS being under Giant,
> which causes lots of contention with other subsystems that also
> require Giant, and therefore introduces latency. If so, you'd see a
> substantial performance improvement on 6.0 with deb
On May 23, 2005, at 3:51 PM, Kris Kennaway wrote:
actually benchmarked this on the package build machines, and found
that 5.4 outperforms 4.11 by at least 10% when performing identical
workloads on identical UP hardware :-)
I have a pair of twin dual opteron boxes built about 1 month apart.
Kris Kennaway wrote:
> Also try defining PREEMPTION in your kernel on 5.x and above (if you
> are running i386 or amd64). There have been very occasional reports
> of panics with this option enabled (although I use it everywhere and
> have not seen problems on my heavily loaded machines), but int
On Mon, May 23, 2005 at 02:31:55PM -0700, Kris Kennaway wrote:
> On Mon, May 23, 2005 at 11:21:13PM +0200, Matthias Buelow wrote:
> > Kris Kennaway wrote:
> >
> > > One thing that probably confuses and misleads a lot of people is when
> > > they build world or a kernel and notice that it's taking
On Mon, May 23, 2005 at 11:21:13PM +0200, Matthias Buelow wrote:
> Kris Kennaway wrote:
>
> > One thing that probably confuses and misleads a lot of people is when
> > they build world or a kernel and notice that it's taking much longer
> > than it did under 4.x, so they assume this means that 5.x
Kris Kennaway wrote:
> One thing that probably confuses and misleads a lot of people is when
> they build world or a kernel and notice that it's taking much longer
> than it did under 4.x, so they assume this means that 5.x is slower
> than 4.x. It doesn't. What it means is that 5.x and 4.x have
On Mon, May 23, 2005 at 05:00:13PM -0400, Mike Jakubik wrote:
> On Mon, May 23, 2005 3:51 pm, Kris Kennaway said:
>
> > The common wisdom has been that FreeBSD 4.11 is faster than 5.4 on
> > single processor systems. Imagine my surprise when I went and actually
> > benchmarked this on the package
On Mon, May 23, 2005 3:51 pm, Kris Kennaway said:
> The common wisdom has been that FreeBSD 4.11 is faster than 5.4 on
> single processor systems. Imagine my surprise when I went and actually
> benchmarked this on the package build machines, and found that 5.4
> outperforms 4.11 by at least 10% w
On Mon, May 23, 2005 at 03:21:32PM -0400, Mike Jakubik wrote:
> Could someone point me to a resource that outlines the expected supported
> lifetime of all the branches? Can't find anything concrete on the webpage.
>
> I'm developing a product, which i hope will run on FreeBSD. However the
> rapid
74 matches
Mail list logo
