[Bug 207080] pfctl crash when load pf.conf, libc/resolv problem ?

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207080

Bug ID: 207080
   Summary: pfctl crash when load pf.conf, libc/resolv problem ?
   Product: Base System
   Version: 9.3-STABLE
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: bin
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: fabrice.br...@orange.com
CC: freebsd-am...@freebsd.org
CC: freebsd-am...@freebsd.org

Created attachment 166833
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=166833=edit
pf.conf file

Hello

I'using FreeBSD 9_STABLE to do firewall with pf.

# uname -a
FreeBSD FreeBSD 9.3 9.3-STABLE FreeBSD 9.3-STABLE #0 r294729: Tue Jan 26
22:00:32 CET 2016 root@9_STABLE:/usr/obj/usr/src/sys/FBSD9PF  amd64

With a specific pf.conf file (join with this message), in some case pftcl -f
pf.conf crash with :
pfctl: failed to create table __automatic_4130873d_220 in : Cannot allocate
memory
Segmentation fault: 11 (core dumped)

Ok my pf.conf file is bad and not optimize, but syntax is ok.
To be sure to reproduce the bug, just do with attach pf.conf :
while true;do pftcl -f pf.conf;done 
and wait a few minutes.

I've tried to understand the core file, but I'm a newbie in gdb usage, so I
reproduce here what I've done :

