From mboxrd@z Thu Jan 1 00:00:00 1970 From: Frank Steiner Date: Fri, 01 Oct 2004 06:25:20 +0000 Subject: Re: Hanging udev process on nfs-mounted /dev Message-Id: <415CF850.1050400@bio.ifi.lmu.de> List-Id: References: <415980BF.1020401@bio.ifi.lmu.de> In-Reply-To: <415980BF.1020401@bio.ifi.lmu.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org Kay Sievers wrote > It would be nice to know, if there is posssibly one process spinning at > this time, which blocks all the other processes? Or if there is a "real" > deadlock, where all processes are blocking in the lock call. As far as I remember, when the udev process was running with 90% cpu time, it was the only udev process (pgrep udev). > You may increase the alarm()-timout to have more than 20 seconds to > investigate this :) I will try, but the hosts where the problem occured most frequently are desktop clients of research asisstants. So it is not that easy to debug it without stopping the users from working :-) > Yeah, it does not sound very sane to do concurrent writing to the same > file over nfs without proper locking. A local tmpfs-based /dev seems > more appropriate for that. It should be faster anyway and there is no > reason to store the /dev anywhere while using udev. With debugging and logging enabled now (needed for your patch to compile), I get lots of messages from udev broadcasted to every shell, which is quite annoying for the users, because they get all their xterms filled: Oct 1 05:46:50 noether udevinfo[336]: rec_read bad magic 0xd9fee666 at offsety12 And this about 15 times, every time the card reader reconnects. On the hosts where I already replaces /dev/ with a tmpfs, those messages do not appear at all. Apart from /dev-over-nfs vs. /dev-over-tmpfs there are no differences between these hosts. So it seems that the nfs causes some other problems, that tmpfs is not suffering from. I would like to switch all hosts to tmpfs immediately, but I'm afraid I won't get any deadlocks anymore so that we cannot do useful debugging :-) cu, Frank -- Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/ LMU, Amalienstr. 17 Phone: +49 89 2180-4049 80333 Muenchen, Germany Fax: +49 89 2180-99-4049 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. * ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel