[Bug 242423] netstat -rs is broken
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242423 --- Comment #3 from Olivier Cochard --- Yes it fixes it. Thanks! -- 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 224496] mpr and mps drivers seems to have issues with large seagate drives
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224496 --- Comment #22 from Matthias Pfaller --- I'm running FreeBSD 12.1 now. Yesterday we reattached the drives to the LSI controller. Problems showed up during the next backup :-( Kernel log: Dec 4 10:13:30 nyx kernel: mps0: port 0x8000-0x80ff mem 0xdf70-0xdf703fff,0xdf68-0xdf6b irq 32 at device 0.0 on pci3 Dec 4 10:13:30 nyx kernel: mps0: Firmware: 20.00.07.00, Driver: 21.02.00.00-fbsd Dec 4 10:13:30 nyx kernel: mps0: IOCCapabilities: 185c Dec 4 10:33:08 nyx kernel: mps0: port 0x8000-0x80ff mem 0xdf70-0xdf703fff,0xdf68-0xdf6b irq 32 at device 0.0 on pci3 Dec 4 10:33:08 nyx kernel: mps0: Firmware: 20.00.07.00, Driver: 21.02.00.00-fbsd Dec 4 10:33:08 nyx kernel: mps0: IOCCapabilities: 185c Dec 4 10:33:08 nyx kernel: da0 at mps0 bus 0 scbus0 target 2 lun 0 Dec 4 10:33:08 nyx kernel: da1 at mps0 bus 0 scbus0 target 3 lun 0 Dec 4 10:33:08 nyx kernel: da2 at mps0 bus 0 scbus0 target 4 lun 0 Dec 4 10:33:08 nyx kernel: da4 at mps0 bus 0 scbus0 target 6 lun 0 Dec 4 10:33:08 nyx kernel: da5 at mps0 bus 0 scbus0 target 7 lun 0 Dec 4 10:33:08 nyx kernel: da6 at mps0 bus 0 scbus0 target 8 lun 0 Dec 4 10:33:08 nyx kernel: da3 at mps0 bus 0 scbus0 target 5 lun 0 Dec 4 10:33:08 nyx kernel: da7 at mps0 bus 0 scbus0 target 9 lun 0 Dec 4 22:42:34 nyx kernel: (da4:mps0:0:6:0): READ(16). CDB: 88 00 00 00 00 03 45 37 b3 48 00 00 00 08 00 00 length 4096 SMID 1583 Command timeout on target 6(0x0010) 6 set, 60.66782887 elapsed Dec 4 22:42:34 nyx kernel: mps0: Sending abort to target 6 for SMID 1583 Dec 4 22:42:34 nyx kernel: (da4:mps0:0:6:0): READ(16). CDB: 88 00 00 00 00 03 45 37 b3 48 00 00 00 08 00 00 length 4096 SMID 1583 Aborting command 0xfe00f9364f28 Dec 4 22:42:34 nyx kernel: (da7:mps0:0:9:0): WRITE(16). CDB: 8a 00 00 00 00 03 60 06 f6 c8 00 00 00 18 00 00 length 12288 SMID 925 Command timeout on target 9(0x000d) 6 set, 60.23115994 elapsed Dec 4 22:42:34 nyx kernel: mps0: Sending abort to target 9 for SMID 925 Dec 4 22:42:34 nyx kernel: (da7:mps0:0:9:0): WRITE(16). CDB: 8a 00 00 00 00 03 60 06 f6 c8 00 00 00 18 00 00 length 12288 SMID 925 Aborting command 0xfe00f932daf8 Dec 4 22:42:34 nyx kernel: (da0:mps0:0:2:0): WRITE(16). CDB: 8a 00 00 00 00 04 dc 52 aa d8 00 00 00 30 00 00 length 24576 SMID 1033 Command timeout on target 2(0x000c) 6 set, 60.24094823 elapsed Dec 4 22:42:34 nyx kernel: mps0: Sending abort to target 2 for SMID 1033 Dec 4 22:42:34 nyx kernel: (da0:mps0:0:2:0): WRITE(16). CDB: 8a 00 00 00 00 04 dc 52 aa d8 00 00 00 30 00 00 length 24576 SMID 1033 Aborting command 0xfe00f9336c18 Dec 4 22:42:34 nyx kernel: (da1:mps0:0:3:0): WRITE(16). CDB: 8a 00 00 00 00 04 dc 52 aa d8 00 00 00 30 00 00 length 24576 SMID 1440 Command timeout on target 3(0x000b) 6 set, 60.24535090 elapsed Dec 4 22:42:34 nyx kernel: mps0: Sending abort to target 3 for SMID 1440 Dec 4 22:42:34 nyx kernel: (da1:mps0:0:3:0): WRITE(16). CDB: 8a 00 00 00 00 04 dc 52 aa d8 00 00 00 30 00 00 length 24576 SMID 1440 Aborting command 0xfe00f9358f00 Dec 4 22:42:34 nyx kernel: (da2:mps0:0:4:0): WRITE(10). CDB: 2a 00 24 36 61 98 00 00 18 00 length 12288 SMID 1472 Command timeout on target 4(0x000a) 6 set, 60.24982318 elapsed Dec 4 22:42:34 nyx kernel: mps0: Sending abort to target 4 for SMID 1472 Dec 4 22:42:34 nyx kernel: (da2:mps0:0:4:0): WRITE(10). CDB: 2a 00 24 36 61 98 00 00 18 00 length 12288 SMID 1472 Aborting command 0xfe00f935ba00 Dec 4 22:42:34 nyx kernel: (da5:mps0:0:7:0): WRITE(10). CDB: 2a 00 24 36 61 10 00 00 a0 00 length 81920 SMID 507 Command timeout on target 7(0x000f) 6 set, 60.25666047 elapsed Dec 4 22:42:34 nyx kernel: mps0: Sending abort to target 7 for SMID 507 Dec 4 22:42:34 nyx kernel: (da5:mps0:0:7:0): WRITE(10). CDB: 2a 00 24 36 61 10 00 00 a0 00 length 81920 SMID 507 Aborting command 0xfe00f930a948 Dec 4 22:42:40 nyx kernel: (xpt0:mps0:0:7:0): SMID 6 task mgmt 0xfe00f92e0810 timed out Dec 4 22:42:40 nyx kernel: mps0: Reinitializing controller Dec 4 22:42:40 nyx kernel: mps0: Unfreezing devq for target ID 6 Dec 4 22:42:40 nyx kernel: mps0: Unfreezing devq for target ID 9 Dec 4 22:42:40 nyx kernel: mps0: Unfreezing devq for target ID 2 ... lots more Just the reinitialization messages: Dec 4 22:42:40 nyx kernel: mps0: Reinitializing controller Dec 4 23:01:27 nyx kernel: mps0: Reinitializing controller Dec 4 23:40:55 nyx kernel: mps0: Reinitializing controller Dec 4 23:47:49 nyx kernel: mps0: Reinitializing controller Dec 4 23:58:02 nyx kernel: mps0: Reinitializing controller Dec 5 00:17:33 nyx kernel: mps0: Reinitializing controller Dec 5 00:20:18 nyx kernel: mps0: Reinitializing controller Dec 5 00:21:33 nyx kernel: mps0: Reinitializing controller Dec 5 00:24:30 nyx kernel: mps0: Reinitializing controller Dec 5 00:26:40 nyx kernel: mps0: Reinitializing controller Dec 5 00:29:30 nyx kernel: mps0: Reini
[Bug 241639] Fatal trap 12: page fault ... current process = 0 (vmbusdev) when using mlx4en
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241639 --- Comment #52 from commit-h...@freebsd.org --- A commit references this bug: Author: hselasky Date: Thu Dec 5 14:50:46 UTC 2019 New revision: 355417 URL: https://svnweb.freebsd.org/changeset/base/355417 Log: MFC r355108 and r355170: Fix panic when loading kernel modules before root file system is mounted. Make sure the rootvnode is always NULL checked. Differential Revision:https://reviews.freebsd.org/D22545 PR: 241639 Sponsored by: Mellanox Technologies Changes: _U stable/12/ stable/12/sys/kern/kern_linker.c stable/12/sys/kern/subr_firmware.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 241639] Fatal trap 12: page fault ... current process = 0 (vmbusdev) when using mlx4en
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241639 --- Comment #53 from commit-h...@freebsd.org --- A commit references this bug: Author: hselasky Date: Thu Dec 5 14:52:07 UTC 2019 New revision: 355418 URL: https://svnweb.freebsd.org/changeset/base/355418 Log: MFC r355108 and r355170: Fix panic when loading kernel modules before root file system is mounted. Make sure the rootvnode is always NULL checked. Differential Revision:https://reviews.freebsd.org/D22545 PR: 241639 Sponsored by: Mellanox Technologies Changes: _U stable/11/ stable/11/sys/kern/kern_linker.c stable/11/sys/kern/subr_firmware.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 241639] Fatal trap 12: page fault ... current process = 0 (vmbusdev) when using mlx4en
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241639 --- Comment #54 from commit-h...@freebsd.org --- A commit references this bug: Author: hselasky Date: Thu Dec 5 14:53:47 UTC 2019 New revision: 355419 URL: https://svnweb.freebsd.org/changeset/base/355419 Log: MFC r355108 and r355170: Fix panic when loading kernel modules before root file system is mounted. Make sure the rootvnode is always NULL checked. Differential Revision:https://reviews.freebsd.org/D22545 PR: 241639 Sponsored by: Mellanox Technologies Changes: _U stable/10/ stable/10/sys/kern/kern_linker.c stable/10/sys/kern/subr_firmware.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 242427] pmap_remove() sometimes is very slow causing 10+ minutes long reboots
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242427
--- Comment #6 from Peter Eriksson ---
(In reply to Konstantin Belousov from comment #5)
Yes, you are correct (and I was wrong). Sorry about that.
I've rewritten the timing tests now to use nanouptime() instead, and now things
look slightly different. Albeit still takes a long time...
Here's a sample from a server that has been up for some hours:
keg_free_slab: keg->uk_freef(mem) {page_free} took 2077 µs
keg_free_slab: keg->uk_freef(mem) {page_free} took 2123 µs
keg_free_slab: keg->uk_freef(mem) {page_free} took 2107 µs
keg_free_slab: keg->uk_freef(mem) {page_free} took 2190 µs
keg_drain: while()-keg_free_slab-loop took 163 s (163765748 µs) [240297
loops, 4 slow, avg=681 µs, min=246 µs, max=7922 µs]
zone_drain_wait(): zone_foreach_keg(zone, &keg_drain) took 163 s
zone_dtor(): zone_drain_wait(zone, M_WAITOK) took 163 s
zone_free_item(zone=UMA Zones): zone->uz_dtor() took 163 s
uma_zdestroy(zio_buf_16384) took 163 s
kmem_cache_destroy: uma_zdestroy(0xf80346601880) [zio_buf_16384] took 164
seconds
zio_fini: kmem_cache_destroy(zio_buf_cache[28]) took 164 seconds
keg_free_slab only prints the keg->uk_freef(mem) (calls page_free which calls
kmem_free) call timings if it takes over 2000µs. Most of them are not shown,
the majority seems to be around 1000-1500µs.
Anyway, I wonder if one couldn't just skip all this freeing of kernel memory at
reboot/shutdown time. Perhaps it could conditionally be disabled via a sysctl
setting?
In order to test this I added such a sysctl and with the calls to
kmem_cache_destroy() in zio_fini() disabled this machine reboots in under 1
minute instead of atleast 10 minutes (for a newly booted server). (The LSI SAS
HBA shutdown and the ZFS unmounting takes the most of that time).
(I suppose the current code is needed for the case where you have dynamically
loaded zfs and wishes to kldunload it (without rebooting) - or one will have a
massive memory leak, but since we're rebooting almost immediately after this I
don't really see why we have to spend 10-60 minutes freeing all this memory
:-).
zio.fini() is in /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c
The rest are in /usr/src/sys/vm/uma_core.c & vm_kern.c
A slightly longer output (verbose-level 2 so skipping some timing measurements
in keg_free_slab and below that might inflate the timing numbers) for reference
from a freshly rebooted server:
Freeing ZFS ZIO caches:
keg_drain: while()-keg_free_slab-loop took 994 ms (993875 µs) [1450 loops, 0
slow, avg=685 µs, min=383 µs, max=1713 µs, 0 zero]
zone_drain_wait(): zone_foreach_keg(zone, &keg_drain) took 7319 µs
zone_dtor(): zone_drain_wait(zone, M_WAITOK) took 14 ms
uma_zdestroy(zio_buf_8192) took 19 ms
keg_drain: while()-keg_free_slab-loop took 15 s (15886587 µs) [23217 loops, 0
slow, avg=684 µs, min=279 µs, max=1745 µs, 0 zero]
zone_drain_wait(): zone_foreach_keg(zone, &keg_drain) took 15 s
zone_dtor(): zone_drain_wait(zone, M_WAITOK) took 15 s
uma_zdestroy(zio_buf_12288) took 15 s
kmem_cache_destroy: uma_zdestroy(0xf803465f6980) [zio_buf_12288] took 16
seconds
zio_fini: kmem_cache_destroy(zio_buf_cache[20]) took 16 seconds
keg_drain: while()-keg_free_slab-loop took 61 s (61698566 µs) [86029 loops, 11
slow, avg=717 µs, min=265 µs, max=2252 µs, 0 zero]
zone_drain_wait(): zone_foreach_keg(zone, &keg_drain) took 61 s
zone_dtor(): zone_drain_wait(zone, M_WAITOK) took 61 s
uma_zdestroy(zio_buf_16384) took 61 s
kmem_cache_destroy: uma_zdestroy(0xf803465f6880) [zio_buf_16384] took 62
seconds
zio_fini: kmem_cache_destroy(zio_buf_cache[28]) took 62 seconds
keg_drain: while()-keg_free_slab-loop took 87 s (86986351 µs) [123793 loops, 24
slow, avg=702 µs, min=297 µs, max=2398 µs, 0 zero]
zone_drain_wait(): zone_foreach_keg(zone, &keg_drain) took 87 s
zone_dtor(): zone_drain_wait(zone, M_WAITOK) took 87 s
uma_zdestroy(zio_buf_131072) took 87 s
kmem_cache_destroy: uma_zdestroy(0xf8034c904640) [zio_buf_131072] took 87
seconds
zio_fini: kmem_cache_destroy(zio_buf_cache[224]) took 87 seconds
keg_drain: while()-keg_free_slab-loop took 344 ms (5340963 µs) [7730 loops, 0
slow, avg=690 µs, min=371 µs, max=1739 µs, 0 zero]
zone_drain_wait(): zone_foreach_keg(zone, &keg_drain) took 357 ms
zone_dtor(): zone_drain_wait(zone, M_WAITOK) took 364 ms
uma_zdestroy(zio_data_buf_131072) took 370 ms
kmem_cache_destroy: uma_zdestroy(0xf8034c904600) [zio_data_buf_131072] took
6 seconds
zio_fini: kmem_cache_destroy(zio_data_buf_cache[224]) took 6 seconds
--
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 242427] zfsshutdown -> zfs_fini -> kmem_cache_destroy(zio_*_buf) is very slow causing 10+ minutes long reboots
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242427 Peter Eriksson changed: What|Removed |Added Summary|pmap_remove() sometimes is |zfsshutdown -> zfs_fini -> |very slow causing 10+ |kmem_cache_destroy(zio_*_bu |minutes long reboots|f) is very slow causing 10+ ||minutes long reboots -- 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 242427] zfsshutdown -> zfs_fini -> kmem_cache_destroy(zio_*_buf) is very slow causing 10+ minutes long reboots
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242427
--- Comment #7 from Peter Eriksson ---
> keg_free_slab: keg->uk_freef(mem) {page_free} took 2190 µs
> keg_drain: while()-keg_free_slab-loop took 163 s (163765748 µs) [240297
> loops, 4 slow, avg=681 µs, min=246 µs, max=7922 µs]
Just a FYI:
The "max" value should probably be subtracted with ~6000µs - calling printf()
with a line of text seems to take about that time - so if I run the same test
without printing anything in keg_free_slab() the max is around 2000µs instead.
--
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 242457] freebsd-update from 12.0-R to 12.1-R borked base source, rendering system unable to build kernel
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242457 Bug ID: 242457 Summary: freebsd-update from 12.0-R to 12.1-R borked base source, rendering system unable to build kernel Product: Base System Version: 12.1-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: sblachm...@gmail.com A few weeks ago I downloaded the DVD-ISO of 12.0-Release, as it then was shown as the most current release on the "Download FreeBSD" page. I installed it, with base source and ports tree installation options checked. To make sure that security patches are applied, I recently ran freebsd-update according to Handbook Section 23.2 (freebsd-update fetch+install). freebsd-update then warned me that there is a custom kernel active, preventing full update. Iirc I answered "no" to some prompt "Do you want to update anyway?" and rebuilt+installed GENERIC. Then, after finishing the security updates, freebsd-update warned me about 12.0-R lifetime expiring very soon and advised to update to 12.1. So, following the handbook instructions, I ran "freebsd-update -r 12.1-RELEASE upgrade", with GENERIC kernel active. This was successful insofar that the system rebooted into 12.1 smoothly. However, when I attempt to rebuild kernel (no matter whether custom or GENERIC), the system aborted build, complaining about some missing header file (apparently belonging to the em driver, filename was something like i_if_em.h). I did not touch anything in /usr/src/... except adding my personally modified kernel configuration file. Thus my gut feeling told me that freebsd-update botched something in the sources, rendering the upgraded system unable to build kernel. So I decided to do fresh install from 12.1 USB image, and the resulting system was able to build kernel. Did I do something wrong, or is it a freebsd-update bug? -- 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 224496] mpr and mps drivers seems to have issues with large seagate drives
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224496 --- Comment #23 from Bane Ivosev --- Really sad news ... We are still running for 18 days now, everything is great with 12.1 for us, but is still early to make conclusions and your expirience is not promissing. -- 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 242303] GCE 11.3-RELEASE image doesn't have right dependency of google-compute-engine installed
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242303 Ed Maste changed: What|Removed |Added Assignee|s...@freebsd.org |b...@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 242470] Unable to boot from ANY burned media
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242470 Bug ID: 242470 Summary: Unable to boot from ANY burned media Product: Base System Version: 12.1-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: misc Assignee: b...@freebsd.org Reporter: kgordon2...@frontier.com I have burned at least three ISOs to disk, and/or flash drive, repeatedly, have adjusted the BIOS in two computers to choose whatever it takes to boot from, and every time, from both computers, I get an error message "Unable to find file boot/lua/loader.lua", yet looking at the DVDs or CDs I have made, it IS there. I have downloaded the files both via Firefox, and by using FileZilla, and BINARY and the same thing results every time. I have used both Nero and a freeware ISOBurner. I have burnt the .IMG file to flashdrive at least three times, and the only directory that shows up is one labeled efi. I know both computers will boot from a flashdrive, because I have an issue of Ubuntu on one and it works in both. So far, no joy. Any help? Ken Gordon -- 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"
