Re: Intel Haswell support - Any updates?

2015-09-22 Thread Jean-Sébastien Pédron 
On 18.09.2015 08:30, Shane Ambler wrote:
> A little off-topic but has anyone tried to get nvidia to return libcuda
> to our drivers? While it was there a few years ago it was removed yet
> again. From what I could tell we had to use the linux sdk to compile
> cuda kernels which probably hindered freebsd using it so the sdk may
> need porting to freebsd as well.

During XDC last week, we talked about that with an NVIDIA developer (ie.
working for NVIDIA, not on Nouveau). CUDA is a bit complex: it's not
only a library but also a toolchain. This is a lot of effort and, as a
company, they probably won't port/maintain it except if FreeBSD
customers are asking for it.

However, this developer will see if libOpenCL.so can be compiled on
FreeBSD and shipped with nvidia-driver. It could just be a matter of
enabling the build.

-- 
Jean-Sébastien Pédron



signature.asc
Description: OpenPGP digital signature

Re: Intel Haswell support - Any updates?

2015-09-22 Thread Jean-Sébastien Pédron 
On 17.09.2015 21:22, O. Hartmann wrote:
>> Why does it take so much time to update? Once Konstantin committed his
>> i915 update, I was busy with non-FreeBSD activities until last July,
>> when I slowly started back to work on i915. My goal is to reduce the
>> diff with Linux as much as possible. But, as opposed to OpenBSD and
>> DragonFlyBSD, we do not use a Linux compatibility layer which would
>> dramatically ease our life.
> 
> My concerns are speed and performance. Isn't any kind of layer consuming 
> performance -
> sometimes worse, sometimes negligible. But anyway, HPC isn't a FreeBSD 
> domain, so ...

Like Nikola said, the layer shouldn't have any performance impact. Most
of the functions are either macros wrapping the FreeBSD native functions
or new implementations (for instance, linux/idr.h).

> The spoken of facilities are "generic" or are they Linux-unique and have to 
> be adopted
> for FreeBSD?

Those facilities are generic tools.

-- 
Jean-Sébastien Pédron



signature.asc
Description: OpenPGP digital signature

Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel (really, this time)

2015-09-22 Thread Rui Paulo 
On Tue, 2015-09-22 at 10:23 -0400, Ed Maste wrote:
> I am preparing to move the standalone kernel debug data out of
> /boot/kernel/ into /usr/lib/debug/boot/kernel/, mirroring the
> approach
> used for userland debug data. This significantly reduces the boot
> partition size requirement, and is a step towards supporting the
> installation of kernel debug data ony when required. LLDB and GDB
> automatically search for debug data under /usr/lib/debug/ so this
> change should be transparent from an end-user perspective.
> 
> The change can be reviewed in Phabricator at
> https://reviews.freebsd.org/D1006 and can be fetched as a unified
> diff
> from https://people.freebsd.org/~emaste/patches/D1006.diff
> 
> This change was discussed on -current last year[1] and a number of
> concerns were raised. These are addressed in the updated patch, and
> I'll summarize them here:
> 
> * /usr/lib seems like an odd location for this data
> /usr/lib/debug is the standard location established by GDB, and seems
> reasonable enough. I don't want to introduce gratuitous differences
> when compared with other systems.
> 
> * Do gdb / lldb look also in /usr/local/lib/debug, for ports debug
> files?
> Not yet; this is definitely something to address with additional
> work.
> 
> * Is it possible to keep the current behaviour?
> Yes, set KERN_DEBUGDIR="" in src.conf(5).
> 
> * /usr now needs to be mounted for savecore to work
> Savecore does not rely on debug files; crashinfo does. As crashinfo
> also requires /usr/bin/gdb /usr already needs to be mounted.
> 
> * This makes working with multiple kernels more difficult.
> Users with a workflow requiring a single "cp" or "mv" to shuffle
> around kernels and debug data can use the src.conf(5) setting to keep
> things as today. The techniques documented in build(7) for working
> with multiple named kernels require no changes; for example a kernel
> in /boot/newkernel/ will have its debug data in
> /usr/lib/debug/boot/newkernel/. The kernel to kernel.old rotation
> also
> works on both /boot/kernel and /usr/lib/debug/boot/kernel.
> 
> * Why rename .symbols to .debug?
> 1) This is what they're called elsewhere.
> 2) It's not an accurate description of the file's content. Some
> symbol
> data also exists in the binary or library, and there is a lot more
> debugging information in the standalone debug file than just symbols.
> 3) Userland and kernel debug data will have the same debug extension.
> Renaming them along with the other changes is a better approach than
> having another change later on.
> 
> I plan to commit the change later this week.
> 

