[Bug 218026] sbin/gpart: can't/won't keep secondary GPT table in sync with the primary table

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218026 Bug ID: 218026 Summary: sbin/gpart: can't/won't keep secondary GPT table in sync with the primary table Product: Base System Version: CURRENT Hardware: Any

[Bug 213705] shutdown not gracefully exiting shells losing their console history.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213705 jo...@a1poweruser.com changed: What|Removed |Added Status|New |Closed Resolution|-

[Bug 218018] BSD diff ignores fractional seconds and original file mtime

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218018 --- Comment #2 from Conrad Meyer --- This would make an easy unit test, too. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list h

[Bug 218018] BSD diff ignores fractional seconds and original file mtime

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218018 Jan Beich (mail not working) changed: What|Removed |Added Summary|BSD diff ignores original |BSD diff ignores fra

[Bug 218018] BSD diff ignores original file mtime

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218018 --- Comment #1 from Jan Beich (mail not working) --- I have vfs.timestamp_precision=3 (default is 2), so GNU diff matches Linux behavior. BSD diff just truncates to seconds. Looking at the code it appears to be another bug. https://www.gnu

[Bug 218018] BSD diff ignores original file mtime

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218018 Bug ID: 218018 Summary: BSD diff ignores original file mtime Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Keywords: needs

[Bug 218006] sys/dev/isci/scil/sati_util.c: PVS-Studio: V764

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218006 --- Comment #1 from Alexander Motin --- I think your patch is wrong. While there indeed a confusion, it looks like wrong parameter order is only in a header file in function declaration. Real use seems correct. -- You are receiving this

[Bug 205697] vi gets confused and corrupts file being edited

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205697 Michael Dexter changed: What|Removed |Added CC||dex...@freebsd.org --- Comment #3

[Bug 210099] Remove redundant MPASS which always evaluates to true in kern/subr_sleepqueue.c

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210099 John Baldwin changed: What|Removed |Added CC||j...@freebsd.org Status

[Bug 217994] Kernel panic in native_lapic_setup with 12-CURRENT on EC2 machine

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217994 Andriy Gapon changed: What|Removed |Added Status|New |Closed Resolution|---

[Bug 217994] Kernel panic in native_lapic_setup with 12-CURRENT on EC2 machine

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217994 --- Comment #16 from Sylvain Garrigues --- Guys, I recompiled without CPUTYPE and now the kernel boots. I am so ashamed to have disturbed you for this. Though, my CPU *is* Haswell: # sysctl -a | egrep -i 'hw.machine|hw.ncpu|hw.model' hw.ma

[Bug 218009] dtrace -Z flag does not install newly loaded probes

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218009 Bug ID: 218009 Summary: dtrace -Z flag does not install newly loaded probes Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New

[Bug 218007] sys/contrib/dev/ath/ath_hal/ar9300/ar9300_xmit.c: PVS-Studio: V547

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218007 Bug ID: 218007 Summary: sys/contrib/dev/ath/ath_hal/ar9300/ar9300_xmit.c: PVS-Studio: V547 Product: Base System Version: CURRENT Hardware: Any OS: Any

[Bug 218006] sys/dev/isci/scil/sati_util.c: PVS-Studio: V764

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218006 Bug ID: 218006 Summary: sys/dev/isci/scil/sati_util.c: PVS-Studio: V764 Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Seve

[Bug 218005] sys/netinet/sctp_pcb.c: PVS-Studio: Dead Code (CWE-561)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218005 Bug ID: 218005 Summary: sys/netinet/sctp_pcb.c: PVS-Studio: Dead Code (CWE-561) Product: Base System Version: CURRENT Hardware: Any OS: Any

[Bug 218004] sys/dev/sfxge/common/efx_mcdi.c: PVS-Studio: Dead Code (CWE-561)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218004 Bug ID: 218004 Summary: sys/dev/sfxge/common/efx_mcdi.c: PVS-Studio: Dead Code (CWE-561) Product: Base System Version: CURRENT Hardware: Any OS: Any

