Bug 187299 - SpeedTouch 330 ADSL modem fails to load firmware
SpeedTouch 330 ADSL modem fails to load firmware
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
5
athlon Linux
medium Severity high
: ---
: ---
Assigned To: Pete Zaitcev
Brian Brock
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-29 15:37 EST by Keith Dixon
Modified: 2008-05-06 11:42 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 11:42:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
mainly extracts from /var/log/messages, including a kernel oops (10.07 KB, text/plain)
2006-03-29 15:37 EST, Keith Dixon
no flags Details
firmware_helper.c (3.50 KB, text/plain)
2006-06-28 10:49 EDT, Keith Dixon
no flags Details
More selections from /var/log/messages with kernel 2.6.17 (21.81 KB, text/plain)
2006-06-29 07:27 EDT, Keith Dixon
no flags Details
selections from messages and corresponding o/p from udevmonitor (44.15 KB, application/octet-stream)
2006-10-18 09:27 EDT, Keith Dixon
no flags Details

  None (edit)
Description Keith Dixon 2006-03-29 15:37:39 EST
Description of problem:
Firmware fails to load.  I had no problems with this at any stage with FC4.
The modem is seen and the firmware is in place under /lib/firmware.
Problem has occured from immediately after FC5 installation.

Version-Release number of selected component (if applicable):
Linux version 2.6.15-1.2054_FC5

How reproducible:
Always fails to load firmware but at different stages of boot process.
Sometimes get a kernel oops.

Steps to Reproduce:
1.
Connect SpeedTouch 330 to ASUS K7V
2.
Install FC5
3.
Reboot
  
Actual results:
Have to use 56k dialup modem and pay the phone bills

Expected results:
Use 2M adsl modem on connection already paid for

Additional info:
Extracts from /var/log/messages in attachment, including kernal oops
Comment 1 Keith Dixon 2006-03-29 15:37:39 EST
Created attachment 127018 [details]
mainly extracts from /var/log/messages, including a kernel oops
Comment 2 Keith Dixon 2006-03-31 04:10:01 EST
I noticed that 2.6.16.1 had made it to the updates repository.  I downloaded it
using yumex expecting it to install, but it didn't.  In fact it disappeared
altogether.  I had unchecked "Delete downloaded packages after install/update"
under Edit->Preferences->Preferences->Behaviour but /etc/yum.conf had
keepcache=0 even though the man page states that the default is keepcache=1.  I
used Places->Search to search for kernel-2.6.16-1.2080_FC5.i686.rpm and got the
reply 'No results were found' even though I had a copy of
kernel-2.6.16-1.2080_FC5.i686.rpm in my home directory which I had downloaded
previously from http://people.redhat.com/davej/kernels/Fedora/FC5/RPMS.kernel/
(back to command line find).  I had not installed this earlier because the file
was not signed.  Then my dialup ISP decided to loose all the data on their
webmail server, first time in 5 years, so I could not read your replies.  But
enough of my problems.  Third time lucky, I used Applications->System
Tools->Software Updater to update the kernel, (three downloads of the kernel
over a 56k modem).  

And the end result?

The problem remains. However, I have not yet had the kernel oops re-occur, (but
there is still time), and one of two other failure modes has changed a little. 
Here are a couple of examples:-

Mar 30 21:12:48 localhost kernel: Linux version 2.6.16-1.2080_FC5
(bhcompile@hs20-bc1-5.build.redhat.com) (gcc version 4.1.0 20060304 (Red Hat
4.1.0-3)) #1 Tue Mar 28 03:38:34 EST 2006
Mar 30 21:12:55 localhost kernel: Kernel command line: ro root=LABEL=/1
Mar 30 21:13:05 localhost kernel: usbcore: registered new driver speedtch
Mar 30 21:13:05 localhost kernel: speedtch 1-2:1.0: found stage 1 firmware
speedtch-1.bin
Mar 30 21:13:06 localhost kernel: speedtch 1-2:1.0: found stage 2 firmware
speedtch-2.bin
Mar 30 21:13:06 localhost kernel: Non-volatile memory driver v1.2
Mar 30 21:13:06 localhost kernel: speedtch 1-2:1.0: speedtch_upload_firmware:
write BLOCK3 to modem failed (-110)!
Mar 30 21:13:06 localhost kernel: speedtch 1-2:1.0: speedtch_heavy_init:
firmware upload failed (-110)!