Yay, thanks!


-- 
Rui Paulo

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HWPMC panic

2015-09-22 Thread Larry Rosenman 

On 2015-09-22 15:43, Sean Bruno wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On 08/26/15 14:12, Larry Rosenman wrote:

Was playing with pmcstats -S instructions -T, and got the following
when I tried to ctrl/c out.


oldtbh.lerctr.org dumped core - see /var/crash/vmcore.3

Wed Aug 26 16:05:16 CDT 2015

FreeBSD oldtbh.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #18
r287033: Sun Aug 23 18:08:24 CDT 2015
r...@oldtbh.lerctr.org:/usr/obj/usr/src/sys/VT-LER  amd64

panic: [p4,700] class mismatch pd 260 != id class 4

GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation,
Inc. GDB is free software, covered by the GNU General Public
License, and you are welcome to change it and/or distribute copies
of it under certain conditions. Type "show copying" to see the
conditions. There is absolutely no warranty for GDB.  Type "show
warranty" for details. This GDB was configured as
"amd64-marcel-freebsd"...

Unread portion of the kernel message buffer: panic: [p4,700] class
mismatch pd 260 != id class 4 cpuid = 1 KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe0238744770 vpanic() at vpanic+0x189/frame
0xfe02387447f0 kassert_panic() at kassert_panic+0x132/frame
0xfe0238744860 p4_read_pmc() at p4_read_pmc+0x185/frame
0xfe02387448b0 pmc_stop() at pmc_stop+0x132/frame
0xfe02387448f0 pmc_syscall_handler() at
pmc_syscall_handler+0x1752/frame 0xfe0238744ae0 amd64_syscall()
at amd64_syscall+0x25d/frame 0xfe0238744bf0 Xfast_syscall() at
Xfast_syscall+0xfb/frame 0xfe0238744bf0 --- syscall (0, FreeBSD
ELF64, nosys), rip = 0x801407ffa, rsp = 0x7fffe588, rbp =
0x7fffe5a0 --- Uptime: 2d8h36m19s Dumping 3475 out of 8158
MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%

Reading symbols from /boot/kernel/if_lagg.ko.symbols...done. Loaded
symbols for /boot/kernel/if_lagg.ko.symbols Reading symbols from
/boot/kernel/hwpmc.ko.symbols...done. Loaded symbols for
/boot/kernel/hwpmc.ko.symbols #0  doadump (textdump=1) at
pcpu.h:221 221  pcpu.h: No such file or directory. in pcpu.h (kgdb)
#0  doadump (textdump=1) at pcpu.h:221 #1  0x80b34ca5 in
kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:329 #2
0x80b35298 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:626 #3
0x80b350c2 in kassert_panic (fmt=) at
/usr/src/sys/kern/kern_shutdown.c:516 #4  0x8242ee25 in
p4_read_pmc (cpu=1, ri=12, v=0xf8012b206aa0) at
/usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_piv.c:699 #5
0x82425102 in pmc_stop (pm=0xf8012b206a80) at
/usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_mod.c:2741 #6
0x82423a12 in pmc_syscall_handler (td=, syscall_args=) at
/usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_mod.c:3923 #7
0x80f7c38d in amd64_syscall (td=0xf801060759a0,
traced=0) at subr_syscall.c:133 #8  0x80f5b26b in
Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:395 #9
0x000801407ffa in ?? () Previous frame inner to this frame
(corrupt stack?) Current language:  auto; currently minimal (kgdb)



vmcore IS available, and I *CAN* give ssh access.




Odd, can you post what CPU type you have? e.g. from my dmesg:

CPU: Intel(R) Xeon(R) CPU   E5620  @ 2.40GHz (2400.13-MHz
K8-class CPU)
  Origin="GenuineIntel"  Id=0x206c2  Family=0x6  Model=0x2c  Stepping=2

