zpool export: umount failed, device inexplicably busy
lsof finds no open file. How else might I tell why the device is busy? Mobile hard disk drive, USB. -- root@momh167-gjp4-8570p:~ # zpool export Transcend cannot unmount '/Volumes/t500': umount failed root@momh167-gjp4-8570p:~ # lsof /Volumes/t500 root@momh167-gjp4-8570p:~ # zpool export Transcend cannot unmount '/Volumes/t500': umount failed root@momh167-gjp4-8570p:~ # zpool export Transcend cannot unmount '/Volumes/t500': umount failed root@momh167-gjp4-8570p:~ # umount /Volumes/t500/ umount: unmount of /Volumes/t500 failed: Device busy root@momh167-gjp4-8570p:~ # lsof /Volumes/t500 root@momh167-gjp4-8570p:~ # zfs version zfs-0.8.0-1 zfs-kmod-0.8.0-1 root@momh167-gjp4-8570p:~ # zpool iostat Transcend 3 capacity operations bandwidth pool alloc free read write read write -- - - - - - - Transcend 126G 338G 0 0 3.29K 1.45K Transcend 126G 338G 0 0 0 0 Transcend 126G 338G 0 0 0 0 Transcend 126G 338G 0 0 0 0 Transcend 126G 338G 0 0 0 0 Transcend 126G 338G 0 0 0 0 ^C root@momh167-gjp4-8570p:~ # umount /Volumes/t500/ umount: unmount of /Volumes/t500 failed: Device busy root@momh167-gjp4-8570p:~ # ls -ahl /Volumes/t500 total 10 drwxr-xr-x 3 root wheel 3B Sep 2 19:02 . drwxr-xr-x 4 root wheel 4B Sep 5 09:15 .. drwxr-xr-x 6 grahamperrin grahamperrin 6B Sep 11 17:54 VirtualBox root@momh167-gjp4-8570p:~ # zpool status Transcend pool: Transcend state: ONLINE scan: scrub repaired 0B in 00:28:07 with 0 errors on Tue Oct 6 00:03:13 2020 config: NAME STATE READ WRITE CKSUM Transcend ONLINE 0 0 0 da0p1 ONLINE 0 0 0 errors: No known data errors root@momh167-gjp4-8570p:~ # umount /Volumes/t500/ umount: unmount of /Volumes/t500 failed: Device busy root@momh167-gjp4-8570p:~ # lsof /Volumes/t500 root@momh167-gjp4-8570p:~ # date ; uname -v Tue Oct 6 21:20:17 BST 2020 FreeBSD 13.0-CURRENT #67 r366424: Sun Oct 4 19:54:32 BST 2020 root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG root@momh167-gjp4-8570p:~ # ls /dev/da* /dev/da0 /dev/da0p1 root@momh167-gjp4-8570p:~ # zfs get all Transcend Transcend/VirtualBox NAME PROPERTY VALUE SOURCE Transcend type filesystem - Transcend creation Wed Sep 2 18:31 2020 - Transcend used 126G - Transcend available 324G - Transcend referenced 126G - Transcend compressratio 1.66x - Transcend mounted yes - Transcend quota none default Transcend reservation none default Transcend recordsize 128K default Transcend mountpoint /Volumes/t500 local Transcend sharenfs off default Transcend checksum on default Transcend compression zstd local Transcend atime on default Transcend devices on default Transcend exec on default Transcend setuid on default Transcend readonly off default Transcend jailed off default Transcend snapdir hidden default Transcend aclmode discard default Transcend aclinherit restricted default Transcend createtxg 1 - Transcend canmount on default Transcend xattr on default Transcend copies 1 default Transcend version 5 - Transcend utf8only off - Transcend normalization none - Transcend casesensitivity sensitive - Transcend vscan off default Transcend nbmand off default Transcend sharesmb off default Transcend refquota none default Transcend refreservation none default Transcend guid 6806553549477274436 - Transcend primarycache all default Transcend secondarycache all default Transcend usedbysnapshots 0B
Re: Please check the current beta git conversions
Ulrich Spörlein wrote in : |On Mon, Oct 5, 2020 at 7:21 PM Steffen Nurpmeso wrote: |> Ulrich Spörlein wrote in |> : |>|On Sun, Oct 4, 2020 at 1:53 AM Bakul Shah wrote: |>|> git clone --bare https://cgit-beta.freebsd.org/src.git |>|> cd src.git |>|> git fetch origin 'refs/notes/*:refs/notes/origin/*' # <<< not sure ... |>|This is a quirk of the conversion. We have to patch up several tags |>|post-conversion, which patches up their notes, but that happens after the |>|full conversion is done. Notes are just 1 long linear branch, which ... |>|well, is unfortunate. So essentially every update to the repo changes the |>|last couple hundred of hashes for the commit notes ... |>|This will all cease with the final transition, obviously. |> |> I guess they will simply vanish and i could remove the reference |> from my config already today? |> |They will not vanish. They are there to map git commits back to SVN |revisions. |What will change is that they'll never change again and are just a static, |eternal record |of that mapping. | |Of course, freebsd committers can then in the future push their own notes |(but not force-push them) , but it's not clear what you would want to put |into them? | |If you don't have a need to ever map git <-> svn commits, then you don't |need to fetch |them indeed. Fantastic! Sure thing if FreeBSD moves over to git as such. Thank you. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ 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: iflib/bridge kernel panic
On Tue, Sep 29, 2020 at 05:36:15PM -0400, Shawn Webb wrote:
> On Tue, Sep 29, 2020 at 11:20:44PM +0200, Kristof Provost wrote:
> >
> >
> > On 28 Sep 2020, at 16:44, Alexander Leidinger wrote:
> >
> > > Quoting Kristof Provost (from Mon, 28 Sep 2020 13:53:16
> > > +0200):
> > >
> > > > On 28 Sep 2020, at 12:45, Alexander Leidinger wrote:
> > > > > Quoting Kristof Provost (from Sun, 27 Sep 2020
> > > > > 17:51:32 +0200):
> > > > > > Here???s an early version of a task queue based approach:
> > > > > > http://people.freebsd.org/~kp/0001-bridge-Cope-with-if_ioctl-s-that-sleep.patch
> > > > > >
> > > > > > That still needs to be cleaned up, but this should resolve
> > > > > > the sleep issue and the LOR.
> > > > >
> > > > > There are some issues... seems like inside a jail I can't ping
> > > > > systems outside of the hardware.
> > > > >
> > > > > Bridge setup:
> > > > >- member jail A
> > > > >- member jail B
> > > > >- member external_if of host
> > > > >
> > > > > If I ping the router from the host, it works. If I ping from one
> > > > > jail to another, it works. If I ping from the jail to the IP of
> > > > > the external_if, it works. If I ping from a jail to the router,
> > > > > I do not get a response.
> > > > >
> > > > Can you check for 'failed ifpromisc' error messages in dmesg? And
> > > > verify that all bridge member interfaces are in promiscuous mode?
> > >
> > > I have a panic for you...:
> > > - startup still in progress = 22 jails in startup, somewhere after a
> > > few jails started the panic happened
> > > - tcpdump was running on the external interface
> > > - a ping to a jail IP from another system was running, the first ping
> > > went through, then it paniced
> > >
> > > First regarding your questions about promisc mode: no error, but the
> > > promisc mode is directly disabled again on all interfaces.
> > >
> > I think I see why you had issues with the promiscuous setting. I???ve
> > updated the patch to be even more horrific than it was before.
> >
> > I can???t explain the panic, and the backtrace also doesn???t appear to be
> > directly related to this patch. Not sure what???s going on with that.
>
> I should have time to test the new patch this weekend. ${LIFE} is
> keeping me busy the past few weeks. I'm gonna add an event in my
> calendar to remind me to test the patch. heh.
Sorry for the delay. I rebuilt with the new patch this morning.
Looking good on all fronts, including LORs.
Thanks,
--
Shawn Webb
Cofounder / Security Engineer
HardenedBSD
GPG Key ID: 0xFF2E67A277F8E1FA
GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2
https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
signature.asc
Description: PGP signature
Re: panic: non-current pmap 0xffffa00020eab8f0 on Rpi3
On Mon, Oct 05, 2020 at 07:10:29PM -0700, bob prohaska wrote: > Still seeing non-current pmap panics on the Pi3, this time a B+ running > 13.0-CURRENT (GENERIC-MMCCAM) #0 71e02448ffb-c271826(master) > during a -j4 buildworld. The backtrace reports > > panic: non-current pmap 0xa00020eab8f0 Could you show the output of "show procvm" from the debugger? ___ 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: Please check the current beta git conversions
On Mon, Oct 5, 2020 at 7:21 PM Steffen Nurpmeso wrote: > Ulrich Spörlein wrote in > : > |On Sun, Oct 4, 2020 at 1:53 AM Bakul Shah wrote: > |> git clone --bare https://cgit-beta.freebsd.org/src.git > |> cd src.git > |> git fetch origin 'refs/notes/*:refs/notes/origin/*' # <<< not sure > about > |> this > |> # don't recall if I manually added the second fetch line in the > |> config file. > |> # but notes get fetched fine; though I don't understand why \ > |> 100MB+ > |> get > |> # downloaded every time even though only a few files change. > | > |This is a quirk of the conversion. We have to patch up several tags > |post-conversion, which patches up their notes, but that happens after the > |full conversion is done. Notes are just 1 long linear branch, which ... > |well, is unfortunate. So essentially every update to the repo changes the > |last couple hundred of hashes for the commit notes > objects/tree/DAG/linear > |train. They always need to get force-pushed upstream and you always have > to > |re-fetch quite a bunch of them. > > I was astonished to see third-to-last commit on my notes is from > Dag-Erling Smørgrav "+svn path=/vendor-crypto/openssh/5.8p2/; > revision=221485; tag=vendor/openssh/5.8p2". > > |This will all cease with the final transition, obviously. > > I guess they will simply vanish and i could remove the reference > from my config already today? > > They will not vanish. They are there to map git commits back to SVN revisions. What will change is that they'll never change again and are just a static, eternal record of that mapping. Of course, freebsd committers can then in the future push their own notes (but not force-push them) , but it's not clear what you would want to put into them? If you don't have a need to ever map git <-> svn commits, then you don't need to fetch them indeed. hth Uli ___ 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"
