understanding firmware loader for speedtouch (kernel 2.6.21.5)

understanding firmware loader for speedtouch (kernel 2.6.21.5)

[mikie]

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 ?

All I get is :

Jul  6 13:41:37 srv kernel: speedtch 1-2:1.0: speedtch_find_firmware:
looking for speedtch-1.bin.2.00
[...]
Jul  6 13:42:19 srv kernel: speedtch 1-2:1.0: speedtch_find_firmware:
looking for speedtch-1.bin.2
[...]
Jul  6 13:43:19 srv kernel: speedtch 1-2:1.0: speedtch_find_firmware:
looking for speedtch-1.bin

And nothing more happens. The firmware does not get loaded to the
modem. There is also no information in the logs that the firmware
loading failed...

It is worth noting that I use slackware distro, that was installed
long time ago with 8.1 (or 9.0) CD version, and I only make package
upgrades. I used to work with kernel 2.4.33.3 (I compile the kernel
myself), but now decided I switch to the new 2.6 series. The old
distro means that I do not use hotplug nor udevd in my system (and
would like to stick with that scenario, if possible).

I have read and checked the firmware.agent script from some hotplug
package, and noticed that it makes something like simple file copy of
the firmware to the "data" and echoing 1 or 0 to the "loading" file.
But what is the location of these data/loading ? Also the firmware is
split into 2 parts -- should I upload them one after another? Is that
all that should be done to get the firmware loaded?

Regards,
MK

Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)

[Duncan Sands]

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!
 
> All I get is :
> 
> Jul  6 13:41:37 srv kernel: speedtch 1-2:1.0: speedtch_find_firmware:
> looking for speedtch-1.bin.2.00
> [...]
> Jul  6 13:42:19 srv kernel: speedtch 1-2:1.0: speedtch_find_firmware:
> looking for speedtch-1.bin.2
> [...]
> Jul  6 13:43:19 srv kernel: speedtch 1-2:1.0: speedtch_find_firmware:
> looking for speedtch-1.bin
> 
> And nothing more happens. The firmware does not get loaded to the
> modem. There is also no information in the logs that the firmware
> loading failed...

It should either print:
	no stage 1 firmware found!
or
	found stage 1 firmware <name>
Does it really print neither?  If so, that must mean that the
firmware loader got stuck.

> I have read and checked the firmware.agent script from some hotplug
> package, and noticed that it makes something like simple file copy of
> the firmware to the "data" and echoing 1 or 0 to the "loading" file.
> But what is the location of these data/loading ? Also the firmware is
> split into 2 parts -- should I upload them one after another? Is that
> all that should be done to get the firmware loaded?

You need to write the file that was asked for: the modem starts by asking
for the first file, uploads it, then asks for the second file and uploads it.
The file is written to the "data" file, but note that the data file is created
on the fly when the modem requests a firmware load so you can't write to it
at some random time.

Ciao,

Duncan.

Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)

[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.


>> I have read and checked the firmware.agent script from some hotplug
>> package, and noticed that it makes something like simple file copy of
>> the firmware to the "data" and echoing 1 or 0 to the "loading" file.
>> But what is the location of these data/loading ? Also the firmware is
>> split into 2 parts -- should I upload them one after another? Is that
>> all that should be done to get the firmware loaded?
>
> You need to write the file that was asked for: the modem starts by asking
> for the first file, uploads it, then asks for the second file and uploads it.
> The file is written to the "data" file, but note that the data file is created
> on the fly when the modem requests a firmware load so you can't write to it
> at some random time.

If you really don't want to use udevd, you could use the below script I wrote
(not really tested, it's an bash version of the Udev rules I've have, more or less.)

Echo the script pathname to /proc/sys/kernel/hotplug early at bootup and all
should work, assuming your pppd is setup correctly and the script isn't buggy.

#!/bin/sh
set -e

p()
{
	# For debugging/logging, edit for your needs.
	echo "$*"
	echo "$*" > /dev/vc/1;
	echo "$*" >> /tmp/bla;
}

if [ "$SUBSYSTEM" = "firmware" ]; then
	p "Loading firmware..."
	cd /sys/$DEVPATH
	if [ -f "/lib/firmware/$FIRMWARE" ]; then
		echo 1 > loading
		cat "/lib/firmware/$FIRMWARE" > data
		echo 0 > loading
		p "Done."
	else
		echo -1 > loading
		p "$FIRMWARE not found."
	fi
elif [ "$SUBSYSTEM" = "atm" ]; then
	if [[ "$KERNEL" != speedtch* ]]; then
		exit
	fi
	if [ "$ACTION" = "add" ]; then
		p "Starting pppd."
		pppd call adsl
	elif [ "$ACTION" = "remove" ]; then
		p "Stopping pppd."
		pkill pppd
	fi
fi

Greetings,

Indan

Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)