Features=0xbfebfbff

Features2=0x29ee3ff
  AMD Features=0x2c100800
  AMD Features2=0x1
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQF8BAEBCgBmBQJWAb1iXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx
MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kcewIAISYfYFC/9rpqZ3vb+ZwIdlc
Jhlt15YNhNn10NjtEEi5VE90+gSHXW5I96qTmBaplCNOYRBc86D8KgNUMJT48H2e
VTL0J2nBLn6jsqflq+08ps4/z0yFd7L8f+1EayP9RpkXsD6ZpdqMQsX26fT6UZDK
q1lTJI9eEngN7EsbIcCmSYYm2geieePxOQgJIOXCO2k8MnB6yfiTHIowTe2klLvT
aHzcr6YOCIVG42KFdNFg8ECjBF2VAzov08u5axVuzC447OI9dsItE2f7xum7Cwq6
Tq7kVMI+0+XXxXHCq/ju7gjvp0E5hRqsi3TiO7eEz6WmIYyTnnD8A+ffgC/9v/A=
=C+xz
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to 
"freebsd-current-unsubscr...@freebsd.org"

CPU: Intel(R) Xeon(TM) CPU 3.00GHz (2992.57-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0xf43  Family=0xf  Model=0x4  Stepping=3
  
Features=0xbfebfbff

  Features2=0x641d
  AMD Features=0x20100800
  TSC: P-state invariant
real memory  = 9395240960 (8960 MB)
avail memory = 8257761280 (7875 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 2 package(s) x 1 core(s) x 2 HTT threads



--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 7011 W Parmer Ln, Apt 1115, Austin, T

Re: HWPMC panic

2015-09-22 Thread Sean Bruno 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On 08/26/15 14:12, Larry Rosenman wrote:
> Was playing with pmcstats -S instructions -T, and got the following
> when I tried to ctrl/c out.
> 
> 
> oldtbh.lerctr.org dumped core - see /var/crash/vmcore.3
> 
> Wed Aug 26 16:05:16 CDT 2015
> 
> FreeBSD oldtbh.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #18
> r287033: Sun Aug 23 18:08:24 CDT 2015
> r...@oldtbh.lerctr.org:/usr/obj/usr/src/sys/VT-LER  amd64
> 
> panic: [p4,700] class mismatch pd 260 != id class 4
> 
> GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation,
> Inc. GDB is free software, covered by the GNU General Public
> License, and you are welcome to change it and/or distribute copies
> of it under certain conditions. Type "show copying" to see the
> conditions. There is absolutely no warranty for GDB.  Type "show
> warranty" for details. This GDB was configured as
> "amd64-marcel-freebsd"...
> 
> Unread portion of the kernel message buffer: panic: [p4,700] class
> mismatch pd 260 != id class 4 cpuid = 1 KDB: stack backtrace: 
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfe0238744770 vpanic() at vpanic+0x189/frame
> 0xfe02387447f0 kassert_panic() at kassert_panic+0x132/frame
> 0xfe0238744860 p4_read_pmc() at p4_read_pmc+0x185/frame
> 0xfe02387448b0 pmc_stop() at pmc_stop+0x132/frame
> 0xfe02387448f0 pmc_syscall_handler() at
> pmc_syscall_handler+0x1752/frame 0xfe0238744ae0 amd64_syscall()
> at amd64_syscall+0x25d/frame 0xfe0238744bf0 Xfast_syscall() at
> Xfast_syscall+0xfb/frame 0xfe0238744bf0 --- syscall (0, FreeBSD
> ELF64, nosys), rip = 0x801407ffa, rsp = 0x7fffe588, rbp =
> 0x7fffe5a0 --- Uptime: 2d8h36m19s Dumping 3475 out of 8158
> MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
> 
> Reading symbols from /boot/kernel/if_lagg.ko.symbols...done. Loaded
> symbols for /boot/kernel/if_lagg.ko.symbols Reading symbols from
> /boot/kernel/hwpmc.ko.symbols...done. Loaded symbols for
> /boot/kernel/hwpmc.ko.symbols #0  doadump (textdump=1) at
> pcpu.h:221 221pcpu.h: No such file or directory. in pcpu.h (kgdb)
> #0  doadump (textdump=1) at pcpu.h:221 #1  0x80b34ca5 in
> kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:329 #2
> 0x80b35298 in vpanic (fmt=, ap= optimized out>) at /usr/src/sys/kern/kern_shutdown.c:626 #3
> 0x80b350c2 in kassert_panic (fmt=) at
> /usr/src/sys/kern/kern_shutdown.c:516 #4  0x8242ee25 in
> p4_read_pmc (cpu=1, ri=12, v=0xf8012b206aa0) at
> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_piv.c:699 #5
> 0x82425102 in pmc_stop (pm=0xf8012b206a80) at
> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_mod.c:2741 #6
> 0x82423a12 in pmc_syscall_handler (td= out>, syscall_args=) at
> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_mod.c:3923 #7
> 0x80f7c38d in amd64_syscall (td=0xf801060759a0,
> traced=0) at subr_syscall.c:133 #8  0x80f5b26b in
> Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:395 #9
> 0x000801407ffa in ?? () Previous frame inner to this frame
> (corrupt stack?) Current language:  auto; currently minimal (kgdb)
> 
> 
> 
> vmcore IS available, and I *CAN* give ssh access.
> 


Odd, can you post what CPU type you have? e.g. from my dmesg:

CPU: Intel(R) Xeon(R) CPU   E5620  @ 2.40GHz (2400.13-MHz
K8-class CPU)
  Origin="GenuineIntel"  Id=0x206c2  Family=0x6  Model=0x2c  Stepping=2

Features=0xbfebfbff

Features2=0x29ee3ff
  AMD Features=0x2c100800
  AMD Features2=0x1
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQF8BAEBCgBmBQJWAb1iXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx
MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kcewIAISYfYFC/9rpqZ3vb+ZwIdlc
Jhlt15YNhNn10NjtEEi5VE90+gSHXW5I96qTmBaplCNOYRBc86D8KgNUMJT48H2e
VTL0J2nBLn6jsqflq+08ps4/z0yFd7L8f+1EayP9RpkXsD6ZpdqMQsX26fT6UZDK
q1lTJI9eEngN7EsbIcCmSYYm2geieePxOQgJIOXCO2k8MnB6yfiTHIowTe2klLvT
aHzcr6YOCIVG42KFdNFg8ECjBF2VAzov08u5axVuzC447OI9dsItE2f7xum7Cwq6
Tq7kVMI+0+XXxXHCq/ju7gjvp0E5hRqsi3TiO7eEz6WmIYyTnnD8A+ffgC/9v/A=
=C+xz
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT: net/igb broken

2015-09-22 Thread Sean Bruno 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On 09/21/15 23:23, O. Hartmann wrote:
> On Mon, 21 Sep 2015 21:13:18 + Eric Joyner 
> wrote:
> 
>> If you do a diff between r288057 and r287761, there are no
>> differences between the sys/dev/e1000, sys/modules/em, and
>> sys/modules/igb directories. Are you sure r287761 actually
>> works?
> 
> I'm quite sure r287761 works (and r287762 doesn't), double checked
> this this morning again. I also checked r288093 and it is still not
> working.
> 
> The ensure that I'm not the culprit and stupid here:
> 
> I use a NanoBSD environment and the only thing that gets exchanged,
> is the underlying OS/OS revision. The configuration always stays
> the same. The base system for all of my tests is built from a clean
> source - (deleted obj/ dir, clean, fresh build into obj/ for every
> test I ran).
> 
> I realised a funny thing. Playing around with enabling/disabling
> TSO (I have been told that could be the culprit in an earlier Email
> from this list) with the commend sequence:
> 
> ifconfig igb1 down ifconfig igb1 -tso ifconfig igb1 up ifconfig
> igb1 down ifconfig igb1 tso ifconfig igb1 up . . .
> 
> while a ping is pinging in the background a remote host connected
> to that specific interface, the ping does work for a while and dies
> then after a round trip of roughly 10 - 20. I can reproduce this.
> 
> is that observation of any help?
> 
> Regards,
> 
> oh
> 
>> 
>> On Mon, Sep 21, 2015 at 1:58 AM O. Hartmann
>>  wrote:
>> 
>>> On Sat, 19 Sep 2015 11:23:44 -0700 Sean Bruno
>>>  wrote:
>>> 
> 
> 
> On 09/18/15 10:20, Eric Joyner wrote:
>> He has an i210 -- he would want to revert
>> e1000_i210.[ch], too.
>> 
>> Sorry for the thrash Sean -- it sounds like it would be a
>> good idea for you should revert this patch, and Jeff and
>> I can go look at trying these shared code updates and igb
>> changes internally again. We at Intel really could've
>> done a better job of making sure these changes worked
>> across a wider variety of devices.
>> 
>> - Eric
> 
> I've reverted the changes to head.  I'll reopen the reviews and we
> can proceed from there.
> 
> sean
> 
> 
>> 
>> On Fri, Sep 18, 2015 at 9:50 AM Sean Bruno
>> mailto:sbr...@freebsd.org>> wrote:
>> 
>> 
>>> 
>>> r287762 broke the system
>> 
>> 
>> Before I revert this changeset *again* can you test
>> revert r287762 from if_igb.c, e1000_82575.c and
>> e1000_82575.h *only*
>> 
>> That narrows down the change quite a bit.
>> 
>> sean ___ 
>> freebsd-current@freebsd.org
>>  mailing list 
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to 
>> "freebsd-current-unsubscr...@freebsd.org 
>> "
>> 
>>> 
>>> I'm now on r288057 on that specific machine, supposedly
>>> reverted changes that seemingly has been identified as the
>>> culprit. Still NO change in behaviour!
>>> 
>>> r287761 works with the same configuration on igb (i210), any
>>> further does not. Not ping/connect from the outside, no
>>> ping/connect from the inside. Tried different protocols (SAMBA,
>>> ssh, LDAP, DNS). Affected is/are only boxes with the igb driver
>>> and i210 chipset (we do not have other chips covered by igb).
>>> 
>>> Regards, Oliver
>>> 
>> ___ 
>> freebsd-current@freebsd.org mailing list 
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current To
>> unsubscribe, send any mail to
>> "freebsd-current-unsubscr...@freebsd.org"
> 
> 


For my entertainment (and HPS's), can you run HEAD and revert r287775?

sean
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQF8BAEBCgBmBQJWAbWOXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx
MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kPTAH/jmm1tudLRYVtC+xb9NXHQgr
dl8/fZC8/xL3m0EVM8pWdKlRbF1tHUDSB/2ftYUBEe6SIkab2IZx2Z/0VgdflrbB
05HQUuq1yM3dYBiEAjyM0oK6lfeWu2Jg8nOaA5YWi1GO2OfkuDfXRUkK3sm7xa0C
PE+ZMlfofQCV0RyDu2ew17yZKYRbCXdc+GYg6CGNRRVJHeITZPyAAh8X1d7pC8G3
8vJLKC8JOmg0i5yToYSkKvXdrReHUpzF+hZKgxsl5Lb4BhcHEukkSWQVsJ9IuVGU
615sN6eVub2+OBbxJyV+CcjUVwdLJba/YBUXhWdKslDrN2z9l/sAFHCxDJlmAvc=
=zdDL
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: BXR.SU, Super User's BSD Cross Reference w/ OpenGrok, publicly private beta

2015-09-22 Thread Jan Beich 
"Constantine A. Murenin"  writes:

[...]
>   Just how fast is BXR.SU?
>
> We expect that most search requests should be fulfilled (search page
> results generated) in well under 100ms.  In my tests, and according to
> OpenGrok metrics at the bottom of each search page, most search pages
> are generated in about 30 to 50ms, so, it does seem like there's some
> room to spare.  In addition, of course we use nginx, so, once
> generated at 40ms, a page should be available immediately in no time
> should a subsequent identical request come along within a couple of
> seconds or so.
>
>
>   How does it compare with fxr.watson.org?
>
> + we're based on OpenGrok, instead of LXR
> + we also index userland of all BSDs, not just the kernels like the fxr
> + we do daily updates and re-index of all 4 BSDs
> - we only track -CURRENT of each BSD
> + the -current that we track is actually current

Last modified date on FreeBSD files is 09-Dec-2013. Do you plan to fix it?

-

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

HEADS UP: Standalone kernel debug files moving out of /boot/kernel (really, this time)

2015-09-22 Thread Ed Maste 
I am preparing to move the standalone kernel debug data out of
/boot/kernel/ into /usr/lib/debug/boot/kernel/, mirroring the approach
used for userland debug data. This significantly reduces the boot
partition size requirement, and is a step towards supporting the
installation of kernel debug data ony when required. LLDB and GDB
automatically search for debug data under /usr/lib/debug/ so this
change should be transparent from an end-user perspective.

The change can be reviewed in Phabricator at
https://reviews.freebsd.org/D1006 and can be fetched as a unified diff
from https://people.freebsd.org/~emaste/patches/D1006.diff

This change was discussed on -current last year[1] and a number of
concerns were raised. These are addressed in the updated patch, and
I'll summarize them here:

* /usr/lib seems like an odd location for this data
/usr/lib/debug is the standard location established by GDB, and seems
reasonable enough. I don't want to introduce gratuitous differences
when compared with other systems.

* Do gdb / lldb look also in /usr/local/lib/debug, for ports debug files?
Not yet; this is definitely something to address with additional work.

* Is it possible to keep the current behaviour?
Yes, set KERN_DEBUGDIR="" in src.conf(5).

* /usr now needs to be mounted for savecore to work
Savecore does not rely on debug files; crashinfo does. As crashinfo
also requires /usr/bin/gdb /usr already needs to be mounted.

* This makes working with multiple kernels more difficult.
Users with a workflow requiring a single "cp" or "mv" to shuffle
around kernels and debug data can use the src.conf(5) setting to keep
things as today. The techniques documented in build(7) for working
with multiple named kernels require no changes; for example a kernel
in /boot/newkernel/ will have its debug data in
/usr/lib/debug/boot/newkernel/. The kernel to kernel.old rotation also
works on both /boot/kernel and /usr/lib/debug/boot/kernel.

* Why rename .symbols to .debug?
1) This is what they're called elsewhere.
2) It's not an accurate description of the file's content. Some symbol
data also exists in the binary or library, and there is a lot more
debugging information in the standalone debug file than just symbols.
3) Userland and kernel debug data will have the same debug extension.
Renaming them along with the other changes is a better approach than
having another change later on.

