[Bug 236513] HP Thin clients T620/T730 ACPI: Only CPU core 0 detects C2 state

2019-03-28 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236513

--- Comment #34 from Andriy Gapon  ---
(In reply to stockhausen from comment #32)
1. Ah, you are right, I forgot that modern processors intercept C-state I/O
accesses at a core level.
Just to clarify, I assume that on your T620 cpucontrol -m 0xC0010073
/dev/cpuctl0 gives 0x414?

3.b(2) The root bridge has a range that covers 0x414, so that's okay.

A. I do not think so.  I think that the code currently expects BIOS to set up
everything correctly. We could try to think about how FreeBSD ACPI code could
work around not having Cx I/O ports in the system resources...

By the way, I see why acpi cpu devices cannot share a resource if it's not an
acpi system resource.  If a resource is a system resource then it is allocated
from the nexus (very early) and the acpi bus manages it on its own.  That means
that acpi_set_resource() -> resource_list_reserve(flags=0) ->
resource_list_alloc() -> BUS_ALLOC_RESOURCE() -> nexus_alloc_resource() ->
rman_reserve_resource(flags=0) would always fail.  But that's okay, because
acpi_alloc_resource() has a fallback to acpi_alloc_sysres().  And if the
resource is consistently allocated with RF_SHARED, then all allocations of it
succeed.
If a resource is _not_ a system resource, then the resource is not allocated by
the acpi bus in the nexus as the acpi bus is unaware of it.  Then, when the
first cpu calls acpi_PkgGas() -> acpi_bus_alloc_gas() -> bus_set_resource() ->
acpi_set_resource() -> resource_list_reserve(flags=0) ->
resource_list_alloc(flags=0) -> BUS_ALLOC_RESOURCE(flags=0) ->
nexus_alloc_resource(flags=0) -> rman_reserve_resource(flags=0), the resource
is allocated in the nexus and it is allocated without RF_SHARED flag.  Because
the allocation is successful, the resource is added to the device's resource
list.  After bus_set_resource(), acpi_bus_alloc_gas() calls
bus_alloc_resource_any() -> acpi_alloc_resource(flags=RF_ACTIVE|RF_SHARED) ->
resource_list_alloc().
Because the resource already exists in the device's resource list,
resource_list_alloc() would simply activate it and return. So, for the first
cpu acpi_bus_alloc_gas() is successful.
For any subsequent cpu, this call chain acpi_PkgGas() -> acpi_bus_alloc_gas()
-> bus_set_resource() -> acpi_set_resource() -> resource_list_reserve(flags=0)
-> resource_list_alloc(flags=0) -> BUS_ALLOC_RESOURCE(flags=0) ->
nexus_alloc_resource(flags=0) -> rman_reserve_resource(flags=0) would fail
because the resource is already allocated in nexus and it is not shared.  Thus,
the resource would not be created in the device's resource list.  Thus, the
subsequent call to bus_alloc_resource_any() ->
acpi_alloc_resource(flags=RF_ACTIVE|RF_SHARED) -> resource_list_alloc() would
not find that resource and it would have to call BUS_ALLOC_RESOURCE() ->
nexus_alloc_resource() -> rman_reserve_resource() and that would fail again for
the same reason.  And, in this case, acpi_alloc_resource()'s fallback to
acpi_alloc_sysres() would also fail, because the resource is not a system
resource.  In the end, acpi_PkgGas() -> acpi_bus_alloc_gas() fails just as you
have seen.

B. I would add 0x414 to CRS of Device S900.  E.g. using 0x040B as an example, I
would add this just after it:
IO (Decode16,
0x0414, // Range Minimum
0x0414, // Range Maximum
0x00,   // Alignment
0x04,   // Length
)

-- 
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 236513] HP Thin clients T620/T730 ACPI: Only CPU core 0 detects C2 state

2019-03-28 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236513

--- Comment #35 from stockhau...@collogia.de ---
Phew, I see you found the culprit. Although I do not know every single function
I saw a lot of the names during my code analysis.

Regarding HP T620 settings: cpucontrol -m 0xC0010073 /dev/cpuctl0 gives 0x413
(The CPU gets Port+1 from BIOS). So the ACPI tables need:

For T620:
IO (Decode16,
0x0413, // Range Minimum
0x0413, // Range Maximum
0x00,   // Alignment
0x08,   // Length
)