# gdb
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".
(gdb) core pfctl.core
Core was generated by `pfctl'.
Program terminated with signal 11, Segmentation fault.
#0  0x000800cfe6e6 in ?? ()
(gdb) add-symbol-file /usr/lib/debug/lib/libc.so.7.debug 0x000800cfe6e6
add symbol table from file "/usr/lib/debug/lib/libc.so.7.debug" at
.text_addr = 0x800cfe6e6
(y or n) y
Reading symbols from /usr/lib/debug/lib/libc.so.7.debug...done.
(gdb) bt
#0  0x000800cfe6e6 in .text ()
#1  0x0001 in ?? ()
#2  0x00639668 in ?? ()
#3  0x7fffd870 in ?? ()
#4  0x00080140 in ?? ()
#5  0x00080001 in ?? ()
#6  0x0008018009d0 in ?? ()
#7  0x in ?? ()
#8  0x0008014045d0 in ?? ()
#9  0x in ?? ()
#10 0x000801402ad0 in ?? ()
#11 0x0008 in ?? ()
#12 0x0008014024d0 in ?? ()
#13 0x0008 in ?? ()
#14 0x0008014021d0 in ?? ()
#15 0x in ?? ()
#16 0x000801401ed0 in ?? ()
#17 0x7fff in ?? ()
#18 0x000801401a50 in ?? ()
#19 0x00080001 in ?? ()
#20 0x000801401a50 in ?? ()
#21 0x0017 in ?? ()
#22 0x7fffd5e0 in ?? ()
#23 0x000800d6dc29 in __printf_render_int (io=0x7, pi=0x6394b0, arg=) at /usr/src/lib/libc/stdio/xprintf_int.c:422
#24 0x000800faab40 in ?? ()
#25 0x7fffd33b in ?? ()
#26 0x000800d06eca in files_rpcent (retval=0x800cfc36f, mdata=, ap=) at
/usr/src/lib/libc/rpc/getrpcent.c:317
#27 0x65726168732f6c61 in ?? ()
#28 0x62696c2f736c6e2f in ?? ()
#29 0x0074616300432f63 in ?? ()
#30 0x7fffd400 in ?? ()
#31 0x000800652c00 in ?? ()
#32 0x7fffd410 in ?? ()
#33 0x7fffd3b0 in ?? ()
#34 0x in ?? ()
(gdb) add-symbol-file /usr/lib/debug/lib/libc.so.7.debug 0x7fffd3b0
add symbol table from file "/usr/lib/debug/lib/libc.so.7.debug" at
.text_addr = 0x7fffd3b0
(y or n) y
Reading symbols from /usr/lib/debug/lib/libc.so.7.debug...done.
(gdb) bt
#0  0x000800cfe6e6 in .text ()
#1  0x0001 in ?? ()
#2  0x00639668 in ?? ()
#3  0x7fffd870 in wcsxfrm_l (dest=0x7fffd0b0, src=0x7fffd0d0,
len=6526232, locale=) at
/usr/src/lib/libc/string/wcsxfrm.c:126
#4  0x0002 in ?? ()
#5  0x0002 in ?? ()
#6  0x000800faab40 in ?? ()
#7  0x000800faab40 in ?? ()
#8  0x000800faab40 in ?? ()
#9  0x7fffd33b in ?? ()
#10 0x000800d06eca in files_rpcent (retval=0x800d06eca, mdata=, ap=) at
/usr/src/lib/libc/rpc/getrpcent.c:317
#11 0x000800d83e3e in __res_pquery (statp=0x7fffd320, msg=, len=, file=0x800cfc11a) at
/usr/src/lib/libc/resolv/res_debug.c:305
#12 0x in ?? ()
(gdb) 


If my use of gdb is correct, it seems to be a problem in
/usr/src/lib/libc/resolv/res_debug.c ?

I can send the core file but 14Mo ...

Thanks for your help
Fabrice

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 207068] hwpmc wrap around/sign extension

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207068

--- Comment #2 from joss.up...@yahoo.com ---
Created attachment 166832
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=166832=edit
pmc sign extension diff

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 207068] hwpmc wrap around/sign extension

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207068

--- Comment #3 from joss.up...@yahoo.com ---
(In reply to Konstantin Belousov from comment #1)
My apologies... attached now.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 202069] FreeBSD 11-CURRENT r285794 on Dell Inspiron 13 7352: ACPI Error: [\_SB_.PCI0.LPCB.H_EC.ECRD] Namespace lookup failure, AE_NOT_FOUND (20150619/psargs-391)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202069

Neel Chauhan  changed:

   What|Removed |Added

   Severity|Affects Only Me |Affects Some People

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 207086] LCD Brightness

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207086

Bug ID: 207086
   Summary: LCD Brightness
   Product: Base System
   Version: 10.2-STABLE
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: ae...@posteo.de
CC: freebsd-am...@freebsd.org
CC: freebsd-am...@freebsd.org

I'm unable to change LCD brightness on Lenovo Thinkpad Edge E145 using ☼+ and
☼- buttons. To be more specific, the brightness can be changed only until an
early system boot.  It works in the loader menu, and right after kernel is
loaded, but stops working soon after that (perhaps when acpi0 is loaded:
“acpi0:  on motherboard”).

I tested multiple FreeBSD version:

Affected FreeBSD versions:
  - 11.0: FreeBSD-11.0-CURRENT-amd64-20160206-r295345-memstick.img
  - 10.3: FreeBSD-10.3-PRERELEASE-amd64-20160127-r294913-memstick.img
  - 10.2: 10.2-RELEASE-p12
  - 10.1: FreeBSD-10.1-RELEASE-amd64-memstick.img

Working version:
  - 9.3: FreeBSD-9.3-RELEASE-amd64-memstick.img (with “CPU0: local
ACPI error 0x80”)

As you can see, the problem occurred between 9.3 and 10.1.


I also tried different methods to change the brightness on 10.2:

acpi_call
=

acpi_call -v -p '\VBRU'

Path: \VBRU
Number of arguments: 0
ioctl: Device not configured

# no effect


acpi_ibm


sysctl dev.acpi_ibm.0.lcd_brightness=7

# value changes, but it no effect on the brightness


acpi_video
==

sysctl hw.acpi.video.lcd0.brightness=50
hw.acpi.video.lcd0.brightness: 50 -> #

# no effect

pressing Fn+☼+- buttons has no effect, but logs:

can't evaluate \134_SB_.PCI0.VGA_.LCD_._BQC - AE_NOT_FOUND

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 207085] pmc assertion failure: pmc %p non-NULL

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207085

Bug ID: 207085
   Summary: pmc assertion failure: pmc %p non-NULL
   Product: Base System
   Version: 10.2-RELEASE
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: joss.up...@yahoo.com
CC: freebsd-am...@freebsd.org, joss.up...@yahoo.com
CC: freebsd-am...@freebsd.org

I see these panics with INVARIANTS enabled on 10.2-R on an SMP machine running
many processes using hwpmc in parallel.

[core,2376] PHW pmc non-NULL
cpuid = 1

pmc_process_exit() does the following:
sx_xlock();
critical_enter();
free_attached_pmcs...
critical_exit();
free_owner_pmcs...
sx_unlock();

and the various drivers do *_release_pmc():
... KASSERT(phw->phw_pmc == NULL) ...

What I'm seeing is on an SMP machine, from time to time a process which
owns PMCs races with a process that has attached PMCs.  free_owner_pmcs()
calls *_release_pmc() which checks to make sure the per-cpu counter
isn't in use.  A process with attached pmcs will have freed them with
both the pmc_lock and scheduler lock held.  But, a process being scheduled
onto the pmc can sneak in between the critical_exit() and the sx_unlock(),
but before the free_owner_pmcs() resulting in an assertion failure.

free_owner_pmcs can't be protected by the scheduler lock because it
may need to sleep waiting on sampling counters to come off the cpu.  I'm
not sure how to approach a fix other than disabling the KASSERT, and I'm not
sure if that's safe.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 207087] kernel: r295285 in 10.2-STABLE breaks OpenVPN functionality

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087

g_amana...@yahoo.com changed:

   What|Removed |Added

 CC||a...@freebsd.org,
   ||freebsd-bugs@FreeBSD.org,
   ||freebsd-...@freebsd.org,
   ||melif...@freebsd.org
URL||https://reviews.freebsd.org
   ||/D4042

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 205800] random device not loaded; using insecure entropy

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205800

--- Comment #6 from commit-h...@freebsd.org ---
A commit references this bug:

Author: jhb
Date: Wed Feb 10 18:29:38 UTC 2016
New revision: 295480
URL: https://svnweb.freebsd.org/changeset/base/295480

Log:
  Adjust initialization of random(9) so it is usable earlier.

  A few existing SYSINITs expect the in-kernel PRNG (random(9)) to be
  useable at SI_SUB_RANDOM / SI_ORDER_ANY.  However, the random(4) overhaul
  merged for 10.0 performs all of its initialization at SI_SUB_DRIVERS
  (since it is tied in with creating the /dev/random character device).

  This has changed in HEAD where the random initialization is split such
  that the in-kernel random(9) is initialized at SI_SUB_RANDOM and the
  supporting bits for userland random(4) (such as /dev/random) are initialized
  later.

  However, the changes in HEAD are large and invasive.  Instead, this change
  is being directly committed to stable/10.

  This change moves most of the random(9)/random(4) initialization to
  SI_SUB_RANDOM with the exception that the creation of the harvesting kernel
  process and the /dev/random character device are deferred to new
  SYSINITs that run at SI_SUB_DRIVERS.

  This fixes the "random device not loaded; using insecure entropy" message
  output during boot on some systems.

  PR:   205800
  Reviewed by:  markm, so@
  Approved by:  so
  Approved by:  re (gjb)
  Tested by:Mark Saad 

Changes:
  stable/10/sys/dev/random/live_entropy_sources.c
  stable/10/sys/dev/random/live_entropy_sources.h
  stable/10/sys/dev/random/random_adaptors.c
  stable/10/sys/dev/random/random_adaptors.h
  stable/10/sys/dev/random/random_harvestq.c
  stable/10/sys/dev/random/randomdev.c
  stable/10/sys/dev/random/randomdev_soft.c

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 207087] kernel: r295285 in 10.2-STABLE breaks OpenVPN functionality

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087

--- Comment #2 from g_amana...@yahoo.com ---
Also I just figured out that my Android devices which connect directly to the
gateway running the OpenVPN server (they connect to the internal interface and
not through OpenVPN) are not able to open regular webpages and some apps (eBay,
Amazon, YouTube) stop functioning if this commit is applied.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 207087] kernel: r295285 in 10.2-STABLE breaks OpenVPN functionality

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087

--- Comment #1 from g_amana...@yahoo.com ---
Created attachment 166845
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=166845=edit
client.conf

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 207087] kernel: r295285 in 10.2-STABLE breaks OpenVPN functionality

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087

Bug ID: 207087
   Summary: kernel: r295285 in 10.2-STABLE breaks OpenVPN
functionality
   Product: Base System
   Version: 10.2-STABLE
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: g_amana...@yahoo.com
CC: freebsd-am...@freebsd.org
CC: freebsd-am...@freebsd.org

Created attachment 166844
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=166844=edit
server.conf

r295285 in 10.2-STABLE breaks OpenVPN server functionality. Tested with OpenVPN
2.3.10 on amd64 bare-metal hardware with IPv4. Clients connected to the OpenVPN
server experience slow IPv4 www traffic and connection resets. 

Clients connect via IPv4 UDP to the server, and in-kernel NAT is performed on
the external interface. OpenVPN configs are attached. The kernel has IPSEC,
IPSEC_NAT_T and VIMAGE enabled, and SCTP disabled.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 207087] kernel: r295285 in 10.2-STABLE breaks OpenVPN functionality

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087

--- Comment #6 from mgro...@shrew.net ---
Doah, sorry. I stopped and started writing that last paragraph while in the
middle of something else. I was still thinking of things in terms of tunneling.
Please disregard and I'll go away and be quiet now :)

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 207087] kernel: r295285 in 10.2-STABLE breaks OpenVPN functionality

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087

mgro...@shrew.net changed:

   What|Removed |Added

 CC||mgro...@shrew.net

--- Comment #3 from mgro...@shrew.net ---
Recently I noticed that after upgrading two separate pairs of firewalls to
10.2-RELEASE that my ISAKMP deamons stopped negotiating SAs with peers. I just
haven't gotten around to submitting a bug report yet. It only seems to happen
when large UDP packets get fragmented due to large payloads ( ie. certificate
info is transmitted during late in phase1 negotiation ). This may be unique to
the bge driver or related hardware as the isakmp daemon started working again
on both sets of firewalls once I disabled hardware checksum offload ( ifconfig
bgeX -rxcsum ). This work-around wasn't required until the upgrade to
10.2-RELEASE, but I can't say if it was at a specific patch level. I can say
that one set of firewalls were upgraded from 9.2-RELEASE-p?? and the other set
were upgraded from a patched 10.0-RELEASE, so I assume the commit that broke
UDP re-assembly was committed sometime between 10.0-RELEASE and
10.2-RELEASE-p11. Sorry I can't be more specific.

BTW, this isn't an attempt to hijack your problem report. I just thought that
the issue you describe ( openvpn w/ UDP ) may be related to mine so I thought
it would be worth mentioning. Have you tried disabling hw checksum offload on
your public facing network device? If that improves the situation, it's quite
possible that we are being bit by the same issue.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 207092] dd conv=sparse is broken since r265593

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207092

Maxim Sobolev  changed:

   What|Removed |Added

   Assignee|freebsd-bugs@FreeBSD.org|tho...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 207068] hwpmc wrap around/sign extension

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207068

--- Comment #4 from Konstantin Belousov  ---
(In reply to joss.upton from comment #3)
Could you please provide exact recipe to reproduce the overflow panic ?

I tried e.g. pmcstat -P CPU_CLK_UNHALTED_CORE  on
sandybridge and was unable to panic stock HEAD kernel.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 207087] kernel: r295285 in 10.2-STABLE breaks OpenVPN functionality

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087

--- Comment #4 from g_amana...@yahoo.com ---
(In reply to mgrooms from comment #3)
This issue concerns only 10.2-STABLE (now 10.3-BETA1) which is about to become
10.3-RELEASE. The commit has not been applied to 10.2-RELEASE, so you must be
facing another issue. The OpenVPN clients connect with no problems to the
server. 

It has to do with ip_tryforward(). If I comment out this function in ip_input.c
the symptoms resolve. Could it be that some of the traffic entering
ip_tryforward() bypasses the NAT?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 207092] dd conv=sparse is broken since r265593

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207092

Bug ID: 207092
   Summary: dd conv=sparse is broken since r265593
   Product: Base System
   Version: 10.2-STABLE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Many People
  Priority: ---
 Component: bin
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: sobo...@freebsd.org

The dd(1) sparse conversion is seriously broken after this change. The last
block is never written at least for the case of output being regular file:

$ dd if=/dev/zero of=/tmp/foo.bar bs=1m count=10
10+0 records in
10+0 records out
10485760 bytes transferred in 0.003244 secs (3232431656 bytes/sec)
$ ktrace dd if=/tmp/foo.bar of=/tmp/foo.bar1 bs=1m conv=sparse
10+0 records in
10+0 records out
$ ls -l /tmp/foo.bar /tmp/foo.bar1
-rw-r--r--  1 sobomax  wheel  10485760 Feb  9 23:59 /tmp/foo.bar
-rw-r--r--  1 sobomax  wheel 0 Feb  9 23:59 /tmp/foo.bar1
$ uname -a
FreeBSD abc.sippysoft.com 10.3-PRERELEASE FreeBSD 10.3-PRERELEASE #1
80de3e2(master)-dirty: Tue Feb  2 12:19:57 PST 2016
sobo...@abc.sippysoft.com:/usr/obj/usr/home/sobomax/projects/freebsd103/sys/VAN01
 amd64

ktrace ends with:

  3150 dd   RET   read 1048576/0x10
  3150 dd   CALL  read(0x3,0x801009000,0x10)
  3150 dd   GIO   fd 3 read 0 bytes
   ""
  3150 dd   RET   read 0
  3150 dd   CALL  lseek(0x4,0x90,SEEK_CUR)
  3150 dd   RET   lseek 9437184/0x90
  3150 dd   CALL  close(0x4)
  3150 dd   RET   close 0
  3150 dd   CALL  write(0x2,0x7fffe2c0,0x21)
  3150 dd   GIO   fd 2 wrote 33 bytes
   "10+0 records in
10+0 records out
   "
  3150 dd   RET   write 33/0x21
  3150 dd   CALL  write(0x2,0x7fffe2c0,0x43)
  3150 dd   GIO   fd 2 wrote 67 bytes
   "10485760 bytes transferred in 0.008217 secs (1276090675 bytes/sec)
   "
  3150 dd   RET   write 67/0x43
  3150 dd   CALL  sigprocmask(SIG_BLOCK,0x800822a38,0x7fffe780)
  3150 dd   RET   sigprocmask 0
  3150 dd   CALL  sigprocmask(SIG_SETMASK,0x800822a4c,0)
  3150 dd   RET   sigprocmask 0
  3150 dd   CALL  sigprocmask(SIG_BLOCK,0x800822a38,0x7fffe310)
  3150 dd   RET   sigprocmask 0
  3150 dd   CALL  sigprocmask(SIG_SETMASK,0x800822a4c,0)
  3150 dd   RET   sigprocmask 0
  3150 dd   CALL  sigprocmask(SIG_BLOCK,0x800822a38,0x7fffe310)
  3150 dd   RET   sigprocmask 0
  3150 dd   CALL  sigprocmask(SIG_SETMASK,0x800822a4c,0)
  3150 dd   RET   sigprocmask 0
  3150 dd   CALL  exit(0)


Looking at the code in question I don't see how could it have worked. Look at
the following piece of code in your diff for example:

+   if (force && cnt == 0) {
+   pending -= last_sp;
+   assert(outp == out.db);
+   memset(outp, 0, cnt);
+   }

When the branch is taken, cnt is 0, so at the very least memset(x, y, 0) is
NOP.  Later on, write(2) is conditional on cnt != 0, so that it's never taken.
As a result, lseek is the last operation the file sees.

Also, for what it's worth, you can use ftruncate(2) instead of write() for
regular sparse files to ensure correct size. That would write just as much data
as needed to the end. I've made a quick and dirty patch, that seems to be
working better than current code at least:

http://sobomax.sippysoft.com/dd.diff

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 207087] kernel: r295285 in 10.2-STABLE breaks OpenVPN functionality

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087

--- Comment #5 from mgro...@shrew.net ---
I see. They underlying cause is quite possibly unrelated then. As I said, I
wasn't trying to hijack your bug report. But the symptom still sounds similar
in the respect that some of your UDP traffic ( your OpenVPN control traffic for
example ) appears to be processed correctly, but other traffic ( your OpenVPN
transport traffic being tunneled ) does not. That smacks of a re-assembly
problem. In the latter case, you could have a large inner IP packet size due to
the tunnel overhead which would cause the outer IP packet to be fragmented.
This would lead to stalls and resets from the client perspective, just as you
describe in your bug report.

However, that doesn't necessarily explain your 2nd problem where non-tunneled
traffic stalls. You can't NAT fragmented packets if you have a re-assembly
problem as the required UDP/TCP port values are only available in the initial
packet of a fragmented chain. That usually only effects UDP packets but it can
still be a problem for TCP if the TCP MSS is large enough as the DNF bit is
typically set in the IP header.

In any case, good luck with your problem.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 207068] hwpmc wrap around/sign extension

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207068

--- Comment #5 from joss.up...@yahoo.com ---
(In reply to Konstantin Belousov from comment #4)
I don't know if Sandy Bridge supports the aliases or not.  I do know that
vmware fusion on my Broadwell machine does NOT support the IA32_A_PMCn
registers and thus will panic.

Note you may also need other processes using the PMC to be
scheduled/unscheduled to reproduce... You have to catch a case where it writes
with EAX[31]=1 to IA32_PMCn.  This results in an automatic sign extension (as
described in the Intel arch manual, 18.2.2.3 Full-Width Writes to Performance
Counter Registers) and ignores EDX completely.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 191348] [mps] LSI2308 with WD3000FYYZ drives disappears after hotswapping

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191348

Graham Allan  changed:

   What|Removed |Added

 CC||g...@umn.edu

--- Comment #38 from Graham Allan  ---
I'm not sure if I'm still seeing this same issue here (FreeBSD 10.2-p7). I have
a server with 4 attached SC847-JBOS1 drives chassis, the HBA is 9207-8e with
20.00.04.00 firmware.

I set dev.mps.0.spinup_wait_time="5" a while back, and had to remove/replace 42
drives from one chassis. The system detected all but one drive - I can swap
drives between that and another slot, and it's that particular slot (rather
than the drive) which is persistently not detected.

I'm sure it will be detected after a reboot, but before doing that, I set
dev.mps.0.debug_level=4 and pulled/replaced the drive. I'll attach the output
(along with some earlier bits containing the hardware config etc) in case it
reveals anything - I have no idea if it's really related to this issue.

Graham

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 191348] [mps] LSI2308 with WD3000FYYZ drives disappears after hotswapping

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191348

--- Comment #39 from Graham Allan  ---
Created attachment 166854
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=166854=edit
kern.log with dev.mps.0.debug_level=4, drive removed and reinserted but no
detect

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 207068] hwpmc wrap around/sign extension

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207068

--- Comment #6 from joss.up...@yahoo.com ---
(In reply to joss.upton from comment #5)
Actually, the best test might be to do this:

uint64_t num;

num = rdmsr(0xc1);
printf("init: %lx\n", num);
wrmsr(0xc1, 0x8000);
num = rdmsr(0xc1);
printf("after e31: %lx\n", num);

When I do this:

init: 0
after e31: 8000

This behavior is correct according to the Intel manual, but causes issues with
negative increments if you race it long enough.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 205800] random device not loaded; using insecure entropy

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205800

John Baldwin  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||j...@freebsd.org
 Status|New |Closed

--- Comment #7 from John Baldwin  ---
I believe the referenced commit should fix this.  I do not think there are any
plans currently to backport that change to older releases, but it will be
included in 10.3.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 207068] hwpmc wrap around/sign extension

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207068

Konstantin Belousov  changed:

   What|Removed |Added

 CC||k...@freebsd.org

--- Comment #1 from Konstantin Belousov  ---
There is no patch attached.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 207056] Changing the MAC address on the lagg interface doesn't get retained after lagg port delete operation.

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207056

Mark Linimon  changed:

   What|Removed |Added

   Assignee|freebsd-bugs@FreeBSD.org|freebsd-...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 207055] ipv6 pmtu discovery not working with pf active

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207055

Mark Linimon  changed:

   What|Removed |Added

   Assignee|freebsd-bugs@FreeBSD.org|freebsd-...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 207070] gptboot not zeroing memory while reading from boot.config

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207070

Mark Linimon  changed:

   What|Removed |Added

   Keywords||patch

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 207069] setting loader password in loader.conf disallows boot

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207069

Mark Linimon  changed:

   What|Removed |Added

Summary|setting loader password |setting loader password in
   |crashes boot|loader.conf disallows boot

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 207080] pfctl crash when load pf.conf, libc/resolv problem ?

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207080

Mark Linimon  changed:

   What|Removed |Added

   Assignee|freebsd-bugs@FreeBSD.org|freebsd...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 207086] unable to change LCD brightness on Lenovo Thinkpad Edge E145

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207086

Mark Linimon  changed:

   What|Removed |Added

Summary|LCD Brightness  |unable to change LCD
   ||brightness on Lenovo
   ||Thinkpad Edge E145

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 207087] kernel: r295285 in 10.2-STABLE breaks OpenVPN functionality

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087

Mark Linimon  changed:

   What|Removed |Added

   Assignee|freebsd-bugs@FreeBSD.org|g...@freebsd.org

--- Comment #7 from Mark Linimon  ---
Assign to committer of 295285.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 207087] kernel: r295285 in 10.2-STABLE breaks OpenVPN functionality

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207087

Mark Linimon  changed:

   What|Removed |Added

   Keywords||regression

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 207095] [patch] new /etc/rc.d/ntpd script exits before updating leapsecond file on non chrooted setups

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207095

Bug ID: 207095
   Summary: [patch] new /etc/rc.d/ntpd script exits before
updating leapsecond file on non chrooted setups
   Product: Base System
   Version: 11.0-CURRENT
  Hardware: Any
OS: Any
Status: New
  Keywords: patch
  Severity: Affects Some People
  Priority: ---
 Component: conf
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: madpi...@freebsd.org
CC: c...@freebsd.org
 Flags: mfc-stable10?

Created attachment 166862
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=166862=edit
simple patch

The recent update to the ntpd rc script contains an error imho:

The check for chrooted environment, which causes the precmd to return
immediately if it does not detect a chrooted environment was erroneously put
before the check for the existence of the working copy of the leap seconds
file.

This causes the working copy of the leap seconds file to not be created on
startup, ensuing a warning from ntpd.

Attached patch is a simple fix I have tested.

Also note that this version (containing the mistake) of the ntpd startup script
was merge to stable/10, so this fix should be merged there too ASAP, before
10.3 release.

Thanks in advance.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 207095] [patch] new /etc/rc.d/ntpd script exits before updating leapsecond file on non chrooted setups

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207095

Cy Schubert  changed:

   What|Removed |Added

   Assignee|freebsd-bugs@FreeBSD.org|c...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"