Bug 815579

Summary: linux-firmware shipping wrong firmware for emi
Product: [Fedora] Fedora Reporter: Monty <cmontgom>
Component: linux-firmwareAssignee: David Woodhouse <dwmw2>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 19CC: dwmw2, kem, kernel-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: linux-firmware-20140131-34.gitd7f8a7c8.fc19 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-02-04 02:49:36 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
correct emi26/bitstream.fw file
none
correct emi26/firmware.fw file
none
correct emi26/loader.fw file
none
correct emi62/bitstream.fw file
none
correct emi62/loader.fw file
none
correct emi62/midi.fw file
none
correct emi62/spdif.fw file none

Description Monty 2012-04-23 23:38:59 UTC
Created attachment 579720 [details]
correct emi26/bitstream.fw file

Description of problem:

The firmware files shipping for the emi62 are nonfunctional; they result in a locked-up device with the internal error light on.

The firmware files being shipped for the emi26 are out of date; they're a prerelease version.

Note that the firmware files being shipped in the stock kernel are also broken; it appears the problem happened during a 'cleanup' just before 2.6.27 when the original files that were shipped with the kernel were replaced with the ones there now.

Version-Release number of selected component (if applicable):

All versions to date

How reproducible:

Always

Steps to Reproduce:
1. Plug in emi62m or emi26
2.
3.
  
Actual results:

Emi6|2 lights internal not ready/error red LED; light remains lit with device locked up.

Emi2|6 functions, but missing several capabilities of the hardware (such as 96kHz sampling).

Expected results:

Emi6|2m lights red light for approximately a second, followed by its startup sequence of several green light patterns.  Device at that point is ready to operate.

Emi2|6 starts up normally with green light pattern; 96kHz sampling is listed in endpoint capabilities.  The newer firmware contains several other bugfixes as well.

Additional info:

Will be adding seven attachments for correct firmware files

Comment 1 Monty 2012-04-23 23:40:08 UTC
Created attachment 579721 [details]
correct emi26/firmware.fw file

Comment 2 Monty 2012-04-23 23:40:48 UTC
Created attachment 579722 [details]
correct emi26/loader.fw file

Comment 3 Monty 2012-04-23 23:41:27 UTC
Created attachment 579723 [details]
correct emi62/bitstream.fw file

Comment 4 Monty 2012-04-23 23:41:58 UTC
Created attachment 579724 [details]
correct emi62/loader.fw file

Comment 5 Monty 2012-04-23 23:42:32 UTC
Created attachment 579725 [details]
correct emi62/midi.fw file

Comment 6 Monty 2012-04-23 23:43:07 UTC
Created attachment 579726 [details]
correct emi62/spdif.fw file

Comment 7 Josh Boyer 2012-04-24 00:49:29 UTC
Where did you get these files from?  Also, is there a reason they haven't been sent to the upstream linux-firmware project?

http://git.kernel.org/?p=linux/kernel/git/firmware/linux-firmware.git;a=summary

We essentially package what is in there, so if the files are stale they're stale for everyone using that.  It's probably better to send them to the linux-firmware maintainers upstream, with the proper information on where they came from.

Comment 8 Monty 2012-04-24 01:37:31 UTC
> Where did you get these files from?

They were extracted (by me) from the last driver update Apple offered for download for the device in ~2004 for Mac OS X 10.4. 

> Also, is there a reason they haven't been
> sent to the upstream linux-firmware project?

I offered them to upstream, who was leery that the update from Apple contained no license information (at least, none I can find.  I have grepped the entire contents of the .dmg, including the binaries.  Apple bought eMagic in 2002 shortly after Tapio finished his original driver).

The discussion then got bogged down into whether or not Tapio had ever had explicit permission to distribute the firmware that was put in the kernel in 2002. No one succeeded in contacting him.

In the end they did nothing; they did not restore the old firmware that worked but was buggy, update to the new firmware with no explicit license, or remove the driver that's been nonfunctional for nearly five years.

I'll also point out the clobber that accidentally replaced the working firmware from 2.6.26 with the broken files in 2.6.27 (I think I have those version right) also stripped out the original license text.

> We essentially package what is in there, so if the files are stale they're
> stale for everyone using that.  It's probably better to send them to the
> linux-firmware maintainers upstream, with the proper information on where they
> came from.

That would be nice :-)  OK, I'll try again, especially as the firmware loader in the kernel is itself broken now and in need of patching.

Comment 9 Monty 2012-04-24 01:40:33 UTC
Aplogies-- what is the correct mailing list to contact linux-firmware these days?  I think perhaps my problem in the past was going through the ALSA maintainers.

Comment 10 Josh Boyer 2012-04-24 11:36:21 UTC
(In reply to comment #9)
> Aplogies-- what is the correct mailing list to contact linux-firmware these
> days?  I think perhaps my problem in the past was going through the ALSA
> maintainers.

Send them to David Woodhouse <dwmw2> and Ben Hutchings <ben.uk>, probably with linux-kernel.org CC'd, and maybe the ALSA list as well.

Comment 11 Fedora End Of Life 2013-04-03 14:44:15 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

Comment 13 Josh Boyer 2014-01-31 12:13:54 UTC
I've updated the firmware in Fedora git this morning.  An update will roll out to the releases shortly.

Comment 14 Fedora Update System 2014-01-31 14:26:48 UTC
linux-firmware-20140131-34.gitd7f8a7c8.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/linux-firmware-20140131-34.gitd7f8a7c8.fc19

Comment 15 Fedora Update System 2014-01-31 14:27:57 UTC
linux-firmware-20140131-35.gitd7f8a7c8.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/linux-firmware-20140131-35.gitd7f8a7c8.fc20

Comment 16 Fedora Update System 2014-02-01 04:02:34 UTC
Package linux-firmware-20140131-34.gitd7f8a7c8.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing linux-firmware-20140131-34.gitd7f8a7c8.fc19'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-1860/linux-firmware-20140131-34.gitd7f8a7c8.fc19
then log in and leave karma (feedback).

Comment 17 Fedora Update System 2014-02-04 02:49:36 UTC
linux-firmware-20140131-35.gitd7f8a7c8.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 18 Fedora Update System 2014-02-20 00:45:08 UTC
linux-firmware-20140131-34.gitd7f8a7c8.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.