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
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: 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
Re: mouse pointer has gone.
On Thu, Jan 16, 2014 at 8:50 AM, Rainer Hurling rhur...@gwdg.de 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.
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: 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 f...@freebsd.org 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: mtree acl support
On Wed, Jan 15, 2014, at 23:11, Tim Kientzle wrote: On Jan 14, 2014, at 6:47 AM, Mark Felder f...@freebsd.org 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 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 f...@freebsd.org 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
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
On Jan 16, 2014, at 12:36 PM, Mark Felder f...@freebsd.org wrote: On Wed, Jan 15, 2014, at 23:11, Tim Kientzle wrote: On Jan 14, 2014, at 6:47 AM, Mark Felder f...@freebsd.org 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
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 ag...@yandex.ru: 14.01.2014, 20:14, Subbsd sub...@gmail.com: On Tue, Jan 14, 2014 at 7:43 PM, Andrey Chernov a...@freebsd.org 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
