Re: Problem compiling kernel
On 2011-Nov-06 17:41:49 +0200, Alexander Yerenkow yeren...@gmail.com wrote: And problem compiling kernel for amd64 arch. I attached full log: http://www.box.net/shared/juajg1o2lg1mxbht5x9b It looks like you did a parallel - in which case the actual error is buried somewhere in that output. Please repeat without any '-j' and post the last 50-100 lines of output. -- Peter Jeremy pgp3iXsvFHcL6.pgp Description: PGP signature
Re: Problem compiling kernel
On Nov 6, 2011, at 11:57 PM, Peter Jeremy wrote: On 2011-Nov-06 17:41:49 +0200, Alexander Yerenkow yeren...@gmail.com wrote: And problem compiling kernel for amd64 arch. I attached full log: http://www.box.net/shared/juajg1o2lg1mxbht5x9b It looks like you did a parallel - in which case the actual error is buried somewhere in that output. Please repeat without any '-j' and post the last 50-100 lines of output. ip_fw_nat.o: In function `del_redir_spool_cfg':/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:123: undefined reference to `LibAliasRedirectDelete' ip_fw_nat.o: In function `ipfw_nat_destroy': /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:615: undefined reference to `LibAliasUninit' /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:615: undefined reference to `LibAliasUninit' ip_fw_nat.o: In function `ifaddr_change': /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:80: undefined reference to `LibAliasSetAddress' ip_fw_nat.o: In function `ipfw_nat_del': /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:482: undefined reference to `LibAliasUninit'ip_fw_nat.o: In function `ipfw_nat_cfg':/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:437: undefined reference to `LibAliasSetMode'/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:438: undefined reference to `LibAliasSetAddress' ip_fw_nat.o: In function `add_redir_spool_cfg':/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:193: undefined reference to `LibAliasAddServer'/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:158: undefined reference to `LibAliasRedirectAddr'/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:167: undefined reference to `LibAliasRedirectPort' /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:178: undefined reference to `LibAliasRedirectProto'ip_fw_nat.o: In function `ipfw_nat_cfg':/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:416: undefined reference to `LibAliasInit'ip_fw_nat.o: In function `ipfw_nat': /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:216: undefined reference to `m_megapullup' /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:295: undefined reference to `LibAliasOut' /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:276: undefined reference to `LibAliasOutTry' /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:292: undefined reference to `LibAliasIn' You need to compile with libalias support. -Garrett___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]
2011/11/7 Arnaud Lacombe lacom...@gmail.com:
Hi,
On Sat, Nov 5, 2011 at 10:13 AM, Kostik Belousov kostik...@gmail.com wrote:
On Fri, Nov 04, 2011 at 06:03:39PM +0200, Kostik Belousov wrote:
Below is the KBI patch after vm_page_bits_t merge is done.
Again, I did not spent time converting all in-tree consumers
from the (potentially) loadable modules to the new KPI until it
is agreed upon.
diff --git a/sys/nfsclient/nfs_bio.c b/sys/nfsclient/nfs_bio.c
index 305c189..7264cd1 100644
--- a/sys/nfsclient/nfs_bio.c
+++ b/sys/nfsclient/nfs_bio.c
@@ -128,7 +128,7 @@ nfs_getpages(struct vop_getpages_args *ap)
* can only occur at the file EOF.
*/
VM_OBJECT_LOCK(object);
- if (pages[ap-a_reqpage]-valid != 0) {
+ if (vm_page_read_valid(pages[ap-a_reqpage]) != 0) {
for (i = 0; i npages; ++i) {
if (i != ap-a_reqpage) {
vm_page_lock(pages[i]);
@@ -198,16 +198,16 @@ nfs_getpages(struct vop_getpages_args *ap)
/*
* Read operation filled an entire page
*/
- m-valid = VM_PAGE_BITS_ALL;
- KASSERT(m-dirty == 0,
+ vm_page_write_valid(m, VM_PAGE_BITS_ALL);
+ KASSERT(vm_page_read_dirty(m) == 0,
(nfs_getpages: page %p is dirty, m));
} else if (size toff) {
/*
* Read operation filled a partial page.
*/
- m-valid = 0;
+ vm_page_write_valid(m, 0);
vm_page_set_valid(m, 0, size - toff);
- KASSERT(m-dirty == 0,
+ KASSERT(vm_page_read_dirty(m) == 0,
(nfs_getpages: page %p is dirty, m));
} else {
/*
diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c
index 389aea5..2f41e70 100644
--- a/sys/vm/vm_page.c
+++ b/sys/vm/vm_page.c
@@ -2677,6 +2677,66 @@ vm_page_test_dirty(vm_page_t m)
vm_page_dirty(m);
}
+void
+vm_page_lock_func(vm_page_t m, const char *file, int line)
+{
+
+#if LOCK_DEBUG 0 || defined(MUTEX_NOINLINE)
+ _mtx_lock_flags(vm_page_lockptr(m), 0, file, line);
+#else
+ __mtx_lock(vm_page_lockptr(m), 0, file, line);
+#endif
+}
+
Why do you re-implement the wheel ? all the point of these assessors
is to hide implementation detail. IMO, you should restrict yourself to
the documented API from mutex(9), only.
Oh, wait, you end-up using LOCK_FILE instead of just __FILE__, but
wait LOCK_FILE is either just __FILE__, or NULL, depending on
LOCK_DEBUG, but you wouldn't have those function without
INVARIANTS This whole LOCK_FILE/LOCK_LINE seem completely
fracked-up... If you don't want this code in INVARIANTS, but in
LOCK_DEBUG, only make it live only in the LOCK_DEBUG case.
Btw, let me also question the use of non-inline functions.
My impression is that you don't really understand the patch, thus your
disrespectful words used here are really unjustified.
I think that kib@ intention is just to get the most official way to
pass down file and line to locking functions from the consumers.
His patch is technically right, but I would prefer something
different (see below).
LOCK_FILE and LOCK_LINE exist for reducing the space in .rodata
section. Without INVARIANTS/WITNESS/etc. they will just be NULL and
not pointing to a lot of datas that won't be used in the opposite
case.
I'm unsure if this replies to your concerns because you just criticize
without making a real technical question in this post.
+void
+vm_page_unlock_func(vm_page_t m, const char *file, int line)
+{
+
+#if LOCK_DEBUG 0 || defined(MUTEX_NOINLINE)
+ _mtx_unlock_flags(vm_page_lockptr(m), 0, file, line);
+#else
+ __mtx_unlock(vm_page_lockptr(m), curthread, 0, file, line);
+#endif
+}
Kostik,
we usually catered this case by having interfaces directly specified
in mutex.h in order to keep the implementation details compact
enough (see the thread_lock() case for this).
I'm unsure what you prefer here, at least for the locking functions
you could move over there as there are cons and prons for both
approaches really and I'm fine with both.
Attilio
--
Peace can only be achieved by understanding - A. Einstein
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Problem compiling kernel
2011/11/7 Garrett Cooper yaneg...@gmail.com On Nov 6, 2011, at 11:57 PM, Peter Jeremy wrote: On 2011-Nov-06 17:41:49 +0200, Alexander Yerenkow yeren...@gmail.com wrote: And problem compiling kernel for amd64 arch. I attached full log: http://www.box.net/shared/juajg1o2lg1mxbht5x9b It looks like you did a parallel - in which case the actual error is buried somewhere in that output. Please repeat without any '-j' and post the last 50-100 lines of output. ip_fw_nat.o: In function `del_redir_spool_cfg':/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:123: undefined reference to `LibAliasRedirectDelete' ip_fw_nat.o: In function `ipfw_nat_destroy': /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:615: undefined reference to `LibAliasUninit' /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:615: undefined reference to `LibAliasUninit' ip_fw_nat.o: In function `ifaddr_change': /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:80: undefined reference to `LibAliasSetAddress' ip_fw_nat.o: In function `ipfw_nat_del': /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:482: undefined reference to `LibAliasUninit'ip_fw_nat.o: In function `ipfw_nat_cfg':/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:437: undefined reference to `LibAliasSetMode'/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:438: undefined reference to `LibAliasSetAddress' ip_fw_nat.o: In function `add_redir_spool_cfg':/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:193: undefined reference to `LibAliasAddServer'/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:158: undefined reference to `LibAliasRedirectAddr'/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:167: undefined reference to `LibAliasRedirectPort' /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:178: undefined reference to `LibAliasRedirectProto'ip_fw_nat.o: In function `ipfw_nat_cfg':/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:416: undefined reference to `LibAliasInit'ip_fw_nat.o: In function `ipfw_nat': /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:216: undefined reference to `m_megapullup' /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:295: undefined reference to `LibAliasOut' /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:276: undefined reference to `LibAliasOutTry' /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:292: undefined reference to `LibAliasIn' You need to compile with libalias support. Thanks, that does fix the problem. Is there somewhere request for feature that config must check kernel config for dependencies specified? Or maybe even auto-dependency :) What I mean, someone working at kernel configuration/sanity check util at all? Or mabye it's not requested feature? -Garrett -- Regards, Alexander Yerenkow ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]
2011/11/7 Attilio Rao atti...@freebsd.org:
2011/11/7 Arnaud Lacombe lacom...@gmail.com:
Hi,
On Sat, Nov 5, 2011 at 10:13 AM, Kostik Belousov kostik...@gmail.com wrote:
On Fri, Nov 04, 2011 at 06:03:39PM +0200, Kostik Belousov wrote:
Below is the KBI patch after vm_page_bits_t merge is done.
Again, I did not spent time converting all in-tree consumers
from the (potentially) loadable modules to the new KPI until it
is agreed upon.
diff --git a/sys/nfsclient/nfs_bio.c b/sys/nfsclient/nfs_bio.c
index 305c189..7264cd1 100644
--- a/sys/nfsclient/nfs_bio.c
+++ b/sys/nfsclient/nfs_bio.c
@@ -128,7 +128,7 @@ nfs_getpages(struct vop_getpages_args *ap)
* can only occur at the file EOF.
*/
VM_OBJECT_LOCK(object);
- if (pages[ap-a_reqpage]-valid != 0) {
+ if (vm_page_read_valid(pages[ap-a_reqpage]) != 0) {
for (i = 0; i npages; ++i) {
if (i != ap-a_reqpage) {
vm_page_lock(pages[i]);
@@ -198,16 +198,16 @@ nfs_getpages(struct vop_getpages_args *ap)
/*
* Read operation filled an entire page
*/
- m-valid = VM_PAGE_BITS_ALL;
- KASSERT(m-dirty == 0,
+ vm_page_write_valid(m, VM_PAGE_BITS_ALL);
+ KASSERT(vm_page_read_dirty(m) == 0,
(nfs_getpages: page %p is dirty, m));
} else if (size toff) {
/*
* Read operation filled a partial page.
*/
- m-valid = 0;
+ vm_page_write_valid(m, 0);
vm_page_set_valid(m, 0, size - toff);
- KASSERT(m-dirty == 0,
+ KASSERT(vm_page_read_dirty(m) == 0,
(nfs_getpages: page %p is dirty, m));
} else {
/*
diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c
index 389aea5..2f41e70 100644
--- a/sys/vm/vm_page.c
+++ b/sys/vm/vm_page.c
@@ -2677,6 +2677,66 @@ vm_page_test_dirty(vm_page_t m)
vm_page_dirty(m);
}
+void
+vm_page_lock_func(vm_page_t m, const char *file, int line)
+{
+
+#if LOCK_DEBUG 0 || defined(MUTEX_NOINLINE)
+ _mtx_lock_flags(vm_page_lockptr(m), 0, file, line);
+#else
+ __mtx_lock(vm_page_lockptr(m), 0, file, line);
+#endif
+}
+
Why do you re-implement the wheel ? all the point of these assessors
is to hide implementation detail. IMO, you should restrict yourself to
the documented API from mutex(9), only.
Oh, wait, you end-up using LOCK_FILE instead of just __FILE__, but
wait LOCK_FILE is either just __FILE__, or NULL, depending on
LOCK_DEBUG, but you wouldn't have those function without
INVARIANTS This whole LOCK_FILE/LOCK_LINE seem completely
fracked-up... If you don't want this code in INVARIANTS, but in
LOCK_DEBUG, only make it live only in the LOCK_DEBUG case.
Btw, let me also question the use of non-inline functions.
My impression is that you don't really understand the patch, thus your
disrespectful words used here are really unjustified.
I think that kib@ intention is just to get the most official way to
pass down file and line to locking functions from the consumers.
His patch is technically right, but I would prefer something
different (see below).
LOCK_FILE and LOCK_LINE exist for reducing the space in .rodata
section. Without INVARIANTS/WITNESS/etc. they will just be NULL and
not pointing to a lot of datas that won't be used in the opposite
case.
I'm unsure if this replies to your concerns because you just criticize
without making a real technical question in this post.
+void
+vm_page_unlock_func(vm_page_t m, const char *file, int line)
+{
+
+#if LOCK_DEBUG 0 || defined(MUTEX_NOINLINE)
+ _mtx_unlock_flags(vm_page_lockptr(m), 0, file, line);
+#else
+ __mtx_unlock(vm_page_lockptr(m), curthread, 0, file, line);
+#endif
+}
Kostik,
we usually catered this case by having interfaces directly specified
in mutex.h in order to keep the implementation details compact
enough (see the thread_lock() case for this).
I'm unsure what you prefer here, at least for the locking functions
you could move over there as there are cons and prons for both
approaches really and I'm fine with both.
After thinking a bit about it, my guess is that the best approach
would be patching mutex.h in order to offer a simple way to do what
Kostik needs (i.e. a general interface to do that).
I wouldn't encourage, infact, neither putting more things in mutex.h
or growing checks in other files depending by the compiling options.
I hope I can provide a patch asap.
Attilio
--
Peace can only be achieved by understanding - A. Einstein
___
freebsd-current@freebsd.org mailing list
multimedia/vlc: suddenly no graphical interface
On all of my used FreeBSD 9.0-RCX and FreeBSD 10.0-CURRENT boxes (all amd64 and CLANG compiled), I do not have a graphical user interface in VLC anymore. Instead, calling vlc most recent 1.1.11), I get this error: VLC media player 1.1.11 The Luggage (revision exported) Blocked: call to unsetenv(DBUS_ACTIVATION_ADDRESS) Blocked: call to unsetenv(DBUS_ACTIVATION_BUS_TYPE) [0x8020521b0] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface. [0x80205ad70] main interface error: option qt-volume-complete does not exist [0x80205ad70] skins2 interface error: no suitable dialogs provider found (hint: compile the qt4 plugin, and make sure it is loaded properly) [0x80205ad70] skins2 interface error: cannot instanciate qt4 dialogs provider [0x8020521b0] main libvlc error: interface default initialization failed Recompiling the multimedia/vlc port did not help, also unsuccessful was the recompilation of any qt4-port installed on the system. I also tried to find the local configuration files in my home directory and delete them, without any success. Is there something wrong with the DBUS subsystem named in the error? Help appreciated, thanks. Regards, Oliver ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Fix types of arguments to dtrace syscall return probes
Thank you for your work. I will give it a try in stable/9. I have
another two PR:
kern/160307 and bin/160275 that maybe you can help;
the reason of bin/160275 is complicated, but the fix for kernel crash
caused by module without ctf section(for example, nvidia.ko) missed
somthing
(my mistake)
in kern/kern_ctf.c
int link_elf_ctf_get(linker_file_t lf, linker_ctf_t *lc)
struct nameidata nd;
struct thread *td = curthread;
uint8_t ctf_hdr[CTF_HDR_SIZE];
#endif
int error = 0;
if (lf == NULL || lc == NULL)
return (EINVAL);
/* Set the defaults for no CTF present. That's not a crime! */
bzero(lc, sizeof(*lc));
#ifdef DDB_CTF
/*
* First check if we've tried to load CTF data previously and the
* CTF ELF section wasn't found. We flag that condition by setting
* ctfcnt to -1. See below.
*/
if (ef-ctfcnt 0)//second
time with same module,
return (0);
/* Now check if we've already loaded the CTF data.. */
if (ef-ctfcnt 0) {
/* We only need to load once. */
lc-ctftab = ef-ctftab;
lc-ctfcnt = ef-ctfcnt;
lc-symtab = ef-ddbsymtab;
lc-strtab = ef-ddbstrtab;
lc-strcnt = ef-ddbstrcnt;
lc-nsym = ef-ddbsymcnt;
lc-ctfoffp = (uint32_t **) ef-ctfoff;
lc-typoffp = (uint32_t **) ef-typoff;
lc-typlenp = ef-typlen;
return (0);
}
/*
* We need to try reading the CTF data. Flag no CTF data present
* by default and if we actually succeed in reading it, we'll
* update ctfcnt to the number of bytes read.
*/
ef-ctfcnt = -1;
-
fisrt time, set ctfcnt to -1, if module does not has ctf section, and
ef-ctfcnt does NOT update with a valid value(0) later,
then second time enter this function with same module(ef), previous
if (ef-ctfcnt 0)
return (0);// should not be 0 here
pass over first time ctf section check, I think we need another fix .
diff --git a/sys/kern/kern_ctf.c b/sys/kern/kern_ctf.c
index bdff96e..2737860 100644
--- a/sys/kern/kern_ctf.c
+++ b/sys/kern/kern_ctf.c
@@ -90,7 +90,7 @@ link_elf_ctf_get(linker_file_t lf, linker_ctf_t *lc)
* ctfcnt to -1. See below.
*/
if (ef-ctfcnt 0)
- return (0);
+ return (EFTYPE);
/* Now check if we've already loaded the CTF data.. */
if (ef-ctfcnt 0) {
---
And I post another fix for the ${NORMAL_CTFCONVERT} issue, could you
check it for me?
kern/160307, I check the /boot/kernel/kernel with ctfdump, and found
the kernel image has right ctf information, do you
have any idea?
And thank you again for your work!
--
[PATCH] Fix kernel panics when using dtrace fbt return probes on i386
[PATCH] Fix types of arguments to dtrace syscall return probes
walltimestamp curpsinfo-pr_psargs has no args from Shawn Webb
latt...@gmail.com.
commit ec734d4fb07fec8d1b5fb8d1d4c8caa0fada4eea
Author: rstone rst...@freebsd.org
Replace fasttrap_copyout() with uwrite(). FreeBSD copyout() is not able to
write to the .text section of a process.
commit 83b04575eb8f73e557f245bb2814ac6db0a89696
Author: rstone rst...@freebsd.org
Fix the DTrace pid return trap interrupt vector. Previously we were using
31, but that vector is reserved.
2011/11/6 Ryan Stone ryst...@gmail.com:
Currently if you try to use the args[] array passed to a syscall
return probe, you get variables with the wrong type. This is because
the systrace implementation is currently using the same function to
provide the same argument types for both the entry and return probes,
which is completely wrong. For example:
# dtrace -v -l -n syscall::mmap:return
ID PROVIDER MODULE FUNCTION NAME
32159 syscall mmap return
Probe Description Attributes
Identifier Names: Private
Data Semantics: Private
Dependency Class: ISA
Argument Attributes
Identifier Names: Private
Data Semantics: Private
Dependency Class: ISA
Argument Types
args[0]: caddr_t
args[1]: size_t
args[2]: int
args[3]: int
args[4]: int
Panic in the udp_input() under heavy load
Hi Gang,
We are seeing repeatable panics under high PPS load on our production
systems. It happens when the traffic gets into the range or 200MBps and
150-200K PPS. We have been managed to track it down to the following
piece of code:
(gdb) l *udp_input+0x5d2
0x806f6202 is in udp_input (/usr/src/sys/netinet/udp_usrreq.c:628).
623 if (inp-inp_ip_minttl inp-inp_ip_minttl ip-ip_ttl) {
624 INP_RUNLOCK(inp);
625 goto badunlocked;
626 }
627 up = intoudpcb(inp);
628 if (up-u_tun_func == NULL) {
629 udp_append(inp, ip, m, iphlen + sizeof(struct
udphdr), udp_in);
630 } else {
631 /*
632 * Engage the tunneling protocol.
The faulty line appears to be 628, with up value is being NULL, attempt
to deference it causes NULL pointer exception. I believe this particular
piece of code has been introduced here:
---
Author: bz
Date: Thu Aug 13 15:16:30 2009
New Revision: 196192
URL: http://svn.freebsd.org/changeset/base/196192
Log:
MFC: r192649
Implement UDP control block support.
Add udpcb support with own fields and flags for UDP instead
of further sticking things into in_pcb and flags fields.
Attach the udpcb to the inp_ppcb in the kernel.
Note: the udp tunneling parts are not (yet) existing in 7
and thus were not merged.
Reviewed by: rwatson
---
The screenshot of the panic message is attached. This is pretty recent
8.2-STABLE. Any help is greatly appreciated. This particular bug has
haunted us for at least 4-5 months now.
Thanks!
-Maxim
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
9.0 NFS Installs
I noted that we no longer have the disc1.iso in this release. What should I use to populate a NFS rootfs for netinstalls? This was what I had been using(8.2-RELEASE) to populate NFS roots for netinstalls. This allowed you to boot up into something that was self-contained. The other ISO's seem to have A LOT more stuff with symlinks pointing to absolute paths all over the f/s. This isn't quite as simple to copy over to a rootfs to use as a NFS target for booting. --- 8.2-RELEASE disc1.iso --- netboot# ls -l total 508 dr-xr-xr-x 14 root wheel 512 Nov 5 20:42 8.2-RELEASE -r--r--r-- 1 root wheel4958 Nov 5 20:43 ERRATA.HTM -r--r--r-- 1 root wheel3590 Nov 5 20:43 ERRATA.TXT -r--r--r-- 1 root wheel 192187 Nov 5 20:43 HARDWARE.HTM -r--r--r-- 1 root wheel 116657 Nov 5 20:43 HARDWARE.TXT -r--r--r-- 1 root wheel 19914 Nov 5 20:43 README.HTM -r--r--r-- 1 root wheel 14387 Nov 5 20:43 README.TXT -r--r--r-- 1 root wheel 105287 Nov 5 20:43 RELNOTES.HTM -r--r--r-- 1 root wheel 41124 Nov 5 20:43 RELNOTES.TXT dr-xr-xr-x 7 root wheel1024 Nov 5 20:40 boot -r--r--r-- 1 root wheel2048 Nov 5 20:43 boot.catalog -r--r--r-- 1 root wheel 39 Nov 5 20:43 cdrom.inf -r--r--r-- 1 root wheel3802 Nov 5 20:43 docbook.css dr-xr-xr-x 5 root wheel 512 Nov 5 20:41 packages --- 9.0-RELEASE bootonly.iso --- total 492 -rw-r--r-- 2 root wheel 788 Oct 18 19:24 .cshrc -rw-r--r-- 2 root wheel 251 Oct 18 19:24 .profile drwxr-xr-x 2 root wheel4096 Oct 18 19:24 .rr_moved -r--r--r-- 1 root wheel6194 Oct 18 19:24 COPYRIGHT -r--r--r-- 1 root wheel5167 Oct 18 19:24 ERRATA.HTM -r--r--r-- 1 root wheel3727 Oct 18 19:24 ERRATA.TXT -r--r--r-- 1 root wheel 199303 Oct 18 19:24 HARDWARE.HTM -r--r--r-- 1 root wheel 121623 Oct 18 19:24 HARDWARE.TXT -r--r--r-- 1 root wheel 20698 Oct 18 19:24 README.HTM -r--r--r-- 1 root wheel 15103 Oct 18 19:24 README.TXT -r--r--r-- 1 root wheel 37081 Oct 18 19:24 RELNOTES.HTM -r--r--r-- 1 root wheel 18789 Oct 18 19:24 RELNOTES.TXT drwxr-xr-x 2 root wheel6144 Oct 18 19:24 bin drwxr-xr-x 7 root wheel6144 Oct 18 19:24 boot dr-xr-xr-x 2 root wheel2048 Oct 18 19:24 dev -r--r--r-- 1 root wheel3924 Oct 18 19:24 docbook.css drwxr-xr-x 20 root wheel 12288 Oct 18 19:24 etc drwxr-xr-x 3 root wheel6144 Oct 18 19:24 lib drwxr-xr-x 3 root wheel2048 Oct 18 19:24 libexec drwxr-xr-x 2 root wheel2048 Oct 18 19:24 media drwxr-xr-x 2 root wheel2048 Oct 18 19:24 mnt dr-xr-xr-x 2 root wheel2048 Oct 18 19:24 proc drwxr-xr-x 2 root wheel2048 Oct 18 19:24 rescue drwxr-xr-x 2 root wheel2048 Oct 18 19:24 root drwxr-xr-x 2 root wheel 16384 Oct 18 19:24 sbin lrwxr-xr-x 1 root wheel 11 Oct 18 19:24 sys - usr/src/sys drwxrwxrwt 2 root wheel2048 Oct 18 19:24 tmp drwxr-xr-x 15 root wheel2048 Oct 18 19:24 usr drwxr-xr-x 23 root wheel4096 Oct 18 19:24 var ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Panic in the udp_input() under heavy load
Panic screenshot is here: http://sobomax.sippysoft.com/ScreenShot859.png -Maxim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]
On 11/06/2011 06:43, Kostik Belousov wrote: On Sat, Nov 05, 2011 at 03:00:58PM -0500, Alan Cox wrote: On 11/05/2011 10:15, Kostik Belousov wrote: On Sat, Nov 05, 2011 at 07:37:48AM -0700, m...@freebsd.org wrote: On Sat, Nov 5, 2011 at 7:13 AM, Kostik Belousovkostik...@gmail.com wrote: On Fri, Nov 04, 2011 at 06:03:39PM +0200, Kostik Belousov wrote: Below is the KBI patch after vm_page_bits_t merge is done. Again, I did not spent time converting all in-tree consumers from the (potentially) loadable modules to the new KPI until it is agreed upon. I like my bikeshed orange... I would think a more canonical name would be get/set rather than read/write, especially since these operations aren't reading and writing the page (neither are they getting the page, but at least set is pretty unambiguous). Look at the vm_page.h:385. vm_page_set_valid() is already taken. I don't feel good about creating an interface under which we have functions named vm_page_set_valid() and vm_page_write_valid(). I think that we should take a step back and look at the whole of set of functions that exist for manipulating the page's valid and dirty field and see if we can come up with a logical schema for naming them. I wouldn't then be surprised if this results in renaming some of the existing functions. However, this should not delay the changes to address the vm_page_lock problem. I had two questions about that part of your patch. First, is there any reason that you didn't include vm_page_lockptr()? If we created the page locking macros that you, jhb@, and I were talking about last week, then vm_page_lockptr() would be required. Second, there seems to be precedent for naming the locking functions _vm_page_lock() instead of vm_page_lock_func(), for example, the mutex code, i.e., sys/mutex.h, and the vm map locking functions. I think vm_page_lockptr() should be included when some kind of reloc-iterating macros are actually introduced into the tree. And, I have a hope that they can be wrapped around a function with the signature like void vm_page_relock(vm_page_t locked_page, vm_page_t unlocked_page); which moves the lock from locked_page to unlocked_page. Ok. That sounds reasonable. Regarding the _vm_page_lock() vs. vm_page_lock_func(), the mutex.h has a lot of violations in regard of the namespaces, IMO. The __* namespace is reserved for the language implementation, so our freestanding program (kernel) ignores the requirements of the C standard with the names like __mtx_lock_spin(). Using the name _vm_page_lock() is valid, but makes it not unreasonable for other developers to introduce reserved names. So I decided to use the suffixes. vm_map.h locking is free of these violations. Ok. I'll offer one final suggestion. Please consider an alternative suffix to func. Perhaps, kbi or KBI. In other words, something that hints at the function's reason for existing. Alan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: multimedia/vlc: suddenly no graphical interface
On Mon, 07 Nov 2011 10:46:28 +0100 O. Hartmann ohart...@mail.zedat.fu-berlin.de wrote: On all of my used FreeBSD 9.0-RCX and FreeBSD 10.0-CURRENT boxes (all amd64 and CLANG compiled), I do not have a graphical user interface in VLC anymore. Instead, calling vlc most recent 1.1.11), I get this error: VLC media player 1.1.11 The Luggage (revision exported) Blocked: call to unsetenv(DBUS_ACTIVATION_ADDRESS) Blocked: call to unsetenv(DBUS_ACTIVATION_BUS_TYPE) [0x8020521b0] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface. [0x80205ad70] main interface error: option qt-volume-complete does not exist [0x80205ad70] skins2 interface error: no suitable dialogs provider found (hint: compile the qt4 plugin, and make sure it is loaded properly) [0x80205ad70] skins2 interface error: cannot instanciate qt4 dialogs provider [0x8020521b0] main libvlc error: interface default initialization failed Recompiling the multimedia/vlc port did not help, also unsuccessful was the recompilation of any qt4-port installed on the system. I also tried to find the local configuration files in my home directory and delete them, without any success. Is there something wrong with the DBUS subsystem named in the error? No, this is what I seea and my GUI works: VLC media player 1.1.5 The Luggage (revision exported) Blocked: call to unsetenv(DBUS_ACTIVATION_ADDRESS) Blocked: call to unsetenv(DBUS_ACTIVATION_BUS_TYPE) Blocked: call to setlocale(0, ) Blocked: call to sigaction(20, 0x7f9fbcb0, 0x7f9fbcd0) [0x801c86b70] qt4 interface error: Unable to load extensions module Warning: call to rand() Warning: call to rand() Warning: call to rand() Warning: call to rand() Warning: call to rand() Blocked: call to sigaction(20, 0x7fffd5e0, 0x7fffd600) Blocked: call to sigaction(20, 0x7fffd600, 0x0) The version of vlc which I'm using: drwxr-xr-x 2 root wheel 512 Sep 5 14:03 /var/db/pkg/vlc-1.1.5,3 -- Gary Jennejohn ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 9.0 NFS Installs
On Mon, Nov 7, 2011 at 9:20 AM, Sean Bruno sean...@yahoo-inc.com wrote: I noted that we no longer have the disc1.iso in this release. What should I use to populate a NFS rootfs for netinstalls? This was what I had been using(8.2-RELEASE) to populate NFS roots for netinstalls. This allowed you to boot up into something that was self-contained. The other ISO's seem to have A LOT more stuff with symlinks pointing to absolute paths all over the f/s. This isn't quite as simple to copy over to a rootfs to use as a NFS target for booting. It's just a better idea to use the payload tarballs from here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/uname -m/uname -p/release/ e.g. ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/ as the basis for your system, and probably just run something like make distribution ala mergemaster afterwards and/or use a custom /boot/loader.conf, /etc/... . sysinstall hacked up the system using its custom memory disk with secret sauce binaries and pathing, s.t. it kept most things self-contained to /stand, whereas bsdinstall hacks the system up in different ways -- most of it pointing back to /tmp/bsdinstall_* or similar locations. HTH, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: multimedia/vlc: suddenly no graphical interface
On Mon, Nov 7, 2011 at 9:33 AM, Gary Jennejohn gljennj...@googlemail.com wrote: On Mon, 07 Nov 2011 10:46:28 +0100 O. Hartmann ohart...@mail.zedat.fu-berlin.de wrote: On all of my used FreeBSD 9.0-RCX and FreeBSD 10.0-CURRENT boxes (all amd64 and CLANG compiled), I do not have a graphical user interface in VLC anymore. Instead, calling vlc most recent 1.1.11), I get this error: VLC media player 1.1.11 The Luggage (revision exported) Blocked: call to unsetenv(DBUS_ACTIVATION_ADDRESS) Blocked: call to unsetenv(DBUS_ACTIVATION_BUS_TYPE) [0x8020521b0] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface. [0x80205ad70] main interface error: option qt-volume-complete does not exist [0x80205ad70] skins2 interface error: no suitable dialogs provider found (hint: compile the qt4 plugin, and make sure it is loaded properly) [0x80205ad70] skins2 interface error: cannot instanciate qt4 dialogs provider [0x8020521b0] main libvlc error: interface default initialization failed Recompiling the multimedia/vlc port did not help, also unsuccessful was the recompilation of any qt4-port installed on the system. I also tried to find the local configuration files in my home directory and delete them, without any success. Is there something wrong with the DBUS subsystem named in the error? No, this is what I seea and my GUI works: VLC media player 1.1.5 The Luggage (revision exported) Blocked: call to unsetenv(DBUS_ACTIVATION_ADDRESS) Blocked: call to unsetenv(DBUS_ACTIVATION_BUS_TYPE) Blocked: call to setlocale(0, ) Blocked: call to sigaction(20, 0x7f9fbcb0, 0x7f9fbcd0) [0x801c86b70] qt4 interface error: Unable to load extensions module ^^^ Warning: call to rand() Warning: call to rand() Warning: call to rand() Warning: call to rand() Warning: call to rand() Blocked: call to sigaction(20, 0x7fffd5e0, 0x7fffd600) Blocked: call to sigaction(20, 0x7fffd600, 0x0) The version of vlc which I'm using: Your vlc install is broken too. You'll need to ktrace / truss vlc until you find the broken library as vlc likes to hide those details from the end-user (even when invoking vlc with --verbose). HTH, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: multimedia/vlc: suddenly no graphical interface
On Mon, Nov 7, 2011 at 1:46 AM, O. Hartmann ohart...@mail.zedat.fu-berlin.de wrote: On all of my used FreeBSD 9.0-RCX and FreeBSD 10.0-CURRENT boxes (all amd64 and CLANG compiled), I do not have a graphical user interface in VLC anymore. Instead, calling vlc most recent 1.1.11), I get this error: VLC media player 1.1.11 The Luggage (revision exported) Blocked: call to unsetenv(DBUS_ACTIVATION_ADDRESS) Blocked: call to unsetenv(DBUS_ACTIVATION_BUS_TYPE) [0x8020521b0] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface. [0x80205ad70] main interface error: option qt-volume-complete does not exist [0x80205ad70] skins2 interface error: no suitable dialogs provider found (hint: compile the qt4 plugin, and make sure it is loaded properly) [0x80205ad70] skins2 interface error: cannot instanciate qt4 dialogs provider [0x8020521b0] main libvlc error: interface default initialization failed Recompiling the multimedia/vlc port did not help, also unsuccessful was the recompilation of any qt4-port installed on the system. I also tried to find the local configuration files in my home directory and delete them, without any success. Is there something wrong with the DBUS subsystem named in the error? The best suggestion I have is ldd'ing the depends until you find the broken library (you can't figure this out typically by ldd'ing vlc because it dl_open's things IIRC -- can't verify because I blew away my install with vlc on it recently). -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 9.0 NFS Installs
On 11/07/11 11:20, Sean Bruno wrote: I noted that we no longer have the disc1.iso in this release. What should I use to populate a NFS rootfs for netinstalls? This was what I had been using(8.2-RELEASE) to populate NFS roots for netinstalls. This allowed you to boot up into something that was self-contained. The other ISO's seem to have A LOT more stuff with symlinks pointing to absolute paths all over the f/s. This isn't quite as simple to copy over to a rootfs to use as a NFS target for booting. You can just copy the whole CD over and it will work fine. The CD is basically a vanilla installed system, so you can also just set up an install somewhere (with bsdinstall jail /path/to/nfsroot, for instance). Things on the CD different from a vanilla system: - /etc/rc.local script to start the installer at boot (copied from /usr/src/release/rc.local) - Distfiles copied to /usr/freebsd-dist If you don't copy the distfiles, bsdinstall will automatically download them, but you probably don't want to do that every time. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Panic in the udp_input() under heavy load
On Mon, 7 Nov 2011, Maxim Sobolev wrote:
Hi Gang,
We are seeing repeatable panics under high PPS load on our production
systems. It happens when the traffic gets into the range or 200MBps and
150-200K PPS. We have been managed to track it down to the following piece of
code:
(gdb) l *udp_input+0x5d2
0x806f6202 is in udp_input (/usr/src/sys/netinet/udp_usrreq.c:628).
623 if (inp-inp_ip_minttl inp-inp_ip_minttl ip-ip_ttl) {
624 INP_RUNLOCK(inp);
625 goto badunlocked;
626 }
627 up = intoudpcb(inp);
628 if (up-u_tun_func == NULL) {
629 udp_append(inp, ip, m, iphlen + sizeof(struct
udphdr), udp_in);
630 } else {
631 /*
632 * Engage the tunneling protocol.
The faulty line appears to be 628, with up value is being NULL, attempt to
deference it causes NULL pointer exception. I believe this particular piece
of code has been introduced here:
Unlikely; the inp is properly locked there and the udp info attach
better still be valid there; your problem is most likely elsewhere;
try to see if you have other threads and see what they do at the same
time, etc. You would need to race with udp_detach(); you also want
to make sure that the inp still looks sane from either ddb or a dump
and we are not talking about random memory corruption here.
/bz
--
Bjoern A. Zeeb You have to have visions!
Stop bit received. Insert coin for new address family.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Problem compiling kernel
On Mon, Nov 7, 2011 at 1:57 AM, Alexander Yerenkow yeren...@gmail.com wrote: 2011/11/7 Garrett Cooper yaneg...@gmail.com On Nov 6, 2011, at 11:57 PM, Peter Jeremy wrote: On 2011-Nov-06 17:41:49 +0200, Alexander Yerenkow yeren...@gmail.com wrote: And problem compiling kernel for amd64 arch. I attached full log: http://www.box.net/shared/juajg1o2lg1mxbht5x9b It looks like you did a parallel - in which case the actual error is buried somewhere in that output. Please repeat without any '-j' and post the last 50-100 lines of output. ip_fw_nat.o: In function `del_redir_spool_cfg':/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:123: undefined reference to `LibAliasRedirectDelete' ip_fw_nat.o: In function `ipfw_nat_destroy': /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:615: undefined reference to `LibAliasUninit' /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:615: undefined reference to `LibAliasUninit' ip_fw_nat.o: In function `ifaddr_change': /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:80: undefined reference to `LibAliasSetAddress' ip_fw_nat.o: In function `ipfw_nat_del': /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:482: undefined reference to `LibAliasUninit'ip_fw_nat.o: In function `ipfw_nat_cfg':/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:437: undefined reference to `LibAliasSetMode'/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:438: undefined reference to `LibAliasSetAddress' ip_fw_nat.o: In function `add_redir_spool_cfg':/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:193: undefined reference to `LibAliasAddServer'/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:158: undefined reference to `LibAliasRedirectAddr'/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:167: undefined reference to `LibAliasRedirectPort' /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:178: undefined reference to `LibAliasRedirectProto'ip_fw_nat.o: In function `ipfw_nat_cfg':/zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:416: undefined reference to `LibAliasInit'ip_fw_nat.o: In function `ipfw_nat': /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:216: undefined reference to `m_megapullup' /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:295: undefined reference to `LibAliasOut' /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:276: undefined reference to `LibAliasOutTry' /zpool0/testenv/sources/9/sys/netinet/ipfw/ip_fw_nat.c:292: undefined reference to `LibAliasIn' You need to compile with libalias support. Thanks, that does fix the problem. Is there somewhere request for feature that config must check kernel config for dependencies specified? Or maybe even auto-dependency :) What I mean, someone working at kernel configuration/sanity check util at all? Or mabye it's not requested feature? Unfortunately our build system isn't really kind in this regard, and typically the answer has been you should understand what's going into your KERNCONF instead of having the build system automatically handle it for you (or at least that was the song and dance I got on questions@ 9 years ago when I first started using FreeBSD). It would be nice if the ipfw authors actually generated a manpage that listed the requirements ;)... Also, FWIW: ./ip_fw_nat.c:MODULE_DEPEND(ipfw_nat, libalias, 1, 1, 1); Cheers, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 9.0 NFS Installs
On Mon, 2011-11-07 at 10:29 -0800, Nathan Whitehorn wrote: On 11/07/11 11:20, Sean Bruno wrote: I noted that we no longer have the disc1.iso in this release. What should I use to populate a NFS rootfs for netinstalls? This was what I had been using(8.2-RELEASE) to populate NFS roots for netinstalls. This allowed you to boot up into something that was self-contained. The other ISO's seem to have A LOT more stuff with symlinks pointing to absolute paths all over the f/s. This isn't quite as simple to copy over to a rootfs to use as a NFS target for booting. You can just copy the whole CD over and it will work fine. The CD is basically a vanilla installed system, so you can also just set up an install somewhere (with bsdinstall jail /path/to/nfsroot, for instance). Things on the CD different from a vanilla system: - /etc/rc.local script to start the installer at boot (copied from /usr/src/release/rc.local) - Distfiles copied to /usr/freebsd-dist If you don't copy the distfiles, bsdinstall will automatically download them, but you probably don't want to do that every time. -Nathan Hah! Yes ... this is absolutely correct. I'm netbooting VMs now, excellent. Sean ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]
On Mon, Nov 7, 2011 at 4:36 AM, Attilio Rao atti...@freebsd.org wrote:
2011/11/7 Arnaud Lacombe lacom...@gmail.com:
Hi,
On Sat, Nov 5, 2011 at 10:13 AM, Kostik Belousov kostik...@gmail.com wrote:
On Fri, Nov 04, 2011 at 06:03:39PM +0200, Kostik Belousov wrote:
Below is the KBI patch after vm_page_bits_t merge is done.
Again, I did not spent time converting all in-tree consumers
from the (potentially) loadable modules to the new KPI until it
is agreed upon.
diff --git a/sys/nfsclient/nfs_bio.c b/sys/nfsclient/nfs_bio.c
index 305c189..7264cd1 100644
--- a/sys/nfsclient/nfs_bio.c
+++ b/sys/nfsclient/nfs_bio.c
@@ -128,7 +128,7 @@ nfs_getpages(struct vop_getpages_args *ap)
* can only occur at the file EOF.
*/
VM_OBJECT_LOCK(object);
- if (pages[ap-a_reqpage]-valid != 0) {
+ if (vm_page_read_valid(pages[ap-a_reqpage]) != 0) {
for (i = 0; i npages; ++i) {
if (i != ap-a_reqpage) {
vm_page_lock(pages[i]);
@@ -198,16 +198,16 @@ nfs_getpages(struct vop_getpages_args *ap)
/*
* Read operation filled an entire page
*/
- m-valid = VM_PAGE_BITS_ALL;
- KASSERT(m-dirty == 0,
+ vm_page_write_valid(m, VM_PAGE_BITS_ALL);
+ KASSERT(vm_page_read_dirty(m) == 0,
(nfs_getpages: page %p is dirty, m));
} else if (size toff) {
/*
* Read operation filled a partial page.
*/
- m-valid = 0;
+ vm_page_write_valid(m, 0);
vm_page_set_valid(m, 0, size - toff);
- KASSERT(m-dirty == 0,
+ KASSERT(vm_page_read_dirty(m) == 0,
(nfs_getpages: page %p is dirty, m));
} else {
/*
diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c
index 389aea5..2f41e70 100644
--- a/sys/vm/vm_page.c
+++ b/sys/vm/vm_page.c
@@ -2677,6 +2677,66 @@ vm_page_test_dirty(vm_page_t m)
vm_page_dirty(m);
}
+void
+vm_page_lock_func(vm_page_t m, const char *file, int line)
+{
+
+#if LOCK_DEBUG 0 || defined(MUTEX_NOINLINE)
+ _mtx_lock_flags(vm_page_lockptr(m), 0, file, line);
+#else
+ __mtx_lock(vm_page_lockptr(m), 0, file, line);
+#endif
+}
+
Why do you re-implement the wheel ? all the point of these assessors
is to hide implementation detail. IMO, you should restrict yourself to
the documented API from mutex(9), only.
Oh, wait, you end-up using LOCK_FILE instead of just __FILE__, but
wait LOCK_FILE is either just __FILE__, or NULL, depending on
LOCK_DEBUG, but you wouldn't have those function without
INVARIANTS This whole LOCK_FILE/LOCK_LINE seem completely
fracked-up... If you don't want this code in INVARIANTS, but in
LOCK_DEBUG, only make it live only in the LOCK_DEBUG case.
Btw, let me also question the use of non-inline functions.
My impression is that you don't really understand the patch, thus your
disrespectful words used here are really unjustified.
Well, unfortunately, I wasn't around to comment 10 years ago when this got in.
I think that kib@ intention is just to get the most official way to
pass down file and line to locking functions from the consumers.
His patch is technically right, but I would prefer something
different (see below).
Yes, and that's not an excuse to use the _internal_ implementation
details of mutex(9), and not the exposed API. This is especially true
when applied to someone so eager to follow standards.
LOCK_FILE and LOCK_LINE exist for reducing the space in .rodata
section. Without INVARIANTS/WITNESS/etc. they will just be NULL and
not pointing to a lot of datas that won't be used in the opposite
case.
You comment just as if __FILE__ and __LINE__ were mandatory in a debug
interface. This is _not_ true. __FILE__ and __LINE__ are just hideous
for debugging of anything but early alpha code. LOCK_FILE and
LOCK_LINE are a bad answer to a bad interface. Even if you just pass
NULL and 0 as argument, you've got the bloat of passing unused
argument. You might as well just pass a single argument that would do
the exact same job and be _always_ available, eg. the IP of the
caller, or the first return address. KDB magic still let you translate
to something humanly understandable. If the toolchain does not support
the feature on all supported platform, well, fix the toolchain.
I'm unsure if this replies to your concerns because you just criticize
without making a real technical question in this post.
I made comments on 3 points:
- using internal implementation details of mutex(9) is broken
- LOCK_FILE/LOCK_LINE are broken (a bit of a divergence on the
original subject :/)
- there is _no_
Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3
Hi,
On Wed, Nov 2, 2011 at 6:32 AM, Andriy Gapon a...@freebsd.org wrote:
[restored cc: to the original poster]
on 02/11/2011 08:10 Benjamin Kaduk said the following:
I am perhaps confused. Last I checked, bsd.kmod.mk caused '-include
opt_global.h' to be passed on the command line. Is the issue just that the
opt_global.h used for the kmod could be different from the actual kernel's
opt_global.h, because KERNCONF was not specified and the header is generated
at
module-build time? In this case, clearly the onus is on the user to pass
KERNCONF at module build time.
To be precise, this is what is actually passed to a compiler:
sys/conf/kmod.mk:
.if defined(KERNBUILDDIR)
CFLAGS+= -DHAVE_KERNEL_OPTION_HEADERS -include
${KERNBUILDDIR}/opt_global.h
.endif
where KERNBUILDDIR can be passed via environment from a kernel build:
sys/conf/kern.post.mk:
MKMODULESENV+= KERNBUILDDIR=${.CURDIR} SYSDIR=${SYSDIR}
KERNCONF does not have any meaning in a module build.
To make sure that a module build sees exactly the same kernel options as a
kernel with which the module should work, one has to either build the module
together with the kernel (within the kernel build; search for MODULES in
make.conf(5)) or to manually specify KERNBUILDDIR to point to a correct kernel
build directory. (Which to a certain degree implies impossibility to build a
perfect module for a pre-built binary kernel or to provide a perfect
universal pre-built module for any custom kernel)
Of course, the real problem is that modules should not care about any (or at
least some) kernel options, they should be isolated from the options via a
proper KPI/KBI (perhaps DDI or module-to-kernel interface or whatever). A
module should be able to work correctly with kernels built with different
options.
You cannot be make a point in shade of gray, it either must care or
must not care about kernel option, not care about some, but not
other. Moreover, you cannot advocate stable internal KBI/KPI when you
are not even able to provide a stable userland ABI...
P.P.S. [and tangential] I see that many module makefiles fake up various
kernel
options in a fashion similar to the following:
.if !defined(KERNBUILDDIR)
opt_compat.h:
echo #define COMPAT_FREEBSD6 1 ${.TARGET}
opt_kbd.h:
echo #define KBD_INSTALL_CDEV 1 ${.TARGET}
.endif
And handful of modules fake up opt_global.h, e.g.:
opt_global.h:
echo #define ALTQ 1 ${.TARGET}
personal opinionThis mess is utterly broken./personal opinion
FWIW, I advocate to make KERNBUILDDIR (ie. kernel option's
configuration) mandatory for building any modules.
- Arnaud
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]
On Mon, Nov 07, 2011 at 11:45:38AM -0600, Alan Cox wrote:
Ok. I'll offer one final suggestion. Please consider an alternative
suffix to func. Perhaps, kbi or KBI. In other words, something
that hints at the function's reason for existing.
Sure. Below is the extraction of only vm_page_lock() bits, together
with the suggested rename. When Attilio provides the promised simplification
of the mutex KPI, this can be reduced.
diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c
index 389aea5..ea4ea34 100644
--- a/sys/vm/vm_page.c
+++ b/sys/vm/vm_page.c
@@ -2677,6 +2677,44 @@ vm_page_test_dirty(vm_page_t m)
vm_page_dirty(m);
}
+void
+vm_page_lock_KBI(vm_page_t m, const char *file, int line)
+{
+
+#if LOCK_DEBUG 0 || defined(MUTEX_NOINLINE)
+ _mtx_lock_flags(vm_page_lockptr(m), 0, file, line);
+#else
+ __mtx_lock(vm_page_lockptr(m), 0, file, line);
+#endif
+}
+
+void
+vm_page_unlock_KBI(vm_page_t m, const char *file, int line)
+{
+
+#if LOCK_DEBUG 0 || defined(MUTEX_NOINLINE)
+ _mtx_unlock_flags(vm_page_lockptr(m), 0, file, line);
+#else
+ __mtx_unlock(vm_page_lockptr(m), curthread, 0, file, line);
+#endif
+}
+
+int
+vm_page_trylock_KBI(vm_page_t m, const char *file, int line)
+{
+
+ return (_mtx_trylock(vm_page_lockptr(m), 0, file, line));
+}
+
+void
+vm_page_lock_assert_KBI(vm_page_t m, int a, const char *file, int line)
+{
+
+#ifdef INVARIANTS
+ _mtx_assert(vm_page_lockptr(m), a, file, line);
+#endif
+}
+
int so_zerocp_fullpage = 0;
/*
diff --git a/sys/vm/vm_page.h b/sys/vm/vm_page.h
index 7099b70..a5604b7 100644
--- a/sys/vm/vm_page.h
+++ b/sys/vm/vm_page.h
@@ -218,11 +218,23 @@ extern struct vpglocks pa_lock[];
#definePA_LOCK_ASSERT(pa, a) mtx_assert(PA_LOCKPTR(pa), (a))
+#ifdef KLD_MODULE
+#definevm_page_lock(m) vm_page_lock_KBI((m), LOCK_FILE,
LOCK_LINE)
+#definevm_page_unlock(m) vm_page_unlock_KBI((m), LOCK_FILE,
LOCK_LINE)
+#definevm_page_trylock(m) vm_page_trylock_KBI((m), LOCK_FILE,
LOCK_LINE)
+#ifdef INVARIANTS
+#definevm_page_lock_assert(m, a) \
+vm_page_lock_assert_KBI((m), (a), LOCK_FILE, LOCK_LINE)
+#else
+#definevm_page_lock_assert(m, a)
+#endif
+#else /* KLD_MODULE */
#definevm_page_lockptr(m) (PA_LOCKPTR(VM_PAGE_TO_PHYS((m
#definevm_page_lock(m) mtx_lock(vm_page_lockptr((m)))
#definevm_page_unlock(m) mtx_unlock(vm_page_lockptr((m)))
#definevm_page_trylock(m) mtx_trylock(vm_page_lockptr((m)))
#definevm_page_lock_assert(m, a)
mtx_assert(vm_page_lockptr((m)), (a))
+#endif
#definevm_page_queue_free_mtx vm_page_queue_free_lock.data
/*
@@ -403,6 +415,11 @@ void vm_page_cowfault (vm_page_t);
int vm_page_cowsetup(vm_page_t);
void vm_page_cowclear (vm_page_t);
+void vm_page_lock_KBI(vm_page_t m, const char *file, int line);
+void vm_page_unlock_KBI(vm_page_t m, const char *file, int line);
+int vm_page_trylock_KBI(vm_page_t m, const char *file, int line);
+void vm_page_lock_assert_KBI(vm_page_t m, int a, const char *file, int line);
+
#ifdef INVARIANTS
void vm_page_object_lock_assert(vm_page_t m);
#defineVM_PAGE_OBJECT_LOCK_ASSERT(m) vm_page_object_lock_assert(m)
pgpxFZVFLBvYF.pgp
Description: PGP signature
Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]
Hi, On Mon, Nov 7, 2011 at 2:03 PM, Arnaud Lacombe lacom...@gmail.com wrote: On Mon, Nov 7, 2011 at 4:36 AM, Attilio Rao atti...@freebsd.org wrote: I'm unsure if this replies to your concerns because you just criticize without making a real technical question in this post. I made comments on 3 points: - using internal implementation details of mutex(9) is broken - LOCK_FILE/LOCK_LINE are broken (a bit of a divergence on the original subject :/) - there is _no_ reason not to use inlines function for such trivial oneliners ok, I read the original thread, now that I understand the purpose of the patch. It would make the third comment irrelevant, but I still do not agree about the reason of the patch. - ARnaud ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]
On Mon, Nov 7, 2011 at 11:35 AM, Kostik Belousov kostik...@gmail.com wrote:
On Mon, Nov 07, 2011 at 11:45:38AM -0600, Alan Cox wrote:
Ok. I'll offer one final suggestion. Please consider an alternative
suffix to func. Perhaps, kbi or KBI. In other words, something
that hints at the function's reason for existing.
Sure. Below is the extraction of only vm_page_lock() bits, together
with the suggested rename. When Attilio provides the promised simplification
of the mutex KPI, this can be reduced.
diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c
index 389aea5..ea4ea34 100644
--- a/sys/vm/vm_page.c
+++ b/sys/vm/vm_page.c
@@ -2677,6 +2677,44 @@ vm_page_test_dirty(vm_page_t m)
vm_page_dirty(m);
}
+void
+vm_page_lock_KBI(vm_page_t m, const char *file, int line)
+{
+
+#if LOCK_DEBUG 0 || defined(MUTEX_NOINLINE)
+ _mtx_lock_flags(vm_page_lockptr(m), 0, file, line);
+#else
+ __mtx_lock(vm_page_lockptr(m), 0, file, line);
+#endif
+}
+
+void
+vm_page_unlock_KBI(vm_page_t m, const char *file, int line)
+{
+
+#if LOCK_DEBUG 0 || defined(MUTEX_NOINLINE)
+ _mtx_unlock_flags(vm_page_lockptr(m), 0, file, line);
+#else
+ __mtx_unlock(vm_page_lockptr(m), curthread, 0, file, line);
+#endif
+}
+
+int
+vm_page_trylock_KBI(vm_page_t m, const char *file, int line)
+{
+
+ return (_mtx_trylock(vm_page_lockptr(m), 0, file, line));
+}
+
+void
+vm_page_lock_assert_KBI(vm_page_t m, int a, const char *file, int line)
+{
+
+#ifdef INVARIANTS
+ _mtx_assert(vm_page_lockptr(m), a, file, line);
+#endif
+}
+
int so_zerocp_fullpage = 0;
/*
diff --git a/sys/vm/vm_page.h b/sys/vm/vm_page.h
index 7099b70..a5604b7 100644
--- a/sys/vm/vm_page.h
+++ b/sys/vm/vm_page.h
@@ -218,11 +218,23 @@ extern struct vpglocks pa_lock[];
#define PA_LOCK_ASSERT(pa, a) mtx_assert(PA_LOCKPTR(pa), (a))
+#ifdef KLD_MODULE
+#define vm_page_lock(m) vm_page_lock_KBI((m), LOCK_FILE,
LOCK_LINE)
+#define vm_page_unlock(m) vm_page_unlock_KBI((m), LOCK_FILE,
LOCK_LINE)
+#define vm_page_trylock(m) vm_page_trylock_KBI((m), LOCK_FILE,
LOCK_LINE)
+#ifdef INVARIANTS
+#define vm_page_lock_assert(m, a) \
+ vm_page_lock_assert_KBI((m), (a), LOCK_FILE, LOCK_LINE)
+#else
+#define vm_page_lock_assert(m, a)
+#endif
+#else /* KLD_MODULE */
#define vm_page_lockptr(m) (PA_LOCKPTR(VM_PAGE_TO_PHYS((m
Is it not possible to have vm_page_lockptr() be a function for the
KLD_MODULE case? Because then the vm_page_lock() functions and
friends would all just use mtx_lock, etc., in both the KLD and non-KLD
case.
Or am I missing something?
Thanks,
matthew
#define vm_page_lock(m) mtx_lock(vm_page_lockptr((m)))
#define vm_page_unlock(m) mtx_unlock(vm_page_lockptr((m)))
#define vm_page_trylock(m) mtx_trylock(vm_page_lockptr((m)))
#define vm_page_lock_assert(m, a)
mtx_assert(vm_page_lockptr((m)), (a))
+#endif
#define vm_page_queue_free_mtx vm_page_queue_free_lock.data
/*
@@ -403,6 +415,11 @@ void vm_page_cowfault (vm_page_t);
int vm_page_cowsetup(vm_page_t);
void vm_page_cowclear (vm_page_t);
+void vm_page_lock_KBI(vm_page_t m, const char *file, int line);
+void vm_page_unlock_KBI(vm_page_t m, const char *file, int line);
+int vm_page_trylock_KBI(vm_page_t m, const char *file, int line);
+void vm_page_lock_assert_KBI(vm_page_t m, int a, const char *file, int line);
+
#ifdef INVARIANTS
void vm_page_object_lock_assert(vm_page_t m);
#define VM_PAGE_OBJECT_LOCK_ASSERT(m) vm_page_object_lock_assert(m)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]
On Mon, Nov 07, 2011 at 11:47:59AM -0800, m...@freebsd.org wrote:
On Mon, Nov 7, 2011 at 11:35 AM, Kostik Belousov kostik...@gmail.com wrote:
On Mon, Nov 07, 2011 at 11:45:38AM -0600, Alan Cox wrote:
Ok. I'll offer one final suggestion. Please consider an alternative
suffix to func. Perhaps, kbi or KBI. In other words, something
that hints at the function's reason for existing.
Sure. Below is the extraction of only vm_page_lock() bits, together
with the suggested rename. When Attilio provides the promised simplification
of the mutex KPI, this can be reduced.
diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c
index 389aea5..ea4ea34 100644
--- a/sys/vm/vm_page.c
+++ b/sys/vm/vm_page.c
@@ -2677,6 +2677,44 @@ vm_page_test_dirty(vm_page_t m)
vm_page_dirty(m);
}
+void
+vm_page_lock_KBI(vm_page_t m, const char *file, int line)
+{
+
+#if LOCK_DEBUG 0 || defined(MUTEX_NOINLINE)
+ _mtx_lock_flags(vm_page_lockptr(m), 0, file, line);
+#else
+ __mtx_lock(vm_page_lockptr(m), 0, file, line);
+#endif
+}
+
+void
+vm_page_unlock_KBI(vm_page_t m, const char *file, int line)
+{
+
+#if LOCK_DEBUG 0 || defined(MUTEX_NOINLINE)
+ _mtx_unlock_flags(vm_page_lockptr(m), 0, file, line);
+#else
+ __mtx_unlock(vm_page_lockptr(m), curthread, 0, file, line);
+#endif
+}
+
+int
+vm_page_trylock_KBI(vm_page_t m, const char *file, int line)
+{
+
+ return (_mtx_trylock(vm_page_lockptr(m), 0, file, line));
+}
+
+void
+vm_page_lock_assert_KBI(vm_page_t m, int a, const char *file, int line)
+{
+
+#ifdef INVARIANTS
+ _mtx_assert(vm_page_lockptr(m), a, file, line);
+#endif
+}
+
int so_zerocp_fullpage = 0;
/*
diff --git a/sys/vm/vm_page.h b/sys/vm/vm_page.h
index 7099b70..a5604b7 100644
--- a/sys/vm/vm_page.h
+++ b/sys/vm/vm_page.h
@@ -218,11 +218,23 @@ extern struct vpglocks pa_lock[];
#define PA_LOCK_ASSERT(pa, a) mtx_assert(PA_LOCKPTR(pa), (a))
+#ifdef KLD_MODULE
+#define vm_page_lock(m) vm_page_lock_KBI((m), LOCK_FILE,
LOCK_LINE)
+#define vm_page_unlock(m) vm_page_unlock_KBI((m), LOCK_FILE,
LOCK_LINE)
+#define vm_page_trylock(m) vm_page_trylock_KBI((m), LOCK_FILE,
LOCK_LINE)
+#ifdef INVARIANTS
+#define vm_page_lock_assert(m, a) \
+ vm_page_lock_assert_KBI((m), (a), LOCK_FILE, LOCK_LINE)
+#else
+#define vm_page_lock_assert(m, a)
+#endif
+#else /* KLD_MODULE */
#define vm_page_lockptr(m) (PA_LOCKPTR(VM_PAGE_TO_PHYS((m
Is it not possible to have vm_page_lockptr() be a function for the
KLD_MODULE case? Because then the vm_page_lock() functions and
friends would all just use mtx_lock, etc., in both the KLD and non-KLD
case.
Or am I missing something?
It is possible, but I tried to avoid exposing lockptr.
IMHO vm_page_lockptr() is an implementation detail.
Please also see my other response to Alan regarding the relocking macros.
pgpYgFHehhwCS.pgp
Description: PGP signature
Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]
Hi,
On Mon, Nov 7, 2011 at 2:35 PM, Kostik Belousov kostik...@gmail.com wrote:
On Mon, Nov 07, 2011 at 11:45:38AM -0600, Alan Cox wrote:
Ok. I'll offer one final suggestion. Please consider an alternative
suffix to func. Perhaps, kbi or KBI. In other words, something
that hints at the function's reason for existing.
Sure. Below is the extraction of only vm_page_lock() bits, together
with the suggested rename. When Attilio provides the promised simplification
of the mutex KPI, this can be reduced.
If you want to be pedantic, you also must hide the definition of
`struct vm_page' when KLD_MODULE is defined. You want to be sure no
one is gonna mess with the internal of the structure (ie. either
directly dereference fields, compute size or any offset...) and will
have no other choice but to use assessors.
Maybe you are addressing this in another patch.
- Arnaud
diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c
index 389aea5..ea4ea34 100644
--- a/sys/vm/vm_page.c
+++ b/sys/vm/vm_page.c
@@ -2677,6 +2677,44 @@ vm_page_test_dirty(vm_page_t m)
vm_page_dirty(m);
}
+void
+vm_page_lock_KBI(vm_page_t m, const char *file, int line)
+{
+
+#if LOCK_DEBUG 0 || defined(MUTEX_NOINLINE)
+ _mtx_lock_flags(vm_page_lockptr(m), 0, file, line);
+#else
+ __mtx_lock(vm_page_lockptr(m), 0, file, line);
+#endif
+}
+
+void
+vm_page_unlock_KBI(vm_page_t m, const char *file, int line)
+{
+
+#if LOCK_DEBUG 0 || defined(MUTEX_NOINLINE)
+ _mtx_unlock_flags(vm_page_lockptr(m), 0, file, line);
+#else
+ __mtx_unlock(vm_page_lockptr(m), curthread, 0, file, line);
+#endif
+}
+
+int
+vm_page_trylock_KBI(vm_page_t m, const char *file, int line)
+{
+
+ return (_mtx_trylock(vm_page_lockptr(m), 0, file, line));
+}
+
+void
+vm_page_lock_assert_KBI(vm_page_t m, int a, const char *file, int line)
+{
+
+#ifdef INVARIANTS
+ _mtx_assert(vm_page_lockptr(m), a, file, line);
+#endif
+}
+
int so_zerocp_fullpage = 0;
/*
diff --git a/sys/vm/vm_page.h b/sys/vm/vm_page.h
index 7099b70..a5604b7 100644
--- a/sys/vm/vm_page.h
+++ b/sys/vm/vm_page.h
@@ -218,11 +218,23 @@ extern struct vpglocks pa_lock[];
#define PA_LOCK_ASSERT(pa, a) mtx_assert(PA_LOCKPTR(pa), (a))
+#ifdef KLD_MODULE
+#define vm_page_lock(m) vm_page_lock_KBI((m), LOCK_FILE,
LOCK_LINE)
+#define vm_page_unlock(m) vm_page_unlock_KBI((m), LOCK_FILE,
LOCK_LINE)
+#define vm_page_trylock(m) vm_page_trylock_KBI((m), LOCK_FILE,
LOCK_LINE)
+#ifdef INVARIANTS
+#define vm_page_lock_assert(m, a) \
+ vm_page_lock_assert_KBI((m), (a), LOCK_FILE, LOCK_LINE)
+#else
+#define vm_page_lock_assert(m, a)
+#endif
+#else /* KLD_MODULE */
#define vm_page_lockptr(m) (PA_LOCKPTR(VM_PAGE_TO_PHYS((m
#define vm_page_lock(m) mtx_lock(vm_page_lockptr((m)))
#define vm_page_unlock(m) mtx_unlock(vm_page_lockptr((m)))
#define vm_page_trylock(m) mtx_trylock(vm_page_lockptr((m)))
#define vm_page_lock_assert(m, a)
mtx_assert(vm_page_lockptr((m)), (a))
+#endif
#define vm_page_queue_free_mtx vm_page_queue_free_lock.data
/*
@@ -403,6 +415,11 @@ void vm_page_cowfault (vm_page_t);
int vm_page_cowsetup(vm_page_t);
void vm_page_cowclear (vm_page_t);
+void vm_page_lock_KBI(vm_page_t m, const char *file, int line);
+void vm_page_unlock_KBI(vm_page_t m, const char *file, int line);
+int vm_page_trylock_KBI(vm_page_t m, const char *file, int line);
+void vm_page_lock_assert_KBI(vm_page_t m, int a, const char *file, int line);
+
#ifdef INVARIANTS
void vm_page_object_lock_assert(vm_page_t m);
#define VM_PAGE_OBJECT_LOCK_ASSERT(m) vm_page_object_lock_assert(m)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Panic in the udp_input() under heavy load
On 11/7/2011 10:24 AM, Bjoern A. Zeeb wrote: Unlikely; the inp is properly locked there and the udp info attach better still be valid there; your problem is most likely elsewhere; try to see if you have other threads and see what they do at the same time, etc. You would need to race with udp_detach(); you also want to make sure that the inp still looks sane from either ddb or a dump and we are not talking about random memory corruption here. Well, as you can see from the trace it points pretty strongly to that piece of code. And as I said this panic is completely reproducible, we've seen it at least 5 times to date in exactly this location. Unfortunately the trace is rather long so we could not capture it in full before, until we've switched to the 80x50 mode. If it was a memory corruption it would be just random fault, while here we have it failing in this point reliably. Unfortunately the panic happens in the driver thread context (I believe), so the KDB/dump is not working. After panicing the machine just hangs there. Keyboard is not working and I need to do a hard reset. Is there any other explanation that you can think of? Is it possible for some other portion of the code (i.e. network driver, DMA engine etc) to trash this structure by writing something off bound? Or something along the lines? Thanks! Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts Tel: +1-646-651-1110 Fax: +1-866-857-6942 Web: http://www.sippysoft.com MSN: sa...@sippysoft.com Skype: SippySoft ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Panic in the udp_input() under heavy load
On 11/7/2011 2:57 PM, Maxim Sobolev wrote:
On 11/7/2011 10:24 AM, Bjoern A. Zeeb wrote:
Unlikely; the inp is properly locked there and the udp info attach
better still be valid there; your problem is most likely elsewhere;
try to see if you have other threads and see what they do at the same
time, etc. You would need to race with udp_detach(); you also want
to make sure that the inp still looks sane from either ddb or a dump
and we are not talking about random memory corruption here.
Well, as you can see from the trace it points pretty strongly to that
piece of code. And as I said this panic is completely reproducible,
we've seen it at least 5 times to date in exactly this location.
Unfortunately the trace is rather long so we could not capture it in
full before, until we've switched to the 80x50 mode.
If it was a memory corruption it would be just random fault, while here
we have it failing in this point reliably.
Unfortunately the panic happens in the driver thread context (I
believe), so the KDB/dump is not working. After panicing the machine
just hangs there. Keyboard is not working and I need to do a hard reset.
Is there any other explanation that you can think of? Is it possible for
some other portion of the code (i.e. network driver, DMA engine etc) to
trash this structure by writing something off bound? Or something along
the lines?
OK, I've put the following catch to prove the case:
up = intoudpcb(inp);
if (up == NULL) {
printf(BZZT! Something is terribly wrong, up == NULL!\n);
INP_RUNLOCK(inp);
goto badunlocked;
}
if (up-u_tun_func == NULL) {
I am going to give it a spin on two busiest boxes and see if I can log
anything.
Regards,
--
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
Tel: +1-646-651-1110
Fax: +1-866-857-6942
Web: http://www.sippysoft.com
MSN: sa...@sippysoft.com
Skype: SippySoft
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