...

Mar 30 21:32:25 localhost kernel: Kernel command line: ro root=LABEL=/1
Mar 30 21:32:36 localhost kernel: usbcore: registered new driver speedtch
Mar 30 21:32:36 localhost kernel: firmware_loading_store: unexpected value (0)
Mar 30 21:32:36 localhost kernel: speedtch 1-2:1.0: speedtch_find_firmware: no
stage 1 firmware found!

Note that speedtch_upload_firmware now fails on BLOCK3 rather than BLOCK4.

Reading other posts it would seem that firmware loading is a common problem.
There would appear to be five areas involved:-

1. The speedtch module itself.
2. The kernel request_firmware() hotplug interface.
3. The kernel early userspace support.
4. The (undocumented) nash hotplug builtin. (inferred from init script in
/boot/initrd-2.6.16-1.2080_FC5.img)
5. udev and its rule set.

Should I post to the udev and nash areas myself?  

Comment 3 Keith Dixon 2006-04-01 04:56:24 EST
doing:-

[root@localhost Fedora]# /sbin/modprobe -r speedtch
[root@localhost Fedora]# /sbin/modprobe speedtch

no longer hangs the system, but the entries in /var/log/messages may be usefull:-

Apr  1 09:38:05 localhost kernel: usbcore: deregistering driver speedtch
Apr  1 09:38:05 localhost kernel: NET: Unregistered protocol family 20
Apr  1 09:38:05 localhost kernel: NET: Unregistered protocol family 8
Apr  1 09:38:10 localhost kernel: NET: Registered protocol family 8
Apr  1 09:38:10 localhost kernel: NET: Registered protocol family 20
Apr  1 09:38:11 localhost kernel: usb 1-2: reset full speed USB device using
uhci_hcd and address 2
Apr  1 09:38:11 localhost kernel: usbcore: registered new driver speedtch
Apr  1 09:38:11 localhost firmware_helper[1944]: Loading of
/lib/firmware/speedtch-1.bin.4.00 for speedtch driver failed: No such file or
directory
Apr  1 09:38:11 localhost firmware_helper[1949]: Loading of
/lib/firmware/speedtch-1.bin.4 for speedtch driver failed: No such file or directory
Apr  1 09:38:11 localhost kernel: speedtch 1-2:1.0: found stage 1 firmware
speedtch-1.bin
Apr  1 09:38:11 localhost kernel: speedtch 1-2:1.0: found stage 2 firmware
speedtch-2.bin.4.00
Apr  1 09:38:11 localhost firmware_helper[1960]: Loading of
/lib/firmware/speedtch-2.bin.4.00 for speedtch driver failed: No such file or
directory
Apr  1 09:38:13 localhost kernel: speedtch 1-2:1.0: speedtch_upload_firmware:
read BLOCK4 from modem failed (-110)!
Apr  1 09:38:13 localhost kernel: speedtch 1-2:1.0: speedtch_heavy_init:
firmware upload failed (-110)!

(I guess I should not be posting today... might not be taken seriously.)
firmware_helper is involved in the same behaviour as the nash hotplug builtin.
Either there is the same bug in both, or its the speedtch driver or possibly the
request_firmware() hotplug interface.
Comment 4 Keith Dixon 2006-04-02 10:09:41 EDT
I thought I would try the following