[mikie]

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?

The timeout value in /sys/class/firmware/timeout is 60 and it seems to
be working correctly (see logs with exactly 1 minute delay before next
find_firmware event)
As I check the debug log I can see some uevents :

Jul  9 09:03:19 srv kernel: speedtch 1-2:1.0: usbatm_usb_probe: using
3392 byte buffer for rx channel 0xc5577ca0
Jul  9 09:03:19 srv kernel: speedtch 1-2:1.0: usbatm_usb_probe: using
3392 byte buffer for tx channel 0xc5577ce8
Jul  9 09:03:19 srv kernel: speedtch 1-2:1.0: speedtch_find_firmware:
looking for speedtch-1.bin.2.00
Jul  9 09:03:19 srv kernel: DEV: registering device: ID = '1-2:1.0'
Jul  9 09:03:19 srv kernel: PM: Adding info for No Bus:1-2:1.0
Jul  9 09:03:19 srv kernel: dev_uevent: class uevent() returned -19
Jul  9 09:03:19 srv kernel: bound device '1-2:1.0' to driver 'speedtch'
Jul  9 09:03:19 srv kernel: usb: Bound Device 1-2:1.0 to Driver speedtch
Jul  9 09:04:07 srv kernel: drivers/usb/atm/speedtch.c: speedtch_usb_cleanup
Jul  9 09:04:07 srv kernel: bus usb: remove driver speedtch
Jul  9 09:04:07 srv kernel: speedtch 1-2:1.0: usbatm_usb_disconnect entered
Jul  9 09:04:19 srv kernel: DEV: Unregistering device. ID = '1-2:1.0'
Jul  9 09:04:19 srv kernel: PM: Removing info for No Bus:1-2:1.0
Jul  9 09:04:19 srv kernel: speedtch 1-2:1.0: speedtch_find_firmware:
looking for speedtch-1.bin.2
Jul  9 09:04:19 srv kernel: DEV: registering device: ID = '1-2:1.0'
Jul  9 09:04:19 srv kernel: PM: Adding info for No Bus:1-2:1.0
Jul  9 09:04:19 srv kernel: dev_uevent: class uevent() returned -19
Jul  9 09:05:19 srv kernel: DEV: Unregistering device. ID = '1-2:1.0'
Jul  9 09:05:19 srv kernel: PM: Removing info for No Bus:1-2:1.0
Jul  9 09:05:19 srv kernel: speedtch 1-2:1.0: speedtch_find_firmware:
looking for speedtch-1.bin
Jul  9 09:05:19 srv kernel: DEV: registering device: ID = '1-2:1.0'
Jul  9 09:05:19 srv kernel: PM: Adding info for No Bus:1-2:1.0
Jul  9 09:05:19 srv kernel: dev_uevent: class uevent() returned -19
Jul  9 09:06:19 srv kernel: DEV: Unregistering device. ID = '1-2:1.0'
Jul  9 09:06:19 srv kernel: PM: Removing info for No Bus:1-2:1.0
Jul  9 09:06:19 srv kernel: speedtch 1-2:1.0: speedtch_unbind entered
Jul  9 09:06:19 srv kernel: speedtch 1-2:1.1: usbatm_usb_disconnect entered
Jul  9 09:06:19 srv kernel: speedtch 1-2:1.1: usbatm_usb_disconnect:
NULL instance!

Mostly I think I should be worried about "dev_uevent: class uevent()
returned -19".
It sounds like the uevent failed? I do not have udevd, but still I
thought that in such case the kernel will use the script from
/proc/sys/kernel/hotplug but apparently it does not. Is there any
config option to choose between udev or hotplug in the kernel source ?

Regards,
MK

Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)

[Indan Zupancic]

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) and has "#!/bin/sh"
at the top, or else it won't work. If that's already the case, I've no idea.

Good luck,

Indan

Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)

[mikie]

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...

Regards,
MK

Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)

[Kay Sievers]

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").

Kay

Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)

[mikie]

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:

UEVENT[1183991915.577581] add      /class/firmware/1-2:1.0 (firmware)
ACTION=add
DEVPATH=/class/firmware/1-2:1.0
SUBSYSTEM=firmware
SEQNUM=949
PHYSDEVPATH=/devices/pci0000:00/0000:00:07.2/usb1/1-2/1-2:1.0
PHYSDEVBUS=usb
PHYSDEVDRIVER=speedtch
FIRMWARE=speedtch-1.bin.2.00
TIMEOUT=60

