Re: [RFC/RFT] calloutng
Alexander Motin m...@freebsd.org wrote: Experiments with dummynet shown ineffective support for very short tick-based callouts. New version fixes that, allowing to get as many tick-based callout events as hz value permits, while still be able to aggregate events and generating minimum of interrupts. Also this version modifies system load average calculation to fix some cases existing in HEAD and 9 branches, that could be fixed with new direct callout functionality. http://people.freebsd.org/~mav/calloutng_12_17.patch With this patch (and the previous one, I didn't test the others) my mouse cursor is occasionally not reacting for short amounts of time (less than a second, but long enough to be noticeable). Every now and then the window manager (i3-wm) changes window focus which could be explained by either phantom keyboard or mouse input, or terminal lines are marked as if the cursor was moved with the left button pressed. The problems happen a couple of times per hour but I haven't been able to intentionally reproduce them. They only seem to occur while I'm moving the cursor, but of course I wouldn't otherwise notice a unresponsive cursor anyway. While the cursor is unresponsive, keyboard input and the rest of the system works as expected as far as I can tell. If I set debug.psm.loglevel=4 I get a psm0: lost interrupt? message once per second when not moving the mouse, however that also happens without the patch and thus might be unrelated. I'm using moused. I'm not sure what additional information is necessary to debug this, so here a bunch of sysctl values that may or may not be relevant: fk@r500 ~ $sysctl kern.eventtimer kern.timecounter kern.eventtimer.et.i8254.flags: 1 kern.eventtimer.et.i8254.frequency: 1193182 kern.eventtimer.et.i8254.quality: 100 kern.eventtimer.et.HPET.flags: 3 kern.eventtimer.et.HPET.frequency: 14318180 kern.eventtimer.et.HPET.quality: 450 kern.eventtimer.et.HPET1.flags: 3 kern.eventtimer.et.HPET1.frequency: 14318180 kern.eventtimer.et.HPET1.quality: 440 kern.eventtimer.et.HPET2.flags: 3 kern.eventtimer.et.HPET2.frequency: 14318180 kern.eventtimer.et.HPET2.quality: 440 kern.eventtimer.et.HPET3.flags: 3 kern.eventtimer.et.HPET3.frequency: 14318180 kern.eventtimer.et.HPET3.quality: 440 kern.eventtimer.choice: HPET(450) HPET1(440) HPET2(440) HPET3(440) i8254(100) kern.eventtimer.singlemul: 2 kern.eventtimer.idletick: 0 kern.eventtimer.activetick: 1 kern.eventtimer.timer: HPET kern.eventtimer.periodic: 0 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.i8254.counter: 25970 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.HPET.counter: 3963519587 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.quality: 950 kern.timecounter.tc.ACPI-fast.mask: 16777215 kern.timecounter.tc.ACPI-fast.counter: 7323739 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.quality: 900 kern.timecounter.tc.TSC.mask: 4294967295 kern.timecounter.tc.TSC.counter: 454465294 kern.timecounter.tc.TSC.frequency: 1995040520 kern.timecounter.tc.TSC.quality: -1000 kern.timecounter.stepwarnings: 0 kern.timecounter.hardware: HPET kern.timecounter.choice: TSC(-1000) ACPI-fast(900) HPET(950) i8254(0) dummy(-100) kern.timecounter.tick: 1 kern.timecounter.fast_gettime: 1 kern.timecounter.invariant_tsc: 1 kern.timecounter.smp_tsc: 0 The system is a Lenovo R500 with a Intel(R) Core(TM)2 Duo CPU T5870 @ 2.00GHz (1995.04-MHz K8-class CPU) Fabian signature.asc Description: PGP signature
Re: ipv6_addrs_IF aliases in rc.conf(5)
On Wed, Dec 19, 2012 at 11:47 PM, Kimmo Paasiala kpaas...@gmail.com wrote: On Wed, Dec 19, 2012 at 3:46 PM, Łukasz Wąsikowski luk...@wasikowski.net wrote: W dniu 2012-12-19 07:14, Kimmo Paasiala pisze: I wrote a small patch for /etc/network.subr to add support for ipv6_addrs_IF aliases in rc.conf(5) to match the already existing ipv4_addrs_IF aliases for ipv4 addresses. With this patch the ipv6 aliases can be written like: [...] Did anyone try my patch? I thought it would be nice to have the ipv6_addrs_IF syntax supported to complement the existing ipv4_addrs_IF alias syntax. Can I use range syntax in it like in ipv4? I mean something like: ipv4_addrs_lagg0=x.x.x.10-30/22 That feature would be very nice to have for ipv6. -- best regards, Lukasz Wasikowski I have to admit I overlooked the possibility to use ranges like that. It doesn't look too hard to add that feature as well for ipv6 aliases using the existing code for ipv4 aliases. I'll prepare a new patch and update the PR when I have it working. -Kimmo A question related to this for those who have been doing work on the rc(8) scripts. Can I assume that /usr/bin is available when network.subr functions are used? Doing calculations on hexadecimal numbers is going to be very awkward if I can't use for example bc(1). -Kimmo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: clang compiled kernel panic when mounting zfs root on i386
18.12.2012 00:20, Andriy Gapon: It's been already mentioned many times that ZFS works much better on amd64. It's up to a (potential) user to understand limitations of i386 and to decide whether to use ZFS, in what situations and how. You may want to consider using KSTACK_PAGES=4 in your kernel configuration. For last two fays my system seems stable on kernel compiled with KSTACK_PAGES=4 and WITH_CLANG_IS_CC. -- Sphinx of black quartz, judge my vow. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC/RFT] calloutng
On 20.12.2012 12:56, Fabian Keil wrote: Alexander Motin m...@freebsd.org wrote: Experiments with dummynet shown ineffective support for very short tick-based callouts. New version fixes that, allowing to get as many tick-based callout events as hz value permits, while still be able to aggregate events and generating minimum of interrupts. Also this version modifies system load average calculation to fix some cases existing in HEAD and 9 branches, that could be fixed with new direct callout functionality. http://people.freebsd.org/~mav/calloutng_12_17.patch With this patch (and the previous one, I didn't test the others) my mouse cursor is occasionally not reacting for short amounts of time (less than a second, but long enough to be noticeable). Every now and then the window manager (i3-wm) changes window focus which could be explained by either phantom keyboard or mouse input, or terminal lines are marked as if the cursor was moved with the left button pressed. The problems happen a couple of times per hour but I haven't been able to intentionally reproduce them. They only seem to occur while I'm moving the cursor, but of course I wouldn't otherwise notice a unresponsive cursor anyway. While the cursor is unresponsive, keyboard input and the rest of the system works as expected as far as I can tell. If I set debug.psm.loglevel=4 I get a psm0: lost interrupt? message once per second when not moving the mouse, however that also happens without the patch and thus might be unrelated. I'm using moused. Could you try to revert part of the patch, related to dev/atkbdc? I am not strong in details of that hardware, but in comments there mention that they are related. May be lost keyboard interrupts (which polling rate was increased to 1 second) cause PS/2 mouse delays. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipv6_addrs_IF aliases in rc.conf(5)
On Thu, Dec 20, 2012 at 01:04:34PM +0200, Kimmo Paasiala wrote: A question related to this for those who have been doing work on the rc(8) scripts. Can I assume that /usr/bin is available when network.subr functions are used? Doing calculations on hexadecimal numbers is going to be very awkward if I can't use for example bc(1). You cannot assume that /usr/bin is available when setting up the network. It may be that /usr is mounted via NFS. You can use hexadecimal numbers (prefixed with 0x) in $((...)) expressions. In FreeBSD 9.0 or newer, sh has a printf builtin you can use; in older versions you can use hexdigit and hexprint from network.subr. -- Jilles Tjoelker ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC/RFT] calloutng
Alexander Motin m...@freebsd.org wrote: On 20.12.2012 12:56, Fabian Keil wrote: Alexander Motin m...@freebsd.org wrote: Experiments with dummynet shown ineffective support for very short tick-based callouts. New version fixes that, allowing to get as many tick-based callout events as hz value permits, while still be able to aggregate events and generating minimum of interrupts. Also this version modifies system load average calculation to fix some cases existing in HEAD and 9 branches, that could be fixed with new direct callout functionality. http://people.freebsd.org/~mav/calloutng_12_17.patch With this patch (and the previous one, I didn't test the others) my mouse cursor is occasionally not reacting for short amounts of time (less than a second, but long enough to be noticeable). Every now and then the window manager (i3-wm) changes window focus which could be explained by either phantom keyboard or mouse input, or terminal lines are marked as if the cursor was moved with the left button pressed. The problems happen a couple of times per hour but I haven't been able to intentionally reproduce them. They only seem to occur while I'm moving the cursor, but of course I wouldn't otherwise notice a unresponsive cursor anyway. While the cursor is unresponsive, keyboard input and the rest of the system works as expected as far as I can tell. If I set debug.psm.loglevel=4 I get a psm0: lost interrupt? message once per second when not moving the mouse, however that also happens without the patch and thus might be unrelated. I'm using moused. Could you try to revert part of the patch, related to dev/atkbdc? I am not strong in details of that hardware, but in comments there mention that they are related. May be lost keyboard interrupts (which polling rate was increased to 1 second) cause PS/2 mouse delays. I reverted the changes to sys/dev/atkbdc/* about an hour ago and so far it's looking good. I'll report back tomorrow after some more testing. Fabian signature.asc Description: PGP signature
Re: [RFC/RFT] calloutng
On 20.12.2012 15:26, Fabian Keil wrote: Alexander Motin m...@freebsd.org wrote: On 20.12.2012 12:56, Fabian Keil wrote: Alexander Motin m...@freebsd.org wrote: Experiments with dummynet shown ineffective support for very short tick-based callouts. New version fixes that, allowing to get as many tick-based callout events as hz value permits, while still be able to aggregate events and generating minimum of interrupts. Also this version modifies system load average calculation to fix some cases existing in HEAD and 9 branches, that could be fixed with new direct callout functionality. http://people.freebsd.org/~mav/calloutng_12_17.patch With this patch (and the previous one, I didn't test the others) my mouse cursor is occasionally not reacting for short amounts of time (less than a second, but long enough to be noticeable). Every now and then the window manager (i3-wm) changes window focus which could be explained by either phantom keyboard or mouse input, or terminal lines are marked as if the cursor was moved with the left button pressed. The problems happen a couple of times per hour but I haven't been able to intentionally reproduce them. They only seem to occur while I'm moving the cursor, but of course I wouldn't otherwise notice a unresponsive cursor anyway. While the cursor is unresponsive, keyboard input and the rest of the system works as expected as far as I can tell. If I set debug.psm.loglevel=4 I get a psm0: lost interrupt? message once per second when not moving the mouse, however that also happens without the patch and thus might be unrelated. I'm using moused. Could you try to revert part of the patch, related to dev/atkbdc? I am not strong in details of that hardware, but in comments there mention that they are related. May be lost keyboard interrupts (which polling rate was increased to 1 second) cause PS/2 mouse delays. I reverted the changes to sys/dev/atkbdc/* about an hour ago and so far it's looking good. I'll report back tomorrow after some more testing. Thank you for the report. If it will be fine. you can try to reapply that part of the patch, just changing line: callout_reset_flags(sc-callout, hz, atkbdtimeout, dev, C_PRELSET(0)); to the: callout_reset_flags(sc-callout, hz/10, atkbdtimeout, dev, C_PRELSET(0)); It should about to restore original polling interval, but still make it more flexible then original. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC/RFT] calloutng
Alexander Motin m...@freebsd.org wrote: On 20.12.2012 15:26, Fabian Keil wrote: Alexander Motin m...@freebsd.org wrote: On 20.12.2012 12:56, Fabian Keil wrote: Alexander Motin m...@freebsd.org wrote: Experiments with dummynet shown ineffective support for very short tick-based callouts. New version fixes that, allowing to get as many tick-based callout events as hz value permits, while still be able to aggregate events and generating minimum of interrupts. Also this version modifies system load average calculation to fix some cases existing in HEAD and 9 branches, that could be fixed with new direct callout functionality. http://people.freebsd.org/~mav/calloutng_12_17.patch With this patch (and the previous one, I didn't test the others) my mouse cursor is occasionally not reacting for short amounts of time (less than a second, but long enough to be noticeable). Could you try to revert part of the patch, related to dev/atkbdc? I am not strong in details of that hardware, but in comments there mention that they are related. May be lost keyboard interrupts (which polling rate was increased to 1 second) cause PS/2 mouse delays. I reverted the changes to sys/dev/atkbdc/* about an hour ago and so far it's looking good. I'll report back tomorrow after some more testing. Thank you for the report. If it will be fine. you can try to reapply that part of the patch, just changing line: callout_reset_flags(sc-callout, hz, atkbdtimeout, dev, C_PRELSET(0)); to the: callout_reset_flags(sc-callout, hz/10, atkbdtimeout, dev, C_PRELSET(0)); It should about to restore original polling interval, but still make it more flexible then original. With this change the mouse stops working completely after moving the cursor a couple of pixels, at which point dmesg shows: kbdc: TEST_AUX_PORT status: kbdc: RESET_AUX return code:00fa kbdc: RESET_AUX status:00aa kbdc: RESET_AUX ID: Using the keyboard frequently causes duplicated characters. I'm aware of a problem in vanilla CURRENT where the mouse stops working with similar looking messages when the cursor is being moved at the wrong moment, but this happens less than once a week and I haven't been able to track it down yet. It's possible that it's the same bug and your patch just triggers it more reliable (two times in a row). I haven't seen the duplicated-characters issue before, though. Just for kicks I also tried: callout_reset_flags(sc-callout, hz/100, atkbdtimeout, dev, C_PRELSET(0)); but with this modification I can't even enter my login password and thus can't tell if the mouse would work. Fabian signature.asc Description: PGP signature
Re: HEADS UP: FreeBSD git mirrors demoted to beta status, need your help
Ulrich, Are you still hoping for feedback on this? If so I am currently setting up to run your scripts from: http://wiki.freebsd.org/GitWorkflow#History Let me know if that is not needed though because if I don't need to then I can save myself a bunch of work. I'll report back to you on my success or not. -Alfred On 12/15/12 5:22 AM, Ulrich Spörlein wrote: Bad news everyone, tl;dr The git mirror of the source repository needs to be re-rolled to make the conversion deterministically repeatable, this will change pretty much all git commit hashes. The re-roll will be done January 15, 2013. Not affected are the ports and doc repositories, nor is the svn_head (for use with git-svn) affected. Background The converter (svn2git) was handing commits and objects to git's fast-import in arbitrary order, this makes merge commits have an arbitrary order of their parent commits and thus these merge commits have changing commit hashes for each converter run. This has been fixed, but requires us to move all the branches over to this deterministic scheme, which will change all their commit hashes. None of the contents of these commits change, so rebasing/remerging your work into these branches is possible without running into any merge conflicts. We need your help A goal of these conversions is to have them repeatable by you (yes, you!), so the correctness of the conversion can be verified. There are also no backups of the conversion runs, as they should be repeatable anyway. We need 2-3 volunteers to run these conversions themselves and verify that the produced commit hashes match the published ones. The necessary steps to do this are documented on the Wiki under http://wiki.freebsd.org/GitWorkflow#History Please send me your output of git show-ref in a private mail, thanks. Cheers, Uli PS: This re-roll has nothing to do with the recent security incident. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipv6_addrs_IF aliases in rc.conf(5)
On Thu, Dec 20, 2012 at 3:27 PM, Jilles Tjoelker jil...@stack.nl wrote:
On Thu, Dec 20, 2012 at 01:04:34PM +0200, Kimmo Paasiala wrote:
A question related to this for those who have been doing work on the
rc(8) scripts. Can I assume that /usr/bin is available when
network.subr functions are used? Doing calculations on hexadecimal
numbers is going to be very awkward if I can't use for example bc(1).
You cannot assume that /usr/bin is available when setting up the
network. It may be that /usr is mounted via NFS.
You can use hexadecimal numbers (prefixed with 0x) in $((...))
expressions. In FreeBSD 9.0 or newer, sh has a printf builtin you can
use; in older versions you can use hexdigit and hexprint from
network.subr.
--
Jilles Tjoelker
Thanks, I've rewitten my patch to support ranges. It is attached in
this message.
Again it's against a very recent 9-STABLE, I still haven't found time
to see if it applies to CURRENT.
It does allow you to do crazy stuff like
ipv6_addrs_re0=2001:db8::::1-/64
However I didn't find anything to limit the number of aliases in the
ipv4 version of the function either.
Please test it :)
Then a question about the PR
(http://www.freebsd.org/cgi/query-pr.cgi?pr=174225) I wrote, how can I
attach this new patch to it? The submit follow up -button fires up my
email client and I'm not so sure how to submit a new patch for the PR
in an email in such a way that it appears properly formatted in the
PR.
Regards,
Kimmo Paasiala
Index: network.subr
===
--- network.subr(revision 244523)
+++ network.subr(working copy)
@@ -562,6 +562,7 @@
fi
ifalias_up ${_if} inet6 _ret=0
+ ipv6_addrs_common ${_if} alias _ret=0
ipv6_prefix_hostid_addr_common ${_if} alias _ret=0
ipv6_accept_rtadv_up ${_if} _ret=0
@@ -684,6 +685,49 @@
return $_ret
}
+
+ipv6_addrs_common()
+{
+ local _ret _if _action _ip6prefix _ip6prefixes
+ local _ip6addr _prefixlen
+ local _range _ip6net _ip6low _ip6high
+ _ret=1
+ _if=$1
+ _action=$2
+
+# get the prefixes from ipv6_addrs_IF variable
+ _ip6prefixes=`get_if_var $_if ipv6_addrs_IF`
+ for _ip6prefix in ${_ip6prefixes}; do
+ _ip6addr=${_ip6prefix%%/*}
+ _prefixlen=${_ip6prefix##*/}
+ _range=${_ip6addr##*:}
+ _ip6net=${_ip6addr%:*}
+ _ip6low=${_range%-*}
+ _ip6high=${_range#*-}
+
+# If deleting an alias, set _prefixlen to null string.
+ if [ ${_action} = -alias ]; then
+ _prefixlen=
+ else
+ _prefixlen=prefixlen $_prefixlen
+ fi
+
+ _ip6high=$((0x${_ip6high}))
+ _ip6count=$((0x${_ip6low}))
+ while [ ${_ip6count} -le ${_ip6high} ]; do
+# Re-uses the _ip6addr variable from above
+ _ip6addr=$(printf %x ${_ip6count})
+ eval ifconfig ${_if} inet6 ${_ip6net}:${_ip6addr}
${_prefixlen} ${_action}
+ _ip6count=$((${_ip6count}+1))
+ _ret=0
+ done
+ done
+
+ return $_ret
+}
+
+
+
# ifalias_up if af
# Configure aliases for network interface $if.
# It returns 0 if at least one alias was configured or
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
