Re: wlan can't discover known networks after relocating

2019-09-17 Thread Poul-Henning Kamp 

In message <707bcd3f-fa6b-82eb-fa8f-09c4b800f...@freebsd.org>, Johannes Lundber
g writes:

>For a long time now I have had this problem with iwm and wlan0. Whenever
>I move between work and home it won't reconnect automatically and I have
>to do wlan0 scan manually for it to pick up the different network.

I suffer from the dreaded "reason=0" when I move inside my house:

> scan
OK
<3>CTRL-EVENT-SCAN-RESULTS 
<3>Trying to associate with 6c:3b:6b:3d:a2:e9 (SSID='Palombia' 
freq=2452 MHz)
<3>CTRL-EVENT-DISCONNECTED bssid=6c:3b:6b:3d:a2:e9 reason=0
<3>CTRL-EVENT-SCAN-RESULTS 
<3>Trying to associate with 6c:3b:6b:ab:ce:d4 (SSID='Palombia' 
freq=2412 MHz)
<3>Associated with 6c:3b:6b:ab:ce:d4

a2:e9 is the loudest AP here in my office, but my I have been in the
other end of the house iwn consistently fails to associate with it and
and keeps picking the weaker AP in the far end.

Eventually (hours!) it disconnects from the weaker ap, also with
"reason=0" and gets it right:

<3>WPA: Group rekeying completed with 6c:3b:6b:ab:ce:d4 [GTK=CCMP]
<3>CTRL-EVENT-DISCONNECTED bssid=6c:3b:6b:ab:ce:d4 reason=0
<3>CTRL-EVENT-SCAN-RESULTS 
<3>Trying to associate with 6c:3b:6b:3d:a2:e9 (SSID='Palombia' 
freq=2452 MHz)
<3>Associated with 6c:3b:6b:3d:a2:e9
<3>WPA: Key negotiation completed with 6c:3b:6b:3d:a2:e9 [PTK=CCMP 
GTK=CCMP]
<3>CTRL-EVENT-CONNECTED - Connection to 6c:3b:6b:3d:a2:e9 completed 
[id=3 id_str=]
<3>WPA: Group rekeying completed with 6c:3b:6b:3d:a2:e9 [GTK=CCMP]

And yes, working roaming would be nice too...

-- 
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"

wlan can't discover known networks after relocating

2019-09-17 Thread Johannes Lundberg 
Hi

For a long time now I have had this problem with iwm and wlan0. Whenever
I move between work and home it won't reconnect automatically and I have
to do wlan0 scan manually for it to pick up the different network.

Anyone have a solution for this? For now I think I'll put a 'ifconfig
wlan0 scan' in crontab to run every minute.

Dell laptop, 13-CURRENT, always fairly recent.

Also, I'm using lagg wifi failover but I'm pretty sure it's the same if
I configure only wifi.

Cheers!



___
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: hang up with r352239 and r352386 with i5-7500

2019-09-17 Thread Masachika ISHIZUKA 
>> >>> Can you please use absolute paths to i915kms.ko anyway, just to test?
>> >>The same hang up occure with kld_list="/boot/modules/i915kms.ko"
>> >> in /etc/rc.conf.
>> >> 
>> > 
>> > Even after applying the patch I suggested?
>> 
>>   Yes.
>> 
>>   kld_list="/boot/modules/drm.ko /boot/modules/i915kms.ko"
>> will hang as well.
>> 
>> /boot/modules/{drm,i915kms}.ko is patched modules.
>> 
>> # /boot/kernel.r352239/{drm,i915kms}.ko is not patched.
> 
> Are you able to collect a kernel dump?  If so, remove the kld_list
> setting and set debug.debugger_on_panic=0 and dev.drm.skip_ddb=1.  Then
> manually kldload /boot/modules/i915kms.ko.  If you are running an
> INVARIANTS kernel you might be hitting an assertion failure; having the
> vmcore would help us debug.

  Thank you for mail.

  As I'm busy now, I'll try to get kernel dump about 1 day after.
-- 
Masachika ISHIZUKA
___
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: sleeping thread on r352386

