e100 firmware in 2.6.29-rc7?

Previous thread: [PATCH] bonding: allow bond in mode balance-alb to work properly in bridge by Jiri Pirko on Friday, March 13, 2009 - 11:33 am. (99 messages)

Next thread: Re: [RFC v2: Patch 1/3] net: hand off skb list to other cpu to submit to upper layer by David Miller on Friday, March 13, 2009 - 2:02 pm. (11 messages)
From: Ben Greear
Date: Friday, March 13, 2009 - 1:16 pm

I have selected build-firmware-into-kernel
but it seems e100 is still unhappy in 2.6.29-rc7.

e100 0000:02:01.0: firmware: requesting e100/d102e_ucode.bin
e100: eth4: e100_request_firmware: Failed to load firmware "e100/d102e_ucode.bin": -2

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

--

From: Brandeburg, Jesse
Date: Monday, March 16, 2009 - 11:47 am

can you post anything extra about your config? arch? full dmesg? full 
.config?

There have been several other reports of this but setting 
CONFIG_FIRMWARE_IN_KERNEL=y seems to fix them in general.

also please post lspci -vvv -s 2:1.0, after failing to load.  I'm curious 
if the device might be in D3 still.

you can likely just get working by commenting out the firmware load for 
e100.  It may or may not re-enable a hardware bug depending upon the 
hardware you have.

Jesse
--

From: Ben Greear
Date: Monday, March 16, 2009 - 12:13 pm

We got it working by copying firmware from another system (FC8) that had
it in /lib/firmware.

Just retested with -rc8 from Friday, and it is repeatable.

The config & dmesg is attached.  Some of the options are for patches we've
added, and we even have a small patch in the e100 (but have had it there
for years, so probably un-related to this).  Still, I will not complain
if you decide to ignore the report.


[root@demo1 ~]# lspci -vvv -s 2:1.0
02:01.0 Ethernet controller: Intel Corporation 8255xER/82551IT Fast Ethernet Controller (rev 10)
         Subsystem: Ramix Inc Unknown device 0610
         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
         Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
         Latency: 32 (2000ns min, 14000ns max), Cache Line Size: 32 bytes
         Interrupt: pin A routed to IRQ 16
         Region 0: Memory at e0181000 (32-bit, non-prefetchable) [size=4K]
         Region 1: I/O ports at d400 [size=64]
         Region 2: Memory at e0120000 (32-bit, non-prefetchable) [size=128K]
         Capabilities: [dc] Power Management version 2
                 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
                 Status: D0 PME-Enable- DSel=0 DScale=2 PME-
         Kernel driver in use: e100
         Kernel modules: e100


We can provide more info as needed, including remote login if you want.

Thanks,


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

From: Ben Hutchings
Date: Monday, March 16, 2009 - 12:25 pm

[...]

Your config has CONFIG_E100=m, but CONFIG_FIRMWARE_IN_KERNEL only
applies to firmware used by non-modular drivers.  The assumption is that
once userland is capable of loading modules it is also capable of
loading firmware.

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

--

From: Ben Greear
Date: Monday, March 16, 2009 - 1:05 pm

Well, that's an annoyance.  Would it be that hard to allow modular drivers
to compile-in their FW as well?  It would be a nice option for
those of us trying to build portable pre-compiled kernels for various
distributions and distribution versions.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

--

From: Dan Williams
Date: Monday, March 16, 2009 - 1:12 pm

Most of those distros will have firmware loading capability though,
right?  Every non-embedded distro (Fedora, RHEL, SUSE, Ubuntu,
Slackware, Mandriva, Xandros, etc) has it, so if you're building kernels
for those, there's not really a problem with dropping firmware into the
firmware directory for that distro, right?

Dan


--

From: Ben Greear
Date: Monday, March 16, 2009 - 1:20 pm

No, but figuring out the problem from a customer's bug report ("nothing works")
and then finding the firmware and having the customer install it will be much
worse than just having everything work like it used to.

I just see zero benefits to having external firmware
for the vast majority of end-users, and lots of downside
for at least myself.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

--

Previous thread: [PATCH] bonding: allow bond in mode balance-alb to work properly in bridge by Jiri Pirko on Friday, March 13, 2009 - 11:33 am. (99 messages)

Next thread: Re: [RFC v2: Patch 1/3] net: hand off skb list to other cpu to submit to upper layer by David Miller on Friday, March 13, 2009 - 2:02 pm. (11 messages)