I plan to commit the change later this week.

[1] https://lists.freebsd.org/pipermail/freebsd-current/2014-October/052926.html
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CTF] pkg 1.6.0

2015-09-22 Thread Baptiste Daroussin 
On Tue, Sep 22, 2015 at 09:20:28AM +0200, Ranjan1018 . wrote:
> 2015-09-21 23:27 GMT+02:00 Baptiste Daroussin :
> 
> > Hi all,
> >
> > We are about to release pkg 1.6.0. pkg-devel has been updated to 1.5.99.13
> > aka
> > 1.6.0 rc3 that we hope will become the new pkg 1.6.0 btw the end of the
> > Week
> > (release planned for Saturday 26th of September or no important issues are
> > raised)
> >
> > On the list of changes:
> > - Lots of improvements in the solver (in particular fixes the case like the
> >   recent jpeg upgrade)
> > - Lots of fixes in the 3 way merge code
> > - pkg add can now work without a version specified in the dependency line
> > - pkg check -d now also check the required libraries
> > - Improved support for partial upgrades
> > - Improved zsh completion support
> > - Improved linux support (now all regression tests passes on linux)
> > - Messages can now be context aware: (only print a given message during
> >   installation, upgrade - version aware -, removal, or always)
> > - @keywords now accepts new entries to add context aware messages
> > - Add the ability to generate graphiz's dot format representation of the
> >   solver's problem
> > - pkg search now default on showing the comments of of the matched packages
> > - Lots of bug fixes and code cleanup
> > - Plenty of new bugs
> >
> > Please test heavily, I would like to make a release quite soon to limit the
> > number of users suffering from the jpeg->jpeg-turbo update.
> >
> > Best regards,
> > Bapt
> >
> 
> Thank you Batp,
> 
> running version 1.5.3 I have this error message:
> # pkg upgrade
> Updating FreeBSD repository catalogue...
> FreeBSD repository is up-to-date.
> All repositories are up-to-date.
> Checking for upgrades (40 candidates): 100%
> Processing candidates (40 candidates): 100%
> Checking integrity... done (1 conflicting)
> pkg: Cannot solve problem using SAT solver:
> dependency rule: package Thunar(l) depends on:
> xfce4-tumbler(r)xfce4-tumbler(l)
> upgrade rule: upgrade local xfce4-tumbler-0.1.31_1 to remote
> xfce4-tumbler-0.1.31_1
> cannot install package xfce4-tumbler, remove it from request? [Y/n]:
> pkg: cannot find xfce4-tumbler in the request
> pkg: cannot solve job using SAT solver
> Checking integrity... done (0 conflicting)
> Your packages are up to date.
> 
> With this version I have been able to update the packages.
> 
Thanks for the test!