[root@localhost SPECS]# cd /lib/firmware
[root@localhost firmware]# ls
speedtch-1.bin  speedtch-2.bin
[root@localhost firmware]# mv speedtch-1.bin speedtch-1.bin.4.00
[root@localhost firmware]# mv speedtch-2.bin speedtch-2.bin.4.00
[root@localhost firmware]# /sbin/modprobe -r speedtch
[root@localhost firmware]# /sbin/modprobe speedtch

And the results were:-

Apr  2 11:12:46 localhost kernel: usbcore: deregistering driver speedtch
Apr  2 11:12:46 localhost kernel: NET: Unregistered protocol family 20
Apr  2 11:12:46 localhost kernel: NET: Unregistered protocol family 8
Apr  2 11:12:50 localhost kernel: NET: Registered protocol family 8
Apr  2 11:12:50 localhost kernel: NET: Registered protocol family 20
Apr  2 11:12:51 localhost kernel: usb 1-2: reset full speed USB device using
uhci_hcd and address 2
Apr  2 11:12:51 localhost kernel: usbcore: registered new driver speedtch
Apr  2 11:12:51 localhost kernel: speedtch 1-2:1.0: found stage 1 firmware
speedtch-1.bin.4.00
Apr  2 11:12:52 localhost kernel: speedtch 1-2:1.0: found stage 2 firmware
speedtch-2.bin.4.00
Apr  2 11:12:52 localhost firmware_helper[3624]: Loading of
/lib/firmware/speedtch-1.bin.4.00 for speedtch driver failed: No such file or
directory
Apr  2 11:12:52 localhost firmware_helper[3627]: Loading of
/lib/firmware/speedtch-2.bin.4.00 for speedtch driver failed: No such file or
directory
Apr  2 11:12:54 localhost kernel: speedtch 1-2:1.0: speedtch_upload_firmware:
write BLOCK1 to modem failed (-110)!
Apr  2 11:12:54 localhost kernel: speedtch 1-2:1.0: speedtch_heavy_init:
firmware upload failed (-110)!

Then I thought I would try debuging firmware_helper, so I downloaded
udev-084-13.src.rpm, put a few syslog calls in and compiled and installed it with:-

[dixon@localhost SOURCES]$ gcc firmware_helper.c
[dixon@localhost SOURCES]$ mv a.out firmware_helper
[root@localhost SOURCES]# mv /sbin/firmware_helper /sbin/firmware_helper.orig
[root@localhost SOURCES]# mv firmware_helper /sbin/firmware_helper

Then did:-
[root@localhost SOURCES]# /sbin/modprobe -r speedtch
[root@localhost SOURCES]# /sbin/modprobe speedtch

and got:-


Apr  2 14:32:09 localhost kernel: usbcore: deregistering driver speedtch
Apr  2 14:32:09 localhost kernel: NET: Unregistered protocol family 20
Apr  2 14:32:09 localhost kernel: NET: Unregistered protocol family 8
Apr  2 14:32:13 localhost kernel: NET: Registered protocol family 8
Apr  2 14:32:13 localhost kernel: NET: Registered protocol family 20
Apr  2 14:32:14 localhost kernel: usb 1-2: reset full speed USB device using
uhci_hcd and address 2
Apr  2 14:32:14 localhost kernel: usbcore: registered new driver speedtch
Apr  2 14:32:14 localhost kernel: speedtch 1-2:1.0: found stage 1 firmware
speedtch-1.bin.4.00
Apr  2 14:32:14 localhost firmware_helper[2042]: 
/lib/firmware/speedtch-1.bin.4.00 opened: Success
Apr  2 14:32:14 localhost firmware_helper[2042]: 
/lib/firmware/speedtch-1.bin.4.00 read: Success
Apr  2 14:32:14 localhost firmware_helper[2042]: 
/sys//class/firmware/1-2:1.0/data opened: Success
Apr  2 14:32:14 localhost firmware_helper[2045]: 
/lib/firmware/speedtch-2.bin.4.00 opened: Success
Apr  2 14:32:14 localhost firmware_helper[2050]: Loading of
/lib/firmware/speedtch-2.bin.4 for speedtch driver failed: No such file or directory
Apr  2 14:32:14 localhost firmware_helper[2045]: 
/lib/firmware/speedtch-2.bin.4.00 read: Success
Apr  2 14:32:14 localhost firmware_helper[2045]: 
/sys//class/firmware/1-2:1.0/data opened: Success
Apr  2 14:32:14 localhost kernel: speedtch 1-2:1.0: found stage 2 firmware
speedtch-2.bin
Apr  2 14:32:15 localhost firmware_helper[2056]: Loading of
/lib/firmware/speedtch-2.bin for speedtch driver failed: No such file or directory
Apr  2 14:32:19 localhost kernel: ATM dev 0: ADSL line is synchronising


