sys/x86/isa/clock.c:189: undefined reference to `cyclic_clock_func'
Hello Stable@, Compiling a kernel on stable/8 with DTrace support is failing with the above subject line upon linking kernel.debug. The text leading up to this is: ... ctfconvert -L VERSION -g vers.o linking kernel.debug clock.o(.text+0x84c): In function `clkintr': /usr/src/sys/x86/isa/clock.c:189: undefined reference to `cyclic_clock_func' And upon inspection of clock.c: #ifdef KDTRACE_HOOKS #include #endif And in clkintr(): #ifdef KDTRACE_HOOKS /* * If the DTrace hooks are configured and a callback function * has been registered, then call it to process the high speed * timers. */ int cpu = PCPU_GET(cpuid); if (cyclic_clock_func[cpu] != NULL) (*cyclic_clock_func[cpu])(frame); #endif It seems for some odd reason that is being forgotten when it comes time for linking ? What is going on here ? Id like to just remove the ifdef's for KDTRACE_HOOKS just to get the build to finish but in the case that I want to build another kernel without dtrace I would have to add them back. Anyone have a better fitting solution to this ? Would it be just as good to re-ifdef this to ?WITH_CTF? instead. Anyway... this is latest code from stable/8 on i386. And yes options KDTRACE_HOOKS is in the kernel config. And the command that caused all this: ( make kernel WITH_CTF=1 ) -- Regards, J. Hellenthal (0x89D8547E) JJH48-ARIN ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: sys/x86/isa/clock.c:189: undefined reference to `cyclic_clock_func'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 8 Mar 2011 03:29, jhell@ wrote:
Hello Stable@,
Compiling a kernel on stable/8 with DTrace support is failing with the above
subject line upon linking kernel.debug.
The text leading up to this is:
...
ctfconvert -L VERSION -g vers.o
linking kernel.debug
clock.o(.text+0x84c): In function `clkintr':
/usr/src/sys/x86/isa/clock.c:189: undefined reference to `cyclic_clock_func'
And upon inspection of clock.c:
#ifdef KDTRACE_HOOKS
#include
#endif
And in clkintr():
#ifdef KDTRACE_HOOKS
/*
* If the DTrace hooks are configured and a callback function
* has been registered, then call it to process the high speed
* timers.
*/
int cpu = PCPU_GET(cpuid);
if (cyclic_clock_func[cpu] != NULL)
(*cyclic_clock_func[cpu])(frame);
#endif
It seems for some odd reason that is being forgotten when
it comes time for linking ? What is going on here ?
Id like to just remove the ifdef's for KDTRACE_HOOKS just to get the build to
finish but in the case that I want to build another kernel without dtrace I
would have to add them back. Anyone have a better fitting solution to this ?
Would it be just as good to re-ifdef this to ?WITH_CTF? instead.
Anyway... this is latest code from stable/8 on i386. And yes options
KDTRACE_HOOKS is in the kernel config.
And the command that caused all this:
( make kernel WITH_CTF=1 )
In light of this I decided to just remove the effected section of clock.c
and move forward as this part of the kernel with DTrace is not what I am
looking into.
Attached is a small patch that removes it in case someone else comes
across the same thing and needs a quick workaround.
- --
Regards,
J. Hellenthal
(0x89D8547E)
JJH48-ARIN
-BEGIN PGP SIGNATURE-
Comment: THIS SOFTWARE AND/OR CONTENTS IS PROVIDED BY THE AUTHOR ``AS IS'' AND
Comment: ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
Comment: IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
Comment: PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
Comment: DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
Comment: DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
Comment: OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
Comment: HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
Comment: STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
Comment: IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
Comment: POSSIBILITY OF SUCH DAMAGE.
iQEcBAEBAgAGBQJNdfSCAAoJEJBXh4mJ2FR+K18H/A1KD0Ki1GR696dCvn2iJByH
ym2nrsREjdVzFS2P7tW5PO0fmIc8eiFvqimeKHjexDS9JUH+3ybJ2ccF8JqHrR50
G/lNluptzLibPsqQY3+l/EsOUe//8NZUrUYV0ymOGfMsO5v49fBIfSKAT3JBFmY7
nq8wXMP5ncP8cjGdT6abSryIHmXVxY+E2R2DUOyfmbwZ+J/8fjfNEqxZta+Vc2Bv
N2BJlEW1eJQBHrq2YuEM3iMBGqRkYywaG7hAWnJXXGUf+/8A/B3SgE1zLBlyCbfB
osUjJE/AA7TtBawG6b5V10GCBSMxLaFdhaEzzyd4MtrRPnhuFWsjnPi4ACqnrhc=
=3a8e
-END PGP SIGNATURE-changeset: 947:6dc8de7b9735
branch: DataIX
tag: tip
user:J. Hellenthal
date:Tue Mar 08 03:56:34 2011 -0500
summary: clkintr removal of cyclic_clock_func KDTRACE_HOOKS
diff -r b8f7392deaf6 -r 6dc8de7b9735 sys/x86/isa/clock.c
--- a/sys/x86/isa/clock.c Mon Mar 07 13:06:50 2011 -0500
+++ b/sys/x86/isa/clock.c Tue Mar 08 03:56:34 2011 -0500
@@ -179,17 +179,6 @@
KASSERT(using_lapic_timer == LAPIC_CLOCK_NONE,
("clk interrupt enabled with lapic timer"));
-#ifdef KDTRACE_HOOKS
- /*
-* If the DTrace hooks are configured and a callback function
-* has been registered, then call it to process the high speed
-* timers.
-*/
- int cpu = PCPU_GET(cpuid);
- if (cyclic_clock_func[cpu] != NULL)
- (*cyclic_clock_func[cpu])(frame);
-#endif
-
if (using_atrtc_timer) {
#ifdef SMP
if (smp_started)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
panic on vm_page_cache_transfer: object 0xfffffff0035508000's type is not compatible with cache pages
System: FreeBSD zfs.digiware.nl 8.2-STABLE FreeBSD 8.2-STABLE #1: Sat Feb 26 06:28:43 CET 2011 r...@zfs.digiware.nl:/usr/obj/usr/src/src8/src/sys/ZFS amd64 Don't have a serial console, so I wrote down the traceback. But my guess is that that is not enough, however I needed the system so I rebooted. tb: vm_object_split at +0x125 vm_space_fork at +0x3f7 fork1 at +0x6a9 forkat +0xee syscall_entrat +1c syscall at +4c rip = 0x8006bc39c rsp = 0x7fffe9d8 rbp = 0x800a04470 It looks a lot like what I find on http://people.freebsd.org/~pho/stress/log/kostik079.html But my system is amd64, with 8Gb RAM and is fully ZFS based with swap on 2 gpt freebsd-swap partitions. System crashed last night around 1:30, which is when a few large rsync backups are coming in. Would I be able to call doadump to obtain something usefull afterward (provided I have savecore set?) --WjW ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
ZFS performance as the FS fills up?
Hi, all, we use a big JBOD and ZFS with raidz2 as the target for our nightly Amanda backups. I already suspected that the fact that the FS was > 90% full might be the cause of our backup performance continously decreasing. I just added another vdev - 6 disks of 750 GB each, raidz2 and the FS usage is back to 71% currently. This was while backups were running and write performance instantly skyrocketed compared to the values before. So, is it possible to name a reasonable amount of free space to keep on a raidz2 volume? On last year's EuroBSDCon I got the impression that with recent (RELENG_8) ZFS merges I could get away with using around 90%. Thanks, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 i...@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS performance as the FS fills up?
On Tue, Mar 08, 2011 at 12:26:49PM +0100, Patrick M. Hausen wrote: > we use a big JBOD and ZFS with raidz2 as the target > for our nightly Amanda backups. > > I already suspected that the fact that the FS was > 90% full might > be the cause of our backup performance continously decreasing. > > I just added another vdev - 6 disks of 750 GB each, raidz2 and the > FS usage is back to 71% currently. This was while backups were > running and write performance instantly skyrocketed compared to > the values before. > > So, is it possible to name a reasonable amount of free space to > keep on a raidz2 volume? On last year's EuroBSDCon I got > the impression that with recent (RELENG_8) ZFS merges > I could get away with using around 90%. I'm in no way attempting to dissuade you from your efforts to figure out a good number for utilisation, but when I hear of disks -- no matter how many -- being 90% full, I immediately conclude performance is going to suck simply because the outer "tracks" on a disk contains more sectors than the inner "tracks". This is the reason for performance degradation as the seek offset increases, resulting in graphs like this: http://img171.imageshack.us/img171/4776/1tb2.png Given this info, it shouldn't come as too much of a surprise that adding another vdev (effectively adding more disks to the pool) greatly helps in relieving this issue. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Sense fetching [Was: cdrtools /devel ...]
Hello. Just ensuring that this issue would not be forgotten, If I recall correctly, without added patches one cannot burn CD with cdrtools, quite a problem for media burning suite ;) best regards, - Jakub Lach -- View this message in context: http://old.nabble.com/Sense-fetching--Was%3A-cdrtools--devel-...--tp30144095p31097583.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Sense fetching [Was: cdrtools /devel ...]
On Tue, Mar 8, 2011 at 8:29 AM, Jakub Lach wrote: > > Hello. > > Just ensuring that this issue would not be forgotten, > If I recall correctly, without added patches one > cannot burn CD with cdrtools, quite a problem > for media burning suite ;) > > best regards, > - Jakub Lach mav@ is working on graid(4), a replacement for ataraid(4) using the GEOM framework. This effort has taken precedence over a few outstanding patches he was working on, but he will eventually come back to it :) Perhaps another developer will step up and continue the work on the patches: http://people.freebsd.org/~mav/sense/ -Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: sys/x86/isa/clock.c:189: undefined reference to `cyclic_clock_func'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 8 Mar 2011 04:18, jhell@ wrote: On Tue, 8 Mar 2011 03:29, jhell@ wrote: Hello Stable@, Compiling a kernel on stable/8 with DTrace support is failing with the above subject line upon linking kernel.debug. The text leading up to this is: ... ctfconvert -L VERSION -g vers.o linking kernel.debug clock.o(.text+0x84c): In function `clkintr': /usr/src/sys/x86/isa/clock.c:189: undefined reference to `cyclic_clock_func' And upon inspection of clock.c: #ifdef KDTRACE_HOOKS #include #endif And in clkintr(): #ifdef KDTRACE_HOOKS /* * If the DTrace hooks are configured and a callback function * has been registered, then call it to process the high speed * timers. */ int cpu = PCPU_GET(cpuid); if (cyclic_clock_func[cpu] != NULL) (*cyclic_clock_func[cpu])(frame); #endif It seems for some odd reason that is being forgotten when it comes time for linking ? What is going on here ? Id like to just remove the ifdef's for KDTRACE_HOOKS just to get the build to finish but in the case that I want to build another kernel without dtrace I would have to add them back. Anyone have a better fitting solution to this ? Would it be just as good to re-ifdef this to ?WITH_CTF? instead. Anyway... this is latest code from stable/8 on i386. And yes options KDTRACE_HOOKS is in the kernel config. And the command that caused all this: ( make kernel WITH_CTF=1 ) In light of this I decided to just remove the effected section of clock.c and move forward as this part of the kernel with DTrace is not what I am looking into. Attached is a small patch that removes it in case someone else comes across the same thing and needs a quick workaround. To my best belief the cause is this i386 build is being done without "device apic" that includes I/O APIC (local_apic.c) which defines in a ifdef KDTRACE_HOOKS ( cyclic_clock_func_t cyclic_clock_func[MAXCPU]; ). Since the lack of I/O APIC being used, sys/x86/isa/clock.c needs its own definition of the same cyclic_clock_func, so I have added this in the same way that its implemented in local_apic.c to clock.c and the build succeeds and is usable. Would it be best to just move cyclic_clock_func definition to dtrace_bsd.h instead ? and remove the definition in local_apic.c ? Additional references: ( Thanks to rwatson@ ) http://fxr.watson.org/fxr/ident?v=FREEBSD8&i=cyclic_clock_func Attached is the patch that solved this here but its just adding another definition that could probably be avoided by adding it somewhere else. - -- Regards, J. Hellenthal (0x89D8547E) JJH48-ARIN -BEGIN PGP SIGNATURE- Comment: THIS SOFTWARE AND/OR CONTENTS IS PROVIDED BY THE AUTHOR ``AS IS'' AND Comment: ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE Comment: IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR Comment: PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY Comment: DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL Comment: DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS Comment: OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) Comment: HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, Comment: STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING Comment: IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE Comment: POSSIBILITY OF SUCH DAMAGE. iQEcBAEBAgAGBQJNdkkMAAoJEJBXh4mJ2FR+8j4H/3qcymOBXvbMj2fqILJA/2xx Xj+Og+INWT+3NAM95Ljeq375lLeV0h3FzXUKrHB+z/bQlY8NYdBdZHOtEUWl1ZvV 5W5RGAncSJq1cBU+EMOoGprvmwWaNIYIHJUUHSpSrJbhwdW53unP285ts4bqvk0I eirtOitgmaiyOzBpJAIfDBBWU7RgQWCc/IFsm6GAU90JmjATy65kEeBtba6fNVcV SlHqu5OmtuVN6eHEq/rf3Ai8jGktwvuS9Flgf4rM+u/tZTA1nC9cfo97Rbtek9TH lQ/yZe9U7Wz4OFSdidMoY1nJN3CYisp3Kq+gqabsd3XDkJQQiXcBIIh61hnnjog= =tC6l -END PGP SIGNATURE-changeset: 952:5eb7de8dcdc0 branch: DataIX tag: tip user:J. Hellenthal date:Tue Mar 08 08:20:28 2011 -0500 summary: cyclic_clock_func_t cyclic_clock_func[MAXCPU]; definition. diff -r e1c8a20eb4b2 -r 5eb7de8dcdc0 sys/x86/isa/clock.c --- a/sys/x86/isa/clock.c Tue Mar 08 08:16:59 2011 -0500 +++ b/sys/x86/isa/clock.c Tue Mar 08 08:20:28 2011 -0500 @@ -82,6 +82,7 @@ #ifdef KDTRACE_HOOKS #include +cyclic_clock_func_tcyclic_clock_func[MAXCPU]; #endif #defineTIMER_DIV(x) ((i8254_freq + (x) / 2) / (x)) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Disable probing of bge1?
Hello, Am 07.03.2011 um 13:37 schrieb Tom Evans: > Maybe this loader tunable will help: > hw.bge.allow_asf > Allow the ASF feature for cooperating with IPMI. Can cause sys‐ > tem lockup problems on a small number of systems. Disabled by > default. No - same result: bge0: mem 0xfd21-0xfd21,0xfd20-0xfd20 irq 16 at device 4.0 on pci8 miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:0a:e4:82:c1:0f bge0: [ITHREAD] bge1: irq 1 Here the iRMC console is disconnected. Thanks anyway, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 i...@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Sense fetching [Was: cdrtools /devel ...]
On 08/03/2011 16:15, Brandon Gooch wrote: On Tue, Mar 8, 2011 at 8:29 AM, Jakub Lach wrote: Hello. Just ensuring that this issue would not be forgotten, If I recall correctly, without added patches one cannot burn CD with cdrtools, quite a problem for media burning suite ;) best regards, - Jakub Lach mav@ is working on graid(4), a replacement for ataraid(4) using the GEOM framework. This effort has taken precedence over a few outstanding patches he was working on, but he will eventually come back to it :) Perhaps another developer will step up and continue the work on the patches: http://people.freebsd.org/~mav/sense/ -Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" I hope because I want to use ahci on my machines! :-) -- David Demelier ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: About "panic: bufwrite: buffer is not busy???"
Not sure if the CC: line needs to be trimmed, leaving it as is for now. On Sun, Feb 20, 2011 at 7:46 AM, Jeremy Chadwick wrote: > On Sun, Feb 20, 2011 at 10:30:52AM -0500, Mike Tancsa wrote: >> On 2/20/2011 9:33 AM, Andrey Smagin wrote: >> > On week -current I have same problem, my box paniced every 2-15 min. I >> > resolve problem by next steps - unplug network connectors from 2 intel em >> > (82574L) cards. I think last time that mpd5 related panic, but mpd5 work >> > with another re interface interated on MB. I think it may be em related >> > panic, or em+mpd5. >> >> The latest panic I saw didnt have anything to do with em. Are you sure >> your crashes are because of the nic drive ? > > Not to mention, the error string the OP provided (see Subject) is only > contained in one file: sys/ufs/ffs/ffs_vfsops.c, function > ffs_bufwrite(). So, that would be some kind of weird filesystem-related > issue, not NIC-specific. I have no idea how to debug said problem. I can semi-reliably reproduce this panic message on a 9-CURRENT box, with sources from March 7. On this box, it happens every other time I start hastd. hastd creates the 12 GEOM providers used to create a ZFS pool. A simple "service hastd onestart" will generate the panic. Is there any extra info that needed to help track this down? -- Freddie Cash fjwc...@gmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: panic on vm_page_cache_transfer: object 0xfffffff0035508000's type is not compatible with cache pages
On Tuesday, March 08, 2011 5:54:36 am Willem Jan Withagen wrote: > System: > > FreeBSD zfs.digiware.nl 8.2-STABLE FreeBSD 8.2-STABLE #1: Sat Feb 26 > 06:28:43 CET 2011 > r...@zfs.digiware.nl:/usr/obj/usr/src/src8/src/sys/ZFS amd64 > > Don't have a serial console, so I wrote down the traceback. > But my guess is that that is not enough, however I needed the system so > I rebooted. > > tb: > vm_object_split at +0x125 > vm_space_fork at +0x3f7 > fork1 at +0x6a9 > fork at +0xee > syscall_entr at +1c > syscall at +4c > > rip = 0x8006bc39c > rsp = 0x7fffe9d8 > rbp = 0x800a04470 > > It looks a lot like what I find on > http://people.freebsd.org/~pho/stress/log/kostik079.html > > But my system is amd64, with 8Gb RAM and is fully ZFS based > with swap on 2 gpt freebsd-swap partitions. > > System crashed last night around 1:30, which is when a few large rsync > backups are coming in. > > Would I be able to call doadump to obtain something usefull afterward > (provided I have savecore set?) Hmm, judging from the info at the URL above, I'm not sure what to make of this assertion. In vm_object_split(), the 'new_object' is always OBJT_DEFAULT, so it will always fail that half of the assertion. In fact, this is the only place that vm_page_cache_transfer() is called, so 'new_object->type == OBJT_SWAP' is pretty much guaranteed to almost never be true. I guess it is assuming that swap_pager_copy() would have always converted 'new_object' to OBJT_SWAP if it had any cache pages? Perhaps that is a bogus assumption if 'orig_object' only has cache pages and no currently-swapped out pages (or if the swapped out pages are not in the range of the new object)? I've cc'd Alan to see if he has any ideas. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: sys/x86/isa/clock.c:189: undefined reference to `cyclic_clock_func'
On Tuesday, March 08, 2011 10:19:30 am J. Hellenthal wrote: > > On Tue, 8 Mar 2011 04:18, jhell@ wrote: > > On Tue, 8 Mar 2011 03:29, jhell@ wrote: > >> > >> Hello Stable@, > >> > >> Compiling a kernel on stable/8 with DTrace support is failing with the > >> above > >> subject line upon linking kernel.debug. > >> > >> The text leading up to this is: > >> ... > >> ctfconvert -L VERSION -g vers.o > >> linking kernel.debug > >> clock.o(.text+0x84c): In function `clkintr': > >> /usr/src/sys/x86/isa/clock.c:189: undefined reference to > >> `cyclic_clock_func' > >> > >> And upon inspection of clock.c: > >> #ifdef KDTRACE_HOOKS > >> #include > >> #endif > >> > >> And in clkintr(): > >> #ifdef KDTRACE_HOOKS > >>/* > >> * If the DTrace hooks are configured and a callback function > >> * has been registered, then call it to process the high speed > >> * timers. > >> */ > >>int cpu = PCPU_GET(cpuid); > >>if (cyclic_clock_func[cpu] != NULL) > >>(*cyclic_clock_func[cpu])(frame); > >> #endif > >> > >> > >> It seems for some odd reason that is being forgotten > >> when > >> it comes time for linking ? What is going on here ? > >> > >> Id like to just remove the ifdef's for KDTRACE_HOOKS just to get the build > >> to > >> finish but in the case that I want to build another kernel without dtrace I > >> would have to add them back. Anyone have a better fitting solution to this > >> ? > >> > >> Would it be just as good to re-ifdef this to ?WITH_CTF? instead. > >> > >> Anyway... this is latest code from stable/8 on i386. And yes options > >> KDTRACE_HOOKS is in the kernel config. > >> > >> And the command that caused all this: > >> ( make kernel WITH_CTF=1 ) > >> > > > > In light of this I decided to just remove the effected section of clock.c > > and move forward as this part of the kernel with DTrace is not what I am > > looking into. > > > > Attached is a small patch that removes it in case someone else comes > > across the same thing and needs a quick workaround. > > > > To my best belief the cause is this i386 build is being done without > "device apic" that includes I/O APIC (local_apic.c) which defines in a > ifdef KDTRACE_HOOKS ( cyclic_clock_func_t cyclic_clock_func[MAXCPU]; ). > Since the lack of I/O APIC being used, sys/x86/isa/clock.c needs its own > definition of the same cyclic_clock_func, so I have added this in the same > way that its implemented in local_apic.c to clock.c and the build succeeds > and is usable. > > Would it be best to just move cyclic_clock_func definition to dtrace_bsd.h > instead ? and remove the definition in local_apic.c ? I think DTrace requires the local APIC to work as it hooks directly into the local APIC timer interrupt IIRC. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Port 80 closed?
Hi all An IPFW problem? An help gladly accepted It would appear Port 80 closed Ports 21 25 443 587 998 work well rc.conf defaultrouter="192.168.0.1" gateway_enable="YES" hostname="xxx.xxx.xxx" ifconfig_re0="inet 192.168.0.11 netmask 255.255.255.0" ifconfig_re1="inet 192.168.1.2 netmask 255.255.255.0" keymap="us.iso" moused_enable="YES" sshd_enable="YES" firewall_enable="YES" firewall_script="/etc/rc.firewall" natd_program="/sbin/natd" natd_enable="YES" natd_interface="re0" natd_flags="-f /etc/natd.conf" dhcpd_enable="NO" dhcpd_flags="-q" dhcpd_conf="/usr/local/etc/dhcpd.conf" dhcpd_ifaces="re1" dhcpd_withumask="022" natd.conf interface re0 use_sockets yes same_ports yes log #redirect_port tcp 192.168.1.189:3389 3389 #redirect_port tcp 192.168.1.53:5500 5500 #!/bin/sh /sbin/ipfw -f flush /sbin/ipfw -f pipe flush #Nat Rules /sbin/ipfw add 10 allow ip from 127.0.0.1 to 127.0.0.1 via lo0 /sbin/ipfw add 30 divert natd all from any to any via re0 #Forward to Transparent Proxy Server #/sbin/ipfw add 10001 fwd 127.0.0.1,3128 tcp from any to any 80 #/sbin/ipfw add 10010 fwd 127.0.0.1,3128 tcp from 10.0.21.2 to any 80 /sbin/ipfw add 10001 fwd 127.0.0.1,3128 tcp from any to any 80 /sbin/ipfw add 5 allow ip from any to any Regards ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Port 80 closed?
On 09/03/2011, at 9:22, Dave Johnson wrote: > An IPFW problem? > > An help gladly accepted > > It would appear Port 80 closed > > Ports 21 25 443 587 998 work well It's quite possible your ISP blocks port 80 inbound. And/or there is a problem with your router. PS don't cross post. > > > rc.conf > defaultrouter="192.168.0.1" > gateway_enable="YES" > hostname="xxx.xxx.xxx" > ifconfig_re0="inet 192.168.0.11 netmask 255.255.255.0" > ifconfig_re1="inet 192.168.1.2 netmask 255.255.255.0" > keymap="us.iso" > moused_enable="YES" > sshd_enable="YES" > firewall_enable="YES" > firewall_script="/etc/rc.firewall" > natd_program="/sbin/natd" > natd_enable="YES" > natd_interface="re0" > natd_flags="-f /etc/natd.conf" > dhcpd_enable="NO" > dhcpd_flags="-q" > dhcpd_conf="/usr/local/etc/dhcpd.conf" > dhcpd_ifaces="re1" > dhcpd_withumask="022" > > natd.conf > > interface re0 > use_sockets yes > same_ports yes > log > #redirect_port tcp 192.168.1.189:3389 3389 > #redirect_port tcp 192.168.1.53:5500 5500 > > #!/bin/sh > > /sbin/ipfw -f flush > /sbin/ipfw -f pipe flush > > > > #Nat Rules > /sbin/ipfw add 10 allow ip from 127.0.0.1 to 127.0.0.1 via lo0 > /sbin/ipfw add 30 divert natd all from any to any via re0 > > > #Forward to Transparent Proxy Server > #/sbin/ipfw add 10001 fwd 127.0.0.1,3128 tcp from any to any 80 > #/sbin/ipfw add 10010 fwd 127.0.0.1,3128 tcp from 10.0.21.2 to any 80 > > /sbin/ipfw add 10001 fwd 127.0.0.1,3128 tcp from any to any 80 > > > /sbin/ipfw add 5 allow ip from any to any > > > Regards > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Panic from linux emulation (flashplugin)
Well it started happening again. Basically what I did was rebuild all of ports which downgraded my nvidia driver. I was getting consistent crashes in youtube after this happened. I upgraded my nvidia driver to 260.19.44 by modifying the port and now I can't get it to crash anymore. *HOWEVER* This may or may not be unrelated -- I'm running opera and have a youtube video hidden in another tab. I have upgraded my nvidia driver but didn't reboot, just removed the kernel module and started X again. For some reason the Youtube video in the hidden tab is able to be seen when I put my terminal over the area where it would be if it was in the active tab. http://feld.me/stuff/flash_bug.png is an example of it. I haven't yet rebooted to see what happens on a clean boot, but this is certainly interesting... perhaps bad flash/linuxulator behavior that doesn't trip a panic in the newer nvidia drivers? Weird stuff either way... Now that I have seemingly figured out the combination to a crash I'll see if I can catch one on the console and have something worthwhile to report. Regards, Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: sys/x86/isa/clock.c:189: undefined reference to `cyclic_clock_func'
On Tue, 8 Mar 2011 16:31, jhb@ wrote: On Tuesday, March 08, 2011 10:19:30 am J. Hellenthal wrote: On Tue, 8 Mar 2011 04:18, jhell@ wrote: On Tue, 8 Mar 2011 03:29, jhell@ wrote: Hello Stable@, Compiling a kernel on stable/8 with DTrace support is failing with the above subject line upon linking kernel.debug. The text leading up to this is: ... ctfconvert -L VERSION -g vers.o linking kernel.debug clock.o(.text+0x84c): In function `clkintr': /usr/src/sys/x86/isa/clock.c:189: undefined reference to `cyclic_clock_func' And upon inspection of clock.c: #ifdef KDTRACE_HOOKS #include #endif And in clkintr(): #ifdef KDTRACE_HOOKS /* * If the DTrace hooks are configured and a callback function * has been registered, then call it to process the high speed * timers. */ int cpu = PCPU_GET(cpuid); if (cyclic_clock_func[cpu] != NULL) (*cyclic_clock_func[cpu])(frame); #endif It seems for some odd reason that is being forgotten when it comes time for linking ? What is going on here ? Id like to just remove the ifdef's for KDTRACE_HOOKS just to get the build to finish but in the case that I want to build another kernel without dtrace I would have to add them back. Anyone have a better fitting solution to this ? Would it be just as good to re-ifdef this to ?WITH_CTF? instead. Anyway... this is latest code from stable/8 on i386. And yes options KDTRACE_HOOKS is in the kernel config. And the command that caused all this: ( make kernel WITH_CTF=1 ) In light of this I decided to just remove the effected section of clock.c and move forward as this part of the kernel with DTrace is not what I am looking into. Attached is a small patch that removes it in case someone else comes across the same thing and needs a quick workaround. To my best belief the cause is this i386 build is being done without "device apic" that includes I/O APIC (local_apic.c) which defines in a ifdef KDTRACE_HOOKS ( cyclic_clock_func_t cyclic_clock_func[MAXCPU]; ). Since the lack of I/O APIC being used, sys/x86/isa/clock.c needs its own definition of the same cyclic_clock_func, so I have added this in the same way that its implemented in local_apic.c to clock.c and the build succeeds and is usable. Would it be best to just move cyclic_clock_func definition to dtrace_bsd.h instead ? and remove the definition in local_apic.c ? I think DTrace requires the local APIC to work as it hooks directly into the local APIC timer interrupt IIRC. I was starting to think that myself but after adding the above to clock.c it fixed the issue I was seeing. It appears that clock.c is providing enough of a interrupt to at least hotkernel and dtruss + procsystime. hotkernel ... kernel`bzero 28 0.1% kernel`copyout 31 0.1% kernel`syscallret 31 0.1% kernel`uma_zfree_arg 33 0.1% kernel`fget_unlocked 35 0.1% kernel`cpu_fetch_syscall_args 37 0.1% kernel`sopoll_generic 39 0.1% kernel`uma_zalloc_arg 41 0.1% kernel`poll44 0.1% kernel`copyin 48 0.1% kernel`soreceive_generic 60 0.1% kernel`kern_select 66 0.2% kernel`syscallenter93 0.2% kernel`sched_idletd 135 0.3% kernel`spinlock_exit 337 0.8% kernel`acpi_cpu_c1 40525 95.1% I would say at least for the tests I ran with this so far it fixes it¿ procsystime ... Elapsed Times for all processes, SYSCALL TIME (ns) getppid 13579 sigreturn 18646 fcntl 27752 getpid 36201 fstat 45574 close 47142 socket 55193 sigpending 86178 mmap 111586 connect 171967 swapcontext 224511 write 360017 sigprocmask 369920 setitimer 409114 sigaction 650495 writev 667841 gettimeofday1480759 ioctl3403788 stat4044830 clock_gettime4704770 __sysctl7789725 read 9526207068 kevent10024305765 _umtx_op10142262643 poll15037340342 select34427328326 And a simple run of a d.d from example