Best regards,
Bapt


signature.asc
Description: PGP signature

Jenkins build is back to normal : Build-UFS-image #2390

2015-09-22 Thread jenkins-admin 
See 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CTF] pkg 1.6.0

2015-09-22 Thread Ranjan1018 . 
2015-09-21 23:27 GMT+02:00 Baptiste Daroussin :

> Hi all,
>
> We are about to release pkg 1.6.0. pkg-devel has been updated to 1.5.99.13
> aka
> 1.6.0 rc3 that we hope will become the new pkg 1.6.0 btw the end of the
> Week
> (release planned for Saturday 26th of September or no important issues are
> raised)
>
> On the list of changes:
> - Lots of improvements in the solver (in particular fixes the case like the
>   recent jpeg upgrade)
> - Lots of fixes in the 3 way merge code
> - pkg add can now work without a version specified in the dependency line
> - pkg check -d now also check the required libraries
> - Improved support for partial upgrades
> - Improved zsh completion support
> - Improved linux support (now all regression tests passes on linux)
> - Messages can now be context aware: (only print a given message during
>   installation, upgrade - version aware -, removal, or always)
> - @keywords now accepts new entries to add context aware messages
> - Add the ability to generate graphiz's dot format representation of the
>   solver's problem
> - pkg search now default on showing the comments of of the matched packages
> - Lots of bug fixes and code cleanup
> - Plenty of new bugs
>
> Please test heavily, I would like to make a release quite soon to limit the
> number of users suffering from the jpeg->jpeg-turbo update.
>
> Best regards,
> Bapt
>

