Re: CURRENT: buildworld fails to compile: cannot find -lctf cc: error: linker command failed [libproc.so.3]
Am Sat, 4 Oct 2014 15:58:48 -0700
Mark Johnston ma...@freebsd.org schrieb:
On Sat, Oct 4, 2014 at 3:40 PM, Mark Johnston ma...@freebsd.org wrote:
On Sat, Oct 04, 2014 at 04:39:37PM -0400, Ryan Stone wrote:
On Sat, Oct 4, 2014 at 2:33 PM, Mark Johnston ma...@freebsd.org wrote:
On Sat, Oct 04, 2014 at 07:47:56PM +0200, O. Hartmann wrote:
Recent sources (Revision: 272529) fail to compile:
[...]
cc -m32 -march=native -DCOMPAT_32BIT -isystem
/usr/obj/usr/src/lib32/usr/include/
-L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32
-O2 -pipe
-O3 -O3 -pipe -DYP -I/usr/obj/usr/src/lib32/usr/include/rpcsvc
-std=gnu99
-fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign
-Wno-empty-body
-Wno-string-plus-int -Wno-unused-const-variable
-Wno-tautological-compare
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function
-Wno-enum-conversion -Wno-switch -Wno-switch-enum
-Wno-knr-promoted-parameter
-Wno-parentheses -Qunused-arguments -c
/usr/src/lib/librpcsvc/yp_passwd.c -o
yp_passwd.o --- all_subdir_libproc --- --- libproc.so.3
--- /usr/obj/usr/src/tmp/usr/bin/ld: skipping
incompatible /usr/obj/usr/src/tmp/usr/lib/libctf.so when searching for
I'm confused by this message. Are you building with -DNO_CLEAN? Do you
have anything in make.conf or src.conf, especially anything that's
changed since libctf was rebuilt?
You might try rebuilding libctf with
$ cd /usr/src
$ make -C cddl/lib/libctf clean all
but I'm not sure why ld is ignoring the existing libctf.so.
The failure is coming while building the lib32 compat libraries. Are
we not currently building a lib32 libctf.so?
No, we do. One thing I've noticed is that cddl/lib is built after lib/
when compiling 32-bit libs, whereas cddl/lib is built first when building
natively.
Sorry, that's not even true. I misread a part of Makefile.inc1.
I'm still not able to reproduce the problem, but it seems that the
patch here is appropriate:
http://people.freebsd.org/~markj/patches/libctf_prebuild.diff
Oliver, could you give this a try?
This patch doesn't apply with sources at rev. 272559, as it bails out.
Investigating the
situation shows, that my top-level Makefile.inc seems different from what the
patch is
supposed to expect:
root@gate [src] patch -p1 /tmp/libctf_prebuild.diff
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--
|diff --git a/Makefile.inc1 b/Makefile.inc1
|index 3b92aef..9350339 100644
|--- a/Makefile.inc1
|+++ b/Makefile.inc1
--
Patching file Makefile.inc1 using Plan A...
Hunk #1 succeeded at 1536 with fuzz 1 (offset 2 lines).
Hunk #2 failed at 1584.
1 out of 2 hunks failed--saving rejects to Makefile.inc1.rej
done
The patch at line 1530 ff:
[...]
lib/libgeom \
${_cddl_lib_libumem} ${_cddl_lib_libnvpair} \
${_cddl_lib_libuutil} \
${_cddl_lib_libavl} \
${_cddl_lib_libzfs_core} \
${_cddl_lib_libctf} \
lib/libutil lib/libpjdlog ${_lib_libypclnt} lib/libz lib/msun \
${_secure_lib_libcrypto} ${_lib_libldns} \
${_secure_lib_libssh} ${_secure_lib_libssl}
My source tree is clean and sober as svn status reports.
A bit spooky, isn't it?
Oliver
signature.asc
Description: PGP signature
Re: About pmap_mapdev() pmap_unmapdev()
On Sun, Oct 05, 2014 at 01:15:12PM +0900, Kohji Okuno wrote: Hi, On Sat, Oct 04, 2014 at 08:53:35PM +0900, Kohji Okuno wrote: Hi Konstantin, Thank you for your prompt response. I will test and report from next monday. In addtion, I have one question. In current and 10-stable, is vm_map_delete() called by kva_free()? No, kva_free() only releases the vmem backing, leaving the page tables intact. This is why I only did the stable/9 patch. Where are PTEs allocated by pmap_mapdev() freed in current and 10-stable? Could you please explain me? They are not freed. The removal of the vmem which covers the address space managed by corresponding ptes, allows the reuse of both KVA region and corresponding PTEs in the tables. The only concern with the resident page tables is to avoid two kva_alloc() to step over each other, and this is ensured by vmem. I agree that normal pages are reusable. But, since the pages mapped by pmap_mapdev() are concerned with the physicall address of device (For example: video memory), these PTEs aren't reusable, I think. So, should we free these PTEs by pmap_unmapdev()? There is no hold on any physical pages which were referenced by the ptes. The only thing which is left out are the records in the page tables which map the KVA to said device memory. It is harmless. When the KVA is reused, the ptes in page tables are overwritten. It might be argued that clearing PTEs, or at least removing the PG_V bit catches erronous unintended accesses to the freed range, but by the cost of the overhead of re-polluting the caches. And since clearing is not effective without doing TLB flush, which requires broadcast IPI, it is more trouble than advantage. ___ 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: CURRENT: buildworld fails to compile: cannot find -lctf cc: error: linker command failed [libproc.so.3]
Am Sun, 5 Oct 2014 05:36:57 +0400 Arseny Nasokin eir...@gmail.com schrieb: Mark, Thank you for patch, I encounter same error and this patch works for me. ✪ -- Eir Nym On 5 October 2014 04:43, Mark Johnston ma...@freebsd.org wrote: On Sat, Oct 04, 2014 at 04:41:07PM -0700, Russell L. Carter wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/04/14 15:58, Mark Johnston wrote: On Sat, Oct 4, 2014 at 3:40 PM, Mark Johnston ma...@freebsd.org wrote: On Sat, Oct 04, 2014 at 04:39:37PM -0400, Ryan Stone wrote: On Sat, Oct 4, 2014 at 2:33 PM, Mark Johnston ma...@freebsd.org wrote: On Sat, Oct 04, 2014 at 07:47:56PM +0200, O. Hartmann wrote: Recent sources (Revision: 272529) fail to compile: [...] cc -m32 -march=native -DCOMPAT_32BIT -isystem /usr/obj/usr/src/lib32/usr/include/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32 -O2 -pipe -O3 -O3 -pipe -DYP -I/usr/obj/usr/src/lib32/usr/include/rpcsvc -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /usr/src/lib/librpcsvc/yp_passwd.c -o yp_passwd.o --- all_subdir_libproc --- --- libproc.so.3 --- /usr/obj/usr/src/tmp/usr/bin/ld: skipping incompatible /usr/obj/usr/src/tmp/usr/lib/libctf.so when searching for I'm confused by this message. Are you building with -DNO_CLEAN? Do you have anything in make.conf or src.conf, especially anything that's changed since libctf was rebuilt? You might try rebuilding libctf with $ cd /usr/src $ make -C cddl/lib/libctf clean all but I'm not sure why ld is ignoring the existing libctf.so. The failure is coming while building the lib32 compat libraries. Are we not currently building a lib32 libctf.so? No, we do. One thing I've noticed is that cddl/lib is built after lib/ when compiling 32-bit libs, whereas cddl/lib is built first when building natively. Sorry, that's not even true. I misread a part of Makefile.inc1. I'm still not able to reproduce the problem, but it seems that the patch here is appropriate: http://people.freebsd.org/~markj/patches/libctf_prebuild.diff Oliver, could you give this a try? Even poudriere can't get past this one. Sorry, it was incomplete. It's been updated: http://people.freebsd.org/~markj/patches/libctf_prebuild.diff ___ 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 After some minor corrections to the patch (the patched original sources seem not to match most recent CURRENT sources as of revision 272562), buildworld works again as expected. Thank you very much. Oliver signature.asc Description: PGP signature
Re: CURRENT: buildworld fails to compile: cannot find -lctf cc: error: linker command failed [libproc.so.3]
Waiting for patch in -CURRENT. -- Eir Nym On 5 October 2014 13:18, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Am Sun, 5 Oct 2014 05:36:57 +0400 Arseny Nasokin eir...@gmail.com schrieb: Mark, Thank you for patch, I encounter same error and this patch works for me. ✪ -- Eir Nym On 5 October 2014 04:43, Mark Johnston ma...@freebsd.org wrote: On Sat, Oct 04, 2014 at 04:41:07PM -0700, Russell L. Carter wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/04/14 15:58, Mark Johnston wrote: On Sat, Oct 4, 2014 at 3:40 PM, Mark Johnston ma...@freebsd.org wrote: On Sat, Oct 04, 2014 at 04:39:37PM -0400, Ryan Stone wrote: On Sat, Oct 4, 2014 at 2:33 PM, Mark Johnston ma...@freebsd.org wrote: On Sat, Oct 04, 2014 at 07:47:56PM +0200, O. Hartmann wrote: Recent sources (Revision: 272529) fail to compile: [...] cc -m32 -march=native -DCOMPAT_32BIT -isystem /usr/obj/usr/src/lib32/usr/include/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32 -O2 -pipe -O3 -O3 -pipe -DYP -I/usr/obj/usr/src/lib32/usr/include/rpcsvc -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /usr/src/lib/librpcsvc/yp_passwd.c -o yp_passwd.o --- all_subdir_libproc --- --- libproc.so.3 --- /usr/obj/usr/src/tmp/usr/bin/ld: skipping incompatible /usr/obj/usr/src/tmp/usr/lib/libctf.so when searching for I'm confused by this message. Are you building with -DNO_CLEAN? Do you have anything in make.conf or src.conf, especially anything that's changed since libctf was rebuilt? You might try rebuilding libctf with $ cd /usr/src $ make -C cddl/lib/libctf clean all but I'm not sure why ld is ignoring the existing libctf.so. The failure is coming while building the lib32 compat libraries. Are we not currently building a lib32 libctf.so? No, we do. One thing I've noticed is that cddl/lib is built after lib/ when compiling 32-bit libs, whereas cddl/lib is built first when building natively. Sorry, that's not even true. I misread a part of Makefile.inc1. I'm still not able to reproduce the problem, but it seems that the patch here is appropriate: http://people.freebsd.org/~markj/patches/libctf_prebuild.diff Oliver, could you give this a try? Even poudriere can't get past this one. Sorry, it was incomplete. It's been updated: http://people.freebsd.org/~markj/patches/libctf_prebuild.diff ___ 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 After some minor corrections to the patch (the patched original sources seem not to match most recent CURRENT sources as of revision 272562), buildworld works again as expected. Thank you very much. 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: About pmap_mapdev() pmap_unmapdev()
Hi Konstantin, Thank you very much for your detailed explanatin. I understood the policy of vmem. Many thanks, Kohji Okuno On Sun, Oct 05, 2014 at 01:15:12PM +0900, Kohji Okuno wrote: Hi, On Sat, Oct 04, 2014 at 08:53:35PM +0900, Kohji Okuno wrote: Hi Konstantin, Thank you for your prompt response. I will test and report from next monday. In addtion, I have one question. In current and 10-stable, is vm_map_delete() called by kva_free()? No, kva_free() only releases the vmem backing, leaving the page tables intact. This is why I only did the stable/9 patch. Where are PTEs allocated by pmap_mapdev() freed in current and 10-stable? Could you please explain me? They are not freed. The removal of the vmem which covers the address space managed by corresponding ptes, allows the reuse of both KVA region and corresponding PTEs in the tables. The only concern with the resident page tables is to avoid two kva_alloc() to step over each other, and this is ensured by vmem. I agree that normal pages are reusable. But, since the pages mapped by pmap_mapdev() are concerned with the physicall address of device (For example: video memory), these PTEs aren't reusable, I think. So, should we free these PTEs by pmap_unmapdev()? There is no hold on any physical pages which were referenced by the ptes. The only thing which is left out are the records in the page tables which map the KVA to said device memory. It is harmless. When the KVA is reused, the ptes in page tables are overwritten. It might be argued that clearing PTEs, or at least removing the PG_V bit catches erronous unintended accesses to the freed range, but by the cost of the overhead of re-polluting the caches. And since clearing is not effective without doing TLB flush, which requires broadcast IPI, it is more trouble than advantage. ___ 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: CURRENT: buildworld fails to compile: cannot find -lctf cc: error: linker command failed [libproc.so.3]
2014-10-05 11:37 GMT+02:00 Arseny Nasokin eir...@gmail.com: Waiting for patch in -CURRENT. -- Eir Nym This patch work in r272559 for me: http://pastebin.com/2QJRYjCK Regards Maurizio ___ 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: HEADS UP: Merging projects/ipfw to HEAD
On 10/4/14 20:35, Alexander V. Chernikov wrote: Hi, I'm going to merge projects/ipfw branch to HEAD in the middle of next week. What has changed: Main user-visible changes are related to tables: * Tables are now identified by names, not numbers. There can be up to 65k tables with up to 63-byte long names. * Tables are now set-aware (default off), so you can switch/move them atomically with rules. * More functionality is supported (swap, lock, limits, user-level lookup, batched add/del) by generic table code. * New table types are added (flow) so you can match multiple packet fields at once. * Ability to add different type of lookup algorithms for particular table type has been added. * New table algorithms are added (cidr:hash, iface:array, number:array and flow:hash) to make certain types of lookup more effective. * Table value are now capable of holding multiple data fields for different tablearg users Some examples (see ipfw(8) manual page for the description): 0:02 [2] zfscurr0# ipfw table fl2 create type flow:src-ip,proto,dst-port algo flow:hash valtype skipto,fib 0:02 [2] zfscurr0# ipfw table fl2 info +++ table(fl2), set(0) +++ kindex: 0, type: flow:src-ip,proto,dst-port valtype: number, references: 0 algorithm: flow:hash items: 0, size: 280 0:02 [2] zfscurr0# ipfw table fl2 add 2a02:6b8::333,tcp,443 45000,12 0:02 [2] zfscurr0# ipfw table fl2 add 10.0.0.92,tcp,80 22000,13 0:02 [2] zfscurr0# ipfw table fl2 list +++ table(fl2), set(0) +++ 2a02:6b8::333,6,443 45000 10.0.0.92,6,80 22000 0:02 [2] zfscurr0# ipfw add 200 count tcp from me to 78.46.89.105 80 flow 'table(fl2)' ipfw table mi_test create type cidr algo cidr:hash masks=/30,/64 ipfw table mi_test add 10.0.0.8/30 ipfw table mi_test add 2a02:6b8:b010::1/64 25 # ipfw table si add 1.1.1.1/32 2.2.2.2/32 added: 1.1.1.1/32 added: 2.2.2.2/32 # ipfw table si add 2.2.2.2/32 2200 4.4.4.4/32 exists: 2.2.2.2/32 2200 added: 4.4.4.4/32 ipfw: Adding record failed: record already exists ^ Returns error but keeps inserted items # ipfw table si list +++ table(si), set(0) +++ 1.1.1.1/32 2.2.2.2/32 4.4.4.4/32 # ipfw table si atomic add 3.3.3.3/32 4.4.4.4/32 4400 5.5.5.5/32 added(reverted): 3.3.3.3/32 exists: 4.4.4.4/32 4400 ignored: 5.5.5.5/32 ipfw: Adding record failed: record already exists ^ Returns error and reverts added records Performance changes: * Main ipfw lock was converted to rmlock * Rule counters were separated from rule itself and made per-cpu. * Radix table entries fits into 128 bytes * struct ip_fw is now more compact so more rules will fit into 64 bytes * interface tables uses array of existing ifindexes for faster match ABI changes: All functionality supported by old ipfw(8) remains functional. Old new binaries can work together with the following restrictions: * Tables named other than ^\d+$ are shown as table(65535) in ruleset in old binaries * I'm a bit unsure about lookup src-port|dst-port N case, something may be broken here. Anyway, this can be fixed for MFC Internal changes:. Changing table ids to numbers resulted in format modification for most sockopt codes. Old sopt format was compact, but very hard to extend (no versioning, inability to add more opcodes), so * All relevant opcodes were converted to TLV-based versioned IP_FW3-based codes. * The remaining opcodes were also converted to be able to eliminate all older opcodes at once * All IP_FW3 handlers uses special API instead of calling sooptcopy* directly to ease adding another communication methods * struct ip_fw is now different for kernel and userland * tablearg value has been changed to 0 to ease future extensions * table values are now indexes in special value array which holds extended data for given index * Batched add/delete has been added to tables code * Most changes has been done to permit batched rule addition. * interface tracking API has been added (started on demand) to permit effective interface tables operations * O(1) skipto cache, currently turned off by default at compile-time (eats 512K). * Several steps has been made towards making libipfw: * most of new functions were separated into parse/prepare/show and actuall-do-stuff pieces (already merged). * there are separate functions for parsing text string into struct ip_fw and printing struct ip_fw to supplied buffer (already merged). * Probably some more less significant/forgotten features ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org Hi, Good job, Waiting for your code :) Regards, Bycn82 ___ freebsd-current@freebsd.org mailing list
Re: i915 driver update testing
On 10/03/2014 13:02, Konstantin Belousov wrote: Please find at the https://kib.kiev.ua/kib/drm/i915.1.patch a patch which provides some updates to the i915 driver. At large, this is import of the batch of Linux commits, and as such, it is interesting mostly as attempt to restart the race to get us more up to date Linux code imported. It might provide some bug fixes, most likely for IvyBridge. Interesting from the development PoV is the update of the GEM i/o ioctl code path to mimic Linux code structure. I am asking _only_ for reports of regressions with the patch applied, comparing with the code which is currently in HEAD. I will not debug any existing bugs, my goal right now is to commit this update, which is needed for further work. I.e., only when you get an issue with the patch applied, but cannot reproduce the problem without the patch, please prepare a bug report. FYI, the driver will attach to haswell gfx, but I am not interested in reports about this (see above paragraph). On my test box, which is Core i7 4770S, the mode-setting and front-buffer rendering works, but Mesa immediately cause renderer to bug out. Work was sponsored by The FreeBSD Foundation, both by time and hardware, and Intel provided access to the documentation. I receive a Fatal trap 12: page fault while in kernel mode. I was previously loading i915kms in rc.conf on 10-stable where the screen would blank out for a short time then switch to native resolution. Last night I compiled a fresh kernel from -head so I could test recent ZFS code (userland still from 10). It behaved like 10. After applying i915.1.patch, the screen blanks in the same place then invisibly panics with a page fault. I hastily replaced the broken kernel so I didn't accidentally boot it, but I would be happy to compile a new one (FYI since info below may not match a new compile). Please tell me if or how you would like me to help. Thanks. FreeBSD colfax 11.0-CURRENT FreeBSD 11.0-CURRENT #2 r272549M: Sun Oct 5 10:32:28 EDT 2014 mcdouga9@colfax:/usr/obj/usr/src/sys/AMD64-11 amd64 panic: page fault CPU: Intel(R) Core(TM) i5 CPU 660 @ 3.33GHz (3325.07-MHz K8-class CPU) [11] Loading kernel modules: [11] info: [drm] Initialized drm 1.1.0 20060810 [11] drmn0: Intel IronLake on vgapci0 [11] info: [drm] MSI enabled 1 message(s) [11] info: [drm] AGP at 0xd000 256MB [11] iicbus0: Philips I2C bus on iicbb0 addr 0xff [11] iic0: I2C generic I/O on iicbus0 [11] iic1: I2C generic I/O on iicbus1 [11] iicbus2: Philips I2C bus on iicbb1 addr 0x0 [11] iic2: I2C generic I/O on iicbus2 [11] iic3: I2C generic I/O on iicbus3 [11] iicbus4: Philips I2C bus on iicbb2 addr 0x0 [11] iic4: I2C generic I/O on iicbus4 [11] iic5: I2C generic I/O on iicbus5 [11] iicbus6: Philips I2C bus on iicbb3 addr 0x0 [11] iic6: I2C generic I/O on iicbus6 [11] iic7: I2C generic I/O on iicbus7 [11] iicbus8: Philips I2C bus on iicbb4 addr 0x0 [11] iic8: I2C generic I/O on iicbus8 [11] iic9: I2C generic I/O on iicbus9 [11] iicbus10: Philips I2C bus on iicbb5 addr 0x0 [11] iic10: I2C generic I/O on iicbus10 [11] iic11: I2C generic I/O on iicbus11 [11] info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [11] info: [drm] Driver supports precise vblank timestamp query. [11] [11] [11] Fatal trap 12: page fault while in kernel mode [11] cpuid = 0; apic id = 00 [11] fault virtual address = 0x0 [11] fault code = supervisor read data, page not present [11] instruction pointer= 0x20:0x8166808e [11] stack pointer = 0x28:0xfe01fe0b2260 [11] frame pointer = 0x28:0xfe01fe0b22a0 [11] code segment = base 0x0, limit 0xf, type 0x1b [11]= DPL 0, pres 1, long 1, def32 0, gran 1 [11] processor eflags = interrupt enabled, resume, IOPL = 0 [11] current process= 124 (kldload) [11] trap number= 12 [11] panic: page fault [11] cpuid = 0 [11] Uptime: 11s [11] Dumping 252 out of 3874 MB:..7%..13%..26%..32%..45%..51%..64%..76%..83%..95% Reading symbols from /boot/kernel/zfs.ko.symbols...done. Loaded symbols for /boot/kernel/zfs.ko.symbols Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. Loaded symbols for /boot/kernel/opensolaris.ko.symbols Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. Loaded symbols for /boot/kernel/linprocfs.ko.symbols Reading symbols from /boot/kernel/linux.ko.symbols...done. Loaded symbols for /boot/kernel/linux.ko.symbols Reading symbols from /boot/kernel/i915kms.ko.symbols...done. Loaded symbols for /boot/kernel/i915kms.ko.symbols Reading symbols from /boot/kernel/drm2.ko.symbols...done. Loaded symbols for /boot/kernel/drm2.ko.symbols Reading symbols from /boot/kernel/iicbus.ko.symbols...done. Loaded symbols for /boot/kernel/iicbus.ko.symbols Reading symbols from /boot/kernel/iic.ko.symbols...done. Loaded symbols for /boot/kernel/iic.ko.symbols Reading symbols from
Re: Buildworld Failure
On Sat, Oct 4, 2014 at 8:30 PM, Shawn Webb latt...@gmail.com wrote:
It looks like buildworld is failing when building the rescue binaries. I'm
not sure which commit broke it. Log is here:
http://0xfeedface.org/~shawn/2014-10-04-build.txt
The build is erroring out when trying to build the crunchgen'd cat for
rescue. Here's the relevant part of the build log:
--- rescue.all__D ---
echo int _crunched_cat_stub(int argc, char **argv, char **envp){return
main(argc,argv,envp);} cat_stub.c
make[5]: make[5]: don't know how to make
/jenkins/usr/local/jenkins/workspace/HardenedBSD-Master/rescue/rescue//usr/local/jenkins/workspace/HardenedBSD-Master/bin/cat/cat.o.
Stop
make[5]: stopped in
/jenkins/usr/local/jenkins/workspace/HardenedBSD-Master/rescue/rescue
*** [rescue] Error code 2
make[4]: stopped in
/usr/local/jenkins/workspace/HardenedBSD-Master/rescue/rescue
1 error
make[4]: stopped in
/usr/local/jenkins/workspace/HardenedBSD-Master/rescue/rescue
*** [_sub.all] Error code 2
Thanks,
Shawn
___
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: i915 driver update testing
On Sun, Oct 05, 2014 at 11:01:14AM -0400, Adam McDougall wrote: (kgdb) #0 doadump (textdump=1) at pcpu.h:219 #1 0x80661efd in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0x80662450 in panic (fmt=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:746 #3 0x808fe52f in trap_fatal (frame=value optimized out, eva=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:866 #4 0x808fe87c in trap_pfault (frame=0xfe01fe0b21b0, usermode=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:677 #5 0x808fde9e in trap (frame=0xfe01fe0b21b0) at /usr/src/sys/amd64/amd64/trap.c:426 #6 0x808e00a2 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #7 0x8166808e in i915_write32 (dev_priv=0xf800031f1c00, reg=20736, val=0) at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_drv.c:992 In kgdb, from this frame, please do p *dev_priv p *(dev_priv-dev) p *(dev_priv-info) #8 0x816928ae in intel_iicbb_pre_xfer (idev=value optimized out) at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c:144 #9 0x81725a17 in iicbb_transfer (dev=0xf800066fa400, msgs=0xfe01fe0b2410, nmsgs=2) at iicbb_if.h:38 #10 0x816931b7 in intel_gmbus_transfer (idev=value optimized out, msgs=value optimized out, nmsgs=value optimized out) at iicbus_if.h:131 #11 0x816a16b3 in intel_sdvo_init (dev=value optimized out, sdvo_reg=value optimized out, is_sdvob=value optimized out) at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_sdvo.c:286 #12 0x81681bd7 in intel_modeset_init (dev=0xf80003c04000) at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_display.c:6603 #13 0x81664fb7 in i915_driver_load (dev=0xf80003c04000, flags=20736) at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_dma.c:1167 #14 0x816e4b85 in drm_attach (kdev=0xf800031e3500, idlist=value optimized out) at /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_drv.c:591 at device_if.h:180 #16 0x806990f9 in bus_generic_driver_added ( dev=value optimized out, driver=value optimized out) at /usr/src/sys/kern/subr_bus.c:2793 #17 0x80695d5a in devclass_driver_added (dc=0xf80003085580, driver=0x816bdf20) at bus_if.h:204 #18 0x80695cbc in devclass_add_driver (dc=0xf80003085580, driver=0x816bdf20, pass=value optimized out, dcp=value optimized out) at /usr/src/sys/kern/subr_bus.c:1137 #19 0x80649d12 in module_register_init (arg=0x816bdf08) at /usr/src/sys/kern/kern_module.c:123 #20 0x8063d214 in linker_load_module (kldname=value optimized out, modname=0xf800060fc400 i915kms, parent=0x0, verinfo=0x0, lfpp=0xfe01fe0b2a80) at /usr/src/sys/kern/kern_linker.c:224 #21 0x8063ed08 in kern_kldload (td=value optimized out, file=value optimized out, fileid=0xfe01fe0b2ac4) at /usr/src/sys/kern/kern_linker.c:1029 #22 0x8063ee4b in sys_kldload (td=0xf80006584920, uap=value optimized out) at /usr/src/sys/kern/kern_linker.c:1055 #23 0x808fef8b in amd64_syscall (td=0xf80006584920, traced=0) at subr_syscall.c:133 #24 0x808e038b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:390 #25 0x000800888cba in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) ___ 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
printing text file with LPD - non-printable characters
I have two LPD errors
1. I see two characters being replaced by strings on the hard copy (the {â}
below is an {a^}). This happens on the first page and not on following
pages.
instead of I get: â\200\234 (235 for trailing )
instead of ' I get: â\200\231
2. All non-english characters get garbled, on all pages. These are
characters like ç, ö, etc.
With these two seemingly separate errors, I can't figure out whether this is
an lpr or enscript error.
* The file being sent through lpr is a simple text file.
* /etc/printcap entry for default printer is:
lp|hp2100|HP 2100TN:\
:rm=192.168.1.9:rp=raw:\
:if=/usr/local/libexec/filters/psif:\
:lf=/var/log/lpd-filter-errs:\
:sd=/var/spool/lpd/hp2100:\
:mx=0:sh:
* /var/log/lpd-filter-errs shows: [ 4 pages * 1 copy ] left in - \ 59
lines were wrapped \ 7 non-printable characters
* filetrs/psif is also very basic:
#!/bin/sh
IFS= read -r first_line
first_two_chars=`expr $first_line : '\(..\)'`
case $first_two_chars in
%!)
# %! : PostScript job, print it.
echo $first_line cat exit 0
exit 2
;;
*)
# otherwise, format with enscript
( echo $first_line; cat ) | /usr/local/bin/enscript -o - exit 0
exit 2
;;
esac
-
FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/printing-text-file-with-LPD-non-printable-characters-tp5954561.html
Sent from the freebsd-current mailing list archive at Nabble.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: printing text file with LPD - non-printable characters
El día Sunday, October 05, 2014 a las 10:41:43AM -0700, Beeblebrox escribió:
I have two LPD errors
1. I see two characters being replaced by strings on the hard copy (the {â}
below is an {a^}). This happens on the first page and not on following
pages.
instead of I get: â\200\234 (235 for trailing )
instead of ' I get: â\200\231
2. All non-english characters get garbled, on all pages. These are
characters like ç, ö, etc.
With these two seemingly separate errors, I can't figure out whether this is
an lpr or enscript error.
First of all check, what encoding has your text file, UTF-8 or ISO or
...?
Then run the file through the filter
$ /usr/local/bin/enscript -o - file out
and check the resulting file 'out'.
I do not know enscript, but guess that it should produce Postscript from
your input file.
I moved the thread by setting Reply-To: to the normal freebsd-question@
list;
matthias
--
Matthias Apitz | /\ ASCII Ribbon Campaign:
E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail
WWW: http://www.unixarea.de/ | X- No proprietary attachments
phone: +49-170-4527211 | / \ - Respect for open standards
| en.wikipedia.org/wiki/ASCII_Ribbon_Campaign
___
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
printing text file with LPD - non-printable characters
@Matthias: I moved the thread by setting Reply-To: to the normal freebsd-question@ list; I'm using the nabble interface, so if the move does not work.. (I've never tried with moved thread before). First of all check, what encoding has your text file, UTF-8 or ISO or $ file print.txt UTF-8 Unicode text, with very long lines Then run the file through the filter Thanks for that idea - helped narrow down the problem to enscript: $ enscript mytext.txt -o filter.txt [ 4 pages * 1 copy ] left in ens.txt 59 lines were wrapped 7 non-printable characters Resulting file has same encoding errors as hard copy. * I should also mention that I tried this from both Desktop and from tty* with same results. * Will any environment settings affect this? The only relevant entry is: LANG=en_US.UTF-8 Regards. -- FreeBSD_amd64_11-Current_RadeonKMS - FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/printing-text-file-with-LPD-non-printable-characters-tp5954561p5954593.html Sent from the freebsd-current mailing list archive at Nabble.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: i915 driver update testing
On Fri, 2014-10-03 at 20:02 +0300, Konstantin Belousov wrote: Please find at the https://kib.kiev.ua/kib/drm/i915.1.patch a patch which provides some updates to the i915 driver. At large, this is import of the batch of Linux commits, and as such, it is interesting mostly as attempt to restart the race to get us more up to date Linux code imported. It might provide some bug fixes, most likely for IvyBridge. Interesting from the development PoV is the update of the GEM i/o ioctl code path to mimic Linux code structure. I am asking _only_ for reports of regressions with the patch applied, comparing with the code which is currently in HEAD. I will not debug any existing bugs, my goal right now is to commit this update, which is needed for further work. I.e., only when you get an issue with the patch applied, but cannot reproduce the problem without the patch, please prepare a bug report. FYI, the driver will attach to haswell gfx, but I am not interested in reports about this (see above paragraph). On my test box, which is Core i7 4770S, the mode-setting and front-buffer rendering works, but Mesa immediately cause renderer to bug out. Work was sponsored by The FreeBSD Foundation, both by time and hardware, and Intel provided access to the documentation. Hi, I got a working X-server and framebuffer console on my Sandybridge system. The only regression I noticed so far is the line below, where the number after 'expected' changes per time the line is printed. Oct 5 21:50:12 crashalot kernel: error: [drm:pid1049:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 160d, was 1600 Oct 5 21:51:04 crashalot kernel: error: [drm:pid1049:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 160d, was 1600 Oct 5 21:53:14 crashalot kernel: error: [drm:pid1170:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 160d, was 1600 ___ 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: What do you use for kernel debugging?
Hi Daniel, On Thu, 2 Oct 2014 20:50:30 -0400, O'Connor, Daniel wrote [...] I wrote a quick program to dump xHCI extended capabilities https://gist.github.com/DanielO/c42819ae69a1f680039a Cool! Run pciconf -lb and look for the base value for xhciX then run the command with that like so.. HCCPARAMS1 = 0x014040c3 xECP (0xf0948500) = ID 1 (Legacy support) Specific 0x0100 xECP (0xf0948504) = ID 0 (Reserved (0)) Specific 0xe000 xECP (0xf0948524) = ID 85 (Reserved (85)) Specific 0x2042 That's with AMD: xhci0: XHCI (generic) USB 3.0 controller mem 0xf0948000-0xf0949fff irq 18 at device 16.0 on pci0 usbus0: waiting for BIOS to give up control xhci0: 32 byte context size. usbus0 on xhci0 xhci0@pci0:0:16:0: class=0x0c0330 card=0x080d1025 chip=0x78141022 rev=0x01 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' class = serial bus subclass = USB BR, -- José Pérez Arauzo ___ 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: CURRENT: buildworld fails to compile: cannot find -lctf cc: error: linker command failed [libproc.so.3]
On Sun, Oct 05, 2014 at 11:18:55AM +0200, O. Hartmann wrote: Am Sun, 5 Oct 2014 05:36:57 +0400 Arseny Nasokin eir...@gmail.com schrieb: Mark, Thank you for patch, I encounter same error and this patch works for me. ✪ -- Eir Nym On 5 October 2014 04:43, Mark Johnston ma...@freebsd.org wrote: On Sat, Oct 04, 2014 at 04:41:07PM -0700, Russell L. Carter wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/04/14 15:58, Mark Johnston wrote: On Sat, Oct 4, 2014 at 3:40 PM, Mark Johnston ma...@freebsd.org wrote: On Sat, Oct 04, 2014 at 04:39:37PM -0400, Ryan Stone wrote: On Sat, Oct 4, 2014 at 2:33 PM, Mark Johnston ma...@freebsd.org wrote: On Sat, Oct 04, 2014 at 07:47:56PM +0200, O. Hartmann wrote: Recent sources (Revision: 272529) fail to compile: [...] cc -m32 -march=native -DCOMPAT_32BIT -isystem /usr/obj/usr/src/lib32/usr/include/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32 -O2 -pipe -O3 -O3 -pipe -DYP -I/usr/obj/usr/src/lib32/usr/include/rpcsvc -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /usr/src/lib/librpcsvc/yp_passwd.c -o yp_passwd.o --- all_subdir_libproc --- --- libproc.so.3 --- /usr/obj/usr/src/tmp/usr/bin/ld: skipping incompatible /usr/obj/usr/src/tmp/usr/lib/libctf.so when searching for I'm confused by this message. Are you building with -DNO_CLEAN? Do you have anything in make.conf or src.conf, especially anything that's changed since libctf was rebuilt? You might try rebuilding libctf with $ cd /usr/src $ make -C cddl/lib/libctf clean all but I'm not sure why ld is ignoring the existing libctf.so. The failure is coming while building the lib32 compat libraries. Are we not currently building a lib32 libctf.so? No, we do. One thing I've noticed is that cddl/lib is built after lib/ when compiling 32-bit libs, whereas cddl/lib is built first when building natively. Sorry, that's not even true. I misread a part of Makefile.inc1. I'm still not able to reproduce the problem, but it seems that the patch here is appropriate: http://people.freebsd.org/~markj/patches/libctf_prebuild.diff Oliver, could you give this a try? Even poudriere can't get past this one. Sorry, it was incomplete. It's been updated: http://people.freebsd.org/~markj/patches/libctf_prebuild.diff ___ 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 After some minor corrections to the patch (the patched original sources seem not to match most recent CURRENT sources as of revision 272562), buildworld works again as expected. Thank you very much. Committed as r272576. Sorry for the breakage. The patch was generated from my git tree, which didn't contain r272484, so the patch wouldn't apply to svn cleanly. I'll be sure to check that next time. :( Thanks, -Mark ___ 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: [CFT] alc(4) QAC AR816x/AR817x ethernet controller support
On Sat, Oct 04, 2014 at 08:10:06PM +, Craig Wiesen wrote:
Yonghyeon PYUN pyunyh at gmail.com writes:
On Wed, Oct 01, 2014 at 10:36:37AM +0900, Yonghyeon PYUN wrote:
On Tue, Sep 30, 2014 at 10:57:41AM +0900, Yonghyeon PYUN wrote:
Hi,
I've added support for QAC AR816x/AR817x ethernet controllers. It
passed my limited testing and I need more testers. You can find
patches from the following URLs.
http://people.freebsd.org/~yongari/alc/pci.quirk.diff
and
http://people.freebsd.org/~yongari/alc/alc.diff.20140930
pci.qurik.diff is to workaround silicon bug of AR816x. Without it
MSI/MSIX interrupt wouldn't work. If you just want to use
legacy INTx interrupt you don't have to apply it but you have to
tell alc(4) not to use MSI/MSIX interrupt with tunables(
hw.alc.msi.disable and hw.alc.msix_disable).
alc.diff.20140930 will add support for AR8161/AR8162/AR8171/AR8172
and E2200 controllers. It supports all hardware features except
RSS. If you have any QAC AR816x/AR817x or old AR813x/AR815x
controllers please test and report how the diff works for you.
Thanks.
http://people.freebsd.org/~yongari/alc/pci.quirk.diff
http://people.freebsd.org/~yongari/alc/alc.diff.20141001
Patch updated to address link establishment issue.
http://people.freebsd.org/~yongari/alc/alc.diff.20141002
Patch updated again to correct wrong lock assertion.
___
Hi-
I can add that I tested your patches on a 9.3 Stable machine.
The motherboard is a GA-Z77-D3H (rev. 1.1) with onboard Atheros AR816x.
I did have to apply one of the patch hunks by hand, see below.
I am able to ssh into the machine, and remotely access apache/poudriere.
I have not seen any problems so far.
I've included a few outputs for you to examine.
Thanks for your testing!
[...]
Rejected hunk:
# cat if_alc.c.rej
This was caused by not MFCing r240693. I'll see whether it could
be merged to stable/9.
***
*** 831,843
CSR_WRITE_4(sc, ALC_PCIE_PHYMISC2, val);
}
/* Disable ASPM L0S and L1. */
- cap = CSR_READ_2(sc, base + PCIER_LINK_CAP);
if ((cap PCIEM_LINK_CAP_ASPM) != 0) {
- ctl = CSR_READ_2(sc, base + PCIER_LINK_CTL);
if ((ctl PCIEM_LINK_CTL_RCB) != 0)
sc-alc_rcb = DMA_CFG_RCB_128;
if (bootverbose)
- device_printf(dev, RCB %u bytes\n,
sc-alc_rcb == DMA_CFG_RCB_64 ? 64 :
128);
state = ctl PCIEM_LINK_CTL_ASPMC;
if (state PCIEM_LINK_CTL_ASPMC_L0S)
--- 1279,1291
CSR_WRITE_4(sc, ALC_PCIE_PHYMISC2, val);
}
/* Disable ASPM L0S and L1. */
+ cap = CSR_READ_2(sc, sc-alc_expcap + PCIER_LINK_CAP);
if ((cap PCIEM_LINK_CAP_ASPM) != 0) {
+ ctl = CSR_READ_2(sc, sc-alc_expcap +
PCIER_LINK_CTL);
if ((ctl PCIEM_LINK_CTL_RCB) != 0)
sc-alc_rcb = DMA_CFG_RCB_128;
if (bootverbose)
+ device_printf(sc-alc_dev, RCB %u
bytes\n,
sc-alc_rcb == DMA_CFG_RCB_64 ? 64 :
128);
state = ctl PCIEM_LINK_CTL_ASPMC;
if (state PCIEM_LINK_CTL_ASPMC_L0S)
___
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: HEADS UP: Merging projects/ipfw to HEAD
Hey Alexander, Very nice work, thank you so much to bring these stuff to us. Best Regards, 2014-10-04 20:35 GMT+08:00 Alexander V. Chernikov melif...@freebsd.org: Hi, I'm going to merge projects/ipfw branch to HEAD in the middle of next week. What has changed: Main user-visible changes are related to tables: * Tables are now identified by names, not numbers. There can be up to 65k tables with up to 63-byte long names. * Tables are now set-aware (default off), so you can switch/move them atomically with rules. * More functionality is supported (swap, lock, limits, user-level lookup, batched add/del) by generic table code. * New table types are added (flow) so you can match multiple packet fields at once. * Ability to add different type of lookup algorithms for particular table type has been added. * New table algorithms are added (cidr:hash, iface:array, number:array and flow:hash) to make certain types of lookup more effective. * Table value are now capable of holding multiple data fields for different tablearg users Some examples (see ipfw(8) manual page for the description): 0:02 [2] zfscurr0# ipfw table fl2 create type flow:src-ip,proto,dst-port algo flow:hash valtype skipto,fib 0:02 [2] zfscurr0# ipfw table fl2 info +++ table(fl2), set(0) +++ kindex: 0, type: flow:src-ip,proto,dst-port valtype: number, references: 0 algorithm: flow:hash items: 0, size: 280 0:02 [2] zfscurr0# ipfw table fl2 add 2a02:6b8::333,tcp,443 45000,12 0:02 [2] zfscurr0# ipfw table fl2 add 10.0.0.92,tcp,80 22000,13 0:02 [2] zfscurr0# ipfw table fl2 list +++ table(fl2), set(0) +++ 2a02:6b8::333,6,443 45000 10.0.0.92,6,80 22000 0:02 [2] zfscurr0# ipfw add 200 count tcp from me to 78.46.89.105 80 flow 'table(fl2)' ipfw table mi_test create type cidr algo cidr:hash masks=/30,/64 ipfw table mi_test add 10.0.0.8/30 ipfw table mi_test add 2a02:6b8:b010::1/64 25 # ipfw table si add 1.1.1.1/32 2.2.2.2/32 added: 1.1.1.1/32 added: 2.2.2.2/32 # ipfw table si add 2.2.2.2/32 2200 4.4.4.4/32 exists: 2.2.2.2/32 2200 added: 4.4.4.4/32 ipfw: Adding record failed: record already exists ^ Returns error but keeps inserted items # ipfw table si list +++ table(si), set(0) +++ 1.1.1.1/32 2.2.2.2/32 4.4.4.4/32 # ipfw table si atomic add 3.3.3.3/32 4.4.4.4/32 4400 5.5.5.5/32 added(reverted): 3.3.3.3/32 exists: 4.4.4.4/32 4400 ignored: 5.5.5.5/32 ipfw: Adding record failed: record already exists ^ Returns error and reverts added records Performance changes: * Main ipfw lock was converted to rmlock * Rule counters were separated from rule itself and made per-cpu. * Radix table entries fits into 128 bytes * struct ip_fw is now more compact so more rules will fit into 64 bytes * interface tables uses array of existing ifindexes for faster match ABI changes: All functionality supported by old ipfw(8) remains functional. Old new binaries can work together with the following restrictions: * Tables named other than ^\d+$ are shown as table(65535) in ruleset in old binaries * I'm a bit unsure about lookup src-port|dst-port N case, something may be broken here. Anyway, this can be fixed for MFC Internal changes:. Changing table ids to numbers resulted in format modification for most sockopt codes. Old sopt format was compact, but very hard to extend (no versioning, inability to add more opcodes), so * All relevant opcodes were converted to TLV-based versioned IP_FW3-based codes. * The remaining opcodes were also converted to be able to eliminate all older opcodes at once * All IP_FW3 handlers uses special API instead of calling sooptcopy* directly to ease adding another communication methods * struct ip_fw is now different for kernel and userland * tablearg value has been changed to 0 to ease future extensions * table values are now indexes in special value array which holds extended data for given index * Batched add/delete has been added to tables code * Most changes has been done to permit batched rule addition. * interface tracking API has been added (started on demand) to permit effective interface tables operations * O(1) skipto cache, currently turned off by default at compile-time (eats 512K). * Several steps has been made towards making libipfw: * most of new functions were separated into parse/prepare/show and actuall-do-stuff pieces (already merged). * there are separate functions for parsing text string into struct ip_fw and printing struct ip_fw to supplied buffer (already merged). * Probably some more less significant/forgotten features ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to
Re: [CFT] alc(4) QAC AR816x/AR817x ethernet controller support
On Fri, Oct 03, 2014 at 09:29:46PM +0200, Dariusz Wierzbicki wrote: Dnia 2014-10-02, o godz. 14:07:30 Yonghyeon PYUN pyu...@gmail.com napisał(a): On Wed, Oct 01, 2014 at 10:36:37AM +0900, Yonghyeon PYUN wrote: On Tue, Sep 30, 2014 at 10:57:41AM +0900, Yonghyeon PYUN wrote: Hi, I've added support for QAC AR816x/AR817x ethernet controllers. It passed my limited testing and I need more testers. You can find patches from the following URLs. http://people.freebsd.org/~yongari/alc/pci.quirk.diff and http://people.freebsd.org/~yongari/alc/alc.diff.20140930 pci.qurik.diff is to workaround silicon bug of AR816x. Without it MSI/MSIX interrupt wouldn't work. If you just want to use legacy INTx interrupt you don't have to apply it but you have to tell alc(4) not to use MSI/MSIX interrupt with tunables( hw.alc.msi.disable and hw.alc.msix_disable). alc.diff.20140930 will add support for AR8161/AR8162/AR8171/AR8172 and E2200 controllers. It supports all hardware features except RSS. If you have any QAC AR816x/AR817x or old AR813x/AR815x controllers please test and report how the diff works for you. Thanks. http://people.freebsd.org/~yongari/alc/pci.quirk.diff http://people.freebsd.org/~yongari/alc/alc.diff.20141001 Patch updated to address link establishment issue. http://people.freebsd.org/~yongari/alc/alc.diff.20141002 Patch updated again to correct wrong lock assertion. Hi ! Thanks for your work ! Are your patches only for current ? I tried on 10 stable. No, it should be applied to stable/10 as well. I intentionally didn't include additional diff for MAC statistics which will not work on stable/10 and stable/9 due to if_inc_counter changes made in HEAD. I tried to apply the diff again against stable/10 and it succeeded with minor fuzz and offset differences. My system: dw@dw:~ % uname -a FreeBSD dw 10.1-RC1 FreeBSD 10.1-RC1 #1 r272477M: Fri Oct 3 20:48:05 CEST 2014 dw@dw:/usr/obj/usr/src/sys/DW amd64 [...] I applied that part manually. Compiled and rebooted system. dmesg | grep alc : alc0: could not disable Rx/Tx MAC(0x4000cb20)! alc0: reset timeout(0x4000cb20)! alc0: could not disable Rx/Tx MAC(0x4000cb20)! ^ I'm more worried about MAC reset and master reset timeout shown below. The MAC reset timeout makes me wonder how this can happen since driver just checks bit 0 and bit 1, the low nibble of the register value can't be 0. alc0: link state changed to UP alc0: could not disable Rx/Tx MAC(0x4000cb20)! alc0: Qualcomm Atheros AR8161 Gigabit Ethernet port 0xd000-0xd07f mem 0xf720-0xf723 irq 18 at device 0.0 on pci3 alc0: reset timeout(0x4000cd00)! I think this also can't happen since driver checks bit[0-3], the low byte should be non-zero when the timeout triggers. alc0: 11776 Tx FIFO, 12032 Rx FIFO miibus0: MII bus on alc0 alc0: Ethernet address: 74:d4:35:91:32:04 [...] If you need other data or more testing, let me know. Do you have any local changes in alc(4)? As I said, the diff could be applied to stable/10 without any manual modification. Thanks for testing! ___ 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
NFS installworld failures
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, Am I the only one attempting to maintain a local cluster using a buildworld server and mounting /usr/src/ and /usr/obj/ via NFS? I intermittently run into installworld failures, usually in sys/boot/i386 but occasionally e.g. cddl/lib where the install targets are apparently out of date, and want to be rebuilt, which doesn't work with a read-only mount. Is this a reasonable thing to expect to work, or maybe not? Every system in the cluster has got ntpd functioning correctly. Here's today's 2nd blocker: === cddl/lib/drti (install) /usr/bin/cc -O2 -pipe - -I/usr/src/cddl/lib/drti/../../../sys/cddl/compat/opensolaris - -I/usr/src/cddl/lib/drti/../../../cddl/compat/opensolaris/include - -I/usr/src/cddl/lib/drti/../../../cddl/contrib/opensolaris/head - -I/usr/src/cddl/lib/drti/../../../cddl/contrib/opensolaris/lib/libctf/common -I/usr/src/cddl/lib/drti/../../../cddl/contrib/opensolaris/lib/libdtrace/common -I/usr/src/cddl/lib/drti/../../../sys/cddl/contrib/opensolaris/uts/common -DPIC -fpic -DNEED_SOLARIS_BOOLEAN -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wno-unknown-pragmas -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/cddl/lib/drti/../../../cddl/contrib/opensolaris/lib/libdtrace/common/drti.c -o drti.o error: unable to open output file 'drti.o': '' Best regards, Russell -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUMg52AAoJEFnLrGVSDFaEwrgP+wReSDvMhWBH25l3aOkYJbpx CXl0x/a4eSSS38UOa46KIUTFnx68XKElqUFi8eHRcSXe0L0pCNq1UQw5Qrp5Uaj0 d5GaKpkm3IP/IZtTzIbh60N2oc8einYXHWP5LsDx3Au4b4y0p2CX7ApQr61H7n5G 6E8XJ8lSrS13NBI0RvWAVY54+DzuLeoubvpJqMoodb01YToY/e3HHn/K5gbmF/x8 JK5tsW1XvGsRFxT/NLDKumuaf0JQLrRHD9DjiKTELAvtLdg7k4G4yf0BmobojUrB E1RajK8HppmyP0S2UvZMisMfEZ3radl0PKPbk/cCLMLWC1kiLWyZ70OSZ/537umY 94fF0irY0TmnsHENpQmtDB7OwPFb80bn9ztuEo54PI8j2rnSuvB4FNkHNTuTtkAi JY7V3cu2yjVbuqw7ailutc5We7jEurS+5Gi72KEL9pLs22WFtmtHfAgrZuRE4Ror RudQpszK4TIljNgh9tF3g4nMMiabKwHq4Ws2BqrZ3wJCl8tgLdetR/hGHR325dTL CnLp8YdoU6gbfbTBWqQrnmV02VMOinK+ZAAy7ATufQhy9tVIwai1gz27ou4tkkmb i0vDqv+jQoP7S6/4LfGkBJQ53X1O4L+zRYJ53YCfoH7kM4g4tNbvCDBYYG/EFU3+ 2EDMkHl04WIJvg1VcaT1 =N1ME -END PGP SIGNATURE- ___ 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: NFS installworld failures
On Sun, Oct 05, 2014 at 08:37:26PM -0700, Russell L. Carter wrote:
Greetings,
Am I the only one attempting to maintain a local cluster using
a buildworld server and mounting /usr/src/ and /usr/obj/ via NFS?
No; I do that, as well (for a couple of client machines), but they're
tracking stable/9, rather than head. (I'd switch them to stable/10, but
they run authoritative name servers, and I haven't figured out a
reasonable way to do that migration because of the way the installation
of the dns/bind99 port depends on the version of the OS at install (vs.
run) time.)
I intermittently run into installworld failures, usually
in sys/boot/i386 but occasionally e.g. cddl/lib where the
install targets are apparently out of date, and want to be
rebuilt, which doesn't work with a read-only mount.
Is this a reasonable thing to expect to work, or maybe not?
I would expect it to work -- at least, if the machines are all
reasonably closely synchronized with respect to time-of-day.
Oh -- and if the machines have compatible /etc/{make,src}.conf files.
IIRC, I also ended up needing to create a symlink or two.
Every system in the cluster has got ntpd functioning correctly.
Well, that should take care of the time-of-day (potential) issue.
Here's today's 2nd blocker:
=== cddl/lib/drti (install)
/usr/bin/cc -O2 -pipe
-I/usr/src/cddl/lib/drti/../../../sys/cddl/compat/opensolaris
-I/usr/src/cddl/lib/drti/../../../cddl/compat/opensolaris/include
-I/usr/src/cddl/lib/drti/../../../cddl/contrib/opensolaris/head
-
-I/usr/src/cddl/lib/drti/../../../cddl/contrib/opensolaris/lib/libctf/common
-I/usr/src/cddl/lib/drti/../../../cddl/contrib/opensolaris/lib/libdtrace/common
-I/usr/src/cddl/lib/drti/../../../sys/cddl/contrib/opensolaris/uts/common
-DPIC -fpic -DNEED_SOLARIS_BOOLEAN -std=gnu99 -fstack-protector
-Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align
-Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls
-Wold-style-definition -Wno-pointer-sign -Wno-unknown-pragmas
-Wmissing-variable-declarations -Wthread-safety -Wno-empty-body
-Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c
/usr/src/cddl/lib/drti/../../../cddl/contrib/opensolaris/lib/libdtrace/common/drti.c
-o drti.o
error: unable to open output file 'drti.o': ''
...
Sorry; it's been a long time since I encountered anything similar to
that, and I no longer recall what might have contributed to it. But I
do definitely do NFS installs; ref.:
FreeBSD albert.catwhisker.org 9.3-STABLE FreeBSD 9.3-STABLE #74
r272439M/272471:903504: Fri Oct 3 05:14:22 PDT 2014
r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/ALBERT i386
FreeBSD bats.catwhisker.org 9.3-STABLE FreeBSD 9.3-STABLE #74
r272439M/272471:903504: Fri Oct 3 05:17:39 PDT 2014
r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/BATS i386
(My build machine -- freebeast -- is powered off until just
before midnight.)
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
Taliban: Evil cowards with guns afraid of truth from a 14-year old girl.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
pgpg56MqLTTJ1.pgp
Description: PGP signature
Re: NFS installworld failures
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/05/14 20:51, David Wolfskill wrote: On Sun, Oct 05, 2014 at 08:37:26PM -0700, Russell L. Carter wrote: Greetings, Am I the only one attempting to maintain a local cluster using a buildworld server and mounting /usr/src/ and /usr/obj/ via NFS? [...] that, and I no longer recall what might have contributed to it. But I do definitely do NFS installs; ref.: FreeBSD albert.catwhisker.org 9.3-STABLE FreeBSD 9.3-STABLE #74 r272439M/272471:903504: Fri Oct 3 05:14:22 PDT 2014 r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/ALBERT i386 FreeBSD bats.catwhisker.org 9.3-STABLE FreeBSD 9.3-STABLE #74 r272439M/272471:903504: Fri Oct 3 05:17:39 PDT 2014 r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/BATS i386 (My build machine -- freebeast -- is powered off until just before midnight.) - -current has weather: NFS installs in May Jun required write privileges on the NFS share so the local system could build what it felt was out-of-date, but then at some point root mounts lost write privileges (even though linux can mount NFS root rw no problem, I haven't bothered to track this down yet). And that is basically a GOOD THING, so I've tried hard to get my installs working that way. Through a lot of July and August this was no problem. But in September it started again. It's a timestamp issue with dependencies, I am guessing, but I'm a cmake man these days, and don't know how to debug it. Russell (and am I'm the only luser around that depends on thunderbird external editor to make my messages readable, and now that it appears to be broken I'm back to stupid land?) Peace, david -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUMh4OAAoJEFnLrGVSDFaEWNMQAInucNxPiv2jufB9QXJzf3RC NlKzDL6HgUOLF+RBTwz0CmY2o7yejXpKjqfZVMZCzEcROQMagI4rvjJAyHc8RYmN /7Yv7SSjqGjOzJqMZNLIXTnwApZoXoQjkRK7xGStcjtNFO5eBekVmShvqtfGC6No 39HqFQ7HQGw5g8YQnvBw1lPmOv96Mawn7Yx9QYsM7EsZoy+pij4ZylPDz5Z8Ondq Teya/PNSr6vHeHR0pCsFdbt2ePZyVxjyJAkMJLwc+7WBd0+NG/Nh6YRfHZFOcpT4 reyzAbejSoWvOjOt7qeLsClB90T6Fuu8zN2dbbabjU4VSfAKAF0jG8+lTZ0wBpUD DabsiCrlur+aVwPP6Bi24sbOb7L1rHS7xBQOUYeJpcgFNbh9exDVbvIeB3ZdCDIt yxriPgR43UOYYKmUl4xnzWOv3Z0mGSmOXhXcU2CB6khqjwc9JtofnTOZtTnyuOon NL9QlVbloenDPXDi9OeaxxxRoBd7gNZteq41NcVmLxvb+iwYuy21l954y85fze0d KUMCKvydq2GjXsT81jj5BtIedMtURfPRycNV+3kPl+/MC1A/ECteqVtgXxuIP740 JeCBhUlMRJvifQgIabZezdtNW9v1A7jrmYCtjTGw2CIvvcMs/RITu4Iqu4cDQ/xS 2bXkVKiHicbxTxyEdSpe =qQFl -END PGP SIGNATURE- ___ 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
