Re: 10.0-CUR r226986 ports (general)
El día Wednesday, November 02, 2011 a las 08:36:07PM +0100, Matthias Apitz escribió: Hello, I fetched 10-CUR from SVN as r226986 and /usr/ports from CVS on November 1st; The ports/audio/jack seems installing fine, but the shared lib libjack.so is missing below ports/audio/jack/work and /usr/local/lib; it is mentioned in the list -L of the package; later ports/audio/arts and ports/x11/kde3 are missing the shared lib; It turns out that the problem is more general! A lot of ./configure scripts are detecting in 10-CUR that they can't or should not build shared libs; the problem is that the OS is detected now as host_os: freebsd10.0 and the ./configure scripts have tests like this: ports/audio/jack/work/jack-audio-connection-kit-0.121.3: case $host_os in ... freebsd1*) dynamic_linker=no ;; ... And now? I'm cluesless now how we could solve this :-( matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e g...@unixarea.de - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 ___ 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: 10.0-CUR r226986 ports (general)
On 3 Nov 2011 06:11, Matthias Apitz g...@unixarea.de wrote: El día Wednesday, November 02, 2011 a las 08:36:07PM +0100, Matthias Apitz escribió: Hello, I fetched 10-CUR from SVN as r226986 and /usr/ports from CVS on November 1st; The ports/audio/jack seems installing fine, but the shared lib libjack.so is missing below ports/audio/jack/work and /usr/local/lib; it is mentioned in the list -L of the package; later ports/audio/arts and ports/x11/kde3 are missing the shared lib; It turns out that the problem is more general! A lot of ./configure scripts are detecting in 10-CUR that they can't or should not build shared libs; the problem is that the OS is detected now as host_os: freebsd10.0 and the ./configure scripts have tests like this: ports/audio/jack/work/jack-audio-connection-kit-0.121.3: case $host_os in ... freebsd1*) dynamic_linker=no ;; ... And now? I'm cluesless now how we could solve this :-( Searching the archives of both these lists would help you ;) Chris ___ 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: request: merging if_ath_tx branch to HEAD
On 31 October 2011 20:15, Doug Barton do...@freebsd.org wrote: In any case, I do want to merge the ath 11n stuff into -9, so even if it's not done by 9.0, it'll be done shortly after. Given that RC1 is already out, you should probably check with re@ first. I'll poke them tomorrow, but since others have merged in driver changes and other stuff into -HEAD, I wouldn't be the first person to merge in bigger things. Adrian ___ 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
[RFC] Fix OF_finddevice return code for FDT
[I had posted this to freebsd-ppc@ and freebsd-arm@, did not see any comments, posting to freebsd-current@ to see if there is any interest or comments] While reviewing the previous FDT patch, nwhitehorn@ noted that the return code of OF_finddevice was not correct in case of FDT. According to the 1275 standard, we should return a phandle value of -1 in case of error, but the ofw_fdt_finddevice implementation now returns 0. The attached patches fixes this in the FDT code, and makes changes in the callers to check the return code correctly. Since most of the callers are in ARM, any testing on ARM would be really appreciated. Thanks, JC. fdt-finddevice-fix.patch Description: Binary data arm-fixes.patch Description: Binary data ppc-fixes.patch Description: Binary data ___ 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: USB3 express card panics on 9.0-RC1
On Wednesday 02 November 2011 16:22:20 Jan Henrik Sylvester wrote: I have bought a Super-speed Express Card To USB 3.0 1-Port to connect an USB3 hard disk to my Thinkpad T510, which only has USB2. Trying to hot plug the express card did nothing, but I guess that is expected. Hence, I booted with the express card already inserted, only to receive a panic upon xhci0 initialization, see below. This is on FreeBSD 9.0-RC1/amd64 with a generic kernel installed from the official DVD. I guess I could test 226803 mentioned in http://lists.freebsd.org/pipermail/freebsd-usb/2011-October/010746.html , which happened after RC1, but from the commit message, it only fixes suspend and resume. As I do not have much time now, should I test 226803, find a Linux CD to actually identify the device, or anything else? Cheers, Jan Henrik usbus0: 480 Mbps High Speed USB v2.0 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x18 fault code = supervisor write data, page not present instruction ponter = 0x20:0x806e80aa stack pointer = 0x28:0xff810ee50bc0 frame pointer = 0x28:0xff810ee50bf0 code segment= base 0x0, limit 0xf, type 0x16 = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 15 (xhci0) trap number = 12 panic: page fault cpuid = 0 Uptime = 1s Automatic reboot in 15 seconds - press a key on the console to abort Hi, This looks like a NULL-pointer issue inside xhci_configure_msg() which probably should be easy to fix. Could you compile and boot a kernel with kernel debugging enable so that you get a backgtrace? --HPS ___ 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: 10.0-CUR r226986 ports (general)
Wiadomość napisana przez Matthias Apitz w dniu 3 lis 2011, o godz. 07:10: El día Wednesday, November 02, 2011 a las 08:36:07PM +0100, Matthias Apitz escribió: Hello, I fetched 10-CUR from SVN as r226986 and /usr/ports from CVS on November 1st; The ports/audio/jack seems installing fine, but the shared lib libjack.so is missing below ports/audio/jack/work and /usr/local/lib; it is mentioned in the list -L of the package; later ports/audio/arts and ports/x11/kde3 are missing the shared lib; It turns out that the problem is more general! A lot of ./configure scripts are detecting in 10-CUR that they can't or should not build shared libs; the problem is that the OS is detected now as As a temporary workaround, add WITH_FBSD10_FIX=1 to /etc/make.conf. -- If you cut off my head, what would I say? Me and my head, or me and my body? ___ 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: 10.0-CUR r226986 ports (general)
El día Thursday, November 03, 2011 a las 12:13:31PM +0100, Edward Tomasz Napierała escribió: It turns out that the problem is more general! A lot of ./configure scripts are detecting in 10-CUR that they can't or should not build shared libs; the problem is that the OS is detected now as As a temporary workaround, add WITH_FBSD10_FIX=1 to /etc/make.conf. ports/UPDATING and some of the mails in the archive of -current recommend setting UNAME_r=9.0-CURRENT; is this the same or which method is prefered? Thanks matthias -- Matthias Apitz e g...@unixarea.de - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 ___ 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: 10.0-CUR r226986 ports (general)
On Thu Nov 3 11, Matthias Apitz wrote: El día Wednesday, November 02, 2011 a las 08:36:07PM +0100, Matthias Apitz escribió: Hello, I fetched 10-CUR from SVN as r226986 and /usr/ports from CVS on November 1st; The ports/audio/jack seems installing fine, but the shared lib libjack.so is missing below ports/audio/jack/work and /usr/local/lib; it is mentioned in the list -L of the package; later ports/audio/arts and ports/x11/kde3 are missing the shared lib; It turns out that the problem is more general! A lot of ./configure scripts are detecting in 10-CUR that they can't or should not build shared libs; the problem is that the OS is detected now as host_os: freebsd10.0 and the ./configure scripts have tests like this: ports/audio/jack/work/jack-audio-connection-kit-0.121.3: case $host_os in ... freebsd1*) dynamic_linker=no ;; ... And now? I'm cluesless now how we could solve this :-( are you sure this issue is related to the freebsd1* case? uname -a FreeBSD otaku 9.9-CURRENT FreeBSD 9.9-CURRENT #9: Thu Nov 3 11:41:08 CET 2011 arundel@otaku:/usr/obj/usr/git-freebsd-head/sys/ARUNDEL amd64 i did a 'cd /usr/ports/security/p11-kit ; make ; make install', yet from the following list: otaku% pkg_info -L p11-kit-0.8 Information for p11-kit-0.8: Files: /usr/local/bin/p11-kit /usr/local/include/p11-kit-1/p11-kit/p11-kit.h /usr/local/include/p11-kit-1/p11-kit/pin.h /usr/local/include/p11-kit-1/p11-kit/uri.h /usr/local/include/p11-kit-1/p11-kit/pkcs11.h /usr/local/lib/libp11-kit.a /usr/local/lib/libp11-kit.la /usr/local/lib/libp11-kit.so /usr/local/lib/libp11-kit.so.0 /usr/local/lib/p11-kit-proxy.so /usr/local/libdata/pkgconfig/p11-kit-1.pc /usr/local/share/gtk-doc/html/p11-kit/api-index-full.html /usr/local/share/gtk-doc/html/p11-kit/config-example.html /usr/local/share/gtk-doc/html/p11-kit/config-format.html /usr/local/share/gtk-doc/html/p11-kit/config-global.html /usr/local/share/gtk-doc/html/p11-kit/config-locations.html /usr/local/share/gtk-doc/html/p11-kit/config-module.html /usr/local/share/gtk-doc/html/p11-kit/config.html /usr/local/share/gtk-doc/html/p11-kit/gtk-doc.css /usr/local/share/gtk-doc/html/p11-kit/home.png /usr/local/share/gtk-doc/html/p11-kit/index.html /usr/local/share/gtk-doc/html/p11-kit/index.sgml /usr/local/share/gtk-doc/html/p11-kit/left.png /usr/local/share/gtk-doc/html/p11-kit/p11-kit-Future.html /usr/local/share/gtk-doc/html/p11-kit/p11-kit-Modules.html /usr/local/share/gtk-doc/html/p11-kit/p11-kit-PIN-Callbacks.html /usr/local/share/gtk-doc/html/p11-kit/p11-kit-URIs.html /usr/local/share/gtk-doc/html/p11-kit/p11-kit-Utilities.html /usr/local/share/gtk-doc/html/p11-kit/p11-kit.devhelp2 /usr/local/share/gtk-doc/html/p11-kit/up.png /usr/local/share/gtk-doc/html/p11-kit/reference.html /usr/local/share/gtk-doc/html/p11-kit/right.png /usr/local/share/gtk-doc/html/p11-kit/sharing-initialize.html /usr/local/share/gtk-doc/html/p11-kit/sharing-module.html /usr/local/share/gtk-doc/html/p11-kit/sharing.html /usr/local/share/gtk-doc/html/p11-kit/style.css /usr/local/share/examples/p11-kit/pkcs11.conf.example all *.so* files didn't get installed! cheers. alex matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e g...@unixarea.de - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 ___ 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: USB3 express card panics on 9.0-RC1
On 11/03/2011 09:27, Hans Petter Selasky wrote: On Wednesday 02 November 2011 16:22:20 Jan Henrik Sylvester wrote: I have bought a Super-speed Express Card To USB 3.0 1-Port to connect an USB3 hard disk to my Thinkpad T510, which only has USB2. Trying to hot plug the express card did nothing, but I guess that is expected. Hence, I booted with the express card already inserted, only to receive a panic upon xhci0 initialization, see below. This is on FreeBSD 9.0-RC1/amd64 with a generic kernel installed from the official DVD. I guess I could test 226803 mentioned in http://lists.freebsd.org/pipermail/freebsd-usb/2011-October/010746.html , which happened after RC1, but from the commit message, it only fixes suspend and resume. As I do not have much time now, should I test 226803, find a Linux CD to actually identify the device, or anything else? Cheers, Jan Henrik usbus0: 480 Mbps High Speed USB v2.0 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x18 fault code = supervisor write data, page not present instruction ponter = 0x20:0x806e80aa stack pointer = 0x28:0xff810ee50bc0 frame pointer = 0x28:0xff810ee50bf0 code segment= base 0x0, limit 0xf, type 0x16 = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 15 (xhci0) trap number = 12 panic: page fault cpuid = 0 Uptime = 1s Automatic reboot in 15 seconds - press a key on the console to abort Hi, This looks like a NULL-pointer issue inside xhci_configure_msg() which probably should be easy to fix. Could you compile and boot a kernel with kernel debugging enable so that you get a backgtrace? I have not done this before. The GENERIC kernel already contains makeoptions DEBUG=-g (at least it is in /usr/src/sys/amd64/conf/GENERIC and there are all this large /boot/kernel/*.symbols). Is there anything else needed? (I do not need all the stuff that Ken Smith took out just before RC1 in r226405 just to get a trace, since I do not want to do online debugging, or do I need it anyhow?) From http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html , I thought that setting dumpdev=AUTO in /etc/rc.conf was enough to get a dump in /var/crash/ after the next boot to multiuser. That does not seem to be the case for me. What else do I have to do? Cheers, Jan Henrik ___ 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: 10.0-CUR r226986 ports (general)
Wiadomość napisana przez Matthias Apitz w dniu 3 lis 2011, o godz. 12:26: El día Thursday, November 03, 2011 a las 12:13:31PM +0100, Edward Tomasz Napierała escribió: It turns out that the problem is more general! A lot of ./configure scripts are detecting in 10-CUR that they can't or should not build shared libs; the problem is that the OS is detected now as As a temporary workaround, add WITH_FBSD10_FIX=1 to /etc/make.conf. ports/UPDATING and some of the mails in the archive of -current recommend setting UNAME_r=9.0-CURRENT; is this the same or which method is prefered? No, I guess UPDATING is right. It's just that I never remember to read it when encountering problems after an update, and the above method works for me. -- If you cut off my head, what would I say? Me and my head, or me and my body? ___ 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: gmirror failed with error 19.
On Tue, 2011-11-01 11:23 +0400, Andrey V. Elsukov wrote: On 28.10.2011 13:48, Sascha Klauder wrote: GEOM_MIRROR: Device mirror/gm0 launched (2/2). GEOM_PART: partition 1 has end offset beyond last LBA: 490350671 490350670 GEOM_PART: integrity check failed (mirror/gm0, MBR) This is the main problem. Your MBR' slice is bigger than actual space you have. The only way to fix this - recreate slice. I've partioned and labeled the disk with sysinstall(8) from 8.2-RELEASE media. Does 9.0 use different disk geometry cal- culation than 8.2 or is usage of gmirror the culprit? Both 8.2 and 9.0 kernels report the disk having 490350672 sectors. You can break your mirror, recreate the slice (NOTE: you must preserve one sector for the gmirror's meta-data), then copy your data to the newly created slice, then reboot from the new slice and recreate mirror. I think I'd rather reinstall 9.0 from scratch, getting rid of MBR/disklabel as well. Cheers, -sascha ___ 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: 10.0-CUR r226986 ports (general)
El día Thursday, November 03, 2011 a las 11:28:47AM +, Alexander Best escribió: It turns out that the problem is more general! A lot of ./configure scripts are detecting in 10-CUR that they can't or should not build shared libs; the problem is that the OS is detected now as host_os: freebsd10.0 and the ./configure scripts have tests like this: ports/audio/jack/work/jack-audio-connection-kit-0.121.3: case $host_os in ... freebsd1*) dynamic_linker=no ;; ... And now? I'm cluesless now how we could solve this :-( are you sure this issue is related to the freebsd1* case? I can only comment what I saw: - OS was detected as freebsd10.0 (I inserted a 'echo $host_os' into the ./configure script - ./configure said that it should/will not build shared libs - the *.so* were missing in ports/audio/jack/work/... and in /usr/local/lib I will remove all /usr/ports/* and /usr/local/* and /var/db/pkg/* and will start from scratch with cvs checkout and will set UNAME_r as explained in ports/UPDATING; will let you know the result matthias -- Matthias Apitz e g...@unixarea.de - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 ___ 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: USB3 express card panics on 9.0-RC1
On 11/03/2011 11:51, Jan Henrik Sylvester wrote: On 11/03/2011 09:27, Hans Petter Selasky wrote: On Wednesday 02 November 2011 16:22:20 Jan Henrik Sylvester wrote: I have bought a Super-speed Express Card To USB 3.0 1-Port to connect an USB3 hard disk to my Thinkpad T510, which only has USB2. Trying to hot plug the express card did nothing, but I guess that is expected. Hence, I booted with the express card already inserted, only to receive a panic upon xhci0 initialization, see below. This is on FreeBSD 9.0-RC1/amd64 with a generic kernel installed from the official DVD. I guess I could test 226803 mentioned in http://lists.freebsd.org/pipermail/freebsd-usb/2011-October/010746.html , which happened after RC1, but from the commit message, it only fixes suspend and resume. As I do not have much time now, should I test 226803, find a Linux CD to actually identify the device, or anything else? Cheers, Jan Henrik usbus0: 480 Mbps High Speed USB v2.0 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x18 fault code = supervisor write data, page not present instruction ponter = 0x20:0x806e80aa stack pointer = 0x28:0xff810ee50bc0 frame pointer = 0x28:0xff810ee50bf0 code segment = base 0x0, limit 0xf, type 0x16 = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 15 (xhci0) trap number = 12 panic: page fault cpuid = 0 Uptime = 1s Automatic reboot in 15 seconds - press a key on the console to abort Hi, This looks like a NULL-pointer issue inside xhci_configure_msg() which probably should be easy to fix. Could you compile and boot a kernel with kernel debugging enable so that you get a backgtrace? I have not done this before. The GENERIC kernel already contains makeoptions DEBUG=-g (at least it is in /usr/src/sys/amd64/conf/GENERIC and there are all this large /boot/kernel/*.symbols). Is there anything else needed? (I do not need all the stuff that Ken Smith took out just before RC1 in r226405 just to get a trace, since I do not want to do online debugging, or do I need it anyhow?) From http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html , I thought that setting dumpdev=AUTO in /etc/rc.conf was enough to get a dump in /var/crash/ after the next boot to multiuser. That does not seem to be the case for me. What else do I have to do? After reading a bit more, I still do not know why I do not get a crash dump with dumpdev=AUTO (and /var/crash/ having enough space for a full memory dump). Is it too early during boot for dumpon to be set? After reading http://www.unixguide.net/freebsd/faq/18.13.shtml , I found that 806e8040 t usb_process is the last symbol before instruction pointer = 0x20:0x806e80aa. Does this help? Cheers, Jan Henrik ___ 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 at vm_page_wire with FreeBSD 9.0 Beta 3
On Thu, Nov 03, 2011 at 12:40:08AM -0500, Alan Cox wrote:
On 11/02/2011 05:32, Andriy Gapon wrote:
[restored cc: to the original poster]
As Bruce Evans has pointed to me privately [I am not sure why privately],
there
is already an example in i386 and amd64 atomic.h, where operations are
inlined
for a kernel build, but presented as real (external) functions for a module
build. You can search e.g. sys/amd64/include/atomic.h for KLD_MODULE.
I think that the same treatment could/should be applied to vm_page_*lock*
operations defined in sys/vm/vm_page.h.
*snip*
Yes, it should be. There are without question legitimate reasons for a
module to acquire a page lock.
I agree. Also, I think that we should use the opportunity to also isolate
the modules from the struct vm_page layout changes. As example, I converted
nfsclient.ko.
Patch is not tested.
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 f14da4a..5b8b4e3 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
+}
+
+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
+}
+
+int
+vm_page_trylock_func(vm_page_t m, const char *file, int line)
+{
+
+ return (_mtx_trylock(vm_page_lockptr(m), 0, file, line));
+}
+
+void
+vm_page_lock_assert_func(vm_page_t m, int a, const char *file, int line)
+{
+
+#ifdef INVARIANTS
+ _mtx_assert(vm_page_lockptr(m), a, file, line);
+#endif
+}
+
+vm_page_bits_t
+vm_page_read_dirty_func(vm_page_t m)
+{
+
+ return (m-dirty);
+}
+
+vm_page_bits_t
+vm_page_read_valid_func(vm_page_t m)
+{
+
+ return (m-valid);
+}
+
+void
+vm_page_write_valid_func(vm_page_t m, vm_page_bits_t v)
+{
+
+ m-valid = v;
+}
+
+
int so_zerocp_fullpage = 0;
/*
diff --git a/sys/vm/vm_page.h b/sys/vm/vm_page.h
index 23637bb..618ba2b 100644
--- a/sys/vm/vm_page.h
+++ b/sys/vm/vm_page.h
@@ -113,6 +113,21 @@
TAILQ_HEAD(pglist, vm_page);
+#if PAGE_SIZE == 4096
+#define VM_PAGE_BITS_ALL 0xffu
+typedef uint8_t vm_page_bits_t;
+#elif PAGE_SIZE == 8192
+#define VM_PAGE_BITS_ALL 0xu
+typedef uint16_t vm_page_bits_t;
+#elif PAGE_SIZE == 16384
+#define VM_PAGE_BITS_ALL 0xu
+typedef uint32_t vm_page_bits_t;
+#elif PAGE_SIZE == 32768
+#define VM_PAGE_BITS_ALL 0xlu
+typedef uint64_t vm_page_bits_t;
+#endif
+
+
struct vm_page {
TAILQ_ENTRY(vm_page) pageq; /* queue info for FIFO queue or free
list (Q) */
TAILQ_ENTRY(vm_page) listq; /* pages in same object (O) */
@@ -138,19 +153,8 @@ struct vm_page {
/* NOTE that these must support one bit per DEV_BSIZE in a page!!! */
/* so, on normal X86 kernels, they must be at least 8 bits wide */
/* In reality, support for 32KB pages is not fully implemented. */
-#if PAGE_SIZE == 4096
- uint8_t valid; /* map of valid DEV_BSIZE chunks (O) */
- uint8_t dirty; /* map of dirty
Re: 10.0-CUR r226986 ports (general)
On Thu Nov 3 11, Matthias Apitz wrote: El día Thursday, November 03, 2011 a las 11:28:47AM +, Alexander Best escribió: It turns out that the problem is more general! A lot of ./configure scripts are detecting in 10-CUR that they can't or should not build shared libs; the problem is that the OS is detected now as host_os: freebsd10.0 and the ./configure scripts have tests like this: here's my config.log after building and installing security/p11-kit. i have edited my newvers.sh according to UPDATING and uname -a now properly reports: FreeBSD otaku 9.9-CURRENT FreeBSD 9.9-CURRENT #9: Thu Nov 3 11:41:08 CET 2011 arundel@otaku:/usr/obj/usr/git-freebsd-head/sys/ARUNDEL amd64 still for me the issue remains: no libs get built and thus not installed! cheers. alex ports/audio/jack/work/jack-audio-connection-kit-0.121.3: case $host_os in ... freebsd1*) dynamic_linker=no ;; ... And now? I'm cluesless now how we could solve this :-( are you sure this issue is related to the freebsd1* case? I can only comment what I saw: - OS was detected as freebsd10.0 (I inserted a 'echo $host_os' into the ./configure script - ./configure said that it should/will not build shared libs - the *.so* were missing in ports/audio/jack/work/... and in /usr/local/lib I will remove all /usr/ports/* and /usr/local/* and /var/db/pkg/* and will start from scratch with cvs checkout and will set UNAME_r as explained in ports/UPDATING; will let you know the result matthias -- Matthias Apitz e g...@unixarea.de - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by p11-kit configure 0.8, which was generated by GNU Autoconf 2.68. Invocation command line was $ ./configure --disable-gtk-doc --disable-nls --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/ --build=amd64-portbld-freebsd9.9 ## - ## ## Platform. ## ## - ## hostname = otaku uname -m = amd64 uname -r = 9.9-CURRENT uname -s = FreeBSD uname -v = FreeBSD 9.9-CURRENT #9: Thu Nov 3 11:41:08 CET 2011 arundel@otaku:/usr/obj/usr/git-freebsd-head/sys/ARUNDEL /usr/bin/uname -p = amd64 /bin/uname -X = unknown /bin/arch = unknown /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /sbin PATH: /bin PATH: /usr/sbin PATH: /usr/bin PATH: /usr/local/sbin PATH: /usr/local/bin PATH: /usr/local/diablo-jre1.6.0/bin ## --- ## ## Core tests. ## ## --- ## configure:2406: checking for a BSD-compatible install configure:2474: result: /usr/bin/install -c -o root -g wheel configure:2485: checking whether build environment is sane configure:2535: result: yes configure:2676: checking for a thread-safe mkdir -p configure:2715: result: ./install-sh -c -d configure:2728: checking for gawk configure:2758: result: no configure:2728: checking for mawk configure:2758: result: no configure:2728: checking for nawk configure:2744: found /usr/bin/nawk configure:2755: result: nawk configure:2766: checking whether make sets $(MAKE) configure:2788: result: yes configure:2868: checking whether build environment is sane configure:2918: result: yes configure:2921: checking whether to disable maintainer-specific portions of Makefiles configure:2930: result: yes configure:2986: checking build system type configure:3000: result: amd64-portbld-freebsd9.9 configure:3020: checking host system type configure:3033: result: amd64-portbld-freebsd9.9 configure:3074: checking how to print strings configure:3101: result: printf configure:3134: checking for style of include used by make configure:3162: result: GNU configure:3232: checking for gcc configure:3259: result: cc configure:3488: checking for C compiler version configure:3497: cc --version 5 cc (GCC) 4.2.2 20070831 prerelease [FreeBSD] Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:3508: $? = 0 configure:3497: cc -v 5 Using built-in specs. Target: amd64-undermydesk-freebsd Configured with: FreeBSD/amd64 system compiler Thread model: posix gcc version 4.2.2 20070831 prerelease [FreeBSD] configure:3508: $? = 0 configure:3497: cc -V 5 cc: '-V' option must have argument configure:3508: $? = 1 configure:3497: cc -qversion 5 cc: unrecognized option '-qversion' cc: No input files specified configure:3508: $? = 1 configure:3528: checking whether the C compiler works configure:3550: cc -O2 -pipe -frename-registers
Re: request: merging if_ath_tx branch to HEAD
Hi, On Thu, Nov 3, 2011 at 3:44 AM, Adrian Chadd adr...@freebsd.org wrote: On 31 October 2011 20:15, Doug Barton do...@freebsd.org wrote: In any case, I do want to merge the ath 11n stuff into -9, so even if it's not done by 9.0, it'll be done shortly after. Given that RC1 is already out, you should probably check with re@ first. I'll poke them tomorrow, but since others have merged in driver changes and other stuff into -HEAD, I wouldn't be the first person to merge in bigger things. Maybe not the place to ask, but why are you (ie. FreeBSD folks) unable to unleash commit to `trunk' and let only required MFC go to `stable/9' ? - 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: request: merging if_ath_tx branch to HEAD
On 3 November 2011 09:45, Arnaud Lacombe lacom...@gmail.com wrote: Maybe not the place to ask, but why are you (ie. FreeBSD folks) unable to unleash commit to `trunk' and let only required MFC go to `stable/9' ? Hi, We can. It's just that we're being nice to keep the diffs between -HEAD and stable/9 low to keep things easier for release engineering. But it's taking a while and I really want to push this 11n stuff into -HEAD so I can continue active development in a way that users can actively test it. :) Adrian ___ 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 at vm_page_wire with FreeBSD 9.0 Beta 3
On 11/03/2011 08:24, Kostik Belousov wrote:
On Thu, Nov 03, 2011 at 12:40:08AM -0500, Alan Cox wrote:
On 11/02/2011 05:32, Andriy Gapon wrote:
[restored cc: to the original poster]
As Bruce Evans has pointed to me privately [I am not sure why privately],
there
is already an example in i386 and amd64 atomic.h, where operations are
inlined
for a kernel build, but presented as real (external) functions for a module
build. You can search e.g. sys/amd64/include/atomic.h for KLD_MODULE.
I think that the same treatment could/should be applied to vm_page_*lock*
operations defined in sys/vm/vm_page.h.
*snip*
Yes, it should be. There are without question legitimate reasons for a
module to acquire a page lock.
I agree. Also, I think that we should use the opportunity to also isolate
the modules from the struct vm_page layout changes. As example, I converted
nfsclient.ko.
I would suggest introducing the vm_page_bits_t change first. If, at the
same time, you change the return type from the function vm_page_bits()
to use vm_page_bits_t, then I believe it is straightforward to fix all
of the places in vm_page.c that don't properly handle a 32 KB page size.
Alan
Patch is not tested.
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 f14da4a..5b8b4e3 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
+}
+
+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
+}
+
+int
+vm_page_trylock_func(vm_page_t m, const char *file, int line)
+{
+
+ return (_mtx_trylock(vm_page_lockptr(m), 0, file, line));
+}
+
+void
+vm_page_lock_assert_func(vm_page_t m, int a, const char *file, int line)
+{
+
+#ifdef INVARIANTS
+ _mtx_assert(vm_page_lockptr(m), a, file, line);
+#endif
+}
+
+vm_page_bits_t
+vm_page_read_dirty_func(vm_page_t m)
+{
+
+ return (m-dirty);
+}
+
+vm_page_bits_t
+vm_page_read_valid_func(vm_page_t m)
+{
+
+ return (m-valid);
+}
+
+void
+vm_page_write_valid_func(vm_page_t m, vm_page_bits_t v)
+{
+
+ m-valid = v;
+}
+
+
int so_zerocp_fullpage = 0;
/*
diff --git a/sys/vm/vm_page.h b/sys/vm/vm_page.h
index 23637bb..618ba2b 100644
--- a/sys/vm/vm_page.h
+++ b/sys/vm/vm_page.h
@@ -113,6 +113,21 @@
TAILQ_HEAD(pglist, vm_page);
+#if PAGE_SIZE == 4096
+#define VM_PAGE_BITS_ALL 0xffu
+typedef uint8_t vm_page_bits_t;
+#elif PAGE_SIZE == 8192
+#define VM_PAGE_BITS_ALL 0xu
+typedef uint16_t vm_page_bits_t;
+#elif PAGE_SIZE == 16384
+#define VM_PAGE_BITS_ALL 0xu
+typedef uint32_t vm_page_bits_t;
+#elif PAGE_SIZE == 32768
+#define VM_PAGE_BITS_ALL 0xlu
+typedef uint64_t vm_page_bits_t;
+#endif
+
+
struct vm_page {
TAILQ_ENTRY(vm_page) pageq; /* queue info for FIFO queue or free
list (Q) */
TAILQ_ENTRY(vm_page) listq; /* pages in same object (O) */
@@ -138,19 +153,8 @@ struct vm_page {
/* NOTE that these must support one bit per
Re: 10.0-CUR r226986 ports (general)
It turns out that the problem is more general! A lot of ./configure scripts are detecting in 10-CUR that they can't or should not build shared libs; the problem is that the OS is detected now as As a temporary workaround, add WITH_FBSD10_FIX=1 to /etc/make.conf. ports/UPDATING and some of the mails in the archive of -current recommend setting UNAME_r=9.0-CURRENT; is this the same or which method is prefered? No, it is not the same. You can either masquerade, by setting UNAME_r and OSVERSION, or by editing the headers and scripts that define them; or you can use WITH_FBSD10_FIX for ports that define HAS_CONFIGURE (which is implied by USE_AUTOTOOLS and GNU_CONFIGURE). Right now the masquerading is probably safer, because there are some problems with the fix that are still being resolved -- and a few ports that may fail despite the fix. But of course if you help to test without masquerading, these problems will be resolved sooner. b. ___ 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: USB3 express card panics on 9.0-RC1
On Thursday 03 November 2011 13:30:19 Jan Henrik Sylvester wrote: On 11/03/2011 11:51, Jan Henrik Sylvester wrote: On 11/03/2011 09:27, Hans Petter Selasky wrote: On Wednesday 02 November 2011 16:22:20 Jan Henrik Sylvester wrote: I have bought a Super-speed Express Card To USB 3.0 1-Port to connect an USB3 hard disk to my Thinkpad T510, which only has USB2. Trying to hot plug the express card did nothing, but I guess that is expected. Hence, I booted with the express card already inserted, only to receive a panic upon xhci0 initialization, see below. This is on FreeBSD 9.0-RC1/amd64 with a generic kernel installed from the official DVD. I guess I could test 226803 mentioned in http://lists.freebsd.org/pipermail/freebsd-usb/2011-October/010746.html , which happened after RC1, but from the commit message, it only fixes suspend and resume. As I do not have much time now, should I test 226803, find a Linux CD to actually identify the device, or anything else? Cheers, Jan Henrik usbus0: 480 Mbps High Speed USB v2.0 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x18 fault code = supervisor write data, page not present instruction ponter = 0x20:0x806e80aa stack pointer = 0x28:0xff810ee50bc0 frame pointer = 0x28:0xff810ee50bf0 code segment = base 0x0, limit 0xf, type 0x16 = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 15 (xhci0) trap number = 12 panic: page fault cpuid = 0 Uptime = 1s Automatic reboot in 15 seconds - press a key on the console to abort Hi, This looks like a NULL-pointer issue inside xhci_configure_msg() which probably should be easy to fix. Could you compile and boot a kernel with kernel debugging enable so that you get a backgtrace? I have not done this before. The GENERIC kernel already contains makeoptions DEBUG=-g (at least it is in /usr/src/sys/amd64/conf/GENERIC and there are all this large /boot/kernel/*.symbols). Is there anything else needed? (I do not need all the stuff that Ken Smith took out just before RC1 in r226405 just to get a trace, since I do not want to do online debugging, or do I need it anyhow?) From http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html , I thought that setting dumpdev=AUTO in /etc/rc.conf was enough to get a dump in /var/crash/ after the next boot to multiuser. That does not seem to be the case for me. What else do I have to do? After reading a bit more, I still do not know why I do not get a crash dump with dumpdev=AUTO (and /var/crash/ having enough space for a full memory dump). Is it too early during boot for dumpon to be set? After reading http://www.unixguide.net/freebsd/faq/18.13.shtml , I found that 806e8040 t usb_process is the last symbol before instruction pointer = 0x20:0x806e80aa. Does this help? Try add: options KDB # Enable kernel debugger support. options DDB # Support DDB. --HPS ___ 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: USB3 express card panics on 9.0-RC1
On Thursday 03 November 2011 19:42:30 Hans Petter Selasky wrote: On Thursday 03 November 2011 13:30:19 Jan Henrik Sylvester wrote: After reading http://www.unixguide.net/freebsd/faq/18.13.shtml , I found that 806e8040 t usb_process is the last symbol before instruction pointer = 0x20:0x806e80aa. Does this help? Try add: options KDB # Enable kernel debugger support. options DDB # Support DDB. Hi, Looks like it panics at: mtx_lock(up-up_mtx); In usb_process() which is created by the xhci0 instance. I would really like to see a dump of up and up_mtx because I cannot see how this can happen. Have you seen any USB errors in the dmesg up to the point of this panic? --HPS ___ 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: USB3 express card panics on 9.0-RC1
On Thursday 03 November 2011 21:04:23 Hans Petter Selasky wrote: On Thursday 03 November 2011 19:42:30 Hans Petter Selasky wrote: On Thursday 03 November 2011 13:30:19 Jan Henrik Sylvester wrote: After reading http://www.unixguide.net/freebsd/faq/18.13.shtml , I found that 806e8040 t usb_process is the last symbol before instruction pointer = 0x20:0x806e80aa. Does this help? Try add: options KDB # Enable kernel debugger support. options DDB # Support DDB. Hi, Looks like it panics at: mtx_lock(up-up_mtx); In usb_process() which is created by the xhci0 instance. I would really like to see a dump of up and up_mtx because I cannot see how this can happen. Have you seen any USB errors in the dmesg up to the point of this panic? --HPS Here is a snippet of assembly code: 806e808b: 48 8b 13mov(%rbx),%rdx 806e808e: 83 6a 0c 01 subl $0x1,0xc(%rdx) 806e8092: e8 19 4e 42 00 callq 80b0ceb0 spinlock_exit 806e8097: 65 48 8b 34 25 00 00mov%gs:0x0,%rsi 806e809e: 00 00 806e80a0: 49 8b 7c 24 40 mov0x40(%r12),%rdi 806e80a5: b8 04 00 00 00 mov$0x4,%eax 806e80aa: f0 48 0f b1 77 18 lock cmpxchg %rsi,0x18(%rdi) ^ fault line 806e80b0: 0f 94 c0sete %al 806e80b3: 84 c0 test %al,%al 806e80b5: 0f 84 5f 01 00 00 je 806e821a usb_process+0x1da 806e80bb: 4d 8d 6c 24 10 lea0x10(%r12),%r13 806e80c0: 4d 8d 74 24 20 lea0x20(%r12),%r14 806e80c5: 49 89 5c 24 38 mov%rbx,0x38(%r12) --HPS ___ 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: USB3 express card panics on 9.0-RC1
On Thursday 03 November 2011 13:30:19 Jan Henrik Sylvester wrote: On 11/03/2011 11:51, Jan Henrik Sylvester wrote: On 11/03/2011 09:27, Hans Petter Selasky wrote: On Wednesday 02 November 2011 16:22:20 Jan Henrik Sylvester wrote: I have bought a Super-speed Express Card To USB 3.0 1-Port to connect an USB3 hard disk to my Thinkpad T510, which only has USB2. Trying to hot plug the express card did nothing, but I guess that is expected. Hence, I booted with the express card already inserted, only to receive a panic upon xhci0 initialization, see below. This is on FreeBSD 9.0-RC1/amd64 with a generic kernel installed from the official DVD. I guess I could test 226803 mentioned in http://lists.freebsd.org/pipermail/freebsd-usb/2011-October/010746.html , which happened after RC1, but from the commit message, it only fixes suspend and resume. As I do not have much time now, should I test 226803, find a Linux CD to actually identify the device, or anything else? Cheers, Jan Henrik usbus0: 480 Mbps High Speed USB v2.0 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x18 fault code = supervisor write data, page not present instruction ponter = 0x20:0x806e80aa stack pointer = 0x28:0xff810ee50bc0 frame pointer = 0x28:0xff810ee50bf0 code segment = base 0x0, limit 0xf, type 0x16 = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 15 (xhci0) trap number = 12 panic: page fault cpuid = 0 Uptime = 1s Automatic reboot in 15 seconds - press a key on the console to abort Hi, This looks like a NULL-pointer issue inside xhci_configure_msg() which probably should be easy to fix. Could you compile and boot a kernel with kernel debugging enable so that you get a backgtrace? I have not done this before. The GENERIC kernel already contains makeoptions DEBUG=-g (at least it is in /usr/src/sys/amd64/conf/GENERIC and there are all this large /boot/kernel/*.symbols). Is there anything else needed? (I do not need all the stuff that Ken Smith took out just before RC1 in r226405 just to get a trace, since I do not want to do online debugging, or do I need it anyhow?) From http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html , I thought that setting dumpdev=AUTO in /etc/rc.conf was enough to get a dump in /var/crash/ after the next boot to multiuser. That does not seem to be the case for me. What else do I have to do? After reading a bit more, I still do not know why I do not get a crash dump with dumpdev=AUTO (and /var/crash/ having enough space for a full memory dump). Is it too early during boot for dumpon to be set? Try removing device xhci from the kernel config file and kldload xhci from the root prompt. Then I think you will get the kernel dump. --HPS ___ 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: Increase the degree of interactivity ULE scheduler
On Sat, 22 Oct 2011, Ivan Klymenko wrote:
Hello people!
I have:
CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1994.48-MHz K8-class CPU)
FreeBSD 10.0-CURRENT r226607 amd64
For example during the building of the port lang/gcc46 in four streams (-j 4)
with a heavy load on the processor - use the system was nearly impossible -
responsiveness was terrible - the mouse cursor sometimes froze on the spot a
few seconds...
Am I right in understanding that you have only two cores? What else is
running that achieves poor interactivity? What is the cpu utilization of
your x server at this time?
I managed to achieve a significant increase in the degree of interactivity ULE
scheduler due to the following changes:
This patch probably breaks nice, adaptive idling, and slows the
interactivity computation. That being said I'm not sure why it helps you.
It seems that there are increasing reports of bad interactivity creeping
in to ULE over the last year. If people can help provide me with data I
can look into this more.
Thanks for your report.
Jeff
##
--- sched_ule.c.orig2011-10-22 11:40:30.0 +0300
+++ sched_ule.c 2011-10-22 12:25:05.0 +0300
@@ -2119,6 +2119,14 @@
THREAD_LOCK_ASSERT(td, MA_OWNED);
tdq = TDQ_SELF();
+ if (td-td_pri_class PRI_FIFO_BIT)
+ return;
+ ts = td-td_sched;
+ /*
+* We used up one time slice.
+*/
+ if (--ts-ts_slice 0)
+ return;
#ifdef SMP
/*
* We run the long term load balancer infrequently on the first cpu.
@@ -2144,9 +2152,6 @@
if (TAILQ_EMPTY(tdq-tdq_timeshare.rq_queues[tdq-tdq_ridx]))
tdq-tdq_ridx = tdq-tdq_idx;
}
- ts = td-td_sched;
- if (td-td_pri_class PRI_FIFO_BIT)
- return;
if (PRI_BASE(td-td_pri_class) == PRI_TIMESHARE) {
/*
* We used a tick; charge it to the thread so
@@ -2157,11 +2162,6 @@
sched_priority(td);
}
/*
-* We used up one time slice.
-*/
- if (--ts-ts_slice 0)
- return;
- /*
* We're out of time, force a requeue at userret().
*/
ts-ts_slice = sched_slice;
##
What do you think about this?
Thanks!
___
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: couple of sched_ule issues
On Thu, 15 Sep 2011, Andriy Gapon wrote: This is more of a just for the record email. I think I've already stated the following observations, but I suspect that they drowned in the noise of a thread in which I mentioned them. 1. Incorrect topology is built for single-package SMP systems. That topology has two levels (shared nothing and shared package) with exactly the same CPU sets. That doesn't work well with the rebalancing algorithm which assumes that each level is a proper/strict subset of its parent. 2. CPU load comparison algorithms are biased towards lower logical CPU IDs. With all other things being equal the algorithms will always pick a CPU with a lower ID. This creates certain load asymmetry and predictable patterns in load distribution. If all other things truly are equal why does selecting a lower cpu number matter? Another observation. It seems that ULE makes a decision about thread-to-CPU affinity at the time when a thread gets switched out. This looks logical from the implementation point of view. But it doesn't seem logical from a general point of view - when the thread will be becoming running again its affinity profile may become completely different. I think that it would depend on how much a thread actually spends not running. The decision is made at sched_add() time. sched_pickcpu() does the work and selects the run-queue we will be added to. We consider the CPU that the thread was last running on but the decision is made at the time that a run queue must be selected. Jeff -- 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: Increase the degree of interactivity ULE scheduler
Thank you for taking the time to answer me. В Thu, 3 Nov 2011 10:21:48 -1000 (HST) Jeff Roberson jrober...@jroberson.net пишет: On Sat, 22 Oct 2011, Ivan Klymenko wrote: Hello people! I have: CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1994.48-MHz K8-class CPU) FreeBSD 10.0-CURRENT r226607 amd64 For example during the building of the port lang/gcc46 in four streams (-j 4) with a heavy load on the processor - use the system was nearly impossible - responsiveness was terrible - the mouse cursor sometimes froze on the spot a few seconds... Am I right in understanding that you have only two cores? Yes. What else is running that achieves poor interactivity? This is mainly a compilation with make option -j = ncpu*2 And as an example - launching a large number of programs http://www.youtube.com/watch?v=1CLCp-dqWu0 This patch allows me to make do with ULE nearly as well as with FBFS Without the patch, somewhere in the middle of the time with ULE has been difficult to control the mouse cursor. What is the cpu utilization of your x server at this time? ~2.00% - 20.00% WCPU time... But sometimes there are up to 79%... Upon unloading the CPU returns to normal... I managed to achieve a significant increase in the degree of interactivity ULE scheduler due to the following changes: This patch probably breaks nice, adaptive idling, and slows the interactivity computation. That being said I'm not sure why it helps you. It seems that there are increasing reports of bad interactivity creeping in to ULE over the last year. If people can help provide me with data I can look into this more. I'll be glad to provide data Thanks for your report. Jeff How to repeat your tests on my system? http://jeffr-tech.livejournal.com/24280.html Sorry for my english. Thanks! ___ 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: Increase the degree of interactivity ULE scheduler
On Thu, 3 Nov 2011, Ivan Klymenko wrote: Thank you for taking the time to answer me. ? Thu, 3 Nov 2011 10:21:48 -1000 (HST) Jeff Roberson jrober...@jroberson.net ?: On Sat, 22 Oct 2011, Ivan Klymenko wrote: Hello people! I have: CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1994.48-MHz K8-class CPU) FreeBSD 10.0-CURRENT r226607 amd64 For example during the building of the port lang/gcc46 in four streams (-j 4) with a heavy load on the processor - use the system was nearly impossible - responsiveness was terrible - the mouse cursor sometimes froze on the spot a few seconds... Am I right in understanding that you have only two cores? Yes. What else is running that achieves poor interactivity? This is mainly a compilation with make option -j = ncpu*2 And as an example - launching a large number of programs http://www.youtube.com/watch?v=1CLCp-dqWu0 This patch allows me to make do with ULE nearly as well as with FBFS Without the patch, somewhere in the middle of the time with ULE has been difficult to control the mouse cursor. What is the cpu utilization of your x server at this time? ~2.00% - 20.00% WCPU time... But sometimes there are up to 79%... Upon unloading the CPU returns to normal... When the x server is down at 20% is it laggy? Can you tell me the priorities of the x server and the compile tasks? You can use the 'pri' keyword with ps and write a short script to log all priorities once per second during your test. That would be most helpful. Let me know if you need assistance with that. Jeff I managed to achieve a significant increase in the degree of interactivity ULE scheduler due to the following changes: This patch probably breaks nice, adaptive idling, and slows the interactivity computation. That being said I'm not sure why it helps you. It seems that there are increasing reports of bad interactivity creeping in to ULE over the last year. If people can help provide me with data I can look into this more. I'll be glad to provide data Thanks for your report. Jeff How to repeat your tests on my system? http://jeffr-tech.livejournal.com/24280.html Sorry for my english. Thanks! ___ 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: 10.0-CUR r226986 ports (general)
Am 11/03/11 18:42, schrieb b. f.: It turns out that the problem is more general! A lot of ./configure scripts are detecting in 10-CUR that they can't or should not build shared libs; the problem is that the OS is detected now as As a temporary workaround, add WITH_FBSD10_FIX=1 to /etc/make.conf. ports/UPDATING and some of the mails in the archive of -current recommend setting UNAME_r=9.0-CURRENT; is this the same or which method is prefered? No, it is not the same. You can either masquerade, by setting UNAME_r and OSVERSION, or by editing the headers and scripts that define them; or you can use WITH_FBSD10_FIX for ports that define HAS_CONFIGURE (which is implied by USE_AUTOTOOLS and GNU_CONFIGURE). Right now the masquerading is probably safer, because there are some problems with the fix that are still being resolved -- and a few ports that may fail despite the fix. But of course if you help to test without masquerading, these problems will be resolved sooner. b. So I presume the WITH_FBSD10_FIX flag is set in /etc/make.conf, right? Setting this and try building ports without the masquerading will help those people involved in fixing more than the masquerading solution? If so, I would like to do so. I compile/update quite often ports, simply to keep my system fresh and for some testing purposes. At the moment I switch very often between CLANG and the legacy gcc 4.2.2 of FBSD 10, so it would not bother me much more as the inherited bothering due to the problems discussed if I have to switch one time more or prepare a PR for the problem. On the other hand, as far as I know, there was only suggested using UNAME_r. When do I have to use the OSVERSION? Regards Oliver signature.asc Description: OpenPGP digital signature
Re: gmirror failed with error 19.
On Thu, Nov 3, 2011 at 4:50 AM, Sascha Klauder sas...@trimind.de wrote: On Tue, 2011-11-01 11:23 +0400, Andrey V. Elsukov wrote: On 28.10.2011 13:48, Sascha Klauder wrote: GEOM_MIRROR: Device mirror/gm0 launched (2/2). GEOM_PART: partition 1 has end offset beyond last LBA: 490350671 490350670 GEOM_PART: integrity check failed (mirror/gm0, MBR) This is the main problem. Your MBR' slice is bigger than actual space you have. The only way to fix this - recreate slice. I've partioned and labeled the disk with sysinstall(8) from 8.2-RELEASE media. Does 9.0 use different disk geometry cal- culation than 8.2 or is usage of gmirror the culprit? Both 8.2 and 9.0 kernels report the disk having 490350672 sectors. You can break your mirror, recreate the slice (NOTE: you must preserve one sector for the gmirror's meta-data), then copy your data to the newly created slice, then reboot from the new slice and recreate mirror. I think I'd rather reinstall 9.0 from scratch, getting rid of MBR/disklabel as well. While using gpart and the 9.0 installer has some real benefits, it also has a few problems. I ave a disk that I partitioned with bsdinstall from the 9.0 distribution media and it worked fine for a STAT disk, but I am unable to boot te same disk when connected to a USB adapter. It shows up in the boot list, but when I select it, the screen blanks for a few seconds (5) and the list re-appears. No errors, but my T520 BIOS clearly is not happy with it. I have no idea how common htis issue might be, but the T520 does have a UEFI BIOS. As noted, GEOM wants the final sector on the disk for its metadata, but GPT mandates that hte ast sector of the disk be used for a backup of the boot sector. The leads to the potential ofr all kinds if ugliness to develop, especially when BIOS, which knows nothing about GEOM, is accessing the disk. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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: 10.0-CUR r226986 ports (general)
On 11/3/11, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Am 11/03/11 18:42, schrieb b. f.: So I presume the WITH_FBSD10_FIX flag is set in /etc/make.conf, right? You can set it in a number of local Makefiles that are automatically included during a port build. That includes make.conf, and the others mentioned in ports/Mk/bsd.port.mk. A few days ago Martin also added WITH_FBSD10_FIX to the Makefiles of a number of commonly-used ports that need the fix. Setting this and try building ports without the masquerading will help those people involved in fixing more than the masquerading solution? If Yes. Some of the known problems with the current fix don't occur when ports are built in tinderboxes or clean sandboxes, but on live systems that already have other ports installed. On the other hand, as far as I know, there was only suggested using UNAME_r. When do I have to use the OSVERSION? You don't have to alter OSVERSION, but if you do not, then for those ports that have WITH_FBSD10_FIX set in their Makefiles, the fix will be applied, and you will be subject to any problems that the fix may cause, even though you are trying to masquerade as a version of FreeBSD less than 10. Look at the conditional that determine whether any action is taken during the run-autotools-fixup target in ports/Mk/bsd.port.mk. b. ___ 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: make installworld fails on releng9
On Sat, 29 Oct 2011, Chuck Burns wrote: On Saturday, October 29, 2011 1:13:58 AM Benjamin Kaduk wrote: Are you running installworld in single-user mode? What is the value of kern.securelevel? -Ben Kaduk Yes, I was running in single-user mode, and kern.securelevel was never modified, and is currently showing as -1 Also, I am running zfs root, if that makes a difference Hmm, ZFS root is indeed potentially interesting. Marco, are you also on ZFS root? Have you run a ZFS scrub recently? (That being about the limit of my ZFS knowledge, unfortunately.) It's pretty puzzling why only this handful of immutable files would trigger an issue, though. -Ben Kaduk ___ 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: getting the cpuid for a userspace process ?
On Tue, Oct 25, 2011 at 8:54 PM, John Baldwin j...@freebsd.org wrote: On Tuesday, October 25, 2011 2:09:12 pm Poul-Henning Kamp wrote: In message 201110251342.45194@freebsd.org, John Baldwin writes: On Tuesday, October 25, 2011 11:06:22 am Luigi Rizzo wrote: as the subject says... is there any way to get the current CPU id for a userspace process (of course, valid only at the time the function is called as the process might be arbitrarily moved while it runs) Not from userland, no. On x86 you can use cpuid to fetch the APIC ID, but that does not map 1:1 to FreeBSD cpu IDs. How does JEmalloc do it ? I don't think it does on FreeBSD. The only thing malloc() knows on FreeBSD is the total number of CPUs. I believe Linux has a system call that returns this though (sched_getcpu() is the public interface which is a wrapper around a getcpu() system call). From the manpage it would seem that sched_getcpu() uses a per-thread shared page of some sort so that it doesn't actually have to enter the kernel to get the CPU ID. Alternatively, you could imagine it on x86 at least exporting a table mapping APIC IDs to CPU IDs and then using cpuid and that table to do the lookup purely in userland. That would only necessitate a global shared page and not one per-thread. You could still fall back to a system call for other architectures that simply returned curthread-td_oncpu. Exposing a table mapping to userland would be somewhat similar to the way L4Ka::Pistachio exports a UTCB area to userland threads: https://github.com/l4ka/pistachio/blob/dd624dde5bce4ab120b2fcecbbcd94473effb201/kernel/src/glue/v4-x86/utcb.h -- John Baldwin -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ 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: Adding disk firmware programming capability to camcontrol
On Fri, Oct 28, 2011 at 1:47 PM, Nima Misaghian nmisagh...@sandvine.com wrote: Hi, I have got code developed by Andre Albsmeier that is capable of programming firmware of hard drives from several vendors and turned it into a camcontrol command. +1 I took a look at your patch and it looks great. I have worked on a storage product before where there was a requirement to reprogram the firmware of hard drives. On tha product, proprietary Windows tools had to be used. It would have been nice to be able to use camcontrol in FreeBSD. I think the patch is fine in its current form. Very few regular users need to reprogram hard drive firmware. It is a special administrative operation. -- Craig Rodrigues rodr...@crodrigues.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: 10.0-CUR r226986 ports/net-mgmt/net-snmp
El día Thursday, November 03, 2011 a las 01:42:50PM -0400, b. f. escribió: No, it is not the same. You can either masquerade, by setting UNAME_r and OSVERSION, or by editing the headers and scripts that define them; or you can use WITH_FBSD10_FIX for ports that define HAS_CONFIGURE (which is implied by USE_AUTOTOOLS and GNU_CONFIGURE). Right now the masquerading is probably safer, because there are some problems with the fix that are still being resolved -- and a few ports that may fail despite the fix. But of course if you help to test without masquerading, these problems will be resolved sooner. Well, I will try to help. I have set WITH_FBSD10_FIX in /etc/make.conf; the port ports/net-mgmt/net-snmp installs: /usr/local/include/net-snmp/net-snmp-config.h with: ... /* define the system type include file here */ #define NETSNMP_SYSTEM_INCLUDE_FILE net-snmp/system/freebsd10.h ... but the named header file is not there: # ls -C1 /usr/local/include/net-snmp/system/free* /usr/local/include/net-snmp/system/freebsd.h /usr/local/include/net-snmp/system/freebsd2.h /usr/local/include/net-snmp/system/freebsd3.h /usr/local/include/net-snmp/system/freebsd4.h /usr/local/include/net-snmp/system/freebsd5.h /usr/local/include/net-snmp/system/freebsd6.h /usr/local/include/net-snmp/system/freebsd7.h /usr/local/include/net-snmp/system/freebsd8.h /usr/local/include/net-snmp/system/freebsd9.h I don't know what the correct fix ist, and for the moment I created 'freebsd10.h' as a copy of 'freebsd9.h': # cat freebsd10.h #include freebsd9.h #define freebsd8 freebsd8 +Cc: maintainer Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e g...@unixarea.de - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 ___ 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 images for FreeBSD
On Wed, 19 Oct 2011, Alexander Yerenkow wrote: Hello all! I'm working currently on creating images with a set pre-installed packages. I looked at project pkgng (candidate for replacing current pkg_* subsystem), and also I have some thought about current packages/ports system. 1. pkg_add can be launched with parameter -p $PREFIX. So, my first thought was: I create empty directory structure with mtree, and I'll install there all required packages; after that I need only update this installation tree (manually by pkg_delete $old pkg_add $new, or with some tool). But I cannot specify to pkg_add relative root, instead of real one. Let me show example: PKG_DBDIR=/zpool0/testroot/var/db/pkg pkg_add -p /zpool0/testroot/usr/local ubench-0.32.tbz installs package, and in /zpool0/testroot/var/db/pkg/ubench-0.32/+CONTENTS there will be such record: @cwd /zpool0/testroot/usr/local I can't specify to pkg_add that it should treat /zpool0/testroot as root, as I need (so record really should be @cwd /usr/local) Instead, pkg_add allows me to make chroot, which as you understand is not good (In specified chroot all required by pkg* binaries/libraries must exists, unfortunately I can't specify some empty dir and install there). Why is that? Because there is +INSTALL script in packages, in which package/port system allows execute any code/script written by porter. This is indeed a frustrating problem. 2. In ports enhancements task list (somewhere i read it) there was one item: Make packages non-executable (or something similar). To do this properly, we must get rid of of free-form post-install post-deinstall scripts. To do this, we need some deep analysis of what types of actions there happening, formalize them and provide some way to porters specify all needed actions in Makefile. I downloaded all packages for 9-current i386, found all +INSTALL scripts, and kinda categorized them, you can get all of them here: http://www.box.net/shared/ieovjj7l8omkrm3l21xb To summarize my efforts: I checked 21195 packages; I found 880 install scripts; 3 scripts contains plain exit 0 8 install scripts contains some perl code; 17 scripts contains some additional install commands; 70 scripts contains some chgroup/chown actions (which probably could be done by specifying mtree file?...) 75 contains uncategorized actions (print of license, some interactive questions, ghostscript actions, tex, fonts etc.) 161 scripts contains some file commands, like (ld / cp / mv, creating backups, creating configs if they aren't exists etc. ) 166 scripts contains useradd/groupadd commands (many similar constructions, not too hard to move this to .mk, in pkgng group/users can be specified in yaml config) 380 contains pear component registration (md5 -q * | uniq - produces exactly one result, so these all scripts are really one, could be moved to some pear.mk) Thank you for doing this analysis/breakdown! However, I worry that it may have missed @exec statements in pkg-plist files ... for example, net/openafs (which I maintain) runs kldxref in /boot/modules after installing a kernel module, which is needed in order for kldload to find the module. Now, this is clearly a case that a potential nonexecutable package framework could handle, checking for installed kernel modules and acting accordingly. However, having not done the survey of the sort you did for install scripts, it is an uneasy dangling unknown. Why I'm interested in non-executable install of package (e.g. simple unpack + execute some typical actions based on package description): - Unpacking of hundreds Mb packages takes several minutes (to mdconfig-ed filesystem) - Installation of these packages via pkg_add (they downloads from local ftp) took hours in my case (to mdconfig-ed filesystem) This is quite a telling statistic :) As you understand, to make efficient image building system, I need to deal with package installation without spending too many cpu/disk resources. Ideally I consider all required packages are extracted to some their own directory, like for ubench: $X/packages/ubench/ (and here goes all directory structure which should be copied to new root) plus separated info of new users/groups (maybe there need some additional data to make package installed in such way fully working). There would certainly be additional data needed, e.g. for installing sample configuration files and copying to the real location, and removing both copies on uninstallation if the real file is unchanged from the sample. I'm sure there are others, too. So, maybe someone working in this direction, or have any comments? I would be very hesitant to proceed in this direction without doing some investigation of other package-based systems. For example, Debian packages are inherently binary-based, there is not a real parallel to our ports framework. Yet if anything, I think that executable packages may be even more heavily used in Debian than in FreeBSD. In addition to
Re: 10.0-CUR r226986 ports/net-mgmt/net-snmp
On Nov 3, 2011, at 8:25 PM, Matthias Apitz wrote: El día Thursday, November 03, 2011 a las 01:42:50PM -0400, b. f. escribió: No, it is not the same. You can either masquerade, by setting UNAME_r and OSVERSION, or by editing the headers and scripts that define them; or you can use WITH_FBSD10_FIX for ports that define HAS_CONFIGURE (which is implied by USE_AUTOTOOLS and GNU_CONFIGURE). Right now the masquerading is probably safer, because there are some problems with the fix that are still being resolved -- and a few ports that may fail despite the fix. But of course if you help to test without masquerading, these problems will be resolved sooner. Well, I will try to help. I have set WITH_FBSD10_FIX in /etc/make.conf; the port ports/net-mgmt/net-snmp installs: /usr/local/include/net-snmp/net-snmp-config.h with: ... /* define the system type include file here */ #define NETSNMP_SYSTEM_INCLUDE_FILE net-snmp/system/freebsd10.h ... but the named header file is not there: # ls -C1 /usr/local/include/net-snmp/system/free* /usr/local/include/net-snmp/system/freebsd.h /usr/local/include/net-snmp/system/freebsd2.h /usr/local/include/net-snmp/system/freebsd3.h /usr/local/include/net-snmp/system/freebsd4.h /usr/local/include/net-snmp/system/freebsd5.h /usr/local/include/net-snmp/system/freebsd6.h /usr/local/include/net-snmp/system/freebsd7.h /usr/local/include/net-snmp/system/freebsd8.h /usr/local/include/net-snmp/system/freebsd9.h I don't know what the correct fix ist, and for the moment I created 'freebsd10.h' as a copy of 'freebsd9.h': # cat freebsd10.h #include freebsd9.h #define freebsd8 freebsd8 +Cc: maintainer You'll need to do more than just that. Take a look at the port history for more details... -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 images for FreeBSD
On 19/10/2011, at 21:19, Alexander Yerenkow wrote: I can't specify to pkg_add that it should treat /zpool0/testroot as root, as I need (so record really should be @cwd /usr/local) Instead, pkg_add allows me to make chroot, which as you understand is not good (In specified chroot all required by pkg* binaries/libraries must exists, unfortunately I can't specify some empty dir and install there). Hmmm, why is it empty? When I have made something analogous I did an installkernel/world into a directory and then chroot'd in there and built ports. There is no reason you couldn't pkg_add from a local mirror (or nullfs mount a local package mirror directory into the chroot). Why is that? Because there is +INSTALL script in packages, in which package/port system allows execute any code/script written by porter. This is a feature ;) To summarize my efforts: I checked 21195 packages; I found 880 install scripts; 3 scripts contains plain exit 0 8 install scripts contains some perl code; 17 scripts contains some additional install commands; 70 scripts contains some chgroup/chown actions (which probably could be done by specifying mtree file?...) 75 contains uncategorized actions (print of license, some interactive questions, ghostscript actions, tex, fonts etc.) 161 scripts contains some file commands, like (ld / cp / mv, creating backups, creating configs if they aren't exists etc. ) 166 scripts contains useradd/groupadd commands (many similar constructions, not too hard to move this to .mk, in pkgng group/users can be specified in yaml config) 380 contains pear component registration (md5 -q * | uniq - produces exactly one result, so these all scripts are really one, could be moved to some pear.mk) Interesting stats, thanks for taking the time to do the analysis. I think one of the reasons pkg_add is so slow is that it copies everything to a staging directory, then copies the files.. This is very tedious (obviously). I wonder if it could be modified to have a stream mode where it unpacks directly into the target FS. Alternatively you could cut it in 2 conceptually and modify pkg_add so it can run it a mode where it just unpacks to a staging area, and another mode where it copies from the staging area to the destination. -- 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-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: 10.0-CUR r226986 ports/security/cyrus-sasl2-saslauthd
El día Thursday, November 03, 2011 a las 01:42:50PM -0400, b. f. escribió: No, it is not the same. You can either masquerade, by setting UNAME_r and OSVERSION, or by editing the headers and scripts that define them; or you can use WITH_FBSD10_FIX for ports that define HAS_CONFIGURE (which is implied by USE_AUTOTOOLS and GNU_CONFIGURE). Right now the masquerading is probably safer, because there are some problems with the fix that are still being resolved -- and a few ports that may fail despite the fix. But of course if you help to test without masquerading, these problems will be resolved sooner. the ports/security/cyrus-sasl2-saslauthd does not install with WITH_FBSD10_FIX; terminates with: cc -O2 -pipe -fno-strict-aliasing -rpath=/usr/lib:/usr/local/lib -o saslauthd mechanisms.o auth_dce.o auth_getpwent.o auth_krb5.o auth_krb4.o auth_pam.o aut h_rimap.o auth_httpform.o auth_shadow.o auth_sia.o auth_sasldb.o lak.o auth_l dap.o cache.o cfile.o krbtf.o utils.o ipc_unix.o ipc_doors.o saslauthd-main.o md5.o -L/usr/lib -lgssapi -lheimntlm -lkrb5 -lhx509 -lcom_err -lcrypto -lasn1 -l roken -lcrypt -lcrypt ../sasldb/.libs/libsasldb.al -lpam cc: ../sasldb/.libs/libsasldb.al: No such file or directory *** Error code 1 installes fine with UNAME_r set to 9-CURRENT; Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e g...@unixarea.de - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 ___ 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