2019-09-17 Thread Masachika ISHIZUKA 
>> >Try the following change, which more accurately tries to avoid
>> >vnode_pager_setsize().  The real cause requires much more extensive
>> >changes.
>> >
>> >diff --git a/sys/fs/nfsclient/nfs_clport.c b/sys/fs/nfsclient/nfs_clport.c
>> >index 63ea4736707..16dc7745c77 100644
>> >--- a/sys/fs/nfsclient/nfs_clport.c
>> >+++ b/sys/fs/nfsclient/nfs_clport.c
>> ...
>> 
>> With that patch, I'm back to "Sleeping thread (...) owns a non-sleepable
>> lock" panics.
> 
> Try this.
> 
> diff --git a/sys/fs/nfsclient/nfs_clport.c b/sys/fs/nfsclient/nfs_clport.c
> index 63ea4736707..a23b4ba4efa 100644

  Thank you for new patch.

  It seems that this patch works fine.
  I patched to r352432(src) and 'make buildkernel && make installkernel
&& reboot' on r351728(kernel)/r352432(user land). After that,
'make -j4 buildworld && make -j4 buildkernel' on r352432M(patched kernel)/
r352432(user land) with the nfs file system was done successfully.
-- 
Masachika ISHIZUKA
___
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 CI Weekly Report 2019-09-15

2019-09-17 Thread Li-Wen Hsu 
(Please send the followup to freebsd-testing@ and note Reply-To is set.)

FreeBSD CI Weekly Report 2019-09-15
===

Here is a summary of the FreeBSD Continuous Integration results for the period
from 2019-09-09 to 2019-09-15.

During this period, we have:

* 2095 builds (95.3% (-4.1) passed, 4.7% (+4.1) failed) were executed on
  aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64,
  powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11
  branches.
* 358 test runs (58.4% (-1.2) passed, 31.0% (-8.1) unstable, 10.6% (+9.3)
  exception) were executed on amd64, i386, riscv64 architectures for head,
  stable/12, stable/11 branches.
* 32 doc builds (100% (0) passed)

Test case status (on 2019-09-15 23:59):
| Branch/Architecture | Total  | Pass   | Fail| Skipped |
| --- | -- | -- | --- | --- |
| head/amd64  | 7563 (+7)  | 7501 (+6)  | 0 (0)   | 62 (+1) |
| head/i386   | 7561 (+7)  | 7490 (+6)  | 2 (0)   | 69 (+1) |
| 12-STABLE/amd64 | 7433 (+40) | 7389 (+48) | 0 (-11) | 44 (+3) |
| 12-STABLE/i386  | 7431 (+40) | 7380 (+51) | 0 (-11) | 51 (0)  |
| 11-STABLE/amd64 | 6846 (0)   | 6802 (0)   | 0 (0)   | 44 (0)  |
| 11-STABLE/i386  | 6844 (0)   | 6767 (0)   | 34 (0)  | 43 (0)  |

(The statistics from experimental jobs are omitted)

If any of the issues found by CI are in your area of interest or expertise
please investigate the PRs listed below.

The latest web version of this report is available at
https://hackmd.io/@FreeBSD-CI/report-20190915 and archive is available at
https://hackmd.io/@FreeBSD-CI/, any help is welcome.

## News