So at least I have a workaround.  I am now going to try puting things back as
they were untill it breaks.
Comment 5 Keith Dixon 2006-04-05 07:00:05 EDT
The failure modes do not seem to be predictable. However, there is mention,
in the 2.6.17 changelog list:-

http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.17-rc1

of race conditions in the kernel request_firmware() hotplug interface:-

commit 9006ea75cfaded82acbc34d03e9d4e86447f40a9
Author: James Ketrenos <jketreno@linux.intel.com>
Date:   Wed Mar 8 03:22:28 2006 +0800

    [PATCH] ipw2200: switch to the new ipw2200-fw-3.0 image format
    
    This patch modifies the driver to support the ipw2200-fw-3.0 image format.
    
    The 3.0 fw image does not add any new capabilities, but as a result of
    image format changes, it should fix two problems experienced by users:
    
    1) Race conditions with the request_firmware interface and udev/hotplug
    are improved as only a single request_firmware call is now required to
    load the firmware and microcode (vs. 3 separate calls previously)
    
    2) The monitor mode firmware (sniffer) is now packaged with the correct
    boot image so it can now function without frequent restarts.
    
    Note: Once you apply this patch, you will also need to upgrade your
    firmware image to the 3.0 version available from:
    
            http://ipw2200.sf.net/firmware.php
    
    Signed-off-by: James Ketrenos <jketreno@linux.intel.com>
    Signed-off-by: Zhu Yi <yi.zhu@intel.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

commit 397ae121ee0116d3b4125d621f0ef528d1d52580
Author: Zhu Yi <yi.zhu@intel.com>
Date:   Tue Jan 24 16:37:22 2006 +0800

    [PATCH] ipw2200: Scale firmware loading watchdog with the firmware size
    
    I can't really help with why restarts happen, but the following patch
    greatly increases the likelihood that a firmware reload will succeed
    afterward on my thinkpad. It addresses two issues. First, sysfs module
    loading and hotplug are asynchronous, and as such file operations on the
    "loading" and "data" files are racy when you load 2 firmwares in quick
    succession. Second, the timeout for DMAing the firmware needs to scale
    with the size of the firmware being loaded. That is, the watchdog needs
    to be on throughput, not on time alone.
    
    I no longer get the firmware load errors, though this is at best a hacky
    workaround for a racy interface. (Obviously, this does nothing to address
    the fatal errors in firmware which cause reloads; it just causes the
    initial loading and the reloads to work more often.)
    
    Signed-off-by: Peter Jones <pjones@redhat.com>
    Signed-off-by: Ben M Cahill <ben.m.cahill@intel.com>
    Signed-off-by: Zhu Yi <yi.zhu@intel.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>


There are two calls to request_firmware in the speedtch driver.

Comment 6 Pete Zaitcev 2006-06-27 14:44:01 EDT
There's more to it, unfortunately.

Keith, I'm sorry that we're letting you down, but I'd like you to keep up
trying and reporting with kernel updates, until you completely run out of
patience or we fix it.