UEVENT[1183991975.599358] add      /class/firmware/1-2:1.0 (firmware)
ACTION=add
DEVPATH=/class/firmware/1-2:1.0
SUBSYSTEM=firmware
SEQNUM=951
PHYSDEVPATH=/devices/pci0000:00/0000:00:07.2/usb1/1-2/1-2:1.0
PHYSDEVBUS=usb
PHYSDEVDRIVER=speedtch
FIRMWARE=speedtch-1.bin.2
TIMEOUT=60

-- 
Regards,
MK

Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)

[Indan Zupancic]

[-- Attachment #1: Type: text/plain, Size: 3130 bytes --]

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?

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

[-- Attachment #2: speedtch.rules --]
[-- Type: application/octet-stream, Size: 287 bytes --]

ACTION=="add", SUBSYSTEM=="firmware", ENV{FIRMWARE}=="?*", RUN+="/lib/udev/firmware.sh"

# add@/class/atm/speedtch0
ACTION=="add", SUBSYSTEM=="atm", KERNEL=="speedtch*" RUN="/usr/sbin/pppd call speedtch"

ACTION=="remove", SUBSYSTEM=="atm", KERNEL=="speedtch*" RUN="/usr/bin/pkill pppd"

Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)

[mikie]

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

Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)

[mikie]

2007/7/9, Duncan Sands <duncan.sands@math.u-psud.fr>:
> > 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 ?
>
> Is it actually running in isochronous mode?  (It prints some messages
> about this).

This is what I get:
root@srv:/# cat /sys/module/speedtch/parameters/enable_isoc
Y

I think it means it confirms the isochronous mode is working.
Especially that I modified the source of the speedtch.c so that the
enable_isoc is on by default.


> You may need new firmware (I've attached some recent
> firmware that was made available by Thomson UK without any licence
> conditions).

Many thanks for your great support. I will try the new firmware
tomorrow, as this is a remote machine and I would now risk loosing it
for an entire evening and night in case something goes wrong (usually
it just does go wrong :)

-- 
Regards,
MK

Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)

[Duncan Sands]

Hi, 

> > Is it actually running in isochronous mode?  (It prints some messages
> > about this).
> 
> This is what I get:
> root@srv:/# cat /sys/module/speedtch/parameters/enable_isoc
> Y
> 
> I think it means it confirms the isochronous mode is working.
> Especially that I modified the source of the speedtch.c so that the
> enable_isoc is on by default.

if you turn on isochronous mode, but there is some reason it can't be
used you get the message: "isochronous transfer not supported - using bulk".

Ciao,

Duncan.

Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)

[mikie]

2007/7/9, Duncan Sands <duncan.sands@math.u-psud.fr>:
> > 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 ?
>
> Is it actually running in isochronous mode?  (It prints some messages
> about this).  You may need new firmware (I've attached some recent
> firmware that was made available by Thomson UK without any licence
> conditions).

Unfortunatelly this firmware does not work with my modem. I get this
thing in the debug log:
Jul 10 09:26:27 srv kernel: speedtch 1-2:1.0: speedtch_upload_firmware entered
Jul 10 09:26:27 srv kernel: speedtch 1-2:1.0:
speedtch_upload_firmware: BLOCK1 uploaded (935 bytes)
Jul 10 09:26:29 srv kernel: usb 1-2: speedtch timed out on ep5in len=0/512

And it hangs at this point for a couple of minutes, so I have to
manually remove the speedtch module. As far as I can see my modem is
revision 2.00 (kernel searches for firmware speedtch-1.bin.2.00).

I also tried a couple of other firmwares available on the net, and
also the one from Windows XP install (which works and achieves speeds
of up to 720kbyte/sec downlink). Some of the firmwares did not work
either, and some worked the same way - it means not more than 3mbit/s
(around 400kbyte/s) could be achieved.

-- 
Regards,
MK

Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)

[Duncan Sands]

> I also tried a couple of other firmwares available on the net, and
> also the one from Windows XP install (which works and achieves speeds
> of up to 720kbyte/sec downlink). Some of the firmwares did not work
> either, and some worked the same way - it means not more than 3mbit/s
> (around 400kbyte/s) could be achieved.

I'm pretty sure you won't get anything faster out of a revision 2 modem.

Sorry,

Duncan.

Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)

[mikie]

2007/7/10, Duncan Sands <duncan.sands@math.u-psud.fr>:
> > I also tried a couple of other firmwares available on the net, and
> > also the one from Windows XP install (which works and achieves speeds
> > of up to 720kbyte/sec downlink). Some of the firmwares did not work
> > either, and some worked the same way - it means not more than 3mbit/s
> > (around 400kbyte/s) could be achieved.
>
> I'm pretty sure you won't get anything faster out of a revision 2 modem.