For T730:
IO (Decode16,
0x1770, // Range Minimum
0x1770, // Range Maximum
0x00,   // Alignment
0x08,   // Length
)

With these settings C2 states come up fine on both machines.

I will check if all of this hard work at least gives some power saving effects.

-- 
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 236853] panic: page fault on rtsock.c

2019-03-28 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236853

Bug ID: 236853
   Summary: panic: page fault  on rtsock.c
   Product: Base System
   Version: CURRENT
  Hardware: i386
OS: Any
Status: New
  Severity: Affects Many People
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: lenzi.ser...@gmail.com

The system panics on /usr/src/sys/net/rtsock.c:839 and all references to
ifp->if_addr->ifa_addr   the pointer ifp->if_addr is invalid.  some race
condition occurs that releases the ifp->if_addr and when the code tries to read
the next pointer a page fault occurs sometimes it happens in
/usr/src/sys/net/rtsock.c:1581 too

how to reproduce:
setup (1) a freebsd 12 or 13 as a ppp-in server (man ppp) using the setup in
the example at http://www.k1.com.br/crash/ppp, than go to another freebsd and
using the ppptun.conf, connect to the (1)  using the command ppp -ddial ppptun
after several connects and disconnects, the (1)  panics...  sometimes the
simple route get "any ppp address"  is enough to panic the system.

The resulting debug files of the panic is in the http://www.k1.com.br/crash

-- 
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 236846] FreeBSD 12.0-STABLE-p3 r345567: panic: vm_fault_hold: fault on nofault entry

2019-03-28 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236846

--- Comment #1 from Viktor Dukhovni  ---
I switched to the 12.0-STABLE kernel, but still essentially the same panic:

panic: vm_fault_hold: fault on nofault entry, addr: 0xfe0075df2000
cpuid = 6
time = 1553772208
KDB: stack backtrace:
#0 0x80bf1907 at kdb_backtrace+0x67
#1 0x80ba58c3 at vpanic+0x1a3
#2 0x80ba5713 at panic+0x43
#3 0x80ee9ed1 at vm_fault_hold+0x2801
#4 0x80ee7680 at vm_fault+0x60
#5 0x81082a92 at trap_pfault+0x162
#6 0x81081f6e at trap+0x29e
#7 0x8105c715 at calltrap+0x8
#8 0x80d32d73 at ip_input+0x463
#9 0x80cc70f6 at netisr_dispatch_src+0xd6
#10 0x80cab643 at ether_demux+0x163
#11 0x80cac7a6 at ether_nh_input+0x346
#12 0x80cc70f6 at netisr_dispatch_src+0xd6
#13 0x80caba44 at ether_input+0x54
#14 0x80cc3836 at iflib_rxeof+0xa66
#15 0x80cbdd06 at _task_fn_rx+0x76
#16 0x80bf0194 at gtaskqueue_run_locked+0x144
#17 0x80befdf8 at gtaskqueue_thread_loop+0x98
Uptime: 5h20m55s


addr2line -afi -e /usr/lib/debug/boot/kernel/kernel.debug 0x80d32d73
0x80d32d73
ip_input
/usr/src/sys/netinet/ip_input.c:606

The kgdb backtrace is:

#0  __curthread () at ./machine/pcpu.h:230
#1  doadump (textdump=) at /usr/src/sys/kern/kern_shutdown.c:371
#2  0x80ba54ab in kern_reboot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:451
#3  0x80ba5923 in vpanic (fmt=, ap=0xfe45c130)
at /usr/src/sys/kern/kern_shutdown.c:877
#4  0x80ba5713 in panic (fmt=) at
/usr/src/sys/kern/kern_shutdown.c:804
#5  0x80ee9ed1 in vm_fault_hold (map=,
vaddr=18446741876663853056, fault_type=, 
fault_flags=, m_hold=0x0) at /usr/src/sys/vm/vm_fault.c:598
#6  0x80ee7680 in vm_fault (map=0xf80003002000, vaddr=, fault_type=4 '\004', fault_flags=0)
at /usr/src/sys/vm/vm_fault.c:548
#7  0x81082a92 in trap_pfault (frame=0xfe45c460, usermode=0) at
/usr/src/sys/amd64/amd64/trap.c:844
#8  0x81081f6e in trap (frame=0xfe45c460) at
/usr/src/sys/amd64/amd64/trap.c:441
#9  
#10 0xfe0075df2450 in ?? ()
#11 0x8201a908 in __pcpu ()
#12 0x8201a908 in __pcpu ()
#13 0xfe640208 in ?? ()
#14 0xf8000377b000 in ?? ()
#15 0xf801 in ?? ()
#16 0x0034 in ?? ()
#17 0xf8000377b000 in ?? ()
#18 0xfe45c630 in ?? ()
#19 0xfe6489f8 in ?? ()
#20 0x0008 in ?? ()
#21 0xf804d4d6c100 in ?? ()
#22 0x65270264 in ?? ()
#23 0xf8000377b000 in ?? ()
#24 0x0014 in ?? ()
#25 0x82014880 in ?? ()
#26 0xf804d4d6c166 in ?? ()
#27 0xfe45c660 in ?? ()
#28 0x80d32d73 in ip_input (m=0xf804d4d6c100) at
/usr/src/sys/netinet/ip_input.c:606
Backtrace stopped: frame did not save the PC