* [FCP 20190401-ci_policy: CI 
policy](https://github.com/freebsd/fcp/blob/master/fcp-20190401-ci_policy.md)
  is in "feedback" state, please check and provide comments on -fcp@ and 
-hackers@ mailing lists.

## Fixed Tests

* https://ci.freebsd.org/job/FreeBSD-stable-12-amd64-test/
* https://ci.freebsd.org/job/FreeBSD-stable-12-i386-test/
* sys.netipsec.tunnel.aes_cbc_128_hmac_sha1.v6
* sys.netipsec.tunnel.aes_cbc_256_hmac_sha2_256.v6
* sys.netipsec.tunnel.aes_gcm_128.v6
* sys.netipsec.tunnel.aes_gcm_256.v6
* sys.netipsec.tunnel.aesni_aes_cbc_128_hmac_sha1.v6
* sys.netipsec.tunnel.aesni_aes_cbc_256_hmac_sha2_256.v6
* sys.netipsec.tunnel.aesni_aes_gcm_128.v6
* sys.netipsec.tunnel.aesni_aes_gcm_256.v6
* sys.netipsec.tunnel.empty.v6
* sys.netpfil.pf.fragmentation.v6
* sys.netpfil.pf.pass_block.v6
* https://bugs.freebsd.org/240437

## Failing Tests

* https://ci.freebsd.org/job/FreeBSD-stable-11-i386-test/
* local.kyua.* (31 cases)
* local.lutok.* (3 cases)

## Failing and Flaky Tests (from experimental jobs)

* https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/
* cddl.usr.sbin.dtrace.common.misc.t_dtrace_contrib.tst_dynopt_d
* https://bugs.freebsd.org/237641
* cddl.usr.sbin.dtrace.amd64.arrays.t_dtrace_contrib.tst_uregsarray_d
* https://bugs.freebsd.org/240358

* https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/
* There are ~60 failing cases, including flakey ones, see
  
https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/
 for more details

## Disabled Tests

* lib.libc.sys.mmap_test.mmap_truncate_signal
  https://bugs.freebsd.org/211924
  Patch available: https://reviews.freebsd.org/D21566
* sys.fs.tmpfs.mount_test.large
  https://bugs.freebsd.org/212862
* sys.fs.tmpfs.link_test.kqueue
  https://bugs.freebsd.org/213662
* sys.kqueue.libkqueue.kqueue_test.main
  https://bugs.freebsd.org/233586
* sys.kern.ptrace_test.ptrace__PT_KILL_competing_stop
  https://bugs.freebsd.org/220841
* lib.libc.regex.exhaust_test.regcomp_too_big (i386 only)
  https://bugs.freebsd.org/237450
* sys.netinet.socket_afinet.socket_afinet_bind_zero (new)
  https://bugs.freebsd.org/238781
* sys.netpfil.pf.names.names
* sys.netpfil.pf.synproxy.synproxy
  https://bugs.freebsd.org/238870
* sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger 
  https://bugs.freebsd.org/239292
* sys.netpfil.pf.forward.v4 (i386 only)
* sys.netpfil.pf.forward.v6 (i386 only)
* sys.netpfil.pf.set_tos.v4 (i386 only)
  https://bugs.freebsd.org/239380 (updating net/scapy to 2.4.3 may fix this)
* sys.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger 
  https://bugs.freebsd.org/239397
* sys.kern.ptrace_test.ptrace__parent_sees_exit_after_child_debugger
  https://bugs.freebsd.org/239399
* sys.kern.ptrace_test.ptrace__follow_fork_parent_detached_unrelated_debugger
  https://bugs.freebsd.org/239425
* lib.libc.gen.getmntinfo_test.getmntinfo_test
  https://bugs.freebsd.org/240049
* sys.sys.qmath_test.qdivq_s64q
  https://bugs.freebsd.org/240219
* (new) sys.kern.ptrace_test.ptrace__getppid
  https://bugs.freebsd.org/240510


## Issues

### Cause build fails
* https://bugs.freebsd.org/233735
  Possible build race:

Re: hang up with r352239 and r352386 with i5-7500

2019-09-17 Thread Mark Johnston 
On Tue, Sep 17, 2019 at 07:20:41AM +0900, Masachika ISHIZUKA wrote:
> > On 2019-09-16 16:06, Masachika ISHIZUKA wrote:
> >>> Can you please use absolute paths to i915kms.ko anyway, just to test?
> >>The same hang up occure with kld_list="/boot/modules/i915kms.ko"
> >> in /etc/rc.conf.
> >> 
> > 
> > Even after applying the patch I suggested?
> 
>   Yes.
> 
>   kld_list="/boot/modules/drm.ko /boot/modules/i915kms.ko"
> will hang as well.
> 
> /boot/modules/{drm,i915kms}.ko is patched modules.
> 
> # /boot/kernel.r352239/{drm,i915kms}.ko is not patched.

Are you able to collect a kernel dump?  If so, remove the kld_list
setting and set debug.debugger_on_panic=0 and dev.drm.skip_ddb=1.  Then
manually kldload /boot/modules/i915kms.ko.  If you are running an
INVARIANTS kernel you might be hitting an assertion failure; having the
vmcore would help us debug.
___
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: sleeping thread on r352386

2019-09-17 Thread Konstantin Belousov 
On Tue, Sep 17, 2019 at 08:18:26PM +1000, Peter Jeremy wrote:
> On 2019-Sep-17 11:06:58 +0300, Konstantin Belousov  
> wrote:
> >Try the following change, which more accurately tries to avoid
> >vnode_pager_setsize().  The real cause requires much more extensive
> >changes.
> >
> >diff --git a/sys/fs/nfsclient/nfs_clport.c b/sys/fs/nfsclient/nfs_clport.c
> >index 63ea4736707..16dc7745c77 100644
> >--- a/sys/fs/nfsclient/nfs_clport.c
> >+++ b/sys/fs/nfsclient/nfs_clport.c
> ...
> 
> With that patch, I'm back to "Sleeping thread (...) owns a non-sleepable
> lock" panics.

Try this.

diff --git a/sys/fs/nfsclient/nfs_clport.c b/sys/fs/nfsclient/nfs_clport.c
index 63ea4736707..a23b4ba4efa 100644
--- a/sys/fs/nfsclient/nfs_clport.c
+++ b/sys/fs/nfsclient/nfs_clport.c
@@ -414,12 +414,12 @@ nfscl_loadattrcache(struct vnode **vpp, struct nfsvattr 
*nap, void *nvaper,
struct nfsnode *np;
struct nfsmount *nmp;
struct timespec mtime_save;
+   vm_object_t object;
u_quad_t nsize;
-   int setnsize, error, force_fid_err;
+   int error, force_fid_err;
+   bool setnsize;
 
error = 0;
-   setnsize = 0;
-   nsize = 0;
 
/*
 * If v_type == VNON it is a new node, so fill in the v_type,
@@ -511,8 +511,7 @@ nfscl_loadattrcache(struct vnode **vpp, struct nfsvattr 
*nap, void *nvaper,
 * zero np->n_attrstamp to indicate that
 * the attributes are stale.
 */
-   nsize = vap->va_size = np->n_size;
-   setnsize = 1;
+   vap->va_size = np->n_size;
np->n_attrstamp = 0;
KDTRACE_NFS_ATTRCACHE_FLUSH_DONE(vp);
} else if (np->n_flag & NMODIFIED) {
@@ -526,22 +525,9 @@ nfscl_loadattrcache(struct vnode **vpp, struct nfsvattr 
*nap, void *nvaper,
np->n_size = vap->va_size;
np->n_flag |= NSIZECHANGED;
}
-   nsize = np->n_size;
-   setnsize = 1;
-   } else if (vap->va_size < np->n_size) {
-   /*
-* When shrinking the size, the call to
-* vnode_pager_setsize() cannot be done
-* with the mutex held, so delay it until
-* after the mtx_unlock call.
-*/
-   nsize = np->n_size = vap->va_size;
-   np->n_flag |= NSIZECHANGED;
-   setnsize = 1;
} else {
-   nsize = np->n_size = vap->va_size;
+   np->n_size = vap->va_size;
np->n_flag |= NSIZECHANGED;
-   setnsize = 1;
}
} else {
np->n_size = vap->va_size;
@@ -579,6 +565,23 @@ nfscl_loadattrcache(struct vnode **vpp, struct nfsvattr 
*nap, void *nvaper,
if (np->n_attrstamp != 0)
KDTRACE_NFS_ATTRCACHE_LOAD_DONE(vp, vap, error);
 #endif
+   nsize = vap->va_size;
+   object = vp->v_object;
+   setnsize = false;
+   if (object != NULL) {
+   if (OFF_TO_IDX(nsize + PAGE_MASK) < object->size) {
+   /*
+* When shrinking the size, the call to
+* vnode_pager_setsize() cannot be done with
+* the mutex held, because we might need to
+* wait for a busy page.  Delay it until after
+* the node is unlocked.
+*/
+   setnsize = true;
+   } else {
+   vnode_pager_setsize(vp, nsize);
+   }
+   }
NFSUNLOCKNODE(np);
if (setnsize)
vnode_pager_setsize(vp, nsize);
___
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: r352368 can't boot

2019-09-17 Thread Warner Losh 
On Tue, Sep 17, 2019, 11:24 AM Toomas Soome  wrote:

>
>
> On 17 Sep 2019, at 13:09, Warner Losh  wrote:
>
>
>
> On Tue, Sep 17, 2019, 6:47 AM Toomas Soome  wrote:
>
>>
>>
>> > On 17 Sep 2019, at 08:30, KIRIYAMA Kazuhiko  wrote:
>> >
>> > Hi,all
>> >
>> > Yesterday I've updated latest head (r352368) and rebuild
>> > 13.0-CURRENT. All went fine, but when I boot, it's stopped
>> > at boot stage. Then I typed `boot', booted normally and put
>> > login prompt and login go ahead. But `shutdown -r now',
>> > stopped at loader prompt same as login case. What happened?
>> > All I've done is whithin bhyve VM.
>> >
>> >
>>
>>
>> > Consoles: userboot
>> >
>> > FreeBSD/amd64 User boot, Revision 1.1
>> > (Mon Jun 18 16:11:55 UTC 2018 r...@releng3.nyi.freebsd.org)
>> > Loading /boot/defaults/loader.conf
>> > xemit not found
>> > Error while including /boot/frames.4th, in the line:
>> >h_el @ xemit
>> >
>> > can't load 'kernel'
>> >
>> > Type '?' for a list of commands, 'help' for more detailed help.
>> > OK
>> >
>>
>> This is unfortunate case where the guest image has more recent boot
>> scripts than hosts /boot/userboot.so has. I did push the fix for that issue
>> to stable/11 and stable/12. The patch does introduce xemit word.
>>
>> Such situation is unfortunate, but accident waiting to happen with this
>> method where we are attempting to use bootloader (userboot.so) from older
>> system to load  guest vm.
>>
>
> Can we provide a fallback to xemit builtin for old systems without it? I
> believe we did this for other things as a transition. Forth has a way to do
> this, though we need to make sure we properly constrain what we pass to
> emit...
>
> Warner
>
> P.s. I'm at legoland this week, so I can't look at it for a bit.
>
>
> Well, the only way to avoid such issue is to make sure the guest
> environment is providing all the needed bits, but since we do have
> interpreter inside the userboot.so and userboot.so is in host, this does
> set rather unfortunate limits what we can do.
>

Yes. I understand that we are limited in our scripts to somehow testing if
xemit is a forth word and if not providing a fallback implementation of it
in forth using emit.

Warner

rgds,
> toomas
>
___
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: sleeping thread on r352386

2019-09-17 Thread Masachika ISHIZUKA 
>>Try the following change, which more accurately tries to avoid
>>vnode_pager_setsize().  The real cause requires much more extensive
>>changes.
>>
>>diff --git a/sys/fs/nfsclient/nfs_clport.c b/sys/fs/nfsclient/nfs_clport.c
>>index 63ea4736707..16dc7745c77 100644
>>--- a/sys/fs/nfsclient/nfs_clport.c
>>+++ b/sys/fs/nfsclient/nfs_clport.c
> ...
> 
> With that patch, I'm back to "Sleeping thread (...) owns a non-sleepable
> lock" panics.

  Me too.

  I applied this patch to r352432 and rebuild/install kernel/world.
  As the result, 'make buildworld' stopped with a panic that "sleeping
thread (...) owns a non-sleepable lock".
-- 
Masachika ISHIZUKA
___
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: r352368 can't boot

2019-09-17 Thread Toomas Soome 



> On 17 Sep 2019, at 13:09, Warner Losh  wrote:
> 
> 
> 
> On Tue, Sep 17, 2019, 6:47 AM Toomas Soome  > wrote:
> 
> 
> > On 17 Sep 2019, at 08:30, KIRIYAMA Kazuhiko  > > wrote:
> > 
> > Hi,all
> > 
> > Yesterday I've updated latest head (r352368) and rebuild
> > 13.0-CURRENT. All went fine, but when I boot, it's stopped
> > at boot stage. Then I typed `boot', booted normally and put
> > login prompt and login go ahead. But `shutdown -r now',
> > stopped at loader prompt same as login case. What happened?
> > All I've done is whithin bhyve VM.
> > 
> > 
> 
> 
> > Consoles: userboot  
> > 
> > FreeBSD/amd64 User boot, Revision 1.1
> > (Mon Jun 18 16:11:55 UTC 2018 r...@releng3.nyi.freebsd.org 
> > )
> > Loading /boot/defaults/loader.conf
> > xemit not found
> > Error while including /boot/frames.4th, in the line:
> >h_el @ xemit
> > 
> > can't load 'kernel'
> > 
> > Type '?' for a list of commands, 'help' for more detailed help.
> > OK 
> > 
> 
> This is unfortunate case where the guest image has more recent boot scripts 
> than hosts /boot/userboot.so has. I did push the fix for that issue to 
> stable/11 and stable/12. The patch does introduce xemit word.
> 
> Such situation is unfortunate, but accident waiting to happen with this 
> method where we are attempting to use bootloader (userboot.so) from older 
> system to load  guest vm. 
> 
> Can we provide a fallback to xemit builtin for old systems without it? I 
> believe we did this for other things as a transition. Forth has a way to do 
> this, though we need to make sure we properly constrain what we pass to 
> emit...
> 
> Warner
> 
> P.s. I'm at legoland this week, so I can't look at it for a bit.
> 

Well, the only way to avoid such issue is to make sure the guest environment is 
providing all the needed bits, but since we do have interpreter inside the 
userboot.so and userboot.so is in host, this does set rather unfortunate limits 
what we can do.

rgds,
toomas
___
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: sleeping thread on r352386

2019-09-17 Thread Peter Jeremy 
On 2019-Sep-17 11:06:58 +0300, Konstantin Belousov  wrote:
>Try the following change, which more accurately tries to avoid
>vnode_pager_setsize().  The real cause requires much more extensive
>changes.
>
>diff --git a/sys/fs/nfsclient/nfs_clport.c b/sys/fs/nfsclient/nfs_clport.c
>index 63ea4736707..16dc7745c77 100644
>--- a/sys/fs/nfsclient/nfs_clport.c
>+++ b/sys/fs/nfsclient/nfs_clport.c
...

With that patch, I'm back to "Sleeping thread (...) owns a non-sleepable
lock" panics.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: r352368 can't boot

2019-09-17 Thread Warner Losh 
On Tue, Sep 17, 2019, 6:47 AM Toomas Soome  wrote:

>
>
> > On 17 Sep 2019, at 08:30, KIRIYAMA Kazuhiko  wrote:
> >
> > Hi,all
> >
> > Yesterday I've updated latest head (r352368) and rebuild
> > 13.0-CURRENT. All went fine, but when I boot, it's stopped
> > at boot stage. Then I typed `boot', booted normally and put
> > login prompt and login go ahead. But `shutdown -r now',
> > stopped at loader prompt same as login case. What happened?
> > All I've done is whithin bhyve VM.
> >
> >
>
>
> > Consoles: userboot
> >
> > FreeBSD/amd64 User boot, Revision 1.1
> > (Mon Jun 18 16:11:55 UTC 2018 r...@releng3.nyi.freebsd.org)
> > Loading /boot/defaults/loader.conf
> > xemit not found
> > Error while including /boot/frames.4th, in the line:
> >h_el @ xemit
> >
> > can't load 'kernel'
> >
> > Type '?' for a list of commands, 'help' for more detailed help.
> > OK
> >
>
> This is unfortunate case where the guest image has more recent boot
> scripts than hosts /boot/userboot.so has. I did push the fix for that issue
> to stable/11 and stable/12. The patch does introduce xemit word.
>
> Such situation is unfortunate, but accident waiting to happen with this
> method where we are attempting to use bootloader (userboot.so) from older
> system to load  guest vm.
>

Can we provide a fallback to xemit builtin for old systems without it? I
believe we did this for other things as a transition. Forth has a way to do
this, though we need to make sure we properly constrain what we pass to
emit...

Warner

P.s. I'm at legoland this week, so I can't look at it for a bit.


rgds,
> toomas
>
> ___
> 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: panic: sleeping thread on r352386

2019-09-17 Thread Konstantin Belousov 
On Tue, Sep 17, 2019 at 02:42:51PM +0900, Masachika ISHIZUKA wrote:
> >>   This panic happens on 1300047 (both r352239 and r352386) with core
> >> i5-7500 as follows. This panic dose not happen on r351728 (1300044).
> >> (The following lines were typed by hand so they might have some miss
> >> typed letters.)
> >> 
> >> ==
> >> Sleeping thread (tid 100177, pid 1814) owns a non-sleepable lock
> >> KDB: stack backtrace of thread 100177:
> > 
> > 
> > https://svnweb.freebsd.org/base?view=revision=352393
> 
>   Thank you for reply.
> 
>   I updated to r352431 and this does not panic. Thank you very much.
>   But 'make buildworld' fails by segment fault like below.
> (buildworld is running over the nfs file system.)
> 
> --- modules-all ---
> --- ath_hal_ar5211.ko.debug ---
> objcopy --only-keep-debug ath_hal_ar5211.ko.full ath_hal_ar5211.ko.debug
> Segmentation fault (core dumped)
> *** [ath_hal_ar5211.ko.debug] Error code 139
> make[4]: stopped in 
> /usr/altlocal/freebsd-current/src/sys/modules/ath_hal_ar52111 error
> 
>   The position of segment fault is diffrent each time.
>   The below is output of another 'make buildworld'.
> 
> --- kernel.full ---
> Segmentation fault (core dumped)
> *** [kernel.full] Error code 139
> make[2]: stopped in 
> /usr/altlocal/freebsd-current/obj/usr/altlocal/freebsd-current/src/amd64.amd64/sys/GENERIC
> 
>   /var/log/messages is shown as bellow.
> 
> Sep 17 11:22:56 okra kernel: Failed to fully fault in a core file segment at 
> VA
> 0x800a0 with size 0x163000 to be written at offset 0x84a000 for process nm
> Sep 17 11:22:56 okra kernel: pid 53593 (nm), jid 0, uid 16220: exited on 
> signal
> 11 (core dumped)
> Sep 17 11:22:57 okra kernel: Failed to fully fault in a core file segment at 
> VA
> 0x800a0 with size 0x163000 to be written at offset 0x88b000 for process 
> objcopy
> Sep 17 11:22:57 okra kernel: pid 53603 (objcopy), jid 0, uid 16220: exited on 
> signal 11 (core dumped)
> 
>   Retry 'make buildworld'
> 
> Sep 17 12:24:05 okra kernel: Failed to fully fault in a core file segment at 
> VA
> 0x8002f6000 with size 0x93000 to be written at offset 0x239000 for process nm
> Sep 17 12:24:05 okra kernel: pid 96873 (nm), jid 0, uid 16220: exited on 
> signal
> 11 (core dumped)
> Sep 17 12:24:05 okra kernel: Failed to fully fault in a core file segment at 
> VA
> 0x80035f000 with size 0x93000 to be written at offset 0x281000 for process 
> objcopy
> Sep 17 12:24:06 okra kernel: pid 96889 (objcopy), jid 0, uid 16220: exited on 
> signal 11 (core dumped)
> 
>   Retry 'make buildworld'
> 
> Sep 17 14:01:39 okra kernel: Failed to fully fault in a core file segment at 
> VA
> 0x8048da000 with size 0x112000 to be written at offset 0x1a33000 for process 
> ld.lld
> Sep 17 14:01:51 okra kernel: Failed to fully fault in a core file segment at 
> VA
> 0x8117cc000 with size 0x1e7000 to be written at offset 0xe925000 for process 
> ld.lld
> Sep 17 14:01:53 okra kernel: pid 50292 (ld.lld), jid 0, uid 16220: exited on 
> signal 11 (core dumped)
> 
>   I can 'make buildworld' successfully on r351728(1300044).

Try the following change, which more accurately tries to avoid
vnode_pager_setsize().  The real cause requires much more extensive
changes.

diff --git a/sys/fs/nfsclient/nfs_clport.c b/sys/fs/nfsclient/nfs_clport.c
index 63ea4736707..16dc7745c77 100644
--- a/sys/fs/nfsclient/nfs_clport.c
+++ b/sys/fs/nfsclient/nfs_clport.c
@@ -414,12 +414,11 @@ nfscl_loadattrcache(struct vnode **vpp, struct nfsvattr 
*nap, void *nvaper,
struct nfsnode *np;
struct nfsmount *nmp;
struct timespec mtime_save;
-   u_quad_t nsize;
-   int setnsize, error, force_fid_err;
+   u_quad_t nsize, osize;
+   int error, force_fid_err;
+   bool setnsize;
 
error = 0;
-   setnsize = 0;
-   nsize = 0;
 
/*
 * If v_type == VNON it is a new node, so fill in the v_type,
@@ -439,6 +438,7 @@ nfscl_loadattrcache(struct vnode **vpp, struct nfsvattr 
*nap, void *nvaper,
nmp = VFSTONFS(vp->v_mount);
vap = >n_vattr.na_vattr;
mtime_save = vap->va_mtime;
+   osize = vap->va_size;
if (writeattr) {
np->n_vattr.na_filerev = nap->na_filerev;
np->n_vattr.na_size = nap->na_size;
@@ -511,8 +511,7 @@ nfscl_loadattrcache(struct vnode **vpp, struct nfsvattr 
*nap, void *nvaper,
 * zero np->n_attrstamp to indicate that
 * the attributes are stale.
 */
-   nsize = vap->va_size = np->n_size;
-   setnsize = 1;
+   vap->va_size = np->n_size;
np->n_attrstamp = 0;
KDTRACE_NFS_ATTRCACHE_FLUSH_DONE(vp);
} else if (np->n_flag & NMODIFIED) {
@@ -526,22 +525,9 @@ nfscl_loadattrcache(struct vnode **vpp, struct nfsvattr 
*nap, void