Too bad to hear that :/
Especially that windows does this with the same modem without a hitch.
Anyway thanks for all your help.

-- 
Regards,

MK

Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)

[Duncan Sands]

On Tuesday 10 July 2007 11:13:09 mikie wrote:
> 2007/7/10, Duncan Sands <duncan.sands@math.u-psud.fr>:
> > > I also tried a couple of other firmwares available on the net, and
> > > also the one from Windows XP install (which works and achieves speeds
> > > of up to 720kbyte/sec downlink). Some of the firmwares did not work
> > > either, and some worked the same way - it means not more than 3mbit/s
> > > (around 400kbyte/s) could be achieved.
> >
> > I'm pretty sure you won't get anything faster out of a revision 2 modem.
> 
> Too bad to hear that :/
> Especially that windows does this with the same modem without a hitch.

Really?  In that case I take it back, the hardware can clearly do it :)  Presumably
you are using the firmware that came with windows?  Which kernel version?  Also, what
synchronization speed is reported?

> Anyway thanks for all your help.

No problem.

Duncan.

Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)

[mikie]

2007/7/10, Duncan Sands <duncan.sands@math.u-psud.fr>:
> On Tuesday 10 July 2007 11:13:09 mikie wrote:
> > 2007/7/10, Duncan Sands <duncan.sands@math.u-psud.fr>:
> > > > I also tried a couple of other firmwares available on the net, and
> > > > also the one from Windows XP install (which works and achieves speeds
> > > > of up to 720kbyte/sec downlink). Some of the firmwares did not work
> > > > either, and some worked the same way - it means not more than 3mbit/s
> > > > (around 400kbyte/s) could be achieved.
> > >
> > > I'm pretty sure you won't get anything faster out of a revision 2 modem.
> >
> > Too bad to hear that :/
> > Especially that windows does this with the same modem without a hitch.
>
> Really?  In that case I take it back, the hardware can clearly do it :)  Presumably
> you are using the firmware that came with windows?  Which kernel version?  Also, what
> synchronization speed is reported?

Yes, the hardware in the modem can do it for sure. I have a laptop
with a pentium4 CPU, USB2.0, windows XP installed. I attach the same
modem to this laptop and I can go up to 730..740 kbyte/s (the same
phone line of course). Windows XP had to be modified with a registry
tweak (from thomson website) to switch to isochronous mode and it
works.

However my server running linux is on a ECS motherboard (P6BAP as I
remember), Celeron 633 CPU, USB1.1. I have compiled quite fresh kernel
2.6.21.5

I am 100% sure that I use the same firmware for the modem, because I
copied it directly from windows XP from laptop.
Now since the modem itself can go as fast as 6mbit/s, I am only
concerned if the _computer_ hardware on my linux server box can do it
via USB ? I can see the usb reporting it to be at 12Mbit/s, which
should be enough to reach 6mbit/s teoretically. CPU load is normal
even during transfers.
I would have to install windows xp on that machine to be 100% sure
that both modem and computer hardware can go up to 6mbit/s via USB...

By the way, I just tried to switch sw_buffering in the speedtch module
but that did not help.


-- 
Regards,
MK

Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)

[mikie]

2007/7/10, mikie <mikie.pl@gmail.com>:
> 2007/7/10, Duncan Sands <duncan.sands@math.u-psud.fr>:
> > On Tuesday 10 July 2007 11:13:09 mikie wrote:
> > > 2007/7/10, Duncan Sands <duncan.sands@math.u-psud.fr>:
> > > > > I also tried a couple of other firmwares available on the net, and
> > > > > also the one from Windows XP install (which works and achieves speeds
> > > > > of up to 720kbyte/sec downlink). Some of the firmwares did not work
> > > > > either, and some worked the same way - it means not more than 3mbit/s
> > > > > (around 400kbyte/s) could be achieved.
> > > >
> > > > I'm pretty sure you won't get anything faster out of a revision 2 modem.
> > >
> > > Too bad to hear that :/
> > > Especially that windows does this with the same modem without a hitch.
> >
> > Really?  In that case I take it back, the hardware can clearly do it :)  Presumably
> > you are using the firmware that came with windows?  Which kernel version?  Also, what
> > synchronization speed is reported?
>
> Yes, the hardware in the modem can do it for sure. I have a laptop
> with a pentium4 CPU, USB2.0, windows XP installed. I attach the same
> modem to this laptop and I can go up to 730..740 kbyte/s (the same
> phone line of course). Windows XP had to be modified with a registry
> tweak (from thomson website) to switch to isochronous mode and it
> works.
>
> However my server running linux is on a ECS motherboard (P6BAP as I
> remember), Celeron 633 CPU, USB1.1. I have compiled quite fresh kernel
> 2.6.21.5
>
> I am 100% sure that I use the same firmware for the modem, because I
> copied it directly from windows XP from laptop.
> Now since the modem itself can go as fast as 6mbit/s, I am only
> concerned if the _computer_ hardware on my linux server box can do it
> via USB ? I can see the usb reporting it to be at 12Mbit/s, which
> should be enough to reach 6mbit/s teoretically. CPU load is normal
> even during transfers.
> I would have to install windows xp on that machine to be 100% sure
> that both modem and computer hardware can go up to 6mbit/s via USB...
>
> By the way, I just tried to switch sw_buffering in the speedtch module
> but that did not help.