-- 
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 236854] kernel exception at boot time

2019-03-28 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236854

Bug ID: 236854
   Summary: kernel exception at boot time
   Product: Base System
   Version: 11.2-RELEASE
  Hardware: arm64
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: ad...@canmos.net

Hello!

I have seen strange situation during of system boot when rootfs should be
mounted on /dev/md0 (ramdisk):
When system starts to boot into loaded kernel there is the following exception:
FreeBSD/amd64 EFI loader, Revision 1.1
(Fri Jun 22 04:20:29 UTC 2018 r...@releng2.nyi.freebsd.org)
   Load Path: HD(2,GPT,56BFC0A5-33B0-11E9-9FAC-A4BF012E952E,0x64028,0x139BFF8)
   Load Device:
PciRoot(0x9)/Pci(0x0,0x0)/Pci(0x0,0x0)/Ctrl(0x1)/Scsi(0x6,0x0)/H
Btart @ 0x8031 ...s, 'help' for more detailed
help.rompt.x16aee0+0x8
 X64 Exception Type - 0D(#GP - General Protection)  CPU Apic ID - 

RIP  - 5B869C63, CS  - 0038, RFLAGS - 00010206
ExceptionData - 
RAX  - 0002, RCX - , RDX - 2E36E95DE5894855
RBX  - , RSP - 6C0D2D58, RBP - 6C0D2E50
RSI  - 5B899778, RDI - 5B88AC30
R8   - FFFB, R9  - 8080808080808080, R10 - FFF8
R11  - 6C0D2AE0, R12 - 5B88F210, R13 - 5B89D6D8
R14  - 5B88F200, R15 - 0002
DS   - 0030, ES  - 0030, FS  - 0030
GS   - 0030, SS  - 0030
CR0  - 8013, CR2 - , CR3 - 6C033000
CR4  - 0668, CR8 - 
DR0  - , DR1 - , DR2 - 
DR3  - , DR6 - 0FF0, DR7 - 0400
GDTR - 6A510DE0 0047, LDTR - 
IDTR - 6A509018 0FFF,   TR - 
FXSAVE_STATE - 6C0D29B0
 Find PE image (No PDB)  (ImageBase=5B843000,
EntryPoint=5B849E50) 

[closing the connection]

I catched it via SOL (Serial over LAN). Could you please help me to know - is
this a bug or maybe i forget about some specific settings?

My /boot/loader.conf looks like:
# old style
beastie_disable="YES"

# system
mrsas_load="YES"
geom_mirror_load="YES"

# rootfs on ramdisk
initmd_load="YES"
initmd_type="md_image"
initmd_name="/boot/boot.md" #100MB file size
rootdev="ufs:/dev/md0"


I'm booting with UEFI support. My kernel is GENERIC but i recompiled it without
mrsas driver. I load the driver via kernel module compiled from fresh sources
downloaded from MegaRAID site manufacturer.
The log of this driver looks like:
AVAGO MegaRAID SAS FreeBSD mrsas driver version: 07.708.02.00
mrsas0:  port 0xf000-0xf0ff mem
0x39f0-0x39ff,0x39e0-0x39ef,0xee80-0xee8f
at device 0.0
numa-domain 1 on pci11
mrsas0: Using MSI-X with 40 number of vectors
mrsas0: FW supports <128> MSIX vector,Online CPU 40 Current MSIX <40>
mrsas0: NVME page size  : (4096)
mrsas0: FW supports SED
mrsas0: FW supports JBOD Map
mrsas0: FW supports JBOD Map Ext
mrsas0: Jbod map is supported
mrsas0: System PD created target ID: 0x6
mrsas0: System PD created target ID: 0x7
mrsas0: System PD created target ID: 0x8
mrsas0: System PD created target ID: 0x9
mrsas0: MSI-x interrupts setup success

And i use GEOM mirror.

When i remove the strings from /boot/loader.conf:
# rootfs on ramdisk
initmd_load="YES"
initmd_type="md_image"
initmd_name="/boot/boot.md"
rootdev="ufs:/dev/md0"

- then my system boots as usual.

Thank you for helpl 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 236513] HP Thin clients T620/T730 ACPI: Only CPU core 0 detects C2 state