David, I seem to recall you have a similar ADSL kit, any trouble on FC5?
Comment 7 David Woodhouse 2006-06-27 16:17:31 EDT
/me plugs a spare 330 into an FC5 machine.... nope, seems fine. Firmware loads,
if I actually plug it into the DSL line then it syncs fine too.
Comment 8 David Woodhouse 2006-06-27 16:21:23 EDT
Keith, can you confirm precisely when the problem manifests itself and what your
workaround was? Is it sufficient just to reload the speedtch module after the
machine has booted? It only fails to load the firmware when the kernel is first
booting, and it's fine after that?
Comment 9 Keith Dixon 2006-06-28 10:49:47 EDT
Created attachment 131675 [details]
firmware_helper.c

from udev-084-13.src.rpm
Comment 10 Keith Dixon 2006-06-28 10:54:18 EDT
Over here in the UK, those of us in the sticks got 8 Mbit broadband during May.
Given the problems I was having with the SpeedTouch and since my 5 year old PC
has only USB 1.0, I decided to splash out on a Netgear DG834 and FA311 modem
router and lan card.  (the Netgear is Linux based but, as I have since 
discovered, not very open source friendly, perhaps I should have bought a 
Linksys).

I still have the SpeedTouch and will dig it out later today and try it again.
I was waiting for kernel 2.6.17 which I only just installed this morning (I get
free download between 0000 and 0800 BST).  Pup often complains about the 
absence of some server (I cannot remember the details) and gives up, 
particularly over weekends and, this week, did so until this morning 
(wednesday).

Before I got the router, I remember I did a lot of rumaging in the kernel 
source and came to the conclusion that the problem was not in the speedtch 
module or the request_firmware() hotplug interface (although they could both 
benefit from some work) but was a race condition much deeper in the kernel 
which could be affecting functions other than firmware loading.  Then I decided
that until whoever was the maintainer of wherever the problem lay accepted that
there was indeed a problem then the problem would not be fixed.  Given the
rate of change of the relevant areas, which I picked up from LWN, I decided not 
to chase the problem any deeper but wait for 2.6.17.

My workaround is to replace /sbin/firmware_helper with code copiled from the 
source in the attachement and to unload and reload the driver, as described in
Comment #4 above.  Very occasionally, the firmware loads at boot correctly and
sometimes my workaround fails and I have to reboot and try again.  The source
in the attachement may be slightly different from the one that generated the
messages in Comment #4, I played about with it a lot, but the idea is to 
disrupt the timing, with the syslog calls, sufficiently to beat the race 
condition.
Comment 11 David Woodhouse 2006-06-28 11:03:01 EDT
8Mbit/s is only for the lucky ones. Even on 'DSL Max', my line is still syncing
at about 1Mbit/s, which is still well within the 6Mbit/s or so that the
SpeedTouch can handle. 

Can you confirm that you only see this problem when the modem is plugged in
during boot? If you disconnect it and only plug it in later, does the firmware
load OK?
Comment 12 Keith Dixon 2006-06-28 11:24:34 EDT
No. I am pretty certain that I tried that.  I could only get it to load by
changing /sbin/firmware_helper.
Comment 13 Keith Dixon 2006-06-29 07:27:53 EDT
Created attachment 131742 [details]
More  selections from /var/log/messages with kernel 2.6.17

The problem seems to be undiminished.
Comment 14 David Woodhouse 2006-06-29 17:22:06 EDT
I happened to reboot the FC5 machine I'd left a SpeedTouch plugged in to. It
reinitialised perfectly. I'm confused by the errors you're seeing.

Try getting the latest firmware from the drivers at
http://www.speedtouch.co.uk/330.asp ?
Comment 15 Keith Dixon 2006-06-30 02:29:36 EDT
David, how old is the machine with the SpeedTouch?  My machine is a 650Mhz
Athlon.  I have a theory that a modern fast machine would not excite the race
conditions that I think are the problem.  As I reported earlier, I do not think
the problem is in the speedtch module or in the request_firmware() hotplug 
interface but much deeper in the kernel.
Comment 16 David Woodhouse 2006-06-30 04:12:39 EDT
In this case it was a 2.3GHz Mac G5. The machine in which the other SpeedTouch
actually gets _used_ 100% of the time is a 1GHz Pentium-III, running FC3.