I begin to think that the isochronous mode is not working. I tried the
speedtch module with disabled and enabled isoc and there is no
difference in transfer speeds at all.

All I checked was :
root@srv:~# cat /sys/module/speedtch/parameters/enable_isoc
Y

which as I now believe only means what options have been specified,
but does not confirm the actual mode being in use.
Especially that I do not see anything like "isoc support enabled" in
any of the logs.

Are there any requirements for UHCI hardware to support isoc mode  ?
Mine is:
USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 08) (prog-if 00 [UHCI])

Or maybe I am missing something else? I am sure the isoc mode is
supported by my modem, now I only have doubts if my hardware on server
box supports this ?

-- 
Regards,
MK

Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)

[Duncan Sands]

Hi Mikie,

> I begin to think that the isochronous mode is not working. I tried the
> speedtch module with disabled and enabled isoc and there is no
> difference in transfer speeds at all.
> 
> All I checked was :
> root@srv:~# cat /sys/module/speedtch/parameters/enable_isoc
> Y
> 
> which as I now believe only means what options have been specified,
> but does not confirm the actual mode being in use.
> Especially that I do not see anything like "isoc support enabled" in
> any of the logs.
> 
> Are there any requirements for UHCI hardware to support isoc mode  ?
> Mine is:
> USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
> Controller (rev 08) (prog-if 00 [UHCI])
> 
> Or maybe I am missing something else? I am sure the isoc mode is
> supported by my modem, now I only have doubts if my hardware on server
> box supports this ?

can you please send the part of /proc/bus/usb/devices concerning the
modem, while the modem is plugged in and (supposedly) using isoc mode.
If /proc/bus/usb isn't mounted, you can mount it like this IIRC:
	mount -t usbfs usbfs /proc/bus/usb/
Also, looking in the driver I see that if isoc mode is disabled you
should see one of the following messages:
	- setting interface to ?? failed (??)!
	- isochronous transfer not supported - using bulk
The first one may be a debug message, so you will not necessarily see
it depend on which level of kernel debug messages you have turned on.
(I have made some changes in my tree so that if you asked for isoc
transfer but get bulk then a message is printed).

Ciao,

Duncan.

Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)

[mikie]

2007/7/11, Duncan Sands <duncan.sands@math.u-psud.fr>:
> Hi Mikie,
>
> > I begin to think that the isochronous mode is not working. I tried the
> > speedtch module with disabled and enabled isoc and there is no
> > difference in transfer speeds at all.
> >
> > All I checked was :
> > root@srv:~# cat /sys/module/speedtch/parameters/enable_isoc
> > Y
> >
> > which as I now believe only means what options have been specified,
> > but does not confirm the actual mode being in use.
> > Especially that I do not see anything like "isoc support enabled" in
> > any of the logs.
> >
> > Are there any requirements for UHCI hardware to support isoc mode  ?
> > Mine is:
> > USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
> > Controller (rev 08) (prog-if 00 [UHCI])
> >
> > Or maybe I am missing something else? I am sure the isoc mode is
> > supported by my modem, now I only have doubts if my hardware on server
> > box supports this ?
>
> can you please send the part of /proc/bus/usb/devices concerning the
> modem, while the modem is plugged in and (supposedly) using isoc mode.
> If /proc/bus/usb isn't mounted, you can mount it like this IIRC:
>         mount -t usbfs usbfs /proc/bus/usb/

Actually I had to mount it (I  hope that not having it mounted does
not change a lot in this matter). Here is the cat of "devices"  from
/proc/bus/usb