2019-03-28 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236513

--- Comment #36 from John Baldwin  ---
It may be that we need to fix the RF_SHAREABLE to propagate up when the
resource is first allocated by resource_list_reserve, etc.  That might fix this
without requiring the BIOS to be patched.  I haven't looked to see what that
would involve though.

-- 
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 236513] HP Thin clients T620/T730 ACPI: Only CPU core 0 detects C2 state

2019-03-28 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236513

--- Comment #37 from John Baldwin  ---
Created attachment 203218
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=203218&action=edit
shareable_acpi_set_resource.patch

This is an untested hack that uses RF_SHAREABLE when reserving resources for
CPUs.  The other approach is we could just not reserve resources for CPU
devices which might be safer as it would then always honor the flags passed to
bus_alloc_resource().

-- 
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 211771] kernel panic when loading ix interface ( was kernel panic on boot PowerEdge R720xd )

2019-03-28 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211771

Jeremy Shinall  changed:

   What|Removed |Added

 CC||jeremyshin...@icloud.com

--- Comment #22 from Jeremy Shinall  ---
(In reply to Kevin H. Patterson from comment #21)
+1 for this.

I'm having the exact same problem with an E10G42AFDA card in a Dell r515 on
FreeNAS 11.2-U2. I bought this card explicitly because it's on the FreeBSD HCL.
Would love to get some traction on this really old issue.

-- 
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 236846] FreeBSD 12.0-STABLE-p3 r345567: panic: vm_fault_hold: fault on nofault entry

2019-03-28 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236846

--- Comment #2 from Viktor Dukhovni  ---
With fantastic help from Mark Johnston, the issue has been plausibly narrowed
down to the new epoch_tracker code in 12.0 not handling IPv6 via stf0 robustly.
 The crash dump with "option INVARIANTS" looks like:

panic: Assertion etd->et_td == (struct thread *)td failed at
/usr/src/sys/sys/epoch_private.h:178
cpuid = 7
time = 1553806077
KDB: stack backtrace:
#0 0x80bbb047 at kdb_backtrace+0x67
#1 0x80b737c3 at vpanic+0x1a3
#2 0x80b735a3 at panic+0x43
#3 0x80c68357 at epoch_exit_preempt+0x1e7
#4 0x80c6b35d at if_addr_runlock+0x1d
#5 0x82e33b67 at stf_getsrcifa6+0x1a7
#6 0x82e33488 at stf_output+0x48
#7 0x80dc356f at ip6_output+0x1daf
#8 0x80d85d74 at tcp_output+0x1be4
#9 0x80d97739 at tcp_usr_disconnect+0x69
#10 0x80c07eec at soclose+0x9c
#11 0x80b1d86a at _fdrop+0x1a
#12 0x80b20abc at closef+0x1ec
#13 0x80b1dea0 at closefp+0xa0
#14 0x8103ca58 at amd64_syscall+0x278
#15 0x8101589d at fast_syscall_common+0x101

I am now testing a work-around 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 236846] FreeBSD 12.0-STABLE-p3 r345567: stf_output panic in epoch_exit_preempt

2019-03-28 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236846

Viktor Dukhovni  changed:

   What|Removed |Added

Summary|FreeBSD 12.0-STABLE-p3  |FreeBSD 12.0-STABLE-p3
   |r345567: panic: |r345567: stf_output panic
   |vm_fault_hold: fault on |in epoch_exit_preempt
   |nofault entry   |

-- 
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 230876] save-entropy: Sync saved random data

2019-03-28 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230876

Conrad Meyer  changed:

   What|Removed |Added

   Assignee|b...@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"


[Bug 230875] Revisit decision to not block read_random(9) on being seeded

2019-03-28 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230875

Conrad Meyer  changed:

   What|Removed |Added

   Assignee|b...@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"


