A head buildworld race visible in the ci.freebsd.org build history
In watching ci.freebsd.org builds I've seen a notable number of one time failures, such as (example from powerpc64): --- all_subdir_lib/libufs --- ranlib -D libufs.a ranlib: fatal: Failed to open 'libufs.a' *** [libufs.a] Error code 70 where the next build works despite the change being irrelevant to whatever ranlib complained about. Other builds failed similarly: --- all_subdir_lib/libbsm --- ranlib -D libbsm_p.a ranlib: fatal: Failed to open 'libbsm_p.a' *** [libbsm_p.a] Error code 70 and: --- kerberos5/lib__L --- ranlib -D libgssapi_spnego_p.a --- libgssapi_spnego.a --- ranlib -D libgssapi_spnego.a --- libgssapi_spnego_p.a --- ranlib: fatal: Failed to open 'libgssapi_spnego_p.a' *** [libgssapi_spnego_p.a] Error code 70 and so on. It is not limited to powerpc64. For example, for aarch64 there are: --- libpam_exec.a --- building static pam_exec library ar -crD libpam_exec.a `NM='nm' NMFLAGS='' lorder pam_exec.o | tsort -q` ranlib -D libpam_exec.a ranlib: fatal: Failed to open 'libpam_exec.a' *** [libpam_exec.a] Error code 70 and: --- all_subdir_lib/libusb --- ranlib -D libusb.a ranlib: fatal: Failed to open 'libusb.a' *** [libusb.a] Error code 70 and: --- all_subdir_lib/libbsnmp --- ranlib: fatal: Failed to open 'libbsnmp.a' --- all_subdir_lib/ncurses --- --- all_subdir_lib/ncurses/panelw --- --- panel.pico --- --- all_subdir_lib/libbsnmp --- *** [libbsnmp.a] Error code 70 Even amd64 gets such: --- libpcap.a --- ranlib -D libpcap.a ranlib: fatal: Failed to open 'libpcap.a' *** [libpcap.a] Error code 70 and: --- libkafs5.a --- ranlib: fatal: Failed to open 'libkafs5.a' --- libkafs5_p.a --- ranlib: fatal: Failed to open 'libkafs5_p.a' --- cddl/lib__L --- /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/lua/lbaselib.c:60:26: note: include the header or explicitly provide a declaration for 'toupper' --- kerberos5/lib__L --- *** [libkafs5_p.a] Error code 70 make[5]: stopped in /usr/src/kerberos5/lib/libkafs5 --- libkafs5.a --- *** [libkafs5.a] Error code 70 and: --- lib__L --- ranlib -D libclang_rt.asan_cxx-i386.a ranlib: fatal: Failed to open 'libclang_rt.asan_cxx-i386.a' *** [libclang_rt.asan_cxx-i386.a] Error code 70 (Notice the variability in what .a the ranlib's fail for.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ 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: swapping is completely broken in -CURRENT r334649?
On Fri, Jun 15, 2018 at 11:14:40AM +0200, Mikaël Urankar wrote: > Last time I tried (2 weeks ago) qemu-ppc64-static was broken, not sure the > situation has evolved since that. I've been told by more than one person that it works, but the 2? 3? times I've tried it it just hung. I have real hardware so in general it doesn't make a difference to me, but I'd like to know one way or the other. 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: Resume without drm driver results in black screen
On 5/17/18 3:01 AM, Johannes Lundberg wrote: > Hi > > I revived this old bug > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213501 > > Considering this also affects all X users using scfb driver it's worth > investigating. It's just not doable. You need some sort of driver for the GPU that knows how to turn the display back on. That isn't a portable thing, it's GPU-specific. You could perhaps write smaller drivers that only support resume and not graphics acceleration, but that doesn't seem trivial. -- 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: kgdb crashing on a vmcore with dumptid = 0
On 5/4/18 10:49 PM, Eitan Adler wrote:
> gdb$ bt
> #0 thr_kill () at thr_kill.S:3
> #1 0x0008035046b4 in __raise (s=0x6) at /usr/src/lib/libc/gen/raise.c:54
> #2 0x000803504629 in abort () at /usr/src/lib/libc/stdlib/abort.c:67
> #3 0x00c805c6 in dump_core () at utils.c:284
> #4 0x00c81920 in internal_vproblem (problem=0x24bd890
> , file=0x15c560e "inferior.c", line=0x135,
> fmt=0x15780ac "%s: Assertion
> `%s' failed.", ap=0x7fffb9e0) at utils.c:493
> #5 0x00c806d8 in internal_verror (file=0x15c560e
> "inferior.c", line=0x135, fmt=0x15780ac "%s: Assertion `%s' failed.",
> ap=0x7fffb9e0) at utils.c:
> 518
> #6 0x008363a8 in internal_error (file=0x15c560e "inferior.c",
> line=0x135, fmt=0x15780ac "%s: Assertion `%s' failed.") at
> common/errors.c:55
> #7 0x00a8397e in find_inferior_pid (pid=0x0) at inferior.c:309
> #8 0x00a83d54 in find_inferior_ptid (ptid=...) at inferior.c:323
> #9 0x00c10049 in default_thread_architecture (ops=0x2702d90
> , ptid=...) at target.c:3131
> #10 0x00bfec2b in delegate_thread_architecture (self=0x2702d90
> , arg1=...) at ./target-delegates.c:2525
> #11 0x00bfec2b in delegate_thread_architecture (self=0x26eedd0
> , arg1=...) at ./target-delegates.c:2525
> #12 0x00bfec2b in delegate_thread_architecture (self=0x26ec280
> , arg1=...) at ./target-delegates.c:2525
> #13 0x00b53cba in get_thread_regcache (ptid=...) at regcache.c:439
> #14 0x00b53d5e in get_current_regcache () at regcache.c:448
> #15 0x00713077 in kgdb_trgt_open (arg=0x80410900e "vmcore.2",
> from_tty=0x1) at fbsd-kvm.c:335
> #16 0x00bf3980 in open_target (args=0x80410900e "vmcore.2",
> from_tty=0x1, command=0x8041c8f40) at target.c:356
> #17 0x00722c35 in do_sfunc (c=0x8041c8f40, args=0x80410900e
> "vmcore.2", from_tty=0x1) at cli/cli-decode.c:122
> #18 0x00726b5a in cmd_func (cmd=0x8041c8f40, args=0x80410900e
> "vmcore.2", from_tty=0x1) at cli/cli-decode.c:1886
> #19 0x00c450c7 in execute_command (p=0x804109015 "2",
> from_tty=0x1) at top.c:630
> #20 0x00acd4a8 in catch_command_errors (command=0xc445f0
> , arg=0x804109000 "target vmcore
> vmcore.2", from_tty=0x1)
> at main.c:378
> #21 0x00accdf2 in captured_main_1 (context=0x7fffcfe8) at
> main.c:1124
> #22 0x00aca62d in captured_main (data=0x7fffcfe8) at main.c:1146
> #23 0x00aca508 in gdb_main (args=0x7fffcfe8) at main.c:1172
> #24 0x0050bd5b in main (argc=0x3, argv=0x7fffd558) at
> kgdb-main.c:410
>
> gdb$ up 7
> #7 0x00a8397e in find_inferior_pid (pid=0x0) at inferior.c:309
> 309 gdb_assert (pid != 0);
> gdb$ frame
> Stack level 7, frame at 0x7fffba50:
> rip = 0xa8397e in find_inferior_pid (inferior.c:309); saved rip = 0xa83d54
> called by frame at 0x7fffba60, caller of frame at 0x7fffba20
> source language c++.
> Arglist at 0x7fffba40, args: pid=0x0
> Locals at 0x7fffba40, Previous frame's sp is 0x7fffba50
> Saved registers:
> rbp at 0x7fffba40, rip at 0x7fffba48
> pid = 0x0
> inf = 0x8415d5
>
>
> gdb$ list
> 304 struct inferior *inf;
> 305
> 306 /* Looking for inferior pid == 0 is always wrong, and indicative of
> 307 a bug somewhere else. There may be more than one with pid == 0,
> 308 for instance. */
> 309 gdb_assert (pid != 0);
> 310
> 311 for (inf = inferior_list; inf; inf = inf->next)
> 312 if (inf->pid == pid)
> 313 return inf;
>
>
> gdb$ p pid
> $1 = 0x0
>
>
> gdb$ p ptid
> $2 = {
> m_pid = 0x0,
> m_lwp = 0x0,
> m_tid = 0x0
> }
>
> gdb$ up
> #9 0x00c10049 in default_thread_architecture (ops=0x2702d90
> , ptid=...) at target.c:3131
> 3131 inferior *inf = find_inferior_ptid (ptid);
> gdb$ list
> 3126}
> 3127
> 3128static struct gdbarch *
> 3129default_thread_architecture (struct target_ops *ops, ptid_t ptid)
> 3130{
> 3131 inferior *inf = find_inferior_ptid (ptid);
> 3132 gdb_assert (inf != NULL);
> 3133 return inf->gdbarch;
> 3134}
> 3135
> gdb$ p ops
> $4 = (target_ops *) 0x2702d90
>
> gdb$ up
> #14 0x00b53d5e in get_current_regcache () at regcache.c:448
> 448 return get_thread_regcache (inferior_ptid);
> gdb$ list
> 443 }
> 444
> 445 struct regcache *
> 446 get_current_regcache (void)
> 447 {
> 448 return get_thread_regcache (inferior_ptid);
> 449 }
> 450
> 451 /* See common/common-regcache.h. */
> 452
> gdb$ p inferior_ptid
> $13 = {
> m_pid = 0x0,
> m_lwp = 0x0,
> m_tid = 0x0
> }
>
>
> gdb$ up
> #15 0x00713077 in kgdb_trgt_open (arg=0x80410900e "vmcore.2",
> from_tty=0x1) at fbsd-kvm.c:335
> 335 target_fetch_registers (get_current_regcache (), -1);
> gdb$ list
> 330 kt = kgdb_thr_next(kt);
> 331 }
> 332 if (curkthr != 0)
> 333
review of nfsd rc.d script patch
Hi, For the pNFS service MDS machine, the nfsd can't be started until all nfs mounts in /etc/fstab are done. I think that adding "mountcritremote" to the "# REQUIRE:" line is sufficient to do this? I don't think delaying the startup of the nfsd daemon until after any NFS mounts are done will do any harm, but if others think it would be a POLA violation, I could make this dependent on the pNFS service being enabled. Does anyone think this would cause a POLA violation? If someone familiar with the rc scripts could review this little patch, it would be appreciated: --- nfsd.old2018-06-15 16:07:54.279786000 -0400 +++ nfsd2018-06-15 16:08:43.934603000 -0400 @@ -4,7 +4,7 @@ # # PROVIDE: nfsd -# REQUIRE: mountd hostname gssd nfsuserd +# REQUIRE: mountcritremote mountd hostname gssd nfsuserd # KEYWORD: nojail shutdown . /etc/rc.subr 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: freebsd bhyve instance does not show kernel messages after boot screen
> On 14/06/2018 23:26, David P. Discher wrote: > > Try in /boot/loader.conf of the VM : > > > > console=userboot > > > > or after beastie drop to loader OK promot ?and try : > > > > set console=userboot > > > > I think 11.x should fall back to userboot in?bhyve if vidconsole of > > comconsole were set. > > > > (This is assuming non-EFI booting - using bhyveloader ). > > Hi, > > Thanks for trying to help. I tried it both ways - in loader.conf and > from the loader prompt but unfortunately it didn't work. For > clarification, here's the exact way I start the VM: > > 1. $ screen -S fbsd11-vm > 2. $ sudo su - > 3. # (cd to where vm is) > 4. sh /usr/share/examples/bhyve/vmrun.sh -c 4 -m 8192M -t tap3 -d > fbsd-guest.img fbsd-guest > > If I transfer the VM to a freebsd-11 host (r333874) it also happens. So > the behaviour is a property of the VM. Unless of course the issue is > with bhyve itself on both -stable and -current. > > A possible clue (but I'm really out of my depth here) is ISTR something > like this happening if say the VM is called say fbsd-guest and is then > subsequently launched with some other name like fbsd11guest. > > Any ideas? With the VM shutdown look in /dev/vmm for the same name as the VM, if you see it there, make sure you do not have a running instnace of it, then do: bhyvectl --destroy --name=fbsd11-vm You may have remanants of a prior/crashed VM hanging around causing you issues. -- Rod Grimes rgri...@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: swapping is completely broken in -CURRENT r334649?
On Fri, Jun 15, 2018 at 04:40:22AM -0400, Mark Johnston wrote: > > On Fri, Jun 15, 2018 at 01:10:25PM +0800, Kevin Lo wrote: > > On Tue, Jun 05, 2018 at 05:48:08PM -0400, Mark Johnston wrote: > > > > > > On Wed, Jun 06, 2018 at 12:22:08AM +0300, Lev Serebryakov wrote: > > > > On 05.06.2018 19:17, Gary Jennejohn wrote: > > > > > > > > > > > > > I complained about this also and alc@ gave me this hint: > > > > > sysctl vm.pageout_update_period=0 > > > > > > > > Really, situation is worse than stated in subject, because processes > > > > are being killed AFTER memory pressure, when here are a lot of free > > > > memory already! > > > > > > > > It looks like very serious bug. > > > > > > The issue was identified earlier this week and is being worked on. It's > > > a regression from r329882 which appears only on certain hardware. You > > > can probably work around it by setting vm.pageout_oom_seq to a large > > > value (try 1000 for instance), though this will make the "true" OOM > > > killer take longer to kick in. The problem is unrelated to the > > > pageout_update_period. > > > > I have a large swap space and I've encountered this issue as well > > > > pid 90707 (getty), uid 0, was killed: out of swap space > > pid 90709 (getty), uid 0, was killed: out of swap space > > pid 90709 (getty), uid 0, was killed: out of swap space > > ... > > > > Setting vm.pageout_oom_seq to 1000 doesn't help. If you have a patch I'll > > be > > happy to test it, thanks. > > The change was committed as r334752. Are you seeing unexpected OOM > kills on or after that revision? The box is running -CURRENT r334983. I'll investigate further, thanks. ___ 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 bhyve instance does not show kernel messages after boot screen
On 14/06/2018 23:26, David P. Discher wrote: Try in /boot/loader.conf of the VM : console=userboot or after beastie drop to loader OK promot and try : set console=userboot I think 11.x should fall back to userboot in bhyve if vidconsole of comconsole were set. (This is assuming non-EFI booting - using bhyveloader ). Hi, Thanks for trying to help. I tried it both ways - in loader.conf and from the loader prompt but unfortunately it didn't work. For clarification, here's the exact way I start the VM: 1. $ screen -S fbsd11-vm 2. $ sudo su - 3. # (cd to where vm is) 4. sh /usr/share/examples/bhyve/vmrun.sh -c 4 -m 8192M -t tap3 -d fbsd-guest.img fbsd-guest If I transfer the VM to a freebsd-11 host (r333874) it also happens. So the behaviour is a property of the VM. Unless of course the issue is with bhyve itself on both -stable and -current. A possible clue (but I'm really out of my depth here) is ISTR something like this happening if say the VM is called say fbsd-guest and is then subsequently launched with some other name like fbsd11guest. Any ideas? thanks, -- J. ___ 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: swapping is completely broken in -CURRENT r334649?
Hi! > > I just started it again, and after a while the qemu-ppc64-static > > was at approx. 23 GB memory and increasing, without much progress. > Last time I tried (2 weeks ago) qemu-ppc64-static was broken, not sure the > situation has evolved since that. Ok, thanks! Then it's not the same problem. -- p...@opsec.eu+49 171 31013722 years to go ! ___ 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: Help USB keyboard trouble
On 06/15/18 08:45, Alex V. Petrov wrote: Hans Petter! What can you say about my problem? Hi, I didn't have time to look into this. --HPS ___ 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: swapping is completely broken in -CURRENT r334649?
Le ven. 15 juin 2018 à 11:10, Kurt Jaeger a écrit : > Hi! > > > > > The change was committed as r334752. Are you seeing unexpected OOM > > > > kills on or after that revision? > > > > > > When I tried to run a qemu-based poudriere run yesterday on a r334918 > > > box, it killed a few processes outside of that run and did not > > > work out. > > > > > > I'm unsure it was because of that problem or a problem with qemu. > > > > How much memory and swap does the guest have? > > It's started by poudriere, I do not really know. > > > Were you consistently able to complete a run before? > > Two years ago, on a much lower version of FreeBSD, yes. > > I just started it again, and after a while the qemu-ppc64-static > was at approx. 23 GB memory and increasing, without much progress. Last time I tried (2 weeks ago) qemu-ppc64-static was broken, not sure the situation has evolved since that. ___ 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: swapping is completely broken in -CURRENT r334649?
On Fri, Jun 15, 2018 at 11:07:34AM +0200, Kurt Jaeger wrote:
> Hi!
>
> > > > The change was committed as r334752. Are you seeing unexpected OOM
> > > > kills on or after that revision?
> > >
> > > When I tried to run a qemu-based poudriere run yesterday on a r334918
> > > box, it killed a few processes outside of that run and did not
> > > work out.
> > >
> > > I'm unsure it was because of that problem or a problem with qemu.
> >
> > How much memory and swap does the guest have?
>
> It's started by poudriere, I do not really know.
>
> > Were you consistently able to complete a run before?
>
> Two years ago, on a much lower version of FreeBSD, yes.
>
> I just started it again, and after a while the qemu-ppc64-static
> was at approx. 23 GB memory and increasing, without much progress.
I suspect it is a different issue then.
> > If it's happening during a poudriere run, it may well have been a true
> > OOM situation. The patch below prints a few stats to the dmesg before
> > the kill. The output of that together with "sysctl vm" output should be
> > enough to determine what's happening.
> >
> > diff --git a/sys/vm/vm_pageout.c b/sys/vm/vm_pageout.c
> > index 264c98203c51..9c7ebcf451ec 100644
> > --- a/sys/vm/vm_pageout.c
> > +++ b/sys/vm/vm_pageout.c
> > @@ -1670,6 +1670,8 @@ vm_pageout_mightbe_oom(struct vm_domain *vmd, int
> > page_shortage,
> > * start OOM. Initiate the selection and signaling of the
> > * victim.
> > */
> > + printf("v_free_count: %u, v_inactive_count: %u\n",
> > + vmd->vmd_free_count, vmd->vmd_pagequeues[PQ_INACTIVE].pq_cnt);
> > vm_pageout_oom(VM_OOM_MEM);
> >
> > /*
>
> I'll have a look at this.
>
> --
> p...@opsec.eu+49 171 31013722 years to go !
___
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: swapping is completely broken in -CURRENT r334649?
Hi!
> > > The change was committed as r334752. Are you seeing unexpected OOM
> > > kills on or after that revision?
> >
> > When I tried to run a qemu-based poudriere run yesterday on a r334918
> > box, it killed a few processes outside of that run and did not
> > work out.
> >
> > I'm unsure it was because of that problem or a problem with qemu.
>
> How much memory and swap does the guest have?
It's started by poudriere, I do not really know.
> Were you consistently able to complete a run before?
Two years ago, on a much lower version of FreeBSD, yes.
I just started it again, and after a while the qemu-ppc64-static
was at approx. 23 GB memory and increasing, without much progress.
> If it's happening during a poudriere run, it may well have been a true
> OOM situation. The patch below prints a few stats to the dmesg before
> the kill. The output of that together with "sysctl vm" output should be
> enough to determine what's happening.
>
> diff --git a/sys/vm/vm_pageout.c b/sys/vm/vm_pageout.c
> index 264c98203c51..9c7ebcf451ec 100644
> --- a/sys/vm/vm_pageout.c
> +++ b/sys/vm/vm_pageout.c
> @@ -1670,6 +1670,8 @@ vm_pageout_mightbe_oom(struct vm_domain *vmd, int
> page_shortage,
>* start OOM. Initiate the selection and signaling of the
>* victim.
>*/
> + printf("v_free_count: %u, v_inactive_count: %u\n",
> + vmd->vmd_free_count, vmd->vmd_pagequeues[PQ_INACTIVE].pq_cnt);
> vm_pageout_oom(VM_OOM_MEM);
>
> /*
I'll have a look at this.
--
p...@opsec.eu+49 171 31013722 years to go !
___
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: swapping is completely broken in -CURRENT r334649?
On Fri, Jun 15, 2018 at 10:48:08AM +0200, Kurt Jaeger wrote:
> Hi!
>
> > The change was committed as r334752. Are you seeing unexpected OOM
> > kills on or after that revision?
>
> When I tried to run a qemu-based poudriere run yesterday on a r334918
> box, it killed a few processes outside of that run and did not
> work out.
>
> I'm unsure it was because of that problem or a problem with qemu.
How much memory and swap does the guest have? Were you consistently
able to complete a run before?
If it's happening during a poudriere run, it may well have been a true
OOM situation. The patch below prints a few stats to the dmesg before
the kill. The output of that together with "sysctl vm" output should be
enough to determine what's happening.
diff --git a/sys/vm/vm_pageout.c b/sys/vm/vm_pageout.c
index 264c98203c51..9c7ebcf451ec 100644
--- a/sys/vm/vm_pageout.c
+++ b/sys/vm/vm_pageout.c
@@ -1670,6 +1670,8 @@ vm_pageout_mightbe_oom(struct vm_domain *vmd, int
page_shortage,
* start OOM. Initiate the selection and signaling of the
* victim.
*/
+ printf("v_free_count: %u, v_inactive_count: %u\n",
+ vmd->vmd_free_count, vmd->vmd_pagequeues[PQ_INACTIVE].pq_cnt);
vm_pageout_oom(VM_OOM_MEM);
/*
___
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: swapping is completely broken in -CURRENT r334649?
Hi! > The change was committed as r334752. Are you seeing unexpected OOM > kills on or after that revision? When I tried to run a qemu-based poudriere run yesterday on a r334918 box, it killed a few processes outside of that run and did not work out. I'm unsure it was because of that problem or a problem with qemu. -- p...@opsec.eu+49 171 31013722 years to go ! ___ 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: swapping is completely broken in -CURRENT r334649?
On Fri, Jun 15, 2018 at 01:10:25PM +0800, Kevin Lo wrote: > On Tue, Jun 05, 2018 at 05:48:08PM -0400, Mark Johnston wrote: > > > > On Wed, Jun 06, 2018 at 12:22:08AM +0300, Lev Serebryakov wrote: > > > On 05.06.2018 19:17, Gary Jennejohn wrote: > > > > > > > > > > I complained about this also and alc@ gave me this hint: > > > > sysctl vm.pageout_update_period=0 > > > > > > Really, situation is worse than stated in subject, because processes > > > are being killed AFTER memory pressure, when here are a lot of free > > > memory already! > > > > > > It looks like very serious bug. > > > > The issue was identified earlier this week and is being worked on. It's > > a regression from r329882 which appears only on certain hardware. You > > can probably work around it by setting vm.pageout_oom_seq to a large > > value (try 1000 for instance), though this will make the "true" OOM > > killer take longer to kick in. The problem is unrelated to the > > pageout_update_period. > > I have a large swap space and I've encountered this issue as well > > pid 90707 (getty), uid 0, was killed: out of swap space > pid 90709 (getty), uid 0, was killed: out of swap space > pid 90709 (getty), uid 0, was killed: out of swap space > ... > > Setting vm.pageout_oom_seq to 1000 doesn't help. If you have a patch I'll be > happy to test it, thanks. The change was committed as r334752. Are you seeing unexpected OOM kills on or after that revision? ___ 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: Help USB keyboard trouble
Hans Petter! What can you say about my problem? 09.05.2018 18:31, Alex V. Petrov пишет: > 09.05.2018 14:08, Hans Petter Selasky пишет: >> On 05/09/18 05:52, Alex V. Petrov wrote: >>> The new USB-keyboard "Qumo Dragon War Mechanicus K11" continues to print >>> "A" when connected, as if the "a" key is pressed. >>> But in Windows and Linux keyboard work normaly. >>> >>> In log: >>> >>> May 9 10:43:38 alex kernel: ugen2.3: at usbus2 >>> May 9 10:43:38 alex kernel: ukbd0 on uhub6 >>> May 9 10:43:38 alex kernel: ukbd0: >> 2.00/1.00, addr 3> on usbus2 >>> May 9 10:43:38 alex kernel: kbd2 at ukbd0 >>> May 9 10:43:38 alex kernel: ukbd1 on uhub6 >>> May 9 10:43:38 alex kernel: ukbd1: >> 2.00/1.00, addr 3> on usbus2 >>> May 9 10:43:38 alex kernel: kbd3 at ukbd1 >>> ^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^AMay >>> >>> 9 10:43:46 alex kernel: ugen2.3: at usbus2 >>> (disconnected) >>> May 9 10:43:46 alex kernel: ukbd0: at uhub6, port 3, addr 3 >>> (disconnected) >>> May 9 10:43:46 alex kernel: ukbd0: detached >>> May 9 10:43:46 alex kernel: ukbd1: at uhub6, port 3, addr 3 >>> (disconnected) >>> May 9 10:43:46 alex kernel: ukbd1: detached >>> >> >> Hi, >> >> Can you show the output from: >> >> usbconfig -d ugen2.3 dump_device_desc dump_curr_config_desc >> >> And also have a look at: >> >> usbdump -i usbus2 -f 3 -vvv -s 65536 >> >> --HPS >> >> BTW: We have a list specifically for USB problems: freebsd-...@freebsd.org >> > > ugen2.3: at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) > pwr=ON (100mA) > > bLength = 0x0012 > bDescriptorType = 0x0001 > bcdUSB = 0x0200 > bDeviceClass = 0x > bDeviceSubClass = 0x > bDeviceProtocol = 0x > bMaxPacketSize0 = 0x0040 > idVendor = 0x0c45 > idProduct = 0x0820 > bcdDevice = 0x0100 > iManufacturer = 0x0001 > iProduct = 0x0002 > iSerialNumber = 0x > bNumConfigurations = 0x0001 > > > Configuration index 0 > > bLength = 0x0009 > bDescriptorType = 0x0002 > wTotalLength = 0x003b > bNumInterfaces = 0x0002 > bConfigurationValue = 0x0001 > iConfiguration = 0x > bmAttributes = 0x00a0 > bMaxPower = 0x0032 > > Interface 0 > bLength = 0x0009 > bDescriptorType = 0x0004 > bInterfaceNumber = 0x > bAlternateSetting = 0x > bNumEndpoints = 0x0001 > bInterfaceClass = 0x0003 > bInterfaceSubClass = 0x0001 > bInterfaceProtocol = 0x0001 > iInterface = 0x > > Additional Descriptor > > bLength = 0x09 > bDescriptorType = 0x21 > bDescriptorSubType = 0x11 >RAW dump: >0x00 | 0x09, 0x21, 0x11, 0x01, 0x00, 0x01, 0x22, 0x4f, >0x08 | 0x00 > > Endpoint 0 > bLength = 0x0007 > bDescriptorType = 0x0005 > bEndpointAddress = 0x0081 > bmAttributes = 0x0003 > wMaxPacketSize = 0x0008 > bInterval = 0x0008 > bRefresh = 0x > bSynchAddress = 0x > > Interface 1 > bLength = 0x0009 > bDescriptorType = 0x0004 > bInterfaceNumber = 0x0001 > bAlternateSetting = 0x > bNumEndpoints = 0x0001 > bInterfaceClass = 0x0003 > bInterfaceSubClass = 0x0001 > bInterfaceProtocol = 0x0002 > iInterface = 0x > > Additional Descriptor > > bLength = 0x09 > bDescriptorType = 0x21 > bDescriptorSubType = 0x11 >RAW dump: >0x00 | 0x09, 0x21, 0x11, 0x01, 0x00, 0x01, 0x22, 0x71, >0x08 | 0x00 > > Endpoint 0 > bLength = 0x0007 > bDescriptorType = 0x0005 > bEndpointAddress = 0x0082 > bmAttributes = 0x0003 > wMaxPacketSize = 0x0040 > bInterval = 0x0001 > bRefresh = 0x > bSynchAddress = 0x > > > > > 18:27:21.923619 usbus2.3 SUBM-CTRL-EP=,SPD=FULL,NFR=1,SLEN=8,IVAL=0 > frame[0] WRITE 8 bytes > 00 05 03 00 00 00 00 00 -- -- -- -- -- -- -- -- || > flags 0x50 > status 0xea3a3 > > 18:27:21.925027 usbus2.3 > DONE-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0 > frame[0] WRITE 8 bytes > flags 0x50 > status 0xca3a1 > > 18:27:21.925048 usbus2.3 SUBM-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0 > frame[0] WRITE 0 bytes > flags 0x10 > status 0xca0a3 > > 18:27:21.927027 usbus2.3 > DONE-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0 > frame[0] WRITE 0 bytes > flags 0x10 > status 0xea0a1 > > 18:27:21.941516 usbus2.3 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 > frame[0] WRITE 8 bytes > 80 06 00 01 00 00 08 00 -- -- -- -- -- -- -- -- || > frame[1] READ 8 bytes > flags 0x10 > status 0xea1a3 > > 18:27:21.943021 usbus2.3 > DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0,ERR=0 > frame[0] WRITE 8 bytes > frame[1] READ 8 bytes >
