Re: SCHED_ULE bug (was Re: cpuminer mines only on one core regardless of "--threads" option)
On 16.01.2014 11:20, Alexander wrote: > > > 14.01.2014, 22:32, "Alexander" : >> 14.01.2014, 20:14, "Subbsd" : >> >>> On Tue, Jan 14, 2014 at 7:43 PM, Andrey Chernov wrote: On 14.01.2014 17:01, Alexander wrote: > on Freebsd 9.2 x64 on 5 different PCs I installed net-p2p/cpuminer > from ports and by "pkg install" - result is the same - minerd mines > only on one core regardless of "--threads" option. ... > # top -P > CPU 0: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle > CPU 1: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle > CPU 2: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle > CPU 3: 0.0% user, 100% nice, 0.0% system, 0.0% interrupt, 0.0% idle This is SCHED_ULE bug, I see _all_ processes (not minerd only in particular) stuck to the last CPU too (top's 'C' column is equal to the last CPU and never changes), latest -stable i386. It disappears for me switching to SCHED_4BSD. >> >> reboot didn't help (try on 3 different PCs) > ... > minerd was started from cron after reboot immediately and broke SMP, so when > I disable minerd from cron and reboot - SMP works fine. > I think Andrey Chernov said here the reason > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/163585#reply3 > So this bug is alive - on 9.1 and 9.2 x64 releases. > I didn't try SCHED_4BSD yet, cause don't wont to use not-generic kernel > because of mining only, but for interest I'll try it on one machine on this > weekends. I just try it on latest x64 -current, result is exact the same: the bug exist with SCHED_ULE and not with SCHED_4BSD. Something is very wrong in SCHED_ULE+cpuset_setaffinity chain. ___ 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: mtree acl support
On Jan 16, 2014, at 12:36 PM, Mark Felder wrote: > On Wed, Jan 15, 2014, at 23:11, Tim Kientzle wrote: >> >> On Jan 14, 2014, at 6:47 AM, Mark Felder wrote: >> >>> I was recently talking to someone about how one would backup / restore >>> ACLs reliably. I didn't see any mention of ACLs in the mtree man page >>> and after a quick google I came upon this old mailing list post: >>> >>> http://lists.freebsd.org/pipermail/freebsd-hackers/2008-April/024173.html >>> >>> patch in list is here: http://heka.cenkes.org/sat/diffs/mtree_acl.diff >>> I've mirrored it here: https://feld.me/freebsd/mtree_acl.diff >>> >>> This old patch appears to still apply cleanly. I hate to see a patch die >>> and be forgotten. >> >> One problem that ‘tar’ has addressed (inspired by Joerg Schilling’s >> work on star) is to permit ACLs to be restored even if the user database >> is out of date. >> >> This is done by including a fourth field in each ACE with the >> numeric user ID. >> >> I suspect you want to do the same for mtree. I thought >> I remembered acl_to_text having an option to use >> an extended text format, so it might be a trivial change. >> > > As long as it's not default. One of the most convenient ways to change a > user's UID (or multiple users!) is to do an mtree backup, change > UID/GID, and then re-apply mtree backup. Every file that the user(s) > previously owned will be automatically changed to the new UID/GID for > you :-) The extended format stores both name and numeric ID. It tries to restore by name first (looking up as necessary), then falls back on ID if that fails. So this does correctly handle your case. This also lets you restore trees when user lookups are unavailable. For example, user lookups may be broken because of permission problems that you’re trying to fix with mtree. ;-) Tim ___ 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"
picking a new AF_* number for NETLINK ?
In porting the kernel openvswitch code to FreeBSD we have implemented netlink sockets, so we need to pick a number to use for AF_NETLINK/PF_NETLINK in the messages. Obviously we'd like ovs to be loadable as a module on existing kernels, so i wonder if there are any restrictions on what we can use -- specifically, whether we should make sure that AF_NETLINK < AF_MAX or that is irrelevant. cheers luigi ___ 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: mtree acl support
Wiadomość napisana przez Mark Felder w dniu 16 sty 2014, o godz. 21:36:
> On Wed, Jan 15, 2014, at 23:11, Tim Kientzle wrote:
>>
>> On Jan 14, 2014, at 6:47 AM, Mark Felder wrote:
>>
>>> I was recently talking to someone about how one would backup / restore
>>> ACLs reliably. I didn't see any mention of ACLs in the mtree man page
>>> and after a quick google I came upon this old mailing list post:
>>>
>>> http://lists.freebsd.org/pipermail/freebsd-hackers/2008-April/024173.html
>>>
>>> patch in list is here: http://heka.cenkes.org/sat/diffs/mtree_acl.diff
>>> I've mirrored it here: https://feld.me/freebsd/mtree_acl.diff
>>>
>>> This old patch appears to still apply cleanly. I hate to see a patch die
>>> and be forgotten.
>>
>> One problem that ‘tar’ has addressed (inspired by Joerg Schilling’s
>> work on star) is to permit ACLs to be restored even if the user database
>> is out of date.
>>
>> This is done by including a fourth field in each ACE with the
>> numeric user ID.
>>
>> I suspect you want to do the same for mtree. I thought
>> I remembered acl_to_text having an option to use
>> an extended text format, so it might be a trivial change.
>>
>
> As long as it's not default. One of the most convenient ways to change a
> user's UID (or multiple users!) is to do an mtree backup, change
> UID/GID, and then re-apply mtree backup. Every file that the user(s)
> previously owned will be automatically changed to the new UID/GID for
> you :-)
I don't think the functionality above would interfere with that in any way.
The owner entries ("user:" for POSIX, "owner@" for NFSv4 ACLs) are stored
in a different way, and they never have the appended ID.
(Besides, why not just "find ./ -user XXX -print0 | xargs -0 chown YYY"?)
--
If you cut off my head, what would I say? Me and my head, or me and my body?
___
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: mtree acl support
On Wed, Jan 15, 2014, at 23:11, Tim Kientzle wrote: > > On Jan 14, 2014, at 6:47 AM, Mark Felder wrote: > > > I was recently talking to someone about how one would backup / restore > > ACLs reliably. I didn't see any mention of ACLs in the mtree man page > > and after a quick google I came upon this old mailing list post: > > > > http://lists.freebsd.org/pipermail/freebsd-hackers/2008-April/024173.html > > > > patch in list is here: http://heka.cenkes.org/sat/diffs/mtree_acl.diff > > I've mirrored it here: https://feld.me/freebsd/mtree_acl.diff > > > > This old patch appears to still apply cleanly. I hate to see a patch die > > and be forgotten. > > One problem that ‘tar’ has addressed (inspired by Joerg Schilling’s > work on star) is to permit ACLs to be restored even if the user database > is out of date. > > This is done by including a fourth field in each ACE with the > numeric user ID. > > I suspect you want to do the same for mtree. I thought > I remembered acl_to_text having an option to use > an extended text format, so it might be a trivial change. > As long as it's not default. One of the most convenient ways to change a user's UID (or multiple users!) is to do an mtree backup, change UID/GID, and then re-apply mtree backup. Every file that the user(s) previously owned will be automatically changed to the new UID/GID for you :-) ___ 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: mtree acl support
Wiadomość napisana przez Tim Kientzle w dniu 16 sty 2014, o godz. 06:11: > On Jan 14, 2014, at 6:47 AM, Mark Felder wrote: > >> I was recently talking to someone about how one would backup / restore >> ACLs reliably. I didn't see any mention of ACLs in the mtree man page >> and after a quick google I came upon this old mailing list post: >> >> http://lists.freebsd.org/pipermail/freebsd-hackers/2008-April/024173.html >> >> patch in list is here: http://heka.cenkes.org/sat/diffs/mtree_acl.diff >> I've mirrored it here: https://feld.me/freebsd/mtree_acl.diff >> >> This old patch appears to still apply cleanly. I hate to see a patch die >> and be forgotten. > > One problem that ‘tar’ has addressed (inspired by Joerg Schilling’s > work on star) is to permit ACLs to be restored even if the user database > is out of date. > > This is done by including a fourth field in each ACE with the > numeric user ID. > > I suspect you want to do the same for mtree. I thought > I remembered acl_to_text having an option to use > an extended text format, so it might be a trivial change. It's ACL_TEXT_APPEND_ID, used with acl_to_text_np(3). The other side, acl_from_text(3), already does the right thing when appended IDs are present in the textual form. -- If you cut off my head, what would I say? Me and my head, or me and my body? ___ 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: mouse pointer has gone.
On Thu, 2014-01-16 at 17:50 +0100, Rainer Hurling wrote: > Am 16.01.2014 15:07, schrieb clutton: > > Using X, I have a frozen mouse pointer. > > Mouse works fine from syscons but not from X. Booting from kernel.old > > resolves the problem. > > > > Here is my X log with current kernel. > > > > 158:[34.043] (==) NVIDIA(0): Silken mouse enabled > > 208:[34.232] (II) config/hal: Adding input device PS/2 Mouse > > 209:[34.232] (II) LoadModule: "mouse" > > 210:[34.233] (II) > > Loading /usr/local/lib/xorg/modules/input/mouse_drv.so > > 211:[34.236] (II) Module mouse: vendor="X.Org Foundation" > > 215:[34.237] (II) Using input driver 'mouse' for 'PS/2 Mouse' > > 216:[34.237] (**) PS/2 Mouse: always reports core events > > 218:[34.237] (==) PS/2 Mouse: Protocol: "Auto" > > 219:[34.237] (**) PS/2 Mouse: always reports core events > > 222:[34.238] (EE) PS/2 Mouse: cannot open input device > > 223:[34.238] (EE) PreInit returned 2 for "PS/2 Mouse" > > 224:[34.238] (II) UnloadModule: "mouse" > > > > > > And with kernel.old > > > > 158:[30.743] (==) NVIDIA(0): Silken mouse enabled > > 208:[30.941] (II) config/hal: Adding input device PS/2 Mouse > > 209:[30.941] (II) LoadModule: "mouse" > > 210:[30.942] (II) > > Loading /usr/local/lib/xorg/modules/input/mouse_drv.so > > 211:[30.945] (II) Module mouse: vendor="X.Org Foundation" > > 215:[30.946] (II) Using input driver 'mouse' for 'PS/2 Mouse' > > 216:[30.946] (**) PS/2 Mouse: always reports core events > > 217:[30.946] (**) Option "Device" "/dev/sysmouse" > > 218:[30.946] (==) PS/2 Mouse: Protocol: "Auto" > > 219:[30.946] (**) PS/2 Mouse: always reports core events > > 220:[30.947] (==) PS/2 Mouse: Emulate3Buttons, Emulate3Timeout: 50 > > 221:[30.947] (**) PS/2 Mouse: ZAxisMapping: buttons 4 and 5 > > 222:[30.947] (**) PS/2 Mouse: Buttons: 5 > > 224:[30.947] (II) XINPUT: Adding extended input device "PS/2 > > Mouse" (type: MOUSE, id 7) > > 225:[30.948] (**) PS/2 Mouse: (accel) keeping acceleration scheme 1 > > 226:[30.948] (**) PS/2 Mouse: (accel) acceleration profile 0 > > 227:[30.948] (**) PS/2 Mouse: (accel) acceleration factor: 2.000 > > 228:[30.948] (**) PS/2 Mouse: (accel) acceleration threshold: 4 > > 229:[30.948] (II) PS/2 Mouse: SetupAuto: hw.iftype is 4, hw.model is > > 0 > > 230:[30.948] (II) PS/2 Mouse: SetupAuto: protocol is SysMouse > > > > For me, it helped to rebuild devel/dbus and sysutils/hal and restart > that services again. > > HTH, > Rainer Thanks, I rebuild hald, but I hadn't tried rebuilding dbus. signature.asc Description: This is a digitally signed message part
Re: mouse pointer has gone.
On Thu, Jan 16, 2014 at 8:50 AM, Rainer Hurling wrote: > Am 16.01.2014 15:07, schrieb clutton: > > Using X, I have a frozen mouse pointer. > > Mouse works fine from syscons but not from X. Booting from kernel.old > > resolves the problem. > > > > Here is my X log with current kernel. > > > > 158:[34.043] (==) NVIDIA(0): Silken mouse enabled > > 208:[34.232] (II) config/hal: Adding input device PS/2 Mouse > > 209:[34.232] (II) LoadModule: "mouse" > > 210:[34.233] (II) > > Loading /usr/local/lib/xorg/modules/input/mouse_drv.so > > 211:[34.236] (II) Module mouse: vendor="X.Org Foundation" > > 215:[34.237] (II) Using input driver 'mouse' for 'PS/2 Mouse' > > 216:[34.237] (**) PS/2 Mouse: always reports core events > > 218:[34.237] (==) PS/2 Mouse: Protocol: "Auto" > > 219:[34.237] (**) PS/2 Mouse: always reports core events > > 222:[34.238] (EE) PS/2 Mouse: cannot open input device > > 223:[34.238] (EE) PreInit returned 2 for "PS/2 Mouse" > > 224:[34.238] (II) UnloadModule: "mouse" > > > > > > And with kernel.old > > > > 158:[30.743] (==) NVIDIA(0): Silken mouse enabled > > 208:[30.941] (II) config/hal: Adding input device PS/2 Mouse > > 209:[30.941] (II) LoadModule: "mouse" > > 210:[30.942] (II) > > Loading /usr/local/lib/xorg/modules/input/mouse_drv.so > > 211:[30.945] (II) Module mouse: vendor="X.Org Foundation" > > 215:[30.946] (II) Using input driver 'mouse' for 'PS/2 Mouse' > > 216:[30.946] (**) PS/2 Mouse: always reports core events > > 217:[30.946] (**) Option "Device" "/dev/sysmouse" > > 218:[30.946] (==) PS/2 Mouse: Protocol: "Auto" > > 219:[30.946] (**) PS/2 Mouse: always reports core events > > 220:[30.947] (==) PS/2 Mouse: Emulate3Buttons, Emulate3Timeout: 50 > > 221:[30.947] (**) PS/2 Mouse: ZAxisMapping: buttons 4 and 5 > > 222:[30.947] (**) PS/2 Mouse: Buttons: 5 > > 224:[30.947] (II) XINPUT: Adding extended input device "PS/2 > > Mouse" (type: MOUSE, id 7) > > 225:[30.948] (**) PS/2 Mouse: (accel) keeping acceleration scheme 1 > > 226:[30.948] (**) PS/2 Mouse: (accel) acceleration profile 0 > > 227:[30.948] (**) PS/2 Mouse: (accel) acceleration factor: 2.000 > > 228:[30.948] (**) PS/2 Mouse: (accel) acceleration threshold: 4 > > 229:[30.948] (II) PS/2 Mouse: SetupAuto: hw.iftype is 4, hw.model is > > 0 > > 230:[30.948] (II) PS/2 Mouse: SetupAuto: protocol is SysMouse > > > > For me, it helped to rebuild devel/dbus and sysutils/hal and restart > that services again. > > HTH, > Rainer > sysutils/hal needs rebuilding due to a change in the kernel ABI. It is NOT the only port affected by the change and rebuilding all ports is recommended, but to get the pointer to work only requires a re-built hald. devel/dbus has no problems. I can tell you that you need to also rebuild sysutils/tmux, if you use it. I'll admit to being lazy and have not rebuilt all ports to this point. Only the two ports mentioned have caused any problems, so far. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ 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: mouse pointer has gone.
Am 16.01.2014 15:07, schrieb clutton: > Using X, I have a frozen mouse pointer. > Mouse works fine from syscons but not from X. Booting from kernel.old > resolves the problem. > > Here is my X log with current kernel. > > 158:[34.043] (==) NVIDIA(0): Silken mouse enabled > 208:[34.232] (II) config/hal: Adding input device PS/2 Mouse > 209:[34.232] (II) LoadModule: "mouse" > 210:[34.233] (II) > Loading /usr/local/lib/xorg/modules/input/mouse_drv.so > 211:[34.236] (II) Module mouse: vendor="X.Org Foundation" > 215:[34.237] (II) Using input driver 'mouse' for 'PS/2 Mouse' > 216:[34.237] (**) PS/2 Mouse: always reports core events > 218:[34.237] (==) PS/2 Mouse: Protocol: "Auto" > 219:[34.237] (**) PS/2 Mouse: always reports core events > 222:[34.238] (EE) PS/2 Mouse: cannot open input device > 223:[34.238] (EE) PreInit returned 2 for "PS/2 Mouse" > 224:[34.238] (II) UnloadModule: "mouse" > > > And with kernel.old > > 158:[30.743] (==) NVIDIA(0): Silken mouse enabled > 208:[30.941] (II) config/hal: Adding input device PS/2 Mouse > 209:[30.941] (II) LoadModule: "mouse" > 210:[30.942] (II) > Loading /usr/local/lib/xorg/modules/input/mouse_drv.so > 211:[30.945] (II) Module mouse: vendor="X.Org Foundation" > 215:[30.946] (II) Using input driver 'mouse' for 'PS/2 Mouse' > 216:[30.946] (**) PS/2 Mouse: always reports core events > 217:[30.946] (**) Option "Device" "/dev/sysmouse" > 218:[30.946] (==) PS/2 Mouse: Protocol: "Auto" > 219:[30.946] (**) PS/2 Mouse: always reports core events > 220:[30.947] (==) PS/2 Mouse: Emulate3Buttons, Emulate3Timeout: 50 > 221:[30.947] (**) PS/2 Mouse: ZAxisMapping: buttons 4 and 5 > 222:[30.947] (**) PS/2 Mouse: Buttons: 5 > 224:[30.947] (II) XINPUT: Adding extended input device "PS/2 > Mouse" (type: MOUSE, id 7) > 225:[30.948] (**) PS/2 Mouse: (accel) keeping acceleration scheme 1 > 226:[30.948] (**) PS/2 Mouse: (accel) acceleration profile 0 > 227:[30.948] (**) PS/2 Mouse: (accel) acceleration factor: 2.000 > 228:[30.948] (**) PS/2 Mouse: (accel) acceleration threshold: 4 > 229:[30.948] (II) PS/2 Mouse: SetupAuto: hw.iftype is 4, hw.model is > 0 > 230:[30.948] (II) PS/2 Mouse: SetupAuto: protocol is SysMouse > For me, it helped to rebuild devel/dbus and sysutils/hal and restart that services again. HTH, Rainer ___ 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"
mouse pointer has gone.
Using X, I have a frozen mouse pointer. Mouse works fine from syscons but not from X. Booting from kernel.old resolves the problem. Here is my X log with current kernel. 158:[34.043] (==) NVIDIA(0): Silken mouse enabled 208:[34.232] (II) config/hal: Adding input device PS/2 Mouse 209:[34.232] (II) LoadModule: "mouse" 210:[34.233] (II) Loading /usr/local/lib/xorg/modules/input/mouse_drv.so 211:[34.236] (II) Module mouse: vendor="X.Org Foundation" 215:[34.237] (II) Using input driver 'mouse' for 'PS/2 Mouse' 216:[34.237] (**) PS/2 Mouse: always reports core events 218:[34.237] (==) PS/2 Mouse: Protocol: "Auto" 219:[34.237] (**) PS/2 Mouse: always reports core events 222:[34.238] (EE) PS/2 Mouse: cannot open input device 223:[34.238] (EE) PreInit returned 2 for "PS/2 Mouse" 224:[34.238] (II) UnloadModule: "mouse" And with kernel.old 158:[30.743] (==) NVIDIA(0): Silken mouse enabled 208:[30.941] (II) config/hal: Adding input device PS/2 Mouse 209:[30.941] (II) LoadModule: "mouse" 210:[30.942] (II) Loading /usr/local/lib/xorg/modules/input/mouse_drv.so 211:[30.945] (II) Module mouse: vendor="X.Org Foundation" 215:[30.946] (II) Using input driver 'mouse' for 'PS/2 Mouse' 216:[30.946] (**) PS/2 Mouse: always reports core events 217:[30.946] (**) Option "Device" "/dev/sysmouse" 218:[30.946] (==) PS/2 Mouse: Protocol: "Auto" 219:[30.946] (**) PS/2 Mouse: always reports core events 220:[30.947] (==) PS/2 Mouse: Emulate3Buttons, Emulate3Timeout: 50 221:[30.947] (**) PS/2 Mouse: ZAxisMapping: buttons 4 and 5 222:[30.947] (**) PS/2 Mouse: Buttons: 5 224:[30.947] (II) XINPUT: Adding extended input device "PS/2 Mouse" (type: MOUSE, id 7) 225:[30.948] (**) PS/2 Mouse: (accel) keeping acceleration scheme 1 226:[30.948] (**) PS/2 Mouse: (accel) acceleration profile 0 227:[30.948] (**) PS/2 Mouse: (accel) acceleration factor: 2.000 228:[30.948] (**) PS/2 Mouse: (accel) acceleration threshold: 4 229:[30.948] (II) PS/2 Mouse: SetupAuto: hw.iftype is 4, hw.model is 0 230:[30.948] (II) PS/2 Mouse: SetupAuto: protocol is SysMouse signature.asc Description: This is a digitally signed message part
Re: FreeBSD 10-RC4: Got crash in igb driver
> I work with Jack on FreeBSD network drivers, and we have a patch that we > think might fix this problem. It re-implements the header pull-up code that > was in the driver pre-2.4.0, but with IPv6 support. Alexandre, could you > apply this patch to the igb version in HEAD and try it out on your network? > We can't replicate your setup here. > If it solves your problem, then the next step would be to port the patch to > the ixgbe driver since, as Yonghyeon noted, it looks like that driver will > encounter the same problem. We could then modify em to add IPv6 offload > support as well. > Thanks, - Eric Joyner Can I get in on network drivers, two in particular where I have the hardware involved? Drivers in my case are re, which fails on my motherboard, and athn, not currently present in FreeBSD. I would have NetBSD src tree to compare with, and NetBSD re driver works on my motherboard. Tom ___ 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"