[Bug 236864] sys/netpfil/pf/ioctl/validation:addtables triggered a GPF panic

2019-03-28 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236864

Bug ID: 236864
   Summary: sys/netpfil/pf/ioctl/validation:addtables triggered a
GPF panic
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: n...@freebsd.org

>From https://ci.freebsd.org/job/FreeBSD-head-amd64-test/10671/console :

sys/netpfil/pf/ioctl/validation:addtables  ->  
16:58:03 
16:58:03 Fatal trap 9: general protection fault while in kernel mode
16:58:03 cpuid = 0; apic id = 00
16:58:03 instruction pointer= 0x20:0x80cc8c75
16:58:03 stack pointer  = 0x28:0xfe0030faf740
16:58:03 frame pointer  = 0x28:0xfe0030faf740
16:58:03 code segment   = base 0x0, limit 0xf, type 0x1b
16:58:03= DPL 0, pres 1, long 1, def32 0, gran 1
16:58:03 processor eflags   = interrupt enabled, resume, IOPL = 0
16:58:03 current process= 23278 (ifconfig)
16:58:03 trap number= 9
16:58:03 panic: general protection fault
16:58:03 cpuid = 0
16:58:03 time = 1553817482
16:58:03 KDB: stack backtrace:
16:58:03 db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe0030faf450
16:58:03 vpanic() at vpanic+0x19d/frame 0xfe0030faf4a0
16:58:03 panic() at panic+0x43/frame 0xfe0030faf500
16:58:03 trap_fatal() at trap_fatal+0x394/frame 0xfe0030faf560
16:58:03 trap() at trap+0x6c/frame 0xfe0030faf670
16:58:03 calltrap() at calltrap+0x8/frame 0xfe0030faf670
16:58:03 --- trap 0x9, rip = 0x80cc8c75, rsp = 0xfe0030faf740, rbp
= 0xfe0030faf740 ---
16:58:03 strncmp() at strncmp+0x15/frame 0xfe0030faf740
16:58:03 ifunit_ref() at ifunit_ref+0x51/frame 0xfe0030faf780
16:58:03 ifioctl() at ifioctl+0x508/frame 0xfe0030faf850
16:58:03 kern_ioctl() at kern_ioctl+0x28a/frame 0xfe0030faf8c0
16:58:03 sys_ioctl() at sys_ioctl+0x15d/frame 0xfe0030faf990
16:58:03 amd64_syscall() at amd64_syscall+0x276/frame 0xfe0030fafab0
16:58:03 fast_syscall_common() at fast_syscall_common+0x101/frame
0xfe0030fafab0
16:58:03 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8004842ca, rsp =
0x7fffe448, rbp = 0x7fffe4b0 ---

-- 
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 194477] 10.1-RC1 tar(1) spurious directory permission error message

2019-03-28 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194477

and...@tao11.riddles.org.uk changed:

   What|Removed |Added

 CC||and...@tao11.riddles.org.uk

--- Comment #6 from and...@tao11.riddles.org.uk ---
This bug still exists in 12-stable.

-- 
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 236864] sys/netpfil/pf/ioctl/validation:addtables triggered a GPF panic

2019-03-28 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236864

--- Comment #1 from Li-Wen Hsu  ---
hmm, the commit r345660 doesn't seem to be related to this test, and the next
run this case passed.  We need to find a reliable way to reproduce this panic.

-- 
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 236870] libarchive directory traversal gives spurious permission errors

2019-03-28 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236870

Bug ID: 236870
   Summary: libarchive directory traversal gives spurious
permission errors
   Product: Base System
   Version: 12.0-STABLE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Many People
  Priority: ---
 Component: bin
  Assignee: b...@freebsd.org
  Reporter: and...@tao11.riddles.org.uk

Created attachment 203232
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=203232&action=edit
libarchive directory traversal patch

libarchive-based utilities, notably including tar(1), fail if told to traverse
"." if the parent directory is not readable. This is caused by libarchive
trying to open ".." at the end of the traverse in order to exit the directory,
which is an obviously wrong thing to do.

Attached patch (against 12-stable) fixes this and includes a test case.

-- 
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 236870] libarchive directory traversal gives spurious permission errors

2019-03-28 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236870

--- Comment #1 from and...@tao11.riddles.org.uk ---
Sorry, this fix isn't quite complete; there are still error cases with
archiving "foo/bar/." where "foo" is not readable. Will post another fix
shortly.

-- 
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"