[Bug 218002] sys/dev/mps/mps.c: PVS-Studio: Dead Code (CWE-561)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218002 Bug ID: 218002 Summary: sys/dev/mps/mps.c: PVS-Studio: Dead Code (CWE-561) Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New S

[Bug 218001] Livewire+ AES67, SDI (Blackmagic ) ?

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218001 Bug ID: 218001 Summary: Livewire+ AES67, SDI (Blackmagic ) ? Product: Base System Version: 11.0-STABLE Hardware: Any OS: Any Status: New Severity: A

[Bug 217997] [pf] orphaned entries in src-track

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217997 Bug ID: 217997 Summary: [pf] orphaned entries in src-track Product: Base System Version: 10.3-RELEASE Hardware: Any OS: Any Status: New Severity: Af

[Bug 217994] Kernel panic in native_lapic_setup with 12-CURRENT on EC2 machine

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217994 --- Comment #15 from Sylvain Garrigues --- (In reply to Andriy Gapon from comment #14) I'm recompiling kernel w/ GENERIC (instead of GENERIC-NODEBUG) and no CPUTYPE line. Hold your break and expect the end of the suspense in a couple hours.

[Bug 217994] Kernel panic in native_lapic_setup with 12-CURRENT on EC2 machine

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217994 --- Comment #14 from Andriy Gapon --- (In reply to Sylvain Garrigues from comment #13) Thanks! I suspect that the problem is with BEXTR instruction that is available on Haswell, but does not seem to provided by (at least some) EC2 instances

[Bug 217994] Kernel panic in native_lapic_setup with 12-CURRENT on EC2 machine

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217994 --- Comment #13 from Sylvain Garrigues --- (In reply to Andriy Gapon from comment #12) root@ip-172-31-17-21:~ # kgdb7121 /mnt/boot/kernel/kernel GNU gdb (GDB) 7.12.1 [GDB v7.12.1 for FreeBSD] Copyright (C) 2017 Free Software Foundation, In

[Bug 217994] Kernel panic in native_lapic_setup with 12-CURRENT on EC2 machine

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217994 --- Comment #12 from Andriy Gapon --- (In reply to Sylvain Garrigues from comment #11) Those "(bad)" instructions don't look good. Could you please install gdb from packages (pkg install gdb) and repeat the same procedure using kgdb7xxx (kg

[Bug 217994] Kernel panic in native_lapic_setup with 12-CURRENT on EC2 machine

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217994 --- Comment #11 from Sylvain Garrigues --- (kgdb) disassemble native_lapic_setup Dump of assembler code for function native_lapic_setup: 0x8107fd30 : push %rbp 0x8107fd31 : mov%rsp,%rbp 0x8107fd34 :

[Bug 217994] Kernel panic in native_lapic_setup with 12-CURRENT on EC2 machine

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217994 --- Comment #10 from Andriy Gapon --- (In reply to Sylvain Garrigues from comment #9) I would be happy if you just run kgdb /path/to/that/kernel and then "disassemble native_lapic_setup" in kgdb. -- You are receiving this mail because: Yo

[Bug 217994] Kernel panic in native_lapic_setup with 12-CURRENT on EC2 machine

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217994 --- Comment #9 from Sylvain Garrigues --- @Colin: I cannot see the 2017-03-16 in the Community AMIs, where should I find it? Maybe worth to mention is my CPUTYPE?=haswell, may this cause such a fault? Also I did manage to mount the volume

[Bug 217994] Kernel panic in native_lapic_setup with 12-CURRENT on EC2 machine

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217994 --- Comment #8 from Andriy Gapon --- (In reply to Colin Percival from comment #6) Ah, okay, I keep forgetting about PVM vs HVM vs something else. Sorry for the noise. -- You are receiving this mail because: You are the assignee for the bu

