From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756190AbXGIPDV (ORCPT ); Mon, 9 Jul 2007 11:03:21 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753305AbXGIPDO (ORCPT ); Mon, 9 Jul 2007 11:03:14 -0400 Received: from neon.samage.net ([85.17.153.66]:41028 "EHLO neon.samage.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750788AbXGIPDN (ORCPT ); Mon, 9 Jul 2007 11:03:13 -0400 Message-ID: <33435.81.207.0.53.1183993390.squirrel@secure.samage.net> In-Reply-To: References: <200707061620.44348.duncan.sands@math.u-psud.fr> <58019.81.207.0.53.1183749400.squirrel@secure.samage.net> <59741.81.207.0.53.1183977750.squirrel@secure.samage.net> <3ae72650707090659g283f8de8t1f6494c8acf31425@mail.gmail.com> Date: Mon, 9 Jul 2007 17:03:10 +0200 (CEST) Subject: Re: understanding firmware loader for speedtouch (kernel 2.6.21.5) From: "Indan Zupancic" To: "mikie" Cc: "Kay Sievers" , "Duncan Sands" , linux-kernel@vger.kernel.org User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20070709170310_14227" X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: -1.8 X-Scan-Signature: 9484ae446d4f83cee8bf28db5146d16c Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org ------=_20070709170310_14227 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit On Mon, July 9, 2007 16:40, mikie wrote: > 2007/7/9, Kay Sievers : >> On 7/9/07, mikie wrote: >> > 2007/7/9, Indan Zupancic : >> > > On Mon, July 9, 2007 10:49, mikie wrote: >> > > > 2007/7/6, Indan Zupancic : >> > > >> On Fri, July 6, 2007 16:20, Duncan Sands wrote: >> > > >> > On Friday 6 July 2007 14:54:18 mikie wrote: >> > > >> >> Hi, >> > > >> >> >> > > >> >> I experience some problems with the speedtch.c module, especially in >> > > >> >> regards to its firmware loader. >> > > >> >> I am not quite sure if this module is going to load the firmware >> > > >> >> itself or does it use some external software to do that ? >> > > >> > >> > > >> > It loads it itself, using some external software! >> > > >> >> > > >> For information, it generates a hotplug event and the kernel calls the >> > > >> program written at /proc/sys/kernel/hotplug with certain information. >> > > >> That used to be /sbin/hotplug, became later udev, but today in general >> > > >> udev reads the uevents generated by the kernel. >> > > > >> > > > On my system the /proc/sys/kernel/hotplug points to /sbin/hotplug. >> > > > I copied your script to /sbin/hotplug and also added simple logging, >> > > > so I can see whenever the script is being started. It turns out that >> > > > the script is not started at all by the kernel... >> > > > >> > > > I am afraid that the kernel generates uevents only, could this be true? >> > > >> > > Not really, it would break backward compatibility, and if it were true, >> > > they're remove the /proc/sys/kernel/hotplug setting too. As far as I know, >> > > if it's set, that program will be executed, and if zero is written to it, only >> > > uevents are generated. >> > > >> > > Make sure that the script is executable (chmod +x) >> > >> > Yes I have set it to be executable: >> > root@srv:/sbin# ls -lah hotplug >> > -rwxr-xr-x 1 root root 934 Jul 9 09:13 hotplug >> > >> > > and has "#!/bin/sh" >> > > at the top, or else it won't work. If that's already the case, I've no idea. >> > >> > root@srv:/sbin# head hotplug >> > #!/bin/sh >> > set -e >> > >> > >> > Everything looks OK, but still it does not fire up the script... >> >> It should run, if the kernel creates events. Can you run "udevmonitor >> --env" while loading the driver? That way we can see if events are >> generated by the kernel (if you don't have it, no need to install >> udev, just download the udev tarball, type "make" and run >> "./udevmonitor --env"). > > It seems that uevents are generated: What if you run a very simple script like #!/bin/sh echo "test" >> /tmp/test is it called at all? If it is then it's probably something with the other script. Try removing the set -e and/or run it manually with the right parameters set and see if anything goes wrong. Or use a minimal udev and let it do the hotplugging, having only rules for speedtouch and firmware loading (attached, but make sure the paths and pppd call is correct for your system). /dev can stay static, just change udev.conf to handle /udev or something. Regards, Indan ------=_20070709170310_14227 Content-Type: application/octet-stream; name="speedtch.rules" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="speedtch.rules" QUNUSU9OPT0iYWRkIiwgU1VCU1lTVEVNPT0iZmlybXdhcmUiLCBFTlZ7RklSTVdBUkV9PT0iPyoi LCBSVU4rPSIvbGliL3VkZXYvZmlybXdhcmUuc2giCgojIGFkZEAvY2xhc3MvYXRtL3NwZWVkdGNo MApBQ1RJT049PSJhZGQiLCBTVUJTWVNURU09PSJhdG0iLCBLRVJORUw9PSJzcGVlZHRjaCoiIFJV Tj0iL3Vzci9zYmluL3BwcGQgY2FsbCBzcGVlZHRjaCIKCkFDVElPTj09InJlbW92ZSIsIFNVQlNZ U1RFTT09ImF0bSIsIEtFUk5FTD09InNwZWVkdGNoKiIgUlVOPSIvdXNyL2Jpbi9wa2lsbCBwcHBk Igo= ------=_20070709170310_14227--