T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=ff(vend.) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=06b9 ProdID=4061 Rev= 2.00
S:  Manufacturer=ALCATEL
S:  Product=Speed Touch 330
S:  SerialNumber=0090D0AA28CD
C:* #Ifs= 3 Cfg#= 1 Atr=80 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=00 Prot=00 Driver=speedtch
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=50ms
I:  If#= 1 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=00 Prot=00 Driver=speedtch
I:  If#= 1 Alt= 1 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=speedtch
E:  Ad=06(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=07(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=87(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:  If#= 1 Alt= 2 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=speedtch
E:  Ad=06(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=07(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=87(I) Atr=01(Isoc) MxPS= 640 Ivl=1ms
I:* If#= 1 Alt= 3 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=speedtch
E:  Ad=06(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=07(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=87(I) Atr=01(Isoc) MxPS= 960 Ivl=1ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=speedtch
E:  Ad=05(O) Atr=02(Bulk) MxPS=   8 Ivl=0ms
E:  Ad=85(I) Atr=02(Bulk) MxPS=   8 Ivl=0ms


> Also, looking in the driver I see that if isoc mode is disabled you
> should see one of the following messages:
>         - setting interface to ?? failed (??)!
>         - isochronous transfer not supported - using bulk
> The first one may be a debug message, so you will not necessarily see
> it depend on which level of kernel debug messages you have turned on.
> (I have made some changes in my tree so that if you asked for isoc
> transfer but get bulk then a message is printed).

I have CONFIG_USB_DEBUG=y set in kernel. However I do not see any of
the messages you are referring to. It does not say that it tried isoc
and falls to bulk, nothing like that. Also nothing about "setting
interface to ?? failed". Which debug option should I switch to see
these?

-- 
Regards,
MK

Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)

[Duncan Sands]

Hi,

> Actually I had to mount it (I  hope that not having it mounted does
> not change a lot in this matter).

probably not.  Not having sysfs mounted can cause hotplug to fail,
but I think not having /proc/bus/usb mounted shouldn't cause any
trouble nowadays.

> I:* If#= 1 Alt= 3 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=speedtch
> E:  Ad=06(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
> E:  Ad=07(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
> E:  Ad=87(I) Atr=01(Isoc) MxPS= 960 Ivl=1ms

The * means that this altsetting is being used - this is the altsetting
when using isochronous mode.  So it looks to me like isochronous mode is
being used.

> I have CONFIG_USB_DEBUG=y set in kernel. However I do not see any of
> the messages you are referring to. It does not say that it tried isoc 
> and falls to bulk, nothing like that. Also nothing about "setting 
> interface to ?? failed".

Most likely it is using isochronous transfer.  The question then is: why
is it slow?  I will look in my cupboard to see if I have the same modem,
and if so see what speed I can get out of it.

> Which debug option should I switch to see these?

Something like this IIRC:
	echo 7 > /proc/sys/kernel/printk
Then it should turn up in dmesg.

Ciao,

Duncan.

Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)

[mikie]

2007/7/11, Duncan Sands <duncan.sands@math.u-psud.fr>:
> Hi,
>
> > Actually I had to mount it (I  hope that not having it mounted does
> > not change a lot in this matter).
>
> probably not.  Not having sysfs mounted can cause hotplug to fail,
> but I think not having /proc/bus/usb mounted shouldn't cause any
> trouble nowadays.
>
> > I:* If#= 1 Alt= 3 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=speedtch
> > E:  Ad=06(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
> > E:  Ad=07(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
> > E:  Ad=87(I) Atr=01(Isoc) MxPS= 960 Ivl=1ms
>
> The * means that this altsetting is being used - this is the altsetting
> when using isochronous mode.  So it looks to me like isochronous mode is
> being used.
>
> > I have CONFIG_USB_DEBUG=y set in kernel. However I do not see any of
> > the messages you are referring to. It does not say that it tried isoc
> > and falls to bulk, nothing like that. Also nothing about "setting
> > interface to ?? failed".
>
> Most likely it is using isochronous transfer.  The question then is: why
> is it slow?  I will look in my cupboard to see if I have the same modem,
> and if so see what speed I can get out of it.
>
> > Which debug option should I switch to see these?
>
> Something like this IIRC:
>         echo 7 > /proc/sys/kernel/printk
> Then it should turn up in dmesg.
>

I made a more advanced testing. I used one computer only to be
absolutely sure that this is not a hardware issue. So I took a laptop
(P4 1.8GHz, OHCI usb host), and booted into Knoppix LiveCD. It was
running kernel 2.6.19 and the version of speedtch module was 1.10.
First I did something like rmmod speedtch; rmmod ohci-hcd to be sure
that I start with a fresh environment.
I also did: echo 7 > /proc/sys/kernel/printk which caused the usual
debug messages being printed directly in the console.
Then I did modprobe ohci-hcd;modprobe speedtch enable_isoc=1

Certainly I've put the same firmware in the /lib/firmware so that udev
found it correctly and loaded it up to the modem. The ADSL link went
up with the same values (7456 downlink). PPPd started (I use
pppoatm.so, if that is important). In this setup I achieved transfer
rates of around 480...500 kbyte/s. Then I did the similar thing, but
speedtch without enable_isoc, and the result was exactly the same.
In both cases I still could not see the messages from the speedtch
driver about enabling isochronous mode, or falling back to bulk,
nothing like that.

Right after that, to minimize the risk of any outside network being
overloaded (I doubt that anyway), I switched to Windows Xp. Transfers
were up to 730 kbyte/s. So this proves definitely that it is not a
hardware related issue.
The transfers were so fast that the LED (marked usb led) on the modem,
which usually blinks where any transfers are in process, it went
completely off, and only blinked once a few seconds...

So there is a small progress when compared to my server box (celeron
633 to remind you), where I can get only 400kbyte/s (on this laptop it
went 100kbyte/s faster).

I still cannot get the full 6mbit/s that my ADSL service runs at on
the linux system.

-- 
Regards,
MK

Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)

[mikie]

Hello Duncan,

Do you have any news regarding my case of slow transfers via
Speedtouch USB modem on linux ?

-- 
Regards,
MK

Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)

[Duncan Sands]

Hi Mikie,

> Do you have any news regarding my case of slow transfers via
> Speedtouch USB modem on linux ?

I found my old speedtouch modem and tested here.  I got 2.1 Mbaud
bulk downspeed, and 3 Mbaud isoc downspeed.  This last is half the
speed my line supports, so something is wrong [*].  Unfortunately
I'm not very motivated to try to find out what, because I don't
use this modem myself anymore.  It looks like someone needs to do
some more reverse engineering work on the windows driver.

Ciao,

Duncan.

[*] I got the same numbers the last time I tested isoc support,
but at that time 3 Mbaud was slightly less than the maximum speed
of my line, which explains why I didn't realize that there is a
problem.

Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)

[mikie]

On Wed, Jul 25, 2007 at 12:03 AM, Duncan Sands
<duncan.sands@math.u-psud.fr> wrote:

>> Do you have any news regarding my case of slow transfers via
>> Speedtouch USB modem on linux ?
>
> I found my old speedtouch modem and tested here.  I got 2.1 Mbaud
> bulk downspeed, and 3 Mbaud isoc downspeed.  This last is half the
> speed my line supports, so something is wrong [*].  Unfortunately
> I'm not very motivated to try to find out what, because I don't
> use this modem myself anymore.  It looks like someone needs to do
> some more reverse engineering work on the windows driver.

Duncan, as you remember we discussed 1 year ago speed issues with
Speedtouch driver. Please let me know if the driver has been fixed to
support higher speeds? Or is it still limited to 3Mbaud top ?

Regards,
MK

Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)

[Duncan Sands]

> >> Do you have any news regarding my case of slow transfers via
> >> Speedtouch USB modem on linux ?
> >
> > I found my old speedtouch modem and tested here.  I got 2.1 Mbaud
> > bulk downspeed, and 3 Mbaud isoc downspeed.  This last is half the
> > speed my line supports, so something is wrong [*].  Unfortunately
> > I'm not very motivated to try to find out what, because I don't
> > use this modem myself anymore.  It looks like someone needs to do
> > some more reverse engineering work on the windows driver.
> 
> Duncan, as you remember we discussed 1 year ago speed issues with
> Speedtouch driver. Please let me know if the driver has been fixed to
> support higher speeds? Or is it still limited to 3Mbaud top ?

Nothing changed, so I suppose it is still slow.  I'm not planning
to work on this - I no longer have any interest in these modems
(I should really remove myself as maintainer).

Sorry for the bad news,

Duncan.

Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)

[Kay Sievers]

On Mon, 2007-07-09 at 16:40 +0200, 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:
> 
> UEVENT[1183991915.577581] add      /class/firmware/1-2:1.0 (firmware)
> ACTION=add

Using /sbin/hotplug works without any problems here:

$ uname -a
Linux lov 2.6.22-dirty #68 SMP Mon Jul 9 03:43:51 CEST 2007 x86_64 x86_64 x86_64 GNU/Linux

$ cat /proc/sys/kernel/hotplug 
/sbin/hotplug

$ ls -l /sbin/hotplug
-rwxr-xr-x 1 root root 39 2007-07-09 17:02 /sbin/hotplug

$ cat /sbin/hotplug
#!/bin/sh
set | logger -t "hotplug $$"

$ tail -50 /var/log/messages
...
Jul  9 17:04:33 lov hotplug 15589: ACTION=add
Jul  9 17:04:33 lov hotplug 15589: BASH=/bin/sh
Jul  9 17:04:33 lov hotplug 15589: BASH_ARGC=([0]="1")
Jul  9 17:04:33 lov hotplug 15589: BASH_ARGV=([0]="usb_endpoint")
Jul  9 17:04:33 lov hotplug 15589: BASH_LINENO=([0]="0")
Jul  9 17:04:33 lov hotplug 15589: BASH_SOURCE=([0]="/sbin/hotplug")
Jul  9 17:04:33 lov hotplug 15589: MAJOR=254
Jul  9 17:04:33 lov hotplug 15589: MINOR=11
Jul  9 17:04:33 lov hotplug 15589: SUBSYSTEM=usb_endpoint
...

Kay

Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)

[Duncan Sands]

Hi,

> 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...

did you turn hotplug on in your kernel's .config?

Ciao,

D.

Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)

[mikie]

2007/7/9, Duncan Sands <duncan.sands@math.u-psud.fr>:
> Hi,
>
> > 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...
>
> did you turn hotplug on in your kernel's .config?

Yes:
cat /usr/src/linux/.config |grep HOTPLUG
CONFIG_HOTPLUG=y
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
# CONFIG_HOTPLUG_PCI is not set

Regards,
MK

Re: understanding firmware loader for speedtouch (kernel 2.6.21.5)

[mikie]

2007/7/6, Duncan Sands <duncan.sands@math.u-psud.fr>:
> Hi, you should keep this discussion on the lkml so it will be archived -
> that way it may help others too.

I was sure I copied lkml, but obviously something went wrong.

> On Friday 6 July 2007 19:06:14 mikie wrote:
> > 2007/7/6, Duncan Sands <duncan.sands@math.u-psud.fr>:
> > > 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!
> >
> > OK, so probably I don't have anything external. Could you please point
> > me to the specific helper-program takes care of this process? As I
> > understand it is not done entirely by kernel itself?
>
> The external helper is the firmware.agent script!  The modem driver calls
> the kernel's firmware subsystem, the firmware subsystem creates a user
> space thread and calls whatever program is specified in /proc/sys/kernel/hotplug
> At the same time the firmware subsystem creates the "data" and "loading" files.
> The hotplug program is supposed to write the firmware into "data".

Thanks for the explanation. Now I get the overall picture of what
whould be done to load the firmware. I will try playing around with
the firmware.agent script, although I do not havfe the entire hotplug
package on my system, but probably this should work with a bit of
manual bash scripting.

> See
> Documentation/firmware_class in the kernel source for details.  More recent
> systems fire off a "uevent" and have udev take care of loading the firmware.

What do you mean by "recent systems" ? Is it distro dependent or
kernel dependent ?

> In any case, the external helper is not specific to this modem - it is part
> of the general hotplug infrastructure.  If you have hotplug or udev installed,
> probably they are looking for the firmware in the wrong place.

Actually I don't have hotplug/udev. That is why I am thinking of some
basic manual firmware loading. I switched from 2.4.33.3 kernel, where
such toold were not needed (I guess).


> > > > All I get is :
> > > >
> > > > Jul  6 13:41:37 srv kernel: speedtch 1-2:1.0: speedtch_find_firmware:
> > > > looking for speedtch-1.bin.2.00
> > > > [...]
> > > > Jul  6 13:42:19 srv kernel: speedtch 1-2:1.0: speedtch_find_firmware:
> > > > looking for speedtch-1.bin.2
> > > > [...]
> > > > Jul  6 13:43:19 srv kernel: speedtch 1-2:1.0: speedtch_find_firmware:
> > > > looking for speedtch-1.bin
> > > >
> > > > And nothing more happens. The firmware does not get loaded to the
> > > > modem. There is also no information in the logs that the firmware
> > > > loading failed...
> > >
> > > It should either print:
> > >         no stage 1 firmware found!
> > > or
> > >         found stage 1 firmware <name>
> > > Does it really print neither?  If so, that must mean that the
> > > firmware loader got stuck.
> >
> > I don't have anything about stage 1. This probably is done by some
> > helper program, as I understood.
>
> No, the modem prints one of these two messages when the user space
> helper returns, or a timeout occurs.  The fact it isn't printed
> suggests that the timeout is infinite.  The timeout is in
> /sys/class/firmware/timeout

I will take a closer look at the timeout value. It is quite
uncomfortable for me right now to switch to the new kernel, because I
loose internet connectivity at that time :)

> > But I don't know which one is that.
> > Perhaps I could do it manually ? Like copying the firmware to the
> > "data" ?
>
> Actually you could.  All the firmware.agent does (or did, maybe it got more
> sophisticated) is use "cat" to write the firmware file to "data".

I tried some basic copy, but received permission denied even though I
was root. Perhaps I was trying at the wrong location. I'll get back
with more info on Monday.

Thanks for your help.

Regards,
MK