[Bug 217994] Kernel panic in native_lapic_setup with 12-CURRENT on EC2 machine

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217994 --- Comment #7 from Andriy Gapon --- (In reply to Sylvain Garrigues from comment #3) If you still have the image / kernel somewhere local (or on another cloud machine), then you can open the kernel in kgdb and disassemble the function. --

[Bug 217994] Kernel panic in native_lapic_setup with 12-CURRENT on EC2 machine

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217994 --- Comment #6 from Colin Percival --- I don't have time to dig into this right now (it's 2AM here), but FreeBSD/EC2 now uses GENERIC kernels since EC2 is running Xen in HVM mode. Sylvain, can you check if the 2017-03-16 snapshot works? -

[Bug 217994] Kernel panic in native_lapic_setup with 12-CURRENT on EC2 machine

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217994 --- Comment #5 from Andriy Gapon --- Should native_lapic_setup be called on Xen at all? I thought that it overrides LAPIC methods... Are you sure that you are using the right kernel config? But then I don't know much about xen and ec2. -

[Bug 217994] Kernel panic in native_lapic_setup with 12-CURRENT on EC2 machine

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217994 --- Comment #4 from Sylvain Garrigues --- TO be extra clear, I got the kernel fault at boot time (right after rebooting the machine). I did reboot several times (on 2017-03-10) the same machine with CURRENT kernel from 2017-03-10 EC2 snaps

[Bug 217994] Kernel panic in native_lapic_setup with 12-CURRENT on EC2 machine

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217994 --- Comment #3 from Sylvain Garrigues --- I don't have access anymore to that machine, it is "in the cloud" and since it cannot boot I cannot login anymore. I just got the kernel fault screenshot from EC2 admin interface. I did install it

[Bug 196666] write(2) maximum I/O size too small / inadequately documented in man page

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=19 Eleonor changed: What|Removed |Added CC||eleonorsteinwe...@gmail.com --- Comment

[Bug 217994] Kernel panic in native_lapic_setup with 12-CURRENT on EC2 machine

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217994 --- Comment #2 from Konstantin Belousov --- What do you mean by 'anymore' ? Which revision causes the breakage for you ? Show the source line number for the faulted instruction. Also it might be useful to provide disassembly of native_lap

[Bug 217994] Kernel panic in native_lapic_setup with 12-CURRENT on EC2 machine

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217994 --- Comment #1 from Sylvain Garrigues --- EC2 machine did boot with official EC2 snapshot on EC2, dated March 10. Rebuilt my current from a src tree which dates from a few days after that. -- You are receiving this mail because: You are t

[Bug 217994] Kernel panic in native_lapic_setup with 12-CURRENT on EC2 machine

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217994 Bug ID: 217994 Summary: Kernel panic in native_lapic_setup with 12-CURRENT on EC2 machine Product: Base System Version: CURRENT Hardware: Any OS: Any

[Bug 217138] head (e.g.) -r314638 for arm64: sh vs. jemalloc asserts: include/jemalloc/internal/tsd.h:687: Failed assertion: "tsd_booted" once swapped in after being swapped out (comment 10)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217138 --- Comment #31 from Mark Millard --- (In reply to Mark Millard from comment #30) Ignore the POSIX_MADV_DONTNEED: the example child had not reached the zero RES(ident memory) status. When it does it fails (and so to the ancestor processes

[Bug 217138] head (e.g.) -r314638 for arm64: sh vs. jemalloc asserts: include/jemalloc/internal/tsd.h:687: Failed assertion: "tsd_booted" once swapped in after being swapped out (comment 10)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217138 --- Comment #30 from Mark Millard --- (In reply to Mark Millard from comment #29) It turns out that POSIX_MADV_WILLNEED can instead be POSIX_MADV_DONTNEED and it still prevents the failures. -- You are receiving this mail because: You ar