Re: USB locks up system -- WAS Re: shutdown or acpi problem
On 2014-11-17 08:58, Dag-Erling Smørgrav wrote: Dag-Erling Smørgrav d...@des.no writes: Steve Kargl s...@troutmask.apl.washington.edu writes: I'll try that tomorrow. But, I now know that this is related to using hal from ports. If I comment out both enable_dbus and enable_hal in /etc/rc.conf, the system works as I would expect (ie., usb now works for unplugging devices!). I further suspect that the problems lies in hal_probe_storage, but haven't got too much further. HAL: the gift that keeps on giving. It also has this wonderful feature where it prevents you from unmounting anything you've ever mounted, because it watches for new mountpoints in the system, opens them, and keeps the file descriptors open indefinitely. I know this isn't really germane, but I just couldn't pass up a chance to complain about HAL. Hold on. It *is* germane: hal_probe_storage auto-mounted your USB stick and is holding on to it. If this also happens with mice and keyboards etc., you're probably looking at two different issues. DES I cursed at HAL a lot because it made uC inside r0ket to crap itself partially... this thing can be USB device but apparently didn't like black magic that HAL did. Maybe it tried to read from the beginning or something. It took lot of time to figure out why it doesn't work. Now I have set of ignore files to prevent grabbing for every single device in system. ___ 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: Changing makeoptions UKBD_DFLT_KEYMAP leads to kernel build fail
Bezüglich Oliver Pinter's Nachricht vom 16.11.2014 12:53 (localtime): On 11/15/14, Dominik Zajac ba...@banym.de wrote: Hi, I am trying to change the default keymap for my keyboard therefore I added the following options to my kernel configuration which leads to the error bellow. Added options: options KBD_INSTALL_CDEV options UKBD_DFLT_KEYMAP makeoptions UKBD_DFLT_KEYMAP=de.iso I tried it with this, too: makeoptions UKBD_DFLT_KEYMAP=german.iso Both leads to the following problem: /usr/src/sys/dev/usb/input/ukbd.c:1209:18: error: use of undeclared identifier 'key_map' sc-sc_keymap = key_map; ^ /usr/src/sys/dev/usb/input/ukbd.c:1210:18: error: use of undeclared identifier 'accent_map' sc-sc_accmap = accent_map; ^ 2 errors generated. *** Error code 1 Hi! See this ticket: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194744 and the related bugs. Is there a dynamic way to change the keyboard layout at boot time to typ the zfs passphrase on my default keyboardlayout? No, you need to change default keymap, like you already found how to. But even if you use the keymap-name matching your current console (unlucky dependency at least since vt and sc use different keymap names, see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193865, already listed as related in Oliver Pinter's BugReport), it most likely won't work for you, since you actually use kbdmux(4) instead ukbd(4) (if you haven't changed in your kernel conf). So first you have to make kbdmux's default keymap customizable (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=153459), then you'll probably want to get rid of the build-dependency of matching keymap-names to the build-machine's active console (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193865). The latter especially for kbdmux, wich is an extra patch you can find in the first BugReport. It's working fine here in some dozend setups, also had feedback that it works, but found none having time to give it a short review and commit it. Wondering why you get error: use of undeclared identifier 'accent_map'; If our active console is vt(4) and you define de or de.kbd [found while writing, you named de.iso!]… -Harry signature.asc Description: OpenPGP digital signature
Re: comments on code-in tasks for FreeBSD (Re: FreeBSD + Google Code-In 2014 = we need ideas.)
On Thu, 13 Nov 2014 19:55:16 -0800 Rui Paulo rpa...@me.com wrote On Nov 13, 2014, at 17:40, Luigi Rizzo ri...@iet.unipi.it wrote: But please nuke the current list -- it is completely inadequate for the code-in candidates and misleading for whoever wants to suggest new tasks. Again i am not saying that the projects suggested there are not important, just belong somewhere else e.g. gsoc. I refrained from voicing my opinion while the call for help was going on, but I completely agree that the target age of this Google initiative is inadequate to FreeBSD. The target population is 13 years to 17 years old and I cannot even imagine a 13 year old knowing what FreeBSD is. I'm not sure we should participate in Code In ever again and perhaps we should focus our efforts on Summer of Code only. @Luigi Very insightful. Thanks for taking the time to share your thoughts. :) @Rui Would tasks in re, or Mk/ be too far off base? --Chris -- Rui Paulo ___ freebsd-hack...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ 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: Changing makeoptions UKBD_DFLT_KEYMAP leads to kernel build fail
Hi Harald, thanks for the detailed answer. I will test this asap. Is there some work planed to make the keyboard layout dynamical changeable? I run into this problem because I have to enter my zfs encryption pass phrase in a different layout than I set it while installation. This maybe confuses others. It would be nice if the installer is able to set the default keymap to the chosen one so you can enter your pass phrase in the same keymap you set it. Dominik On 11/17/2014 02:19 PM, Harald Schmalzbauer wrote: Bezüglich Oliver Pinter's Nachricht vom 16.11.2014 12:53 (localtime): On 11/15/14, Dominik Zajac ba...@banym.de wrote: Hi, I am trying to change the default keymap for my keyboard therefore I added the following options to my kernel configuration which leads to the error bellow. Added options: options KBD_INSTALL_CDEV options UKBD_DFLT_KEYMAP makeoptions UKBD_DFLT_KEYMAP=de.iso I tried it with this, too: makeoptions UKBD_DFLT_KEYMAP=german.iso Both leads to the following problem: /usr/src/sys/dev/usb/input/ukbd.c:1209:18: error: use of undeclared identifier 'key_map' sc-sc_keymap = key_map; ^ /usr/src/sys/dev/usb/input/ukbd.c:1210:18: error: use of undeclared identifier 'accent_map' sc-sc_accmap = accent_map; ^ 2 errors generated. *** Error code 1 Hi! See this ticket: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194744 and the related bugs. Is there a dynamic way to change the keyboard layout at boot time to typ the zfs passphrase on my default keyboardlayout? No, you need to change default keymap, like you already found how to. But even if you use the keymap-name matching your current console (unlucky dependency at least since vt and sc use different keymap names, see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193865, already listed as related in Oliver Pinter's BugReport), it most likely won't work for you, since you actually use kbdmux(4) instead ukbd(4) (if you haven't changed in your kernel conf). So first you have to make kbdmux's default keymap customizable (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=153459), then you'll probably want to get rid of the build-dependency of matching keymap-names to the build-machine's active console (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193865). The latter especially for kbdmux, wich is an extra patch you can find in the first BugReport. It's working fine here in some dozend setups, also had feedback that it works, but found none having time to give it a short review and commit it. Wondering why you get error: use of undeclared identifier 'accent_map'; If our active console is vt(4) and you define de or de.kbd [found while writing, you named de.iso!]… -Harry ___ 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: comments on code-in tasks for FreeBSD (Re: FreeBSD + Google Code-In 2014 = we need ideas.)
On 11/17/14, 6:55 AM, Chris H wrote: On Thu, 13 Nov 2014 19:55:16 -0800 Rui Paulo rpa...@me.com wrote On Nov 13, 2014, at 17:40, Luigi Rizzo ri...@iet.unipi.it wrote: But please nuke the current list -- it is completely inadequate for the code-in candidates and misleading for whoever wants to suggest new tasks. Again i am not saying that the projects suggested there are not important, just belong somewhere else e.g. gsoc. I refrained from voicing my opinion while the call for help was going on, but I completely agree that the target age of this Google initiative is inadequate to FreeBSD. The target population is 13 years to 17 years old and I cannot even imagine a 13 year old knowing what FreeBSD is. I'm not sure we should participate in Code In ever again and perhaps we should focus our efforts on Summer of Code only. @Luigi Very insightful. Thanks for taking the time to share your thoughts. :) @Rui Would tasks in re, or Mk/ be too far off base? [[ cc'd Kris ]] Maybe PCBSD has some ideas for code-in? It's a bit easier on newbies than FreeBSD. Mind you, I was using FreeBSD at 19 years old (would have used it earlier if I'd know about it), coding in assembler at 14... so there are people out there. I just think for it to be something people will want to do it's going to be less edit these text files to improve process and more make dancing daemons happen on the console. -Alfred ___ 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: CFR: AES-GCM and OpenCrypto work review
On 16.11.2014 09:15, John-Mark Gurney wrote: Ok, I was able to reproduce the bug, and found that my optimization for single mbuf packets was broken... I've attached a new patch that has the fix... This patch also has added a lock around the aesni fpu context setting to deal w/ the issue that I had... Let me know how things are w/ this new patch. Hi, with this patch all works as expected. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: CFR: AES-GCM and OpenCrypto work review
Andrey V. Elsukov wrote this message on Mon, Nov 17, 2014 at 21:34 +0300: On 16.11.2014 09:15, John-Mark Gurney wrote: Ok, I was able to reproduce the bug, and found that my optimization for single mbuf packets was broken... I've attached a new patch that has the fix... This patch also has added a lock around the aesni fpu context setting to deal w/ the issue that I had... Let me know how things are w/ this new patch. with this patch all works as expected. Just so you know, even tunnel mode w/ aesni on a clean HEAD can panic.. I just got a: panic: dummy ctx from the tunnel mode by having two machines ping -f'ing each other... This is a different form of the same panic I posted about earlier w/ the fpu context being reused for different threads... I plan on committing the patch w/o the mtx_lock as including the lock will significantly impact people who use geli... I am working on a fix for this w/ kib that will allow us to not allocate an fpu context and get things a little more stable, but there are other bugs that also need to be addressed before aesni is safe to use w/ IPsec... Thanks for testing! -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ 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
Build failed in Jenkins: FreeBSD_HEAD #1863
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/1863/ -- Started by an SCM change Building remotely on jenkins-10.freebsd.org (FreeBSD-10) in workspace https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/ java.io.IOException: remote file operation failed: https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/ at hudson.remoting.Channel@270917b9:jenkins-10.freebsd.org: java.io.IOException: Remote call on jenkins-10.freebsd.org failed at hudson.FilePath.act(FilePath.java:977) at hudson.FilePath.act(FilePath.java:959) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:909) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:844) at hudson.model.AbstractProject.checkout(AbstractProject.java:1258) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:622) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:528) at hudson.model.Run.execute(Run.java:1759) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:89) at hudson.model.Executor.run(Executor.java:240) Caused by: java.io.IOException: Remote call on jenkins-10.freebsd.org failed at hudson.remoting.Channel.call(Channel.java:760) at hudson.FilePath.act(FilePath.java:970) ... 11 more Caused by: java.lang.OutOfMemoryError: PermGen space ___ 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: General Protection Fault in prelist_remove()
On Sat, Nov 15, 2014 at 04:17:35PM -0500, Ryan Stone wrote:
On Mon, Sep 16, 2013 at 1:10 PM, Mark Johnston ma...@freebsd.org wrote:
I've partially fixed this at work by adding a rw lock to protect access
to the the prefix, default router, and DAD lists. The patch is here:
http://people.freebsd.org/~markj/patches/ndp-locking.diff
Hi Mark,
I've hit a bug in this patch today. The problem is in the locking of
the DAD list. Many functions (e.g.
nd6_dad_duplicated) call nd6_dad_find() to look up a dadq structure,
and then manipulate the structure with no lock held. The problem that
once nd6_dad_find() releases the ND lock there is nothing preventing
another thread from going in and free'ing the structure. This causes
a use-after-free in nd6_dad_duplicated. I have a setup which is
somehow triggering DAD on link-local addresses (I don't understand
why; I don't have duplicate mac addresses on the network as best that
I can tell) and with INVARIANTS on I very frequently get a crash in
nd6_dad_duplicated.
It looks to me that the only way to fix it is either introduce
referencing counting into the structure, or push the locking out of
nd6_dad_find() and into the callers. Any opinions?
I spent some time looking at the code. There seem to be a few
miscellaneous bugs in addition to races you described above;
nd6_dad_na_input() can potentially call nd6_dad_duplicated() with a NULL
dadq, for example. I wasn't able to specifically reproduce the
use-after-free that you described, but it's pretty easy to trigger
crashes in the DAD code, e.g. by assigning a duplicate address to an
interface in a loop.
It's hard to fix these races directly because of the different contexts
in which the DAD entry queue is manipulated: entries can be added or
removed with ioctls when addresses are added or removed, the DAD callout
can modify the queue, and nd6_dad_duplicated() can be called in the
packet processing path for some NS or NA packets. It seems to me that
this can be simplified somewhat though, which makes it easier to fix the
races.
The patch below (against HEAD) simplifies the DAD code and tries to fix
remaining races by adding a refcount to struct dadq. Note that hrs@ added a
lock for the DAD queue in r266857, so my ndp-locking patch needs to be
rebased. It simplifies the code by having the DAD callout do most of the
work: when a NS or NA packet indicates that an address is a duplicate,
we just increment a counter and wait for the corresponding DAD callout
to flag the address. With the patch, DAD is only cancelled when the
corresponding address is removed from an interface. It also fixes some
improper handling of the ifa references for struct dadq.
Note that there are still some races around the struct dadq counters
themselves (the increments are non-atomic), and the handling of
in6_flags should be atomic. A copy of the patch is here:
https://people.freebsd.org/~markj/patches/nd6_dad_races.diff
It survives some basic tests and stress testing that previously exposed
some races on HEAD.
Thanks,
-Mark
diff --git a/sys/netinet6/nd6_nbr.c b/sys/netinet6/nd6_nbr.c
index a917b76..819fe30 100644
--- a/sys/netinet6/nd6_nbr.c
+++ b/sys/netinet6/nd6_nbr.c
@@ -51,6 +51,7 @@ __FBSDID($FreeBSD$);
#include sys/syslog.h
#include sys/queue.h
#include sys/callout.h
+#include sys/refcount.h
#include net/if.h
#include net/if_types.h
@@ -1167,6 +1168,7 @@ struct dadq {
int dad_na_icount;
struct callout dad_timer_ch;
struct vnet *dad_vnet;
+ u_int dad_refcnt;
};
static VNET_DEFINE(TAILQ_HEAD(, dadq), dadq);
@@ -1183,12 +1185,22 @@ static VNET_DEFINE(struct rwlock, dad_rwlock);
#defineDADQ_WUNLOCK() rw_wunlock(V_dad_rwlock)
static void
+nd6_dad_rele(struct dadq *dp)
+{
+
+ if (refcount_release(dp-dad_refcnt)) {
+ ifa_free(dp-dad_ifa);
+ free(dp, M_IP6NDP);
+ }
+}
+
+static void
nd6_dad_add(struct dadq *dp)
{
- ifa_ref(dp-dad_ifa); /* just for safety */
+ refcount_acquire(dp-dad_refcnt);
DADQ_WLOCK();
- TAILQ_INSERT_TAIL(V_dadq, (struct dadq *)dp, dad_list);
+ TAILQ_INSERT_TAIL(V_dadq, dp, dad_list);
DADQ_WUNLOCK();
}
@@ -1196,10 +1208,10 @@ static void
nd6_dad_del(struct dadq *dp)
{
- ifa_free(dp-dad_ifa);
DADQ_WLOCK();
- TAILQ_REMOVE(V_dadq, (struct dadq *)dp, dad_list);
+ TAILQ_REMOVE(V_dadq, dp, dad_list);
DADQ_WUNLOCK();
+ nd6_dad_rele(dp);
}
static struct dadq *
@@ -1209,8 +1221,10 @@ nd6_dad_find(struct ifaddr *ifa)
DADQ_RLOCK();
TAILQ_FOREACH(dp, V_dadq, dad_list)
- if (dp-dad_ifa == ifa)
+ if (dp-dad_ifa == ifa) {
+ refcount_acquire(dp-dad_refcnt);
break;
+ }
DADQ_RUNLOCK();
return (dp);
@@ -1228,7 +1242,8 @@ static void
nd6_dad_stoptimer(struct dadq *dp)
{
-
