netdev - Re: [PATCH] starfire: Clean up properly if firmware loading fails

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <4B5E82CB.6040001@moffatt.org.nz>
Date:	Tue, 26 Jan 2010 18:51:07 +1300
From:	Michael <michael@...fatt.org.nz>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Ben Hutchings <bhutchings@...arflare.com>, netdev@...r.kernel.org,
	bugzilla-daemon@...zilla.kernel.org,
	bugme-daemon@...zilla.kernel.org,
	Alan Cox <alan@...rguk.ukuu.org.uk>, stable@...nel.org,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH] starfire: Clean up properly if firmware loading fails

Hi Andrew,

Yep, OK, I hadn't seen that log in dmesg.

That driver is new to me, it's never turned up (or been required) before 
so that must be new between 2.6.24 and 2.6.32.

As this is a root over nfs system, the kernel is compiled elsewhere and 
then installed manually. What I was missing was that there is a new 
adaptec directory that needed to be copied from 
/usr/src/linux-2.6.32/firmware/ to /lib/2.6.32. Actually, I am not sure 
that this is the right place for it (rather than say 
/lib/firmware/2.6.32|, but it seems to work anyway.

Quite a gotchya. After compiling a kernel on a separate compiling 
system, I don't actually run the 'make install' on the nfs system. 
Previously I used to run the 'make install' on a dedicated compiling 
server and then just copy the modules from that system into the root 
over nfs exported /lib/modules directory. That'd worked fine up until now.

I will have to find a cleverer way to copy over the new firmware libs 
for future compiles. The 'make install' seems to copy firmware objects 
into the compiling system's /lib/firmware/ directory without 
distinguishing the kernel version. So I can't easily tell which ones I'm 
supposed to be copying into the nfs export.

Many thanks for all your help. The interfaces are up and apparently you 
understand where the kernel BUG came from.

So does that complete the story now? In other words, is there anything 
further you need from me.

Many thanks,
Michael.
|

Andrew Morton wrote:
> On Tue, 26 Jan 2010 15:58:39 +1300 Michael <michael@...fatt.org.nz> wrote:
>
>   
>> Hi guys,
>>
>> I think I'm the submitter that Ben is referring to.
>>
>> So that could be the answer to the kernel BUG I have reported, but I 
>> don't think that it will answer why the interface doesn't come up... or 
>> does it?
>>     
>
> >From this:
>
> Jan 21 05:08:26 172 kernel: starfire: Failed to load firmware "adaptec/starfire_rx.bin"
> Jan 21 05:08:26 172 kernel: device eth4 entered promiscuous mode
> Jan 21 05:08:26 172 kernel: starfire 0000:03:06.0: firmware: requesting adaptec/starfire_rx.bin
> Jan 21 05:08:26 172 kernel: starfire: Failed to load firmware "adaptec/starfire_rx.bin"
> Jan 21 05:08:26 172 kernel: device eth5 entered promiscuous mode
> Jan 21 05:08:26 172 kernel: starfire 0000:03:07.0: firmware: requesting adaptec/starfire_rx.bin
> Jan 21 05:08:26 172 kernel: starfire: Failed to load firmware "adaptec/starfire_rx.bin"
> Jan 21 05:08:26 172 kernel: device eth6 entered promiscuous mode
> Jan 21 05:08:26 172 kernel: starfire 0000:04:04.0: firmware: requesting adaptec/starfire_rx.bin
>
> I assume that it can't find the firmware?
>   

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html