Thank you Batp,

running version 1.5.3 I have this error message:
# pkg upgrade
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
Checking for upgrades (40 candidates): 100%
Processing candidates (40 candidates): 100%
Checking integrity... done (1 conflicting)
pkg: Cannot solve problem using SAT solver:
dependency rule: package Thunar(l) depends on:
xfce4-tumbler(r)xfce4-tumbler(l)
upgrade rule: upgrade local xfce4-tumbler-0.1.31_1 to remote
xfce4-tumbler-0.1.31_1
cannot install package xfce4-tumbler, remove it from request? [Y/n]:
pkg: cannot find xfce4-tumbler in the request
pkg: cannot solve job using SAT solver
Checking integrity... done (0 conflicting)
Your packages are up to date.

With this version I have been able to update the packages.

I am running:
$ uname -a
FreeBSD microserver 10.2-STABLE FreeBSD 10.2-STABLE #1 r287746: Sun Sep 13
14:06:46 CEST 2015 root@microserver:/usr/obj/usr/src/sys/GENERIC  amd64

With the latest repository:
$ cat /etc/pkg/FreeBSD.conf
# $FreeBSD: stable/10/etc/pkg/FreeBSD.conf 263938 2014-03-30 15:29:54Z
bdrewery $
#
# To disable this repository, instead of modifying or removing this file,
# create a /usr/local/etc/pkg/repos/FreeBSD.conf file:
#
#   mkdir -p /usr/local/etc/pkg/repos
#   echo "FreeBSD: { enabled: no }" > /usr/local/etc/pkg/repos/FreeBSD.conf
#

FreeBSD: {
  url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest";,
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}

Regards,
Maurizio
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"