the state of amd64 ports on -CURRENT as of 20200827
The latest build of amd64-CURRENT ports has just completed: http://beefy18.nyi.freebsd.org/build.html?mastername=head-amd64-default&build=p546132_s364744 The number of build failures is now 740. This is an slight drop from the initial post-clang11 commit of 830. This is due to diligent work by a more than a dozen ports committers. I appreciate their efforts. For comparison, the last build of amd64-CURRENT before the clang11 import was: http://beefy18.nyi.freebsd.org/build.html?mastername=head-amd64-default&build=p544905_s364239 in which there were 66 build failures. I have added two new analyses to the script that generated the Reason column in poudriere (technically: processonelog.sh): "duplicate_symbol" and "clang11". This new change is not yet deployed on the ports build cluster. (I am currently working to make that happen.) For any ports committer interested in working on fixing these regressions, the following files may give some hints. The "corrected" analyses for the current build failures: https://people.freebsd.org/~linimon/tmp/regresslogs.out.wanted and the changes this represents from the Reason column on beefy18: https://people.freebsd.org/~linimon/tmp/diff.out mcl ___ 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: the state of amd64 ports on -CURRENT as of 20200827
I forgot to include the following statistic: repojail% grep duplicate_symbol regresslogs.out.wanted | wc -l 613 mcl ___ 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: Strange USB loop
On Tue, Aug 25, 2020 at 11:29:16AM -0700, bob prohaska wrote: > With a _different_ FT232 plugged in it also came up normally. > > Both are thought to be genuine, but they are of different age > and produce different recognition messages: > > The FT232 that causes trouble reports > ugen1.4: at usbus1 > uftdi0 on uhub1 > uftdi0: on usbus1 > > The one that seems to work is newer and reports > ugen1.4: at usbus1 > uftdi0 on uhub1 > uftdi0: on usbus1 > > On balance I think the new kernel is better-behaved. Beyond that > I'm at a loss. If you can suggest other things to try please do. > > This morning I found on the console a message: uftdi0: at uhub1, port 3, addr 4 (disconnected) uftdi0: detached but, usbconfig -a repored ugen1.4: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (90mA) and lsusb says Bus /dev/usb Device /dev/ugen1.4: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC The FT232 is plugged directly into the Pi. This the newer, supposedly functional, ft232... Unplugging and replugging put on the console ugen1.4: at usbus1 (disconnected) uftdi0: at uhub1, port 3, addr 4 (disconnected) uftdi0: detached ugen1.4: at usbus1 uftdi0 on uhub1 uftdi0: on usbus1 But it still can't connect to the serial port of the correspondent host, which is up and running. Meanwhile, the FT232 which appeared faulty is working fine overnight on RaspiOS Buster. Thanks for reading, and any suggestions bob prohaska ___ 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"
can't handle raw ops yet!!!
After OpenZFS merge, during boot I'm getting several occurrences of what seems to be the following: http://src.illumos.org/source/xref/freebsd-head/sys/contrib/openzfs/module/os/freebsd/spl/spl_kstat.c#207 And, yes, I'm running GENERIC, so with INVARIANTS. Should I be worried? ___ 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: can't handle raw ops yet!!!
Expected. I'm working on it. It's just a friendly reminder when INVARIANTS is enabled. On Thu, Aug 27, 2020 at 11:17 AM Yuri Pankov wrote: > > After OpenZFS merge, during boot I'm getting several occurrences of what > seems to be the following: > > http://src.illumos.org/source/xref/freebsd-head/sys/contrib/openzfs/module/os/freebsd/spl/spl_kstat.c#207 > > And, yes, I'm running GENERIC, so with INVARIANTS. > > Should I be worried? > ___ > 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" ___ 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: can't handle raw ops yet!!!
Matthew Macy wrote: Expected. I'm working on it. It's just a friendly reminder when INVARIANTS is enabled. Good, thanks. On Thu, Aug 27, 2020 at 11:17 AM Yuri Pankov wrote: After OpenZFS merge, during boot I'm getting several occurrences of what seems to be the following: http://src.illumos.org/source/xref/freebsd-head/sys/contrib/openzfs/module/os/freebsd/spl/spl_kstat.c#207 And, yes, I'm running GENERIC, so with INVARIANTS. Should I be worried? ___ 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: buildkernel fais with option ZFS in kernel configuration
Need zstdio option when linking statically On Thu, Aug 27, 2020 at 8:23 AM Scott Kenney wrote: > > Hello, > > Just noticed that buildkernel fails with "options ZFS" in the kernel > configuration file, the modules build without error. > > Source is at revision 364870 > > FreeBSD datura.rmta.org 13.0-CURRENT FreeBSD > 13.0-CURRENT #3 r364525: Sun Aug 23 23:14:23 EDT 2020 > r...@datura.rmta.org:/usr/obj/usr/src/amd64.amd64/sys/DATURA amd64 > > > > linking kernel > ld: error: undefined symbol: zfs_zstd_compress > >>> referenced by zio_compress.c > >>> zio_compress.o:(zio_compress_table) > > ld: error: undefined symbol: zfs_zstd_decompress > >>> referenced by zio_compress.c > >>> zio_compress.o:(zio_compress_table) > > ld: error: undefined symbol: zfs_zstd_decompress_level > >>> referenced by zio_compress.c > >>> zio_compress.o:(zio_compress_table) > *** [kernel] Error code 1 > > make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/DATURA > 1 error > > make[2]: stopped in /usr/obj/usr/src/amd64.a > make[2]: stopped in /usr/obj/usr/src/amd64.a > > > > > > -- > Scott Kenney >|< sa...@coderd.rmta.org > "Let's exchange the experience" - KB > ___ > 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" ___ 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"
usbd_setup_device_desc: getting device descriptor at addr 6 failed, USB_ERR_IOERROR
Another issue that I started seeing lately, didn't try finding out when exactly in case someone knows what it's about: Root mount waiting for: usbus0 usbd_setup_device_desc: getting device descriptor at addr 6 failed, USB_ERR_IOERROR Root mount waiting for: usbus0 usbd_setup_device_desc: getting device descriptor at addr 6 failed, USB_ERR_IOERROR Root mount waiting for: usbus0 Root mount waiting for: usbus0 usbd_setup_device_desc: getting device descriptor at addr 6 failed, USB_ERR_IOERROR Root mount waiting for: usbus0 usbd_setup_device_desc: getting device descriptor at addr 6 failed, USB_ERR_IOERROR Root mount waiting for: usbus0 Root mount waiting for: usbus0 usbd_setup_device_desc: getting device descriptor at addr 6 failed, USB_ERR_IOERROR ugen0.7: at usbus0 (disconnected) uhub_reattach_port: could not allocate new device Root mount waiting for: usbus0 ugen0.7: at usbus0 ugen0.7: at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0310 bDeviceClass = 0x0009 bDeviceSubClass = 0x bDeviceProtocol = 0x0003 bMaxPacketSize0 = 0x0009 idVendor = 0x0bda idProduct = 0x0423 bcdDevice = 0x0103 iManufacturer = 0x0001 iProduct = 0x0002 <2-Port USB 3.1 Hub> iSerialNumber = 0x bNumConfigurations = 0x0001 So far not seeing any ill effects from this, i.e. I can connect USB HDD to these ports, and it's successfully detected. ___ 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: usbd_setup_device_desc: getting device descriptor at addr 6 failed, USB_ERR_IOERROR
On Thu, Aug 27, 2020 at 09:41:16PM +0300, Yuri Pankov wrote: > Another issue that I started seeing lately, didn't try finding out when > exactly in case someone knows what it's about: > > Root mount waiting for: usbus0 > usbd_setup_device_desc: getting device descriptor at addr 6 failed, > USB_ERR_IOERROR > [details snipped] > So far not seeing any ill effects from this, i.e. I can connect USB HDD to > these ports, and it's successfully detected. If it's convenient, connecting a USB-serial adapter and rebooting might be interesting. I'm having trouble with FT232 obstructing disk detection in some cases and self-disconnecting in others on a Pi3B. Thanks for reading, bob prohaska ___ 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: usbd_setup_device_desc: getting device descriptor at addr 6 failed, USB_ERR_IOERROR
bob prohaska wrote: On Thu, Aug 27, 2020 at 09:41:16PM +0300, Yuri Pankov wrote: Another issue that I started seeing lately, didn't try finding out when exactly in case someone knows what it's about: Root mount waiting for: usbus0 usbd_setup_device_desc: getting device descriptor at addr 6 failed, USB_ERR_IOERROR [details snipped] So far not seeing any ill effects from this, i.e. I can connect USB HDD to these ports, and it's successfully detected. If it's convenient, connecting a USB-serial adapter and rebooting might be interesting. I'm having trouble with FT232 obstructing disk detection in some cases and self-disconnecting in others on a Pi3B. Don't have one. It is "desktop" PC, so the only USB devices I have/need are keyboard/mouse and memsticks. ___ 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"
buildkernel fais with option ZFS in kernel configuration
Hello, Just noticed that buildkernel fails with "options ZFS" in the kernel configuration file, the modules build without error. Source is at revision 364870 FreeBSD datura.rmta.org 13.0-CURRENT FreeBSD 13.0-CURRENT #3 r364525: Sun Aug 23 23:14:23 EDT 2020 r...@datura.rmta.org:/usr/obj/usr/src/amd64.amd64/sys/DATURA amd64 linking kernel ld: error: undefined symbol: zfs_zstd_compress >>> referenced by zio_compress.c >>> zio_compress.o:(zio_compress_table) ld: error: undefined symbol: zfs_zstd_decompress >>> referenced by zio_compress.c >>> zio_compress.o:(zio_compress_table) ld: error: undefined symbol: zfs_zstd_decompress_level >>> referenced by zio_compress.c >>> zio_compress.o:(zio_compress_table) *** [kernel] Error code 1 make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/DATURA 1 error make[2]: stopped in /usr/obj/usr/src/amd64.a make[2]: stopped in /usr/obj/usr/src/amd64.a -- Scott Kenney >|< sa...@coderd.rmta.org "Let's exchange the experience" - KB ___ 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: FreeBSD-head-i386-build - Build #17845 (r364891) - Failure
Well, this was unexpected. I have pinged jenkins-admin@. Glen On Thu, Aug 27, 2020 at 09:59:47PM +, jenkins-ad...@freebsd.org wrote: > FreeBSD-head-i386-build - Build #17845 (r364891) - Failure > > Build information: https://ci.FreeBSD.org/job/FreeBSD-head-i386-build/17845/ > Full change log: > https://ci.FreeBSD.org/job/FreeBSD-head-i386-build/17845/changes > Full build log: > https://ci.FreeBSD.org/job/FreeBSD-head-i386-build/17845/console > > Status explanation: > "Failure" - the build is suspected being broken by the following changes > "Still Failing" - the build has not been fixed by the following changes and > this is a notification to note that these changes have > not been fully tested by the CI system > > Change summaries: > (Those commits are likely but not certainly responsible) > > 364891 by gjb: > Merge the projects/release-git branch to head. > This allows building 13.x from Git instead of Subversion. > > No MFC to stable branches is planned at this time. [1] > > Discussed with: git working group [1] > Sponsored by: Rubicon Communications, LLC (netgate.com) > > > [...] > -- > >>> Kernel build for GENERIC completed on Thu Aug 27 21:59:39 UTC 2020 > -- > >>> Kernel(s) GENERIC built in 169 seconds, ncpu: 48, make -j24 > -- > + cd /usr/src/release > + sudo make clean > make: "/usr/src/release/Makefile.inc1" line 14: "Git binary not found. Set > GIT_CMD appropriately." > Build step 'Execute shell' marked build as failure > [WARNINGS]Skipping publisher since build result is FAILURE > FTP: Current build result is [FAILURE], not going to run. > [PostBuildScript] - [INFO] Executing post build scripts. > [PostBuildScript] - [INFO] Build does not have any of the results [SUCCESS]. > Did not execute build step #0. > [PostBuildScript] - [INFO] Executing post build scripts. > [FreeBSD-head-i386-build] $ /bin/sh -xe /tmp/jenkins5000682500845227971.sh > + sh freebsd-ci/scripts/jail/clean.sh > clean jail FreeBSD-head-i386-build > Checking for post-build > Performing post-build step > Checking if email needs to be generated > Email was triggered for: Failure - Any > Sending email for trigger: Failure - Any signature.asc Description: PGP signature
Re: buildkernel fais with option ZFS in kernel configuration
On Thu, Aug 27, 2020 at 11:36:56AM -0700, Matthew Macy wrote: > Need zstdio option when linking statically Thank you. It should probably be added as a requirement to the NOTES file. > On Thu, Aug 27, 2020 at 8:23 AM Scott Kenney wrote: > > > > Hello, > > > > Just noticed that buildkernel fails with "options ZFS" in the kernel > > configuration file, the modules build without error. > > > > Source is at revision 364870 > > > > FreeBSD datura.rmta.org 13.0-CURRENT FreeBSD > > 13.0-CURRENT #3 r364525: Sun Aug 23 23:14:23 EDT 2020 > > r...@datura.rmta.org:/usr/obj/usr/src/amd64.amd64/sys/DATURA amd64 > > > > > > > > linking kernel > > ld: error: undefined symbol: zfs_zstd_compress > > >>> referenced by zio_compress.c > > >>> zio_compress.o:(zio_compress_table) > > > > ld: error: undefined symbol: zfs_zstd_decompress > > >>> referenced by zio_compress.c > > >>> zio_compress.o:(zio_compress_table) > > > > ld: error: undefined symbol: zfs_zstd_decompress_level > > >>> referenced by zio_compress.c > > >>> zio_compress.o:(zio_compress_table) > > *** [kernel] Error code 1 > > > > make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/DATURA > > 1 error > > > > make[2]: stopped in /usr/obj/usr/src/amd64.a > > make[2]: stopped in /usr/obj/usr/src/amd64.a -- Scott Kenney >|< sa...@hotel.rmta.org "Let's exchange the experience" - KB ___ 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"
panic in range_tree_seg64_compare()
Yet another issue I'm seeing after last update (currently running r364870), hit it 2 times today: Fatal trap 12: page fault while in kernel mode cpuid = 19; apic id = 0d fault virtual address = 0xf819e2ecdc40 fault code = supervisor read data, page not present instruction pointer = 0x20:0x8277fa64 stack pointer = 0x28:0xfe01f9ff2d90 frame pointer = 0x28:0xfe01f9ff2d90 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 48792 (blk-3:0-0) trap number = 12 panic: page fault cpuid = 19 time = 1598577675 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe01f9ff2a40 vpanic() at vpanic+0x182/frame 0xfe01f9ff2a90 panic() at panic+0x43/frame 0xfe01f9ff2af0 trap_fatal() at trap_fatal+0x387/frame 0xfe01f9ff2b50 trap_pfault() at trap_pfault+0x97/frame 0xfe01f9ff2bb0 trap() at trap+0x2ab/frame 0xfe01f9ff2cc0 calltrap() at calltrap+0x8/frame 0xfe01f9ff2cc0 --- trap 0xc, rip = 0x8277fa64, rsp = 0xfe01f9ff2d90, rbp = 0xfe01f9ff2d90 --- range_tree_seg64_compare() at range_tree_seg64_compare+0x4/frame 0xfe01f9ff2d90 zfs_btree_find() at zfs_btree_find+0x1bd/frame 0xfe01f9ff2df0 range_tree_find_impl() at range_tree_find_impl+0x6e/frame 0xfe01f9ff2e30 range_tree_find() at range_tree_find+0x1c/frame 0xfe01f9ff2e70 range_tree_contains() at range_tree_contains+0x9/frame 0xfe01f9ff2e80 dnode_block_freed() at dnode_block_freed+0x11d/frame 0xfe01f9ff2eb0 dbuf_read() at dbuf_read+0x70c/frame 0xfe01f9ff2fc0 dmu_buf_hold_array_by_dnode() at dmu_buf_hold_array_by_dnode+0x164/frame 0xfe01f9ff3030 dmu_read_impl() at dmu_read_impl+0xce/frame 0xfe01f9ff30c0 dmu_read() at dmu_read+0x45/frame 0xfe01f9ff3100 zvol_geom_bio_strategy() at zvol_geom_bio_strategy+0x2aa/frame 0xfe01f9ff3180 g_io_request() at g_io_request+0x2df/frame 0xfe01f9ff31b0 g_dev_strategy() at g_dev_strategy+0x155/frame 0xfe01f9ff31e0 physio() at physio+0x4f8/frame 0xfe01f9ff3270 devfs_read_f() at devfs_read_f+0xde/frame 0xfe01f9ff32d0 dofileread() at dofileread+0x81/frame 0xfe01f9ff3320 kern_preadv() at kern_preadv+0x62/frame 0xfe01f9ff3360 sys_preadv() at sys_preadv+0x39/frame 0xfe01f9ff3390 amd64_syscall() at amd64_syscall+0x140/frame 0xfe01f9ff34b0 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe01f9ff34b0 --- syscall (289, FreeBSD ELF64, sys_preadv), rip = 0x8006fd89a, rsp = 0x7fffdfdfcf18, rbp = 0x7fffdfdfcfc0 --- Uptime: 4h13m43s Guessing on zvol_geom_bio_strategy(), it's volmode=dev zvol I'm using for bhyve VM. Anything known? ___ 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: panic in range_tree_seg64_compare()
On Thu, Aug 27, 2020 at 6:34 PM Yuri Pankov wrote:
>
> Yet another issue I'm seeing after last update (currently running
> r364870), hit it 2 times today:
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 19; apic id = 0d
> fault virtual address = 0xf819e2ecdc40
> fault code = supervisor read data, page not present
> instruction pointer = 0x20:0x8277fa64
> stack pointer = 0x28:0xfe01f9ff2d90
> frame pointer = 0x28:0xfe01f9ff2d90
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process = 48792 (blk-3:0-0)
> trap number = 12
> panic: page fault
> cpuid = 19
> time = 1598577675
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfe01f9ff2a40
> vpanic() at vpanic+0x182/frame 0xfe01f9ff2a90
> panic() at panic+0x43/frame 0xfe01f9ff2af0
> trap_fatal() at trap_fatal+0x387/frame 0xfe01f9ff2b50
> trap_pfault() at trap_pfault+0x97/frame 0xfe01f9ff2bb0
> trap() at trap+0x2ab/frame 0xfe01f9ff2cc0
> calltrap() at calltrap+0x8/frame 0xfe01f9ff2cc0
> --- trap 0xc, rip = 0x8277fa64, rsp = 0xfe01f9ff2d90, rbp =
> 0xfe01f9ff2d90 ---
> range_tree_seg64_compare() at range_tree_seg64_compare+0x4/frame
> 0xfe01f9ff2d90
> zfs_btree_find() at zfs_btree_find+0x1bd/frame 0xfe01f9ff2df0
> range_tree_find_impl() at range_tree_find_impl+0x6e/frame 0xfe01f9ff2e30
> range_tree_find() at range_tree_find+0x1c/frame 0xfe01f9ff2e70
> range_tree_contains() at range_tree_contains+0x9/frame 0xfe01f9ff2e80
> dnode_block_freed() at dnode_block_freed+0x11d/frame 0xfe01f9ff2eb0
> dbuf_read() at dbuf_read+0x70c/frame 0xfe01f9ff2fc0
> dmu_buf_hold_array_by_dnode() at dmu_buf_hold_array_by_dnode+0x164/frame
> 0xfe01f9ff3030
> dmu_read_impl() at dmu_read_impl+0xce/frame 0xfe01f9ff30c0
> dmu_read() at dmu_read+0x45/frame 0xfe01f9ff3100
> zvol_geom_bio_strategy() at zvol_geom_bio_strategy+0x2aa/frame
> 0xfe01f9ff3180
> g_io_request() at g_io_request+0x2df/frame 0xfe01f9ff31b0
> g_dev_strategy() at g_dev_strategy+0x155/frame 0xfe01f9ff31e0
> physio() at physio+0x4f8/frame 0xfe01f9ff3270
> devfs_read_f() at devfs_read_f+0xde/frame 0xfe01f9ff32d0
> dofileread() at dofileread+0x81/frame 0xfe01f9ff3320
> kern_preadv() at kern_preadv+0x62/frame 0xfe01f9ff3360
> sys_preadv() at sys_preadv+0x39/frame 0xfe01f9ff3390
> amd64_syscall() at amd64_syscall+0x140/frame 0xfe01f9ff34b0
> fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe01f9ff34b0
> --- syscall (289, FreeBSD ELF64, sys_preadv), rip = 0x8006fd89a, rsp =
> 0x7fffdfdfcf18, rbp = 0x7fffdfdfcfc0 ---
> Uptime: 4h13m43s
>
> Guessing on zvol_geom_bio_strategy(), it's volmode=dev zvol I'm using
> for bhyve VM. Anything known?
Not really. A reproduction scenario would be very helpful. This was
seen once by someone at iX - I committed some additional asserts to
the truenas tree, but haven't heard further.
+++ b/module/zfs/dbuf.c
@@ -3192,7 +3192,7 @@
dbuf_dirty_leaf_with_existing_frontend(dbuf_dirty_state_t *dds)
* scheduled its write with its buffer, we must
* disassociate by replacing the frontend.
*/
- ASSERT(db->db_state & (DB_READ|DB_PARTIAL));
+ ASSERT3U(db->db_state, &, (DB_READ|DB_PARTIAL));
ASSERT3U(db->db_dirtycnt, ==, 1);
dbuf_dirty_set_data(dds);
} else {
@@ -3238,18 +3238,24 @@ dbuf_dirty_record_create_leaf(dbuf_dirty_state_t *dds)
dr = dbuf_dirty_record_create(dds);
+ /*
+* XXX - convert to ASSERT after dn_free_ranges fix
+*/
+ VERIFY(db->db_level == 0);
+ VERIFY(db->db_blkid != DMU_BONUS_BLKID);
Thanks.
-M
___
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: can't handle raw ops yet!!!
https://github.com/openzfs/zfs/pull/10836 On Thu, Aug 27, 2020 at 11:37 AM Yuri Pankov wrote: > > Matthew Macy wrote: > > Expected. I'm working on it. It's just a friendly reminder when > > INVARIANTS is enabled. > > Good, thanks. > > > On Thu, Aug 27, 2020 at 11:17 AM Yuri Pankov wrote: > >> > >> After OpenZFS merge, during boot I'm getting several occurrences of what > >> seems to be the following: > >> > >> http://src.illumos.org/source/xref/freebsd-head/sys/contrib/openzfs/module/os/freebsd/spl/spl_kstat.c#207 > >> > >> And, yes, I'm running GENERIC, so with INVARIANTS. > >> > >> Should I be worried? ___ 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"
Does FreeBSD have an assigned Internet OID?
For the NFS over TLS work, I have a need for an Internet OID. (I understand that IETF assigns ones for things like SNMP under 1.3.6.1.4.1...) I'm referring to the long strings of numbers separated by "."s, where each number is a subtree administered by someone. If either the project or Foundation has one assigned to them, that I can acquire a subnumber (or whatever they call the next layer down), please let me know. Thanks, rick ___ 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: Does FreeBSD have an assigned Internet OID?
Hi! > For the NFS over TLS work, I have a need for an Internet OID. > (I understand that IETF assigns ones for things like SNMP under > 1.3.6.1.4.1...) > > I'm referring to the long strings of numbers separated by "."s, > where each number is a subtree administered by someone. https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers says: 2238 The FreeBSD Project Poul-Henning Kamp phk&FreeBSD.ORG > If either the project or Foundation has one assigned to them, > that I can acquire a subnumber (or whatever they call the next > layer down), please let me know. -- p...@opsec.eu+49 171 3101372Now what ? ___ 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: Does FreeBSD have an assigned Internet OID?
Rick Macklem writes: > For the NFS over TLS work, I have a need for an Internet OID. > (I understand that IETF assigns ones for things like SNMP under > 1.3.6.1.4.1...) See: /usr/share/snmp/mibs/FREEBSD-MIB.txt -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: panic in range_tree_seg64_compare()
Matthew Macy wrote:
On Thu, Aug 27, 2020 at 6:34 PM Yuri Pankov wrote:
Yet another issue I'm seeing after last update (currently running
r364870), hit it 2 times today:
Fatal trap 12: page fault while in kernel mode
cpuid = 19; apic id = 0d
fault virtual address = 0xf819e2ecdc40
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x8277fa64
stack pointer = 0x28:0xfe01f9ff2d90
frame pointer = 0x28:0xfe01f9ff2d90
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 48792 (blk-3:0-0)
trap number = 12
panic: page fault
cpuid = 19
time = 1598577675
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe01f9ff2a40
vpanic() at vpanic+0x182/frame 0xfe01f9ff2a90
panic() at panic+0x43/frame 0xfe01f9ff2af0
trap_fatal() at trap_fatal+0x387/frame 0xfe01f9ff2b50
trap_pfault() at trap_pfault+0x97/frame 0xfe01f9ff2bb0
trap() at trap+0x2ab/frame 0xfe01f9ff2cc0
calltrap() at calltrap+0x8/frame 0xfe01f9ff2cc0
--- trap 0xc, rip = 0x8277fa64, rsp = 0xfe01f9ff2d90, rbp =
0xfe01f9ff2d90 ---
range_tree_seg64_compare() at range_tree_seg64_compare+0x4/frame
0xfe01f9ff2d90
zfs_btree_find() at zfs_btree_find+0x1bd/frame 0xfe01f9ff2df0
range_tree_find_impl() at range_tree_find_impl+0x6e/frame 0xfe01f9ff2e30
range_tree_find() at range_tree_find+0x1c/frame 0xfe01f9ff2e70
range_tree_contains() at range_tree_contains+0x9/frame 0xfe01f9ff2e80
dnode_block_freed() at dnode_block_freed+0x11d/frame 0xfe01f9ff2eb0
dbuf_read() at dbuf_read+0x70c/frame 0xfe01f9ff2fc0
dmu_buf_hold_array_by_dnode() at dmu_buf_hold_array_by_dnode+0x164/frame
0xfe01f9ff3030
dmu_read_impl() at dmu_read_impl+0xce/frame 0xfe01f9ff30c0
dmu_read() at dmu_read+0x45/frame 0xfe01f9ff3100
zvol_geom_bio_strategy() at zvol_geom_bio_strategy+0x2aa/frame
0xfe01f9ff3180
g_io_request() at g_io_request+0x2df/frame 0xfe01f9ff31b0
g_dev_strategy() at g_dev_strategy+0x155/frame 0xfe01f9ff31e0
physio() at physio+0x4f8/frame 0xfe01f9ff3270
devfs_read_f() at devfs_read_f+0xde/frame 0xfe01f9ff32d0
dofileread() at dofileread+0x81/frame 0xfe01f9ff3320
kern_preadv() at kern_preadv+0x62/frame 0xfe01f9ff3360
sys_preadv() at sys_preadv+0x39/frame 0xfe01f9ff3390
amd64_syscall() at amd64_syscall+0x140/frame 0xfe01f9ff34b0
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe01f9ff34b0
--- syscall (289, FreeBSD ELF64, sys_preadv), rip = 0x8006fd89a, rsp =
0x7fffdfdfcf18, rbp = 0x7fffdfdfcfc0 ---
Uptime: 4h13m43s
Guessing on zvol_geom_bio_strategy(), it's volmode=dev zvol I'm using
for bhyve VM. Anything known?
Not really. A reproduction scenario would be very helpful. This was
seen once by someone at iX - I committed some additional asserts to
the truenas tree, but haven't heard further.
+++ b/module/zfs/dbuf.c
@@ -3192,7 +3192,7 @@
dbuf_dirty_leaf_with_existing_frontend(dbuf_dirty_state_t *dds)
* scheduled its write with its buffer, we must
* disassociate by replacing the frontend.
*/
- ASSERT(db->db_state & (DB_READ|DB_PARTIAL));
+ ASSERT3U(db->db_state, &, (DB_READ|DB_PARTIAL));
ASSERT3U(db->db_dirtycnt, ==, 1);
dbuf_dirty_set_data(dds);
} else {
@@ -3238,18 +3238,24 @@ dbuf_dirty_record_create_leaf(dbuf_dirty_state_t *dds)
dr = dbuf_dirty_record_create(dds);
+ /*
+* XXX - convert to ASSERT after dn_free_ranges fix
+*/
+ VERIFY(db->db_level == 0);
+ VERIFY(db->db_blkid != DMU_BONUS_BLKID);
Can't find context for both chunks, there are simply no such functions
in sys/contrib/openzfs/module/zfs/dbuf.c, and yes, note that I'm running
the in-tree version.
___
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"
