Re: FUSE Call for Testing
Damjan, thanks for the suggestion. I did like Alan suggested and: clay@bsd13:~ % pkg info -r fusefs-libs pkg: No package(s) matching fusefs-libs clay@bsd13:~ % pkg info -r fusefs-libs3 pkg: No package(s) matching fusefs-libs3 I'm sitting here looking at a pkg search fuse in LXTerminal and I see: fusefs-ntfs-2017.3.23 Mount NTFS partitions (read/write) and disk images fusefs-ext2-0.0.10_2 FUSE module to mount ext2, ext3 and ext4 with read write support I triple boot with MS Windows 10, MX Linux, and FreeBSD 13.0, so I could certainly make use of those tools. I just now copied all the files I wanted to save from this installation to a thumbdrive, and now downloading r350702. I will report back later. Clay On Fri, Aug 9, 2019 at 12:25 AM Damjan Jovanovic wrote: > NTFS-3G (sysutils/fusefs-ntfs) is probably the most widely used FUSE > filesystem. > > On Fri, Aug 9, 2019 at 4:21 AM Clay Daniels Jr. > wrote: > >> Alan, I'm pretty much into 13.0 Current and most weeks install the newest >> snapshot build. I don't know if I use FUSE or not, if you must know the >> truth. I do some hobby coding, lurk here on the email lists and Forum, and >> try to learn all I can. So do you have any specific suggestions for >> programs to install and test FUSE? I kind of like the no-x console & the >> Xterminal window too, and dabble with clang cc (strictly C, no C++) and >> Python too. Let me know. >> >> Clay Daniels >> >> On Thu, Aug 8, 2019 at 1:36 PM Alan Somers wrote: >> >> > The new FUSE driver has just landed in current. It raises the protocol >> > level from 7.8 to 7.23, fixes many bugs, adds a test suite for the >> > driver, and adds many new features. New features include: >> > * Optional kernel-side permissions checks (-o default_permissions) >> > * Implement VOP_MKNOD, VOP_BMAP, and VOP_ADVLOCK >> > * Allow interrupting FUSE operations >> > * Support named pipes and unix-domain sockets in fusefs file systems >> > * Forward UTIME_NOW during utimensat(2) to the daemon >> > * kqueue support for /dev/fuse >> > * Allow updating mounts with "mount -u" >> > * Allow exporting fusefs file systems over NFS >> > * Server-initiated invalidation of the name cache or data cache >> > * Respect RLIMIT_FSIZE >> > * Try to support servers as old as protocol 7.4 >> > >> > Performance enhancements include: >> > >> > * Implement FUSE's FOPEN_KEEP_CACHE and FUSE_ASYNC_READ flags >> > * Cache file attributes >> > * Cache lookup entries, both positive and negative >> > * Server-selectable cache modes: writethrough, writeback, or uncached >> > * Write clustering >> > * Readahead >> > * Use counter(9) for statistical reporting >> > >> > Now would be a good time for the community to test it. If you are >> > BCCed to this email, it's because you maintain a FUSE-related port. >> > Please test your port on the latest FreeBSD CURRENT image and let me >> > know if you have any problems or find any bugs. >> > >> > Even if you don't maintain a FUSE port, you can still help. If you >> > use current and commonly use any FUSE file systems, please try them >> > out after upgrading to the latest image. >> > >> > Additionally, the following FUSE-related ports don't have maintainers. >> > If you use one of them, or know somebody who does, please test them on >> > current, and consider adopting the port: >> > deskutils/kdeconnect-kde >> > devel/gvfs >> > devel/py-fusefs >> > sysutils/fusefs-afuse >> > sysutils/fusefs-chironfs >> > sysutils/fusefs-cryptofs >> > sysutils/fusefs-funionfs >> > sysutils/fusefs-fusepak >> > sysutils/fusefs-httpfs >> > sysutils/fusefs-s3backer >> > sysutils/fusefs-sqlfs >> > sysutils/fusefs-zip >> > sysutils/p5-Brackup >> > sysutils/p5-Fuse >> > >> > VM images: >> > >> http://ftp0.nyi.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/13.0-CURRENT/amd64/20190808/ >> > ISOs: >> http://ftp0.nyi.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/13.0/ >> > >> > Thanks for any feedback you can give! >> > -Alan >> > ___ >> > 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 >> " >> > ___ 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: FUSE Call for Testing
On Thu, Aug 8, 2019 at 10:25 PM Damjan Jovanovic wrote: > NTFS-3G (sysutils/fusefs-ntfs) is probably the most widely used FUSE > filesystem. > fusefs-exfat is also pretty commonly used. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > > On Fri, Aug 9, 2019 at 4:21 AM Clay Daniels Jr. > > wrote: > > > Alan, I'm pretty much into 13.0 Current and most weeks install the newest > > snapshot build. I don't know if I use FUSE or not, if you must know the > > truth. I do some hobby coding, lurk here on the email lists and Forum, > and > > try to learn all I can. So do you have any specific suggestions for > > programs to install and test FUSE? I kind of like the no-x console & the > > Xterminal window too, and dabble with clang cc (strictly C, no C++) and > > Python too. Let me know. > > > > Clay Daniels > > > > On Thu, Aug 8, 2019 at 1:36 PM Alan Somers wrote: > > > > > The new FUSE driver has just landed in current. It raises the protocol > > > level from 7.8 to 7.23, fixes many bugs, adds a test suite for the > > > driver, and adds many new features. New features include: > > > * Optional kernel-side permissions checks (-o default_permissions) > > > * Implement VOP_MKNOD, VOP_BMAP, and VOP_ADVLOCK > > > * Allow interrupting FUSE operations > > > * Support named pipes and unix-domain sockets in fusefs file systems > > > * Forward UTIME_NOW during utimensat(2) to the daemon > > > * kqueue support for /dev/fuse > > > * Allow updating mounts with "mount -u" > > > * Allow exporting fusefs file systems over NFS > > > * Server-initiated invalidation of the name cache or data cache > > > * Respect RLIMIT_FSIZE > > > * Try to support servers as old as protocol 7.4 > > > > > > Performance enhancements include: > > > > > > * Implement FUSE's FOPEN_KEEP_CACHE and FUSE_ASYNC_READ flags > > > * Cache file attributes > > > * Cache lookup entries, both positive and negative > > > * Server-selectable cache modes: writethrough, writeback, or uncached > > > * Write clustering > > > * Readahead > > > * Use counter(9) for statistical reporting > > > > > > Now would be a good time for the community to test it. If you are > > > BCCed to this email, it's because you maintain a FUSE-related port. > > > Please test your port on the latest FreeBSD CURRENT image and let me > > > know if you have any problems or find any bugs. > > > > > > Even if you don't maintain a FUSE port, you can still help. If you > > > use current and commonly use any FUSE file systems, please try them > > > out after upgrading to the latest image. > > > > > > Additionally, the following FUSE-related ports don't have maintainers. > > > If you use one of them, or know somebody who does, please test them on > > > current, and consider adopting the port: > > > deskutils/kdeconnect-kde > > > devel/gvfs > > > devel/py-fusefs > > > sysutils/fusefs-afuse > > > sysutils/fusefs-chironfs > > > sysutils/fusefs-cryptofs > > > sysutils/fusefs-funionfs > > > sysutils/fusefs-fusepak > > > sysutils/fusefs-httpfs > > > sysutils/fusefs-s3backer > > > sysutils/fusefs-sqlfs > > > sysutils/fusefs-zip > > > sysutils/p5-Brackup > > > sysutils/p5-Fuse > > > > > > VM images: > > > > > > http://ftp0.nyi.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/13.0-CURRENT/amd64/20190808/ > > > ISOs: > http://ftp0.nyi.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/13.0/ > > > > > > Thanks for any feedback you can give! > > > -Alan > > > ___ > > > 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" > > > ___ > 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: FUSE Call for Testing
NTFS-3G (sysutils/fusefs-ntfs) is probably the most widely used FUSE filesystem. On Fri, Aug 9, 2019 at 4:21 AM Clay Daniels Jr. wrote: > Alan, I'm pretty much into 13.0 Current and most weeks install the newest > snapshot build. I don't know if I use FUSE or not, if you must know the > truth. I do some hobby coding, lurk here on the email lists and Forum, and > try to learn all I can. So do you have any specific suggestions for > programs to install and test FUSE? I kind of like the no-x console & the > Xterminal window too, and dabble with clang cc (strictly C, no C++) and > Python too. Let me know. > > Clay Daniels > > On Thu, Aug 8, 2019 at 1:36 PM Alan Somers wrote: > > > The new FUSE driver has just landed in current. It raises the protocol > > level from 7.8 to 7.23, fixes many bugs, adds a test suite for the > > driver, and adds many new features. New features include: > > * Optional kernel-side permissions checks (-o default_permissions) > > * Implement VOP_MKNOD, VOP_BMAP, and VOP_ADVLOCK > > * Allow interrupting FUSE operations > > * Support named pipes and unix-domain sockets in fusefs file systems > > * Forward UTIME_NOW during utimensat(2) to the daemon > > * kqueue support for /dev/fuse > > * Allow updating mounts with "mount -u" > > * Allow exporting fusefs file systems over NFS > > * Server-initiated invalidation of the name cache or data cache > > * Respect RLIMIT_FSIZE > > * Try to support servers as old as protocol 7.4 > > > > Performance enhancements include: > > > > * Implement FUSE's FOPEN_KEEP_CACHE and FUSE_ASYNC_READ flags > > * Cache file attributes > > * Cache lookup entries, both positive and negative > > * Server-selectable cache modes: writethrough, writeback, or uncached > > * Write clustering > > * Readahead > > * Use counter(9) for statistical reporting > > > > Now would be a good time for the community to test it. If you are > > BCCed to this email, it's because you maintain a FUSE-related port. > > Please test your port on the latest FreeBSD CURRENT image and let me > > know if you have any problems or find any bugs. > > > > Even if you don't maintain a FUSE port, you can still help. If you > > use current and commonly use any FUSE file systems, please try them > > out after upgrading to the latest image. > > > > Additionally, the following FUSE-related ports don't have maintainers. > > If you use one of them, or know somebody who does, please test them on > > current, and consider adopting the port: > > deskutils/kdeconnect-kde > > devel/gvfs > > devel/py-fusefs > > sysutils/fusefs-afuse > > sysutils/fusefs-chironfs > > sysutils/fusefs-cryptofs > > sysutils/fusefs-funionfs > > sysutils/fusefs-fusepak > > sysutils/fusefs-httpfs > > sysutils/fusefs-s3backer > > sysutils/fusefs-sqlfs > > sysutils/fusefs-zip > > sysutils/p5-Brackup > > sysutils/p5-Fuse > > > > VM images: > > > http://ftp0.nyi.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/13.0-CURRENT/amd64/20190808/ > > ISOs: http://ftp0.nyi.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/13.0/ > > > > Thanks for any feedback you can give! > > -Alan > > ___ > > 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" > ___ 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: FUSE Call for Testing
Clay, Thanks for offering to help. If you don't know whether or not you're currently using FUSE, just do "pkg info -r fusefs-libs" and " pkg info -r fusefs-libs3". There are a few fuse ports that don't depend on either fusefs-libs or fusefs-libs3, but not many. If you don't find any, but want to play around anyway, then you can try installing something like fusefs-wikipediafs or fusefs-sshfs. The former lets you mount wikipedia as a file system, and the latter lets you view a remote server's file system via an SSH connection. -Alan On Thu, Aug 8, 2019 at 8:21 PM Clay Daniels Jr. wrote: > > Alan, I'm pretty much into 13.0 Current and most weeks install the newest > snapshot build. I don't know if I use FUSE or not, if you must know the > truth. I do some hobby coding, lurk here on the email lists and Forum, and > try to learn all I can. So do you have any specific suggestions for programs > to install and test FUSE? I kind of like the no-x console & the Xterminal > window too, and dabble with clang cc (strictly C, no C++) and Python too. Let > me know. > > Clay Daniels > > On Thu, Aug 8, 2019 at 1:36 PM Alan Somers wrote: >> >> The new FUSE driver has just landed in current. It raises the protocol >> level from 7.8 to 7.23, fixes many bugs, adds a test suite for the >> driver, and adds many new features. New features include: >> * Optional kernel-side permissions checks (-o default_permissions) >> * Implement VOP_MKNOD, VOP_BMAP, and VOP_ADVLOCK >> * Allow interrupting FUSE operations >> * Support named pipes and unix-domain sockets in fusefs file systems >> * Forward UTIME_NOW during utimensat(2) to the daemon >> * kqueue support for /dev/fuse >> * Allow updating mounts with "mount -u" >> * Allow exporting fusefs file systems over NFS >> * Server-initiated invalidation of the name cache or data cache >> * Respect RLIMIT_FSIZE >> * Try to support servers as old as protocol 7.4 >> >> Performance enhancements include: >> >> * Implement FUSE's FOPEN_KEEP_CACHE and FUSE_ASYNC_READ flags >> * Cache file attributes >> * Cache lookup entries, both positive and negative >> * Server-selectable cache modes: writethrough, writeback, or uncached >> * Write clustering >> * Readahead >> * Use counter(9) for statistical reporting >> >> Now would be a good time for the community to test it. If you are >> BCCed to this email, it's because you maintain a FUSE-related port. >> Please test your port on the latest FreeBSD CURRENT image and let me >> know if you have any problems or find any bugs. >> >> Even if you don't maintain a FUSE port, you can still help. If you >> use current and commonly use any FUSE file systems, please try them >> out after upgrading to the latest image. >> >> Additionally, the following FUSE-related ports don't have maintainers. >> If you use one of them, or know somebody who does, please test them on >> current, and consider adopting the port: >> deskutils/kdeconnect-kde >> devel/gvfs >> devel/py-fusefs >> sysutils/fusefs-afuse >> sysutils/fusefs-chironfs >> sysutils/fusefs-cryptofs >> sysutils/fusefs-funionfs >> sysutils/fusefs-fusepak >> sysutils/fusefs-httpfs >> sysutils/fusefs-s3backer >> sysutils/fusefs-sqlfs >> sysutils/fusefs-zip >> sysutils/p5-Brackup >> sysutils/p5-Fuse >> >> VM images: >> http://ftp0.nyi.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/13.0-CURRENT/amd64/20190808/ >> ISOs: http://ftp0.nyi.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/13.0/ >> >> Thanks for any feedback you can give! >> -Alan >> ___ >> 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: FUSE Call for Testing
Alan, I'm pretty much into 13.0 Current and most weeks install the newest snapshot build. I don't know if I use FUSE or not, if you must know the truth. I do some hobby coding, lurk here on the email lists and Forum, and try to learn all I can. So do you have any specific suggestions for programs to install and test FUSE? I kind of like the no-x console & the Xterminal window too, and dabble with clang cc (strictly C, no C++) and Python too. Let me know. Clay Daniels On Thu, Aug 8, 2019 at 1:36 PM Alan Somers wrote: > The new FUSE driver has just landed in current. It raises the protocol > level from 7.8 to 7.23, fixes many bugs, adds a test suite for the > driver, and adds many new features. New features include: > * Optional kernel-side permissions checks (-o default_permissions) > * Implement VOP_MKNOD, VOP_BMAP, and VOP_ADVLOCK > * Allow interrupting FUSE operations > * Support named pipes and unix-domain sockets in fusefs file systems > * Forward UTIME_NOW during utimensat(2) to the daemon > * kqueue support for /dev/fuse > * Allow updating mounts with "mount -u" > * Allow exporting fusefs file systems over NFS > * Server-initiated invalidation of the name cache or data cache > * Respect RLIMIT_FSIZE > * Try to support servers as old as protocol 7.4 > > Performance enhancements include: > > * Implement FUSE's FOPEN_KEEP_CACHE and FUSE_ASYNC_READ flags > * Cache file attributes > * Cache lookup entries, both positive and negative > * Server-selectable cache modes: writethrough, writeback, or uncached > * Write clustering > * Readahead > * Use counter(9) for statistical reporting > > Now would be a good time for the community to test it. If you are > BCCed to this email, it's because you maintain a FUSE-related port. > Please test your port on the latest FreeBSD CURRENT image and let me > know if you have any problems or find any bugs. > > Even if you don't maintain a FUSE port, you can still help. If you > use current and commonly use any FUSE file systems, please try them > out after upgrading to the latest image. > > Additionally, the following FUSE-related ports don't have maintainers. > If you use one of them, or know somebody who does, please test them on > current, and consider adopting the port: > deskutils/kdeconnect-kde > devel/gvfs > devel/py-fusefs > sysutils/fusefs-afuse > sysutils/fusefs-chironfs > sysutils/fusefs-cryptofs > sysutils/fusefs-funionfs > sysutils/fusefs-fusepak > sysutils/fusefs-httpfs > sysutils/fusefs-s3backer > sysutils/fusefs-sqlfs > sysutils/fusefs-zip > sysutils/p5-Brackup > sysutils/p5-Fuse > > VM images: > http://ftp0.nyi.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/13.0-CURRENT/amd64/20190808/ > ISOs: http://ftp0.nyi.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/13.0/ > > Thanks for any feedback you can give! > -Alan > ___ > 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: FUSE Call for Testing
On Thu, Aug 08, 2019 at 12:34:52PM -0600, Alan Somers wrote: > The new FUSE driver has just landed in current. It raises the protocol > level from 7.8 to 7.23, fixes many bugs, adds a test suite for the > driver, and adds many new features. New features include: Thanks for sharing your work! -- Steve ___ 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: kernel module code coverage
Read the bug report. I can't even load modules when I build with GCOV. On Thu, Aug 8, 2019 at 1:04 PM Matthew Macy wrote: > > The whole point of adding gcov support was for integrating with the > ZoL CI framework which does coverage. So it very much does work with > modules. Not sure where that comes from. > -M > > On Thu, Aug 8, 2019 at 6:52 AM Alan Somers wrote: > > > > On Thu, Aug 8, 2019 at 7:42 AM Michael Tuexen wrote: > > > > > > > > > > > > > On 8. Aug 2019, at 14:24, Slava Shwartsman wrote: > > > > > > > > Apparently, Bullseye are dropping support for FreeBSD. > > > > > > > > We are looking for an alternative for kernel module run time analysis. > > > > Mostly interested in code coverage (for now). > > > > > > > > Any suggestions that work for you? > > > Have you looked into /dev/kcov. This is used by SYZKALLER for getting > > > coverage information from the kernel. > > > > > > Best regards > > > Michael > > > > > > > > > > > > Slava > > > > That's part of Matt Macy's gcov project, right?. However, while it > > works for the kernel itself, it doesn't work for modules. > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239194 > > -Alan > > ___ > > 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"
FUSE Call for Testing
The new FUSE driver has just landed in current. It raises the protocol level from 7.8 to 7.23, fixes many bugs, adds a test suite for the driver, and adds many new features. New features include: * Optional kernel-side permissions checks (-o default_permissions) * Implement VOP_MKNOD, VOP_BMAP, and VOP_ADVLOCK * Allow interrupting FUSE operations * Support named pipes and unix-domain sockets in fusefs file systems * Forward UTIME_NOW during utimensat(2) to the daemon * kqueue support for /dev/fuse * Allow updating mounts with "mount -u" * Allow exporting fusefs file systems over NFS * Server-initiated invalidation of the name cache or data cache * Respect RLIMIT_FSIZE * Try to support servers as old as protocol 7.4 Performance enhancements include: * Implement FUSE's FOPEN_KEEP_CACHE and FUSE_ASYNC_READ flags * Cache file attributes * Cache lookup entries, both positive and negative * Server-selectable cache modes: writethrough, writeback, or uncached * Write clustering * Readahead * Use counter(9) for statistical reporting Now would be a good time for the community to test it. If you are BCCed to this email, it's because you maintain a FUSE-related port. Please test your port on the latest FreeBSD CURRENT image and let me know if you have any problems or find any bugs. Even if you don't maintain a FUSE port, you can still help. If you use current and commonly use any FUSE file systems, please try them out after upgrading to the latest image. Additionally, the following FUSE-related ports don't have maintainers. If you use one of them, or know somebody who does, please test them on current, and consider adopting the port: deskutils/kdeconnect-kde devel/gvfs devel/py-fusefs sysutils/fusefs-afuse sysutils/fusefs-chironfs sysutils/fusefs-cryptofs sysutils/fusefs-funionfs sysutils/fusefs-fusepak sysutils/fusefs-httpfs sysutils/fusefs-s3backer sysutils/fusefs-sqlfs sysutils/fusefs-zip sysutils/p5-Brackup sysutils/p5-Fuse VM images: http://ftp0.nyi.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/13.0-CURRENT/amd64/20190808/ ISOs: http://ftp0.nyi.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/13.0/ Thanks for any feedback you can give! -Alan ___ 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: kgdb assert while loading a kernel core
On 7/30/19 2:53 AM, weike.c...@dell.com wrote: > >> -Original Message- >> From: Cy Schubert >> Sent: Tuesday, July 30, 2019 3:49 AM >> To: Chen, Alvin W >> Cc: freebsd-current@freebsd.org >> Subject: Re: kgdb assert while loading a kernel core >> >> >> [EXTERNAL EMAIL] >> >> In message >> >> , Weike >> .c...@dell.com writes: >>> Hi all, >>> >>> I try to do some debugging for the FreeBSD kernel crash. >>> My system is FreeBSD 12. And I have a kernel core file, and while I >>> load it by kgdb. It reports the following error: >>> >>> Inferior.c: 287: internal-error: struct inferior >>> *find_inferior_pid(int): As sertion 'pid != 0' failed. >>> >>> And I also try the gdb in ports/devel, and got the same error. >>> >>> Any workaround for the error? >> >> Which kgdb are you using? The /usr/libexec one or the port? >> > I use the kgdb in port, and I also try the kgdb in /usr/libexec, but it > reports error "Cannot access memory at address 0x0" while loading my core > file. Usually this means that your vmcore file is not from the same kernel you are passing to kgdb. In the case of ports gdb the reason it crashes is that gdb is finding that the value of 'dumptid' from the vmcore is 0 and normally dumptid is the thread id of the thread that called panic. The reason it would be zero is if the vmcore doesn't match the kernel so the dumptid symbol is mapped to some other random place in the vmcore that happens to be zero. -- John Baldwin ___ 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: r350484 and ASLR enabled - init died (signal 6, exit 0)
On Thu, Aug 08, 2019 at 09:35:23AM +0300, Vladimir Zakharov wrote: > On Mon, Aug 05, 2019, Konstantin Belousov wrote: > > On Mon, Aug 05, 2019 at 08:10:43PM +0200, Trond Endrestøl wrote: > > > On Mon, 5 Aug 2019 06:02-0700, David Wolfskill wrote: > > > > > > > On Mon, Aug 05, 2019 at 02:53:04PM +0200, Trond Endrestøl wrote: > > > > > Hi, > > > > > > > > > > Has anyone else noticed the kernel being unable to spawn init lately? > > > > > > > > > > All I get is: > > > > > > > > > > init died (signal 6, exit 0) > > > > > panic: Going nowhere without my init! > > > > > > > Try r350608. There was a mis-merge in the committed patch (more serious > > part), and some limits were not applied, which I did not see in my > > testing due to the mismatch between stock FreeBSD and my testing > > environment. > > The issue persists still at r350713 on HP Probook after clean rebuild. > > root@# uname -a > FreeBSD vzakharov 13.0-CURRENT FreeBSD 13.0-CURRENT r350713 GENERIC-NODEBUG > amd64 > > root@# grep aslr /boot/loader.conf > #kern.elf32.aslr.enable=1 > #kern.elf64.aslr.enable=1 I was able to reproduce it, try r350758. ___ 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: kernel module code coverage
> On 8. Aug 2019, at 15:52, Alan Somers wrote: > > On Thu, Aug 8, 2019 at 7:42 AM Michael Tuexen wrote: >> >> >> >>> On 8. Aug 2019, at 14:24, Slava Shwartsman wrote: >>> >>> Apparently, Bullseye are dropping support for FreeBSD. >>> >>> We are looking for an alternative for kernel module run time analysis. >>> Mostly interested in code coverage (for now). >>> >>> Any suggestions that work for you? >> Have you looked into /dev/kcov. This is used by SYZKALLER for getting >> coverage information from the kernel. >> >> Best regards >> Michael >>> >>> >>> Slava > > That's part of Matt Macy's gcov project, right?. However, while it > works for the kernel itself, it doesn't work for modules. > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239194 > -Alan I think it came from Andrew... So you might assign the bug to him or at least get him in the loop. Best regards Michael ___ 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: kernel module code coverage
On 08-Aug-19 18:14, Michael Tuexen wrote: On 8. Aug 2019, at 16:16, Slava Shwartsman wrote: On 08-Aug-19 16:52, Alan Somers wrote: On Thu, Aug 8, 2019 at 7:42 AM Michael Tuexen wrote: On 8. Aug 2019, at 14:24, Slava Shwartsman wrote: Apparently, Bullseye are dropping support for FreeBSD. We are looking for an alternative for kernel module run time analysis. Mostly interested in code coverage (for now). Any suggestions that work for you? Have you looked into /dev/kcov. This is used by SYZKALLER for getting coverage information from the kernel. Thanks. Is there a man page for /dev/kcov? I don't think so. There was no man page in the commit which introduced the feature: https://svnweb.freebsd.org/base?view=revision&revision=342962 You might want to look at: https://github.com/google/syzkaller/blob/master/tools/kcovtrace/kcovtrace.c how to use it. Best regards Michael Best regards Michael Slava That's part of Matt Macy's gcov project, right?. However, while it works for the kernel itself, it doesn't work for modules. In worst case, I can build my module into the kernel, right? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239194 -Alan Slava Thanks Michael and Alan. Slava ___ 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: kernel module code coverage
> On 8. Aug 2019, at 16:16, Slava Shwartsman wrote: > > > > On 08-Aug-19 16:52, Alan Somers wrote: >> On Thu, Aug 8, 2019 at 7:42 AM Michael Tuexen wrote: >>> >>> >>> On 8. Aug 2019, at 14:24, Slava Shwartsman wrote: Apparently, Bullseye are dropping support for FreeBSD. We are looking for an alternative for kernel module run time analysis. Mostly interested in code coverage (for now). Any suggestions that work for you? >>> Have you looked into /dev/kcov. This is used by SYZKALLER for getting >>> coverage information from the kernel. >>> > > Thanks. > Is there a man page for /dev/kcov? I don't think so. There was no man page in the commit which introduced the feature: https://svnweb.freebsd.org/base?view=revision&revision=342962 You might want to look at: https://github.com/google/syzkaller/blob/master/tools/kcovtrace/kcovtrace.c how to use it. Best regards Michael > >>> Best regards >>> Michael Slava >> That's part of Matt Macy's gcov project, right?. However, while it >> works for the kernel itself, it doesn't work for modules. > > In worst case, I can build my module into the kernel, right? > >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239194 >> -Alan > > > Slava ___ 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: kernel module code coverage
On 08-Aug-19 16:52, Alan Somers wrote: On Thu, Aug 8, 2019 at 7:42 AM Michael Tuexen wrote: On 8. Aug 2019, at 14:24, Slava Shwartsman wrote: Apparently, Bullseye are dropping support for FreeBSD. We are looking for an alternative for kernel module run time analysis. Mostly interested in code coverage (for now). Any suggestions that work for you? Have you looked into /dev/kcov. This is used by SYZKALLER for getting coverage information from the kernel. Thanks. Is there a man page for /dev/kcov? Best regards Michael Slava That's part of Matt Macy's gcov project, right?. However, while it works for the kernel itself, it doesn't work for modules. In worst case, I can build my module into the kernel, right? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239194 -Alan Slava ___ 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: kernel module code coverage
On Thu, Aug 8, 2019 at 7:42 AM Michael Tuexen wrote: > > > > > On 8. Aug 2019, at 14:24, Slava Shwartsman wrote: > > > > Apparently, Bullseye are dropping support for FreeBSD. > > > > We are looking for an alternative for kernel module run time analysis. > > Mostly interested in code coverage (for now). > > > > Any suggestions that work for you? > Have you looked into /dev/kcov. This is used by SYZKALLER for getting > coverage information from the kernel. > > Best regards > Michael > > > > > > Slava That's part of Matt Macy's gcov project, right?. However, while it works for the kernel itself, it doesn't work for modules. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239194 -Alan ___ 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: kernel module code coverage
> On 8. Aug 2019, at 14:24, Slava Shwartsman wrote: > > Apparently, Bullseye are dropping support for FreeBSD. > > We are looking for an alternative for kernel module run time analysis. > Mostly interested in code coverage (for now). > > Any suggestions that work for you? Have you looked into /dev/kcov. This is used by SYZKALLER for getting coverage information from the kernel. Best regards Michael > > > Slava > ___ > 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: kernel module code coverage
In message , Slava Shwartsman writes: >Apparently, Bullseye are dropping support for FreeBSD. > >We are looking for an alternative for kernel module run time analysis. >Mostly interested in code coverage (for now). > >Any suggestions that work for you? Back in early days, I fixed it so that all the BB-counter blocks in the kernel were linked into a list which could be read out through /dev/(k)mem, and I belive I added a program to do that, named something like "kernbb". Today I would probably have made a subtree under sysctl where the counters could be pulled out per source-file... -- 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"
kernel module code coverage
Apparently, Bullseye are dropping support for FreeBSD. We are looking for an alternative for kernel module run time analysis. Mostly interested in code coverage (for now). Any suggestions that work for you? Slava ___ 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"