Can you send a description of this problem to usbatm@lists.infradead.org ?
Comment 17 Keith Dixon 2006-06-30 06:23:44 EDT
I never had any problem with FC3 or FC4.  The problem appeared immediately
after I installed FC5.  BTW I have been using ZZZL_3.012 firmware from the 
start.  Just to make sure I downloaded SpeedTouch330_firmware_3012.zip and 
diffed it with the file already on my disc; they are the same.  I will post to
usbatm.
Comment 18 Eryk Laskowski 2006-07-04 12:03:05 EDT
I have similar problem with my SpeedTouch 330 USB modem. Symptoms are the same
as in Keith's system. I am able to load firmware by reloading speedtch module
(or by replugging the modem). The problems started to appear just after
upgrading from Fedora 4 to Fedora 5. Current kernel: 2.6.17-1.2139_FC5 x86_64. I
didn't try the Keith's workaround.
Comment 19 Milosz K. 2006-09-22 13:54:53 EDT
Has anyone read that: http://tinyurl.com/rmprz ?
Maybe that's the point.
Comment 20 Dave Jones 2006-10-16 16:55:56 EDT
A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed.  See bug 207474 for further details.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.

Thank you.
Comment 21 Keith Dixon 2006-10-18 09:27:21 EDT
Created attachment 138779 [details]
selections from messages and corresponding o/p from udevmonitor

Ho Hum, no luck with 2.6.18.  Gory details in attachment.
Comment 22 Keith Dixon 2006-10-20 06:46:40 EDT
There is a line below which states: "Bug currently in NEEDINFO. Adding comment
will automatically toggle status to ASSIGNED." I entered Comment #21 and the
status is still NEEDINFO.  This comment is just an experiment to see what
happens to the status.
Comment 23 szp@k 2006-10-23 14:49:04 EDT
It's still worse after upgrade to 2.6.18-1.2200.fc5

In the /lib/firmware I've got the files:

speedtch-1.bin.4.00
speedtch-2.bin.4.00

Every time I start the system, I get:

Oct 23 19:20:20 szpak kernel: usbcore: registered new driver speedtch
...
Oct 23 19:20:20 szpak kernel: speedtch 1-1:1.0: found stage 1 firmware
speedtch-1.bin.4.00
Oct 23 19:20:20 szpak kernel: speedtch 1-1:1.0: found stage 2 firmware
speedtch-2.bin.4.00
...
Oct 23 19:20:20 szpak kernel: speedtch 1-1:1.0: speedtch_upload_firmware: read
BLOCK4 from modem failed (-110)!
Oct 23 19:20:20 szpak kernel: speedtch 1-1:1.0: speedtch_heavy_init: firmware
upload failed (-110)!

Usually it was enough to add the script:
rmmod speedtch
sleep 1
modprobe speedtch
to the boot sequence (/etc/rc.d/rc5.d/S09speedtch.sh), and it worked, but after
upgrading kernel to 2.6.18-1.2200.fc5 it doesn't help, I receive:

Oct 23 19:20:20 szpak kernel: usbcore: deregistering driver speedtch
Oct 23 19:20:20 szpak kernel: usb 1-1: reset full speed USB device using
uhci_hcd and address 2
Oct 23 19:20:20 szpak kernel: usbcore: registered new driver speedtch
Oct 23 19:20:20 szpak kernel: speedtch 1-1:1.0: found stage 1 firmware
speedtch-1.bin.4.00
Oct 23 19:20:20 szpak kernel: speedtch 1-1:1.0: found stage 2 firmware
speedtch-2.bin.4.00
Oct 23 19:20:20 szpak kernel: speedtch 1-1:1.0: speedtch_upload_firmware: read
BLOCK4 from modem failed (-110)!
Oct 23 19:20:20 szpak kernel: speedtch 1-1:1.0: speedtch_heavy_init: firmware
upload failed (-110)!

