On Thu, 29 Jun 2017 11:14:54 +0200
Dario Lesca <d.lesca(a)solinos.it> wrote:
Il giorno mer, 28/06/2017 alle 07.56 -0700, stan ha scritto:
> Is it possible you are running into this warning from the kernel
> documentation, cxacru-cf.py?
>
> # Warning: cxacru-cf.bin with MD5 hash #
> bac2689969d5ed5d4850f117702110 # contains mis-aligned values which
> will stop the modem from being able # to make a connection.
Thank Stan, but this is not my case:
> [lesca@igloo ~]$ md5sum /lib/firmware/cxacru-fw.bin
> 48071d47f119c9de550b6d446cf91589 /lib/firmware/cxacru-fw.bin
The problem occur only during the boot process, and only with Fedora
25, if I start old PC with Fedora11 all work fine.
I think this is why it doesn't work at boot,
...support for cxacru-cf.bin has been removed.
So it doesn't load the binary blob, because it doesn't recognize it. I
think the program cxacru-cf.py is meant to reformat the binary blob
into a format that the kernel can recognize. At least that's how I
read the description. The program is in the file in the kernel
documentation, you should be able to find it online with a search on
the name.
It is probable that the support for the firmware binary blob was still
there in F11 kernels, which is why it works.
And in Fedora 25 if I plug the modem after boot all work fine.
I think that works because of this
...While it is capable of managing/maintaining the ADSL connection
without the module loaded, the device will sometimes stop responding
after unloading the driver and it is necessary to unplug/remove power
to the device to fix this.
So, it seems that when the device fails to load the firmware, it will
still work, but it can lock up. By plugging and unplugging you are
resetting it, and allowing it to work without the firmware loaded.
Some other suggest?
...There is a script cxacru-cf.py to convert an existing file to the
sysfs form.
I would try running the cxacru-cf.py program on the cxacru-fw.bin blob,
to convert it to the sysfs form the kernel wants, and see if it will
then load. If that doesn't work, you could try opening a bugzilla to
see if a kernel maintainer can give you better ideas of how to work
around this.
It might be possible to hack the kernel code to restore the
functionality for this driver that was present in F11 kernels in the F25
kernel. Not an easy thing to do, I think.
Or, just resign yourself to your current workaround.