Re: 6.1-STABLE hangs, ddb shows 'acpi_timer_read'?
--On 20 October 2006 13:47 +0100 Robert Watson [EMAIL PROTECTED] wrote: I'm just a little hesitant to put it all in, and end up with a machine that's 80% slower :( Depends a lot on your workload. WITNESS used to really, really slow things down for kernel lock intensive workloads (VFS especially); now it just really slows things down. INVARIANTS overhead is generally measurable, but for most workloads it is likely 20%. The place INVARIANTS hits you is when the kernel is allocating and freeing lots of memory, during which INVARIANTS will be scrubbing and checking for use after free, etc. It's worth running with WITNESS when debugging deadlocks if possible, because it is, essentially, a deadlock debugging tool. A moderate number of people run with INVARIANTS in production, but you generally don't want to do that with WITNESS. Well this is happening on an almost daily basis for me, so I threw everything in. I'd rather have lousy performance for a couple of days - and get all the info needed to fix the problem, than fsck a terrabyte, and mop up after a hung machine daily ;) Thanks for the replies, crossing fingers now :) -Karl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: scheduler CORE for RELENG_6
On Tuesday 24 October 2006 17:31, Stepan A. Baranov wrote: Hello, I prepared patch to port scheduler from HEAD to RELENG_6. I applied this patch for my workstation and scheduler CORE works fine. After applying patch you can say: options SCHED_CORE # CORE scheduler in your KERN CONF file and rebuild your kernel. Please, test it and fix it. Stepan Baranov. Thanks, but I feel the scheduler is still very experiment, there are lots of work to do, I would not like to see it in RELENG_6 and cause lots of questions which I am not ready to answer, I am finding spare time to work on it again. ;-) Regards, David Xu ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: src.conf(5) seems to affect ports build
On Sun, 2006-10-22 at 17:34 +0200, Jeremie Le Hen wrote:
Ruslan,
On Sat, Oct 21, 2006 at 09:25:33PM +0400, Ruslan Ermilov wrote:
Also, your patch avoids performing the WITH(OUT)_* stuff for ports in
order to prevent from polluting the namespace. If there is to be
some WITH(OUT)_* knobs which leads to CFLAGS modification in the future
(I'm thinking about ProPolice with the upcoming GCC 4.1), wouldn't it
be worth benefiting this framework for ports ?
It avoids only /etc/src.conf stuff when running bsd.port.mk; if you put
WITH(OUT)_* in /etc/make.conf it will still be picked up.
Yes indeed, but MK_FOO won't be set and this would require to either
duplicate the code that modifies CFLAGS, or at least test for MK_FOO
or WITH_FOO at the same time.
Let me show you an example.
I have an additional bsd.ssp.mk that is included from both bsd.sys.mk
and bsd.port.mk:
% .if ${MK_SSP} != no
% SSP_CFLAGS ?= -fstack-protector
% CFLAGS += ${SSP_CFLAGS}
% . if defined(WARNS) ${WARNS} = 7 !empty(SSP_CFLAGS)
% CWARNFLAGS += -Wstack-protector
% . endif
% .endif
Currently it is thus quite useful to use MK_SSP when this file is
included from bsd.ports.mk. With your whole patch I would have to
either duplicate these bits in bsd.ports.mk or turn the condition to
something like:
% .if (defined(MK_SSP) ${MK_SSP} != no) || defined(WITH_SSP)
What do you advice me to do ?
Duplicate it in make.conf at the moment. When prime time comes, send a
patch against bsd.port.mk to set CFLAGS accordingly when WITH_SSP is
set.
I don't know if this will be accepted, but it certainly is better than
having src.conf influence bsd.port.mk.
--
Florent Thoumie
[EMAIL PROTECTED]
FreeBSD Committer
signature.asc
Description: This is a digitally signed message part
Re: scheduler CORE for RELENG_6
David Xu writes: On Tuesday 24 October 2006 17:31, Stepan A. Baranov wrote: Hello, I prepared patch to port scheduler from HEAD to RELENG_6. I applied this patch for my workstation and scheduler CORE works fine. After applying patch you can say: options SCHED_CORE # CORE scheduler in your KERN CONF file and rebuild your kernel. Please, test it and fix it. Stepan Baranov. Thanks, but I feel the scheduler is still very experiment, there are lots of work to do, I would not like to see it in RELENG_6 and cause lots of questions which I am not ready to answer, I am finding spare time to work on it again. ;-) Really? I've been using it since it was introduced and find it to be quite good on my dual-core AMD64 machine running in i386 mode. --- Gary Jennejohn / garyjATjennejohnDOTorg gjATfreebsdDOTorg garyjATdenxDOTde ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: scheduler CORE for RELENG_6
Gary Jenneohn wrote: Really? I've been using it since it was introduced and find it to be quite good on my dual-core AMD64 machine running in i386 mode. Any benchmarks, or description of what's improved? :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: src.conf(5) seems to affect ports build
On Sun, Oct 22, 2006 at 05:34:36PM +0200, Jeremie Le Hen wrote:
Ruslan,
On Sat, Oct 21, 2006 at 09:25:33PM +0400, Ruslan Ermilov wrote:
Also, your patch avoids performing the WITH(OUT)_* stuff for ports in
order to prevent from polluting the namespace. If there is to be
some WITH(OUT)_* knobs which leads to CFLAGS modification in the future
(I'm thinking about ProPolice with the upcoming GCC 4.1), wouldn't it
be worth benefiting this framework for ports ?
It avoids only /etc/src.conf stuff when running bsd.port.mk; if you put
WITH(OUT)_* in /etc/make.conf it will still be picked up.
Yes indeed, but MK_FOO won't be set and this would require to either
duplicate the code that modifies CFLAGS, or at least test for MK_FOO
or WITH_FOO at the same time.
Let me show you an example.
I have an additional bsd.ssp.mk that is included from both bsd.sys.mk
and bsd.port.mk:
% .if ${MK_SSP} != no
% SSP_CFLAGS ?= -fstack-protector
% CFLAGS += ${SSP_CFLAGS}
% . if defined(WARNS) ${WARNS} = 7 !empty(SSP_CFLAGS)
% CWARNFLAGS += -Wstack-protector
% . endif
% .endif
Currently it is thus quite useful to use MK_SSP when this file is
included from bsd.ports.mk. With your whole patch I would have to
either duplicate these bits in bsd.ports.mk or turn the condition to
something like:
% .if (defined(MK_SSP) ${MK_SSP} != no) || defined(WITH_SSP)
What do you advice me to do ?
I still don't understand why my patch created a problem for you.
This option is not in bsd.own.mk, so it's not covered by my patch.
All my patch does is don't process /etc/src.conf which is entirely
for src/.
So, you can continue to use your bsd.ssp.mk as before, and my patch
shouldn't influence it.
If you want to really mimic the standard behavior, then bsd.ssp.mk
should check the (WITH|WITHOUT)_SSP set by a user, and set MK_SSP
to yes/no, accordingly; setting MK_SSP by a user shouldn't be
allowed or supported. You then set WITH_SSP= in /etc/make.conf
(or in /etc/src.conf if you want it only for src/), or pass
-DWITH_SSP on the make command line, and you're done.
P.S. There has been a patch floating around that adds support for
/etc/ports.conf. That would allow for clear separation:
src.confsrc/ only settings;
ports.conf ports/ only settings;
make.conf all-time settings, including when building
src/ and ports/.
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
pgpABFizcnWOK.pgp
Description: PGP signature
Re: scheduler CORE for RELENG_6
Ivan Voras writes: Gary Jenneohn wrote: Really? I've been using it since it was introduced and find it to be quite good on my dual-core AMD64 machine running in i386 mode. Any benchmarks, or description of what's improved? :) No. I can only say that it doesn't feel any worse than SCHED_4BSD to me. Totally subjective, of course. --- Gary Jennejohn / garyjATjennejohnDOTorg gjATfreebsdDOTorg garyjATdenxDOTde ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: src.conf(5) seems to affect ports build
On Tue, 2006-10-24 at 17:48 +0400, Ruslan Ermilov wrote:
On Sun, Oct 22, 2006 at 05:34:36PM +0200, Jeremie Le Hen wrote:
Ruslan,
On Sat, Oct 21, 2006 at 09:25:33PM +0400, Ruslan Ermilov wrote:
Also, your patch avoids performing the WITH(OUT)_* stuff for ports in
order to prevent from polluting the namespace. If there is to be
some WITH(OUT)_* knobs which leads to CFLAGS modification in the future
(I'm thinking about ProPolice with the upcoming GCC 4.1), wouldn't it
be worth benefiting this framework for ports ?
It avoids only /etc/src.conf stuff when running bsd.port.mk; if you put
WITH(OUT)_* in /etc/make.conf it will still be picked up.
Yes indeed, but MK_FOO won't be set and this would require to either
duplicate the code that modifies CFLAGS, or at least test for MK_FOO
or WITH_FOO at the same time.
Let me show you an example.
I have an additional bsd.ssp.mk that is included from both bsd.sys.mk
and bsd.port.mk:
% .if ${MK_SSP} != no
% SSP_CFLAGS ?= -fstack-protector
% CFLAGS += ${SSP_CFLAGS}
% . if defined(WARNS) ${WARNS} = 7 !empty(SSP_CFLAGS)
% CWARNFLAGS += -Wstack-protector
% . endif
% .endif
Currently it is thus quite useful to use MK_SSP when this file is
included from bsd.ports.mk. With your whole patch I would have to
either duplicate these bits in bsd.ports.mk or turn the condition to
something like:
% .if (defined(MK_SSP) ${MK_SSP} != no) || defined(WITH_SSP)
What do you advice me to do ?
I still don't understand why my patch created a problem for you.
This option is not in bsd.own.mk, so it's not covered by my patch.
All my patch does is don't process /etc/src.conf which is entirely
for src/.
So, you can continue to use your bsd.ssp.mk as before, and my patch
shouldn't influence it.
If you want to really mimic the standard behavior, then bsd.ssp.mk
should check the (WITH|WITHOUT)_SSP set by a user, and set MK_SSP
to yes/no, accordingly; setting MK_SSP by a user shouldn't be
allowed or supported. You then set WITH_SSP= in /etc/make.conf
(or in /etc/src.conf if you want it only for src/), or pass
-DWITH_SSP on the make command line, and you're done.
P.S. There has been a patch floating around that adds support for
/etc/ports.conf.
[...] that you sent :-)
Could try to revive the thread with a new patch.
--
Florent Thoumie
[EMAIL PROTECTED]
FreeBSD Committer
signature.asc
Description: This is a digitally signed message part
Re: src.conf(5) seems to affect ports build
On Tue, Oct 24, 2006 at 04:23:40PM +0100, Florent Thoumie wrote:
On Tue, 2006-10-24 at 17:48 +0400, Ruslan Ermilov wrote:
On Sun, Oct 22, 2006 at 05:34:36PM +0200, Jeremie Le Hen wrote:
Ruslan,
On Sat, Oct 21, 2006 at 09:25:33PM +0400, Ruslan Ermilov wrote:
Also, your patch avoids performing the WITH(OUT)_* stuff for ports in
order to prevent from polluting the namespace. If there is to be
some WITH(OUT)_* knobs which leads to CFLAGS modification in the
future
(I'm thinking about ProPolice with the upcoming GCC 4.1), wouldn't it
be worth benefiting this framework for ports ?
It avoids only /etc/src.conf stuff when running bsd.port.mk; if you put
WITH(OUT)_* in /etc/make.conf it will still be picked up.
Yes indeed, but MK_FOO won't be set and this would require to either
duplicate the code that modifies CFLAGS, or at least test for MK_FOO
or WITH_FOO at the same time.
Let me show you an example.
I have an additional bsd.ssp.mk that is included from both bsd.sys.mk
and bsd.port.mk:
% .if ${MK_SSP} != no
% SSP_CFLAGS ?= -fstack-protector
% CFLAGS += ${SSP_CFLAGS}
% . if defined(WARNS) ${WARNS} = 7 !empty(SSP_CFLAGS)
% CWARNFLAGS += -Wstack-protector
% . endif
% .endif
Currently it is thus quite useful to use MK_SSP when this file is
included from bsd.ports.mk. With your whole patch I would have to
either duplicate these bits in bsd.ports.mk or turn the condition to
something like:
% .if (defined(MK_SSP) ${MK_SSP} != no) || defined(WITH_SSP)
What do you advice me to do ?
I still don't understand why my patch created a problem for you.
This option is not in bsd.own.mk, so it's not covered by my patch.
All my patch does is don't process /etc/src.conf which is entirely
for src/.
So, you can continue to use your bsd.ssp.mk as before, and my patch
shouldn't influence it.
If you want to really mimic the standard behavior, then bsd.ssp.mk
should check the (WITH|WITHOUT)_SSP set by a user, and set MK_SSP
to yes/no, accordingly; setting MK_SSP by a user shouldn't be
allowed or supported. You then set WITH_SSP= in /etc/make.conf
(or in /etc/src.conf if you want it only for src/), or pass
-DWITH_SSP on the make command line, and you're done.
P.S. There has been a patch floating around that adds support for
/etc/ports.conf.
[...] that you sent :-)
Could try to revive the thread with a new patch.
Better just commit something. :-)
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
pgpX7PM4nLBD5.pgp
Description: PGP signature
Panic caused by bad memory?
Hello all, Without a full dump are there any telltale signs from the panic message that can give me some sign of whether I'm dealing with a hardware or software issue? I have a box that has been running 4.11-p10 for quite some time with no problems. I upgraded a number of ports (apache/php/mysql) and since then I've had two panics. Of course userland apps shouldn't cause this, but that's the only change I see. I can't get a kernel dump since it fails like this each time: dumping to dev #da/0x20001, offset 2097152 dump 1024 1023 1022 1021 Aborting dump due to I/O error. status == 0xb, scsi status == 0x0 failed, reason: i/o error The meat of my question though, what are these lines telling me: (panic 1) instruction pointer = 0x8:0xc028b053 stack pointer = 0x10:0xe138eefc frame pointer = 0x10:0xe138ef2c (panic 2) instruction pointer = 0x8:0xc028b053 stack pointer = 0x10:0xe138eefc frame pointer = 0x10:0xe138ef2c Are those physical memory addresses where the code that caused the panic resides? If so, does that point to bad RAM? Thanks, Charles Here's more info if anyone is curious: [-- MARK -- Mon Oct 23 06:00:00 2006] Fatal trap 12: page fault while in kernel mode mp_lock = 0002; cpuid = 0; lapic.id = fault virtual address = 0xc327c614 fault code = supervisor read, page not present instruction pointer = 0x8:0xc028b053 stack pointer = 0x10:0xe138eefc frame pointer = 0x10:0xe138ef2c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 8 (syncer) interrupt mask = none - SMP: XXX trap number = 12 panic: page fault mp_lock = 0002; cpuid = 0; lapic.id = boot() called on cpu#0 syncing disks... panic: rslock: cpu: 0, addr: 0xc0391ccc, lock: 0x0001 mp_lock = 0002; cpuid = 0; lapic.id = boot() called on cpu#0 Uptime: 441d9h31m5s dumping to dev #da/0x20001, offset 2097152 dump 1024 1023 1022 1021 Aborting dump due to I/O error. status == 0xb, scsi status == 0x0 failed, reason: i/o error Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... cpu_reset called on cpu#0 cpu_reset: Stopping other CPUs [-- MARK -- Tue Oct 24 09:00:00 2006] Fatal trap 12: page fault while in kernel mode mp_lock = 0102; cpuid = 1; lapic.id = 0100 fault virtual address = 0xc29d2b94 fault code = supervisor read, page not present instruction pointer = 0x8:0xc028b053 stack pointer = 0x10:0xe138eefc frame pointer = 0x10:0xe138ef2c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 8 (syncer) interrupt mask = none - SMP: XXX trap number = 12 panic: page fault mp_lock = 0102; cpuid = 1; lapic.id = 0100 boot() called on cpu#1 syncing disks... panic: rslock: cpu: 1, addr: 0xc0391ccc, lock: 0x0101 mp_lock = 0102; cpuid = 1; lapic.id = 0100 boot() called on cpu#1 Uptime: 1d2h55m38s dumping to dev #da/0x20001, offset 2097152 dump 1024 1023 1022 1021 Aborting dump due to I/O error. status == 0xb, scsi status == 0x0 failed, reason: i/o error Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... cpu_reset called on cpu#1 cpu_reset: Stopping other CPUs cpu_reset: Restarting BSP cpu_reset_proxy: Grabbed mp locckp uf_re sBeStP: BSP did not grab mp lock ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic caused by bad memory?
I can't get a kernel dump since it fails like this each time: dumping to dev #da/0x20001, offset 2097152 dump 1024 1023 1022 1021 Aborting dump due to I/O error. status == 0xb, scsi status == 0x0 failed, reason: i/o error Bad memory seems unlikely to cause an I/O error trying to write the dump to the swap partition. I'd guess a dicey drive -- and bad swap space could also account for the original crash. You might be able to get a backup by booting single user, provided nothing activates the (presumably bad) swap partition. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
