Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)

[mikie <mikie.pl@gmail.com>]

2007/7/9, Indan Zupancic <indan@nul.nu>:
> On Mon, July 9, 2007 16:40, mikie wrote:
> > 2007/7/9, Kay Sievers <kay.sievers@vrfy.org>:
> >> On 7/9/07, mikie <mikie.pl@gmail.com> wrote:
> >> > 2007/7/9, Indan Zupancic <indan@nul.nu>:
> >> > > On Mon, July 9, 2007 10:49, mikie wrote:
> >> > > > 2007/7/6, Indan Zupancic <indan@nul.nu>:
> >> > > >> 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