[Bug 202607] [panic] Poudriere umounting file systems causes 'solaris assert: avl_is_empty(&dn->dn_dbufs)' panic

2015-09-23 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202607 --- Comment #17 from Andriy Gapon --- I agree that in this case there is no problem and the buffer gets evicted very soon. However, I wonder if we could somehow avoid this kind of a situation in a higher level code or if we could detect it

[Bug 202607] [panic] Poudriere umounting file systems causes 'solaris assert: avl_is_empty(&dn->dn_dbufs)' panic

2015-09-23 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202607 Andriy Gapon changed: What|Removed |Added Assignee|freebsd-bugs@FreeBSD.org|freebsd...@freebsd.org -- You are

[Bug 203279] /bin/expr operator : fails when the string has a leading hyphen.

2015-09-23 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203279 Bug ID: 203279 Summary: /bin/expr operator : fails when the string has a leading hyphen. Product: Base System Version: 10.2-RELEASE Hardware: Any OS:

[Bug 190447] sshd is loaded too late in startup

2015-09-23 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190447 Kurt Jaeger changed: What|Removed |Added Assignee|freebsd-bugs@FreeBSD.org|p...@freebsd.org CC|

[Bug 203284] arm64: bogus CPU % accounting in top

2015-09-23 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203284 Bug ID: 203284 Summary: arm64: bogus CPU % accounting in top Product: Base System Version: 11.0-CURRENT Hardware: arm64 OS: Any Status: New Severity

[Bug 203288] axge(4) panics on unplug

2015-09-23 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203288 Bug ID: 203288 Summary: axge(4) panics on unplug Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some

[Bug 195970] emulators/virtualbox-ose-kmod & memory allocator problem: "dd: stdout: Cannot allocate memory"

2015-09-23 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195970 --- Comment #3 from Martin Birgmeier --- I have tried to refine the scenario where the problem appears, and the results are as follows. - I run a 3 GB VB client on an 8 GB machine - On this machine I start a dd with a blocksize of 128k to c

[Bug 195970] emulators/virtualbox-ose-kmod & memory allocator problem: "dd: stdout: Cannot allocate memory"

2015-09-23 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195970 Larry Rosenman changed: What|Removed |Added CC||l...@lerctr.org --- Comment #4 fr

[Bug 195970] emulators/virtualbox-ose-kmod & memory allocator problem: "dd: stdout: Cannot allocate memory"

2015-09-23 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195970 --- Comment #5 from Martin Birgmeier --- It is 512. I tried to increase it right away, but alas it is a loader tunable only, and I cannot reboot right now. May I ask why you think this is related, and what problem you experienced? -- Mar

[Bug 195970] emulators/virtualbox-ose-kmod & memory allocator problem: "dd: stdout: Cannot allocate memory"

2015-09-23 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195970 --- Comment #6 from Larry Rosenman --- I was seeing weird messages about not being able to allocate memory on SSH sessions and with zfs(1) sends. Someone back a while suggested it, and the problems went away when I added this tunable. A