I put another script to the boot sequence (/etc/rc.d/rc5.d/S98speedtch.sh), it
didn't work:

Oct 23 19:23:53 szpak kernel: usbcore: deregistering driver speedtch
...
Oct 23 19:23:55 szpak kernel: usbcore: registered new driver speedtch
Oct 23 19:23:55 szpak kernel: speedtch 1-1:1.0: found stage 1 firmware
speedtch-1.bin.4.00
Oct 23 19:23:55 szpak kernel: speedtch 1-1:1.0: found stage 2 firmware
speedtch-2.bin.4.00
Oct 23 19:23:55 szpak firmware_helper[4199]: Loading of
/lib/firmware/speedtch-1.bin.4.00 for speedtch driver failed: No such file or
directory
Oct 23 19:23:55 szpak firmware_helper[4206]: Loading of
/lib/firmware/speedtch-2.bin.4.00 for speedtch driver failed: No such file or
directory


After boot I have to repeat several times:

rmmod speedtch
sleep 1
modprobe speedtch

I get:

usbcore: deregistering driver speedtch
usb 1-1: reset full speed USB device using uhci_hcd and address 2
usbcore: registered new driver speedtch
speedtch 1-1:1.0: found stage 1 firmware speedtch-1.bin.4.00
speedtch 1-1:1.0: found stage 2 firmware speedtch-2.bin.4.00
speedtch 1-1:1.0: speedtch_upload_firmware: read BLOCK4 from modem failed (-110)!
speedtch 1-1:1.0: speedtch_heavy_init: firmware upload failed (-110)!

and after 3-4 times it works:

usbcore: deregistering driver speedtch
usb 1-1: reset full speed USB device using uhci_hcd and address 2
usbcore: registered new driver speedtch
speedtch 1-1:1.0: found stage 1 firmware speedtch-1.bin.4.00
speedtch 1-1:1.0: found stage 2 firmware speedtch-2.bin.4.00
ATM dev 0: ADSL line is synchronising
ATM dev 0: ADSL line is up (320 kb/s down | 160 kb/s up)

It repeats every time I boot/reboot the system.
Comment 24 szp@k 2006-10-25 17:31:56 EDT
...but it works great in kernel-2.6.18-1.2798.fc6 - no need to rmmod/modprobe
speedtch, it works at once.
Comment 25 Keith Dixon 2006-11-05 13:54:18 EST
I can also confirm that FC6 with kernel-2.6.18-1.2798.fc6 works.  I have not had a
failure to load the firmware yet.
Comment 26 Dave Jones 2006-11-20 14:27:37 EST
that's really bizarre, as the firmware loading code, and the speedtouch code in
the latest FC5 & FC6 kernels are _identical_.  The only real differences are in
some config options, and none of those should really make a difference for this.

I'm really at a loss to explain why it's broken on FC5.

A workaround that might help, would be to increase /sys/class/firmware/timeout
Can one of you try this, or have you all upgraded to FC6 now?
Comment 27 Keith Dixon 2006-11-20 15:01:48 EST
I still have an FC5 installation, although I have not used it for a while.  I
seem to remember there being issues around /sys/class/firmware/timeout causing
udev to wait for no good reason at boot.  I have always thought that the problem
is not in  the firmware loading code or the speedtouch code.  When I get the
opportunity I will fire up the FC5 installation and try your suggestion.
Comment 28 Răzvan Sandu 2007-10-29 12:34:45 EDT
I have managed to install the SpeedTouch 330 on Fedora 7 with no problems.

Please see here:
http://www.linux-usb.org/SpeedTouch/index.html


Regards,
Razvan
Comment 29 Bug Zapper 2008-04-03 22:21:53 EDT
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
Comment 30 Bug Zapper 2008-05-06 11:42:14 EDT
This bug is open for a Fedora version that is no longer maintained and
will not be fixed by Fedora. Therefore we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen thus bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.