[Bug 227603] [panic] r323477: Sleeping thread owns a non-sleepable lock

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227603

Eugene Grosbein  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|In Progress |Closed

--- Comment #5 from Eugene Grosbein  ---
(In reply to Stephen Hurd from comment #4)

No problems at all with r332734 applied. Thank you!

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[Bug 227603] [panic] r323477: Sleeping thread owns a non-sleepable lock

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227603

--- Comment #4 from Stephen Hurd  ---
How's it looking?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: gptboot broken when compiled with clang 6 and WITHOUT_LOADER_GELI -- clang 5 is OK

[Lowell Gilbert]

Dimitry Andric  writes:

> On 26 Apr 2018, at 12:06, Dimitry Andric  wrote:
>> 
>> On 26 Apr 2018, at 06:17, Dewayne Geraghty 
>>  wrote:
>>> 
>>> Andre, You're not alone.  I think there's a problem with clang6 on i386
>>> FreeBSD 11.1X, refer:
>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227552
>>> https://forums.freebsd.org/threads/uptime-w-i386-breakage.65584/
>>> and perhaps also on amd64, search for
>>> https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=clang_id=226390.
>>> 
>>> Without time to investigate I've reverted userland
>>> FreeBSD 11.2-PRERELEASE  r332843Mamd64 1101515 1101509
>>> FreeBSD 11.2-PRERELEASE  r332843Mi386 1101515 1101509
>> 
>> As noted in another post, I cannot reproduce the problems with gptboot,
>> but with FreeBSD-11.2-PRERELEASE-i386-20180420-r332802, I do indeed see
>> w and uptime crashing in libxo:
>> 
>> (gdb) bt
>> #0  ifree (tsd=0x2800) at arena.h:799
>> #1  0x2814b506 in __free (ptr=0x280601ef) at tsd.h:716
>> #2  0x2808bb07 in xo_do_emit_fields () at 
>> /usr/src/contrib/libxo/libxo/libxo.c:6419
>> #3 0x28089a1c in xo_do_emit (xop=, flags=> optimized out>, fmt=0x804ad4d "{:time-of-day/%s} ") at
>> /usr/src/contrib/libxo/libxo/libxo.c:6470
>> #4  0x28089b61 in xo_emit (fmt=0x804ad4d "{:time-of-day/%s} ") at 
>> /usr/src/contrib/libxo/libxo/libxo.c:6541
>> #5  0x08049f50 in main (argc=, argv=> out>) at /usr/src/usr.bin/w/w.c:475
>> #6  0x080494cd in _start1 ()
>> #7  0x08049448 in _start ()
>> #8  0x in ?? ()
>> 
>> Not sure if this has anything to do with clang though, it looks more
>> like a double free to me, at first glance.  I'll do some debugging.
>
> Strangely, simply recompiling libxo fixes the problem, or at least works
> around it.  This is on the r332802 snapshot, so I guess the libxo.so.0
> file shipped may be broken, somehow.

Actually, that is a recurring bug
(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227552)
and does seem to be some kind of initialization problem with clang.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: clear old pools remains from active vdevs

[Andriy Gapon]

On 26/04/2018 18:14, Alan Somers wrote:
> On Thu, Apr 26, 2018 at 8:37 AM, Eugene Grosbein  > wrote:
> 
> 26.04.2018 14:50, Andriy Gapon wrote:
> 
> > You can try to use zdb -l to find the stale labels.
> > And then zpool labelclear to clear them.
> 
> Our "zpool labelclear" implementation destroys everything (literally).
> Have you really tried it?

> 
> 
> "zpool labelclear" won't help in this case, because you have literally no
> devices with active labels.  The problem is that the pool is still in your
> /boot/zfs/zpool.cache file.  I think that plain "zpool destroy esx" will work 
> in
> this case.


In the original message Eugene (Zheganin) mentioned that those phantom pools
confused the boot chain.  I do not think that anything in zpool.cache can do 
that.

-- 
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: clear old pools remains from active vdevs

[Andriy Gapon]

On 26/04/2018 17:37, Eugene Grosbein wrote:
> 26.04.2018 14:50, Andriy Gapon wrote:
> 
>> You can try to use zdb -l to find the stale labels.
>> And then zpool labelclear to clear them.
> 
> Our "zpool labelclear" implementation destroys everything (literally).
> Have you really tried it?
> 

I have never needed it, so I have never used it.

-- 
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: clear old pools remains from active vdevs

[Alan Somers]

On Thu, Apr 26, 2018 at 8:37 AM, Eugene Grosbein  wrote:

> 26.04.2018 14:50, Andriy Gapon wrote:
>
> > You can try to use zdb -l to find the stale labels.
> > And then zpool labelclear to clear them.
>
> Our "zpool labelclear" implementation destroys everything (literally).
> Have you really tried it?
>
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>

"zpool labelclear" won't help in this case, because you have literally no
devices with active labels.  The problem is that the pool is still in your
/boot/zfs/zpool.cache file.  I think that plain "zpool destroy esx" will
work in this case.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: clear old pools remains from active vdevs

[Eugene Grosbein]

26.04.2018 14:50, Andriy Gapon wrote:

> You can try to use zdb -l to find the stale labels.
> And then zpool labelclear to clear them.

Our "zpool labelclear" implementation destroys everything (literally).
Have you really tried it?

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: gptboot broken when compiled with clang 6 and WITHOUT_LOADER_GELI -- clang 5 is OK

[Dimitry Andric]

On 26 Apr 2018, at 12:06, Dimitry Andric  wrote:
> 
> On 26 Apr 2018, at 06:17, Dewayne Geraghty 
>  wrote:
>> 
>> Andre, You're not alone.  I think there's a problem with clang6 on i386
>> FreeBSD 11.1X, refer:
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227552
>> https://forums.freebsd.org/threads/uptime-w-i386-breakage.65584/
>> and perhaps also on amd64, search for
>> https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=clang_id=226390.
>> 
>> Without time to investigate I've reverted userland
>> FreeBSD 11.2-PRERELEASE  r332843Mamd64 1101515 1101509
>> FreeBSD 11.2-PRERELEASE  r332843Mi386 1101515 1101509
> 
> As noted in another post, I cannot reproduce the problems with gptboot,
> but with FreeBSD-11.2-PRERELEASE-i386-20180420-r332802, I do indeed see
> w and uptime crashing in libxo:
> 
> (gdb) bt
> #0  ifree (tsd=0x2800) at arena.h:799
> #1  0x2814b506 in __free (ptr=0x280601ef) at tsd.h:716
> #2  0x2808bb07 in xo_do_emit_fields () at 
> /usr/src/contrib/libxo/libxo/libxo.c:6419
> #3  0x28089a1c in xo_do_emit (xop=, flags= optimized out>, fmt=0x804ad4d "{:time-of-day/%s} ") at 
> /usr/src/contrib/libxo/libxo/libxo.c:6470
> #4  0x28089b61 in xo_emit (fmt=0x804ad4d "{:time-of-day/%s} ") at 
> /usr/src/contrib/libxo/libxo/libxo.c:6541
> #5  0x08049f50 in main (argc=, argv= out>) at /usr/src/usr.bin/w/w.c:475
> #6  0x080494cd in _start1 ()
> #7  0x08049448 in _start ()
> #8  0x in ?? ()
> 
> Not sure if this has anything to do with clang though, it looks more
> like a double free to me, at first glance.  I'll do some debugging.

Strangely, simply recompiling libxo fixes the problem, or at least works
around it.  This is on the r332802 snapshot, so I guess the libxo.so.0
file shipped may be broken, somehow.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: gptboot broken when compiled with clang 6 and WITHOUT_LOADER_GELI -- clang 5 is OK

[Dimitry Andric]

On 26 Apr 2018, at 06:17, Dewayne Geraghty 
 wrote:
> 
> Andre, You're not alone.  I think there's a problem with clang6 on i386
> FreeBSD 11.1X, refer:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227552
> https://forums.freebsd.org/threads/uptime-w-i386-breakage.65584/
> and perhaps also on amd64, search for
> https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=clang_id=226390.
> 
> Without time to investigate I've reverted userland
> FreeBSD 11.2-PRERELEASE  r332843Mamd64 1101515 1101509
> FreeBSD 11.2-PRERELEASE  r332843Mi386 1101515 1101509

As noted in another post, I cannot reproduce the problems with gptboot,
but with FreeBSD-11.2-PRERELEASE-i386-20180420-r332802, I do indeed see
w and uptime crashing in libxo:

(gdb) bt
#0  ifree (tsd=0x2800) at arena.h:799
#1  0x2814b506 in __free (ptr=0x280601ef) at tsd.h:716
#2  0x2808bb07 in xo_do_emit_fields () at 
/usr/src/contrib/libxo/libxo/libxo.c:6419
#3  0x28089a1c in xo_do_emit (xop=, flags=, fmt=0x804ad4d "{:time-of-day/%s} ") at 
/usr/src/contrib/libxo/libxo/libxo.c:6470
#4  0x28089b61 in xo_emit (fmt=0x804ad4d "{:time-of-day/%s} ") at 
/usr/src/contrib/libxo/libxo/libxo.c:6541
#5  0x08049f50 in main (argc=, argv=) 
at /usr/src/usr.bin/w/w.c:475
#6  0x080494cd in _start1 ()
#7  0x08049448 in _start ()
#8  0x in ?? ()

Not sure if this has anything to do with clang though, it looks more
like a double free to me, at first glance.  I'll do some debugging.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: gptboot broken when compiled with clang 6 and WITHOUT_LOADER_GELI -- clang 5 is OK

[Dimitry Andric]

On 25 Apr 2018, at 18:58, Andre Albsmeier  wrote:
> 
> I have set up a new system disk for an i386 11.2-PRERELEASE box. I did the
> usual
> 
> gpart create -s gpt $disk
> gpart add -t freebsd-boot -s 984 $disk
> gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 $disk
> ...
> 
> thing, just to notice that the box wouldn't boot. It seems to hang where
> stage 2 should be run -- when the '\' should start spinning the screen
> turns white and the box hangs (tested on two machines, an Asus P5W and a
> Supermicro A2SAV).
> 
> So I replaced gptboot on the new disk by the one from an older machine
> and everything was fine. I wanted to find out what is actually causing
> the issue and recompiled /usr/src/stand after updating the old sources
> in several steps.
> 
> Eventually it turned out that it depends on the compiler. When compiling
> the latest /usr/src/stand with clang 5.0.1 the resulting gptboot works.
> When using 6.0.0 it doesn't. To be exact, it's gptboot.o which is causing
> the problems. When using a gptboot.o from a clang 5 system it is OK, when
> using a gptboot.o from a clang 6 system it fails.
> 
> To add more confusion: I usually have WITHOUT_LOADER_GELI in my make.conf.
> When removing this, the resulting gptboot works even when compiled with
> clang 6...
> 
> I can reproduce this in case s.o. wants me to do some tests...

I can't reproduce it on my end, unfortunately.  I downloaded the latest
FreeBSD-11.2-PRERELEASE-i386-20180420-r332802 snapshot, installed it to
a GPT partitioned disk, and it boots just fine.

This snapshot corresponds to r332802, which has clang 6.0.0, with the
EFLAGS change still reverted, so I assume its copy of gptboot is also
compiled with that.

Which exact revision of the base system were you using?

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: clear old pools remains from active vdevs

[Andriy Gapon]

On 26/04/2018 10:28, Eugene M. Zheganin wrote:
> Hello,
> 
> 
> I have some active vdev disk members that used to be in pool that clearly have
> not beed destroyed properly, so I'm seeing in a "zpool import" output 
> something
> like
> 
> 
> # zpool import
>    pool: zroot
>  id: 14767697319309030904
>   state: UNAVAIL
>  status: The pool was last accessed by another system.
>  action: The pool cannot be imported due to damaged devices or data.
>    see: http://illumos.org/msg/ZFS-8000-EY
>  config:
> 
>     zroot    UNAVAIL  insufficient replicas
>   mirror-0   UNAVAIL  insufficient replicas
>     5291726022575795110  UNAVAIL  cannot open
>     2933754417879630350  UNAVAIL  cannot open
> 
>    pool: esx
>  id: 8314148521324214892
>   state: UNAVAIL
>  status: The pool was last accessed by another system.
>  action: The pool cannot be imported due to damaged devices or data.
>    see: http://illumos.org/msg/ZFS-8000-EY
>  config:
> 
>     esx   UNAVAIL  insufficient replicas
>   mirror-0    UNAVAIL  insufficient replicas
>     10170732803757341731  UNAVAIL  cannot open
>     9207269511643803468   UNAVAIL  cannot open
> 
> 
> is there any _safe_ way to get rid of this ? I'm asking because a gptzfsboot
> loader in recent -STABLE stumbles upon this and refuses to boot the system
> (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227772). The workaround is 
> to
> use the 11.1 loader, but I'm afraid this behavior will now be the intended 
> one.

You can try to use zdb -l to find the stale labels.
And then zpool labelclear to clear them.


-- 
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

clear old pools remains from active vdevs

[Eugene M. Zheganin]

Hello,


I have some active vdev disk members that used to be in pool that 
clearly have not beed destroyed properly, so I'm seeing in a "zpool 
import" output something like



# zpool import
   pool: zroot
 id: 14767697319309030904
  state: UNAVAIL
 status: The pool was last accessed by another system.
 action: The pool cannot be imported due to damaged devices or data.
   see: http://illumos.org/msg/ZFS-8000-EY
 config:

zrootUNAVAIL  insufficient replicas
  mirror-0   UNAVAIL  insufficient replicas
5291726022575795110  UNAVAIL  cannot open
2933754417879630350  UNAVAIL  cannot open

   pool: esx
 id: 8314148521324214892
  state: UNAVAIL
 status: The pool was last accessed by another system.
 action: The pool cannot be imported due to damaged devices or data.
   see: http://illumos.org/msg/ZFS-8000-EY
 config:

esx   UNAVAIL  insufficient replicas
  mirror-0UNAVAIL  insufficient replicas
10170732803757341731  UNAVAIL  cannot open
9207269511643803468   UNAVAIL  cannot open


is there any _safe_ way to get rid of this ? I'm asking because a 
gptzfsboot loader in recent -STABLE stumbles upon this and refuses to 
boot the system 
(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227772). The 
workaround is to use the 11.1 loader, but I'm afraid this behavior will 
now be the intended one.



Eugene.

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"