From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756568AbXGIRA7 (ORCPT ); Mon, 9 Jul 2007 13:00:59 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753465AbXGIRAu (ORCPT ); Mon, 9 Jul 2007 13:00:50 -0400 Received: from an-out-0708.google.com ([209.85.132.240]:29735 "EHLO an-out-0708.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753308AbXGIRAt (ORCPT ); Mon, 9 Jul 2007 13:00:49 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kfM4TgowBuT8sVib0tKEFtMYh3p8zDNJBJg053CyLgt1GzErmNxYas3pODE9bcr6kkHtKWjpuVuhRPofg/pId1LQC35KcSOW2CD8y3F6K7XktV1eGaPYsI4nIz4S3nb7Up2sV8Q7Mo2n2OyZKMsynaGwwJbkLCyiqwKPkbo0YIY= Message-ID: Date: Mon, 9 Jul 2007 19:00:48 +0200 From: mikie To: "Indan Zupancic" Subject: Re: understanding firmware loader for speedtouch (kernel 2.6.21.5) Cc: "Kay Sievers" , "Duncan Sands" , linux-kernel@vger.kernel.org In-Reply-To: <33435.81.207.0.53.1183993390.squirrel@secure.samage.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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> <33435.81.207.0.53.1183993390.squirrel@secure.samage.net> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org 2007/7/9, Indan Zupancic : > 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? I tried that. I modified the script so it writes to /tmp/bla a simple line that the script was started. Now, when I start it manually by simply typing /sbin/hotplug in the bash, then the log shows that the script got started (as expected). However, when I do modprobe speedtch the kernel never runs this script... Certainly, I removed the speedtch module earlier (rmmod speedtch) and checked that it was removed with lsmod. What I tried to do is manually find the firmware directory in /sys/ after inserting the speedtch. Then I manually did the echo 1>loading, cat speedtch-1.bin > data, echo 0>loading. And it worked. Everything after that went fine. So all I am missing is the hotplug script not being started by kernel 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. Thanks for your support and the attached rules. If I can't find other solution I will have to use the minimal udev environment that you provided. One more thing - when the modem finally runs in isochronous mode, yet I cannot get high transfer rates. I can't get nothing more than 3Mbits/s. When I used kernel 2.4 with bulk mode I had only 2.5 Mbit/s. So there is a little progress, but still not too much. Is it possible that weak and old hardware (Celeron 633 on a VIA chipset motherboard) is causing this ? -- Regards, MK