From: Michael <michael@moffatt.org.nz>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Ben Hutchings <bhutchings@solarflare.com>,
netdev@vger.kernel.org, bugzilla-daemon@bugzilla.kernel.org,
bugme-daemon@bugzilla.kernel.org,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
stable@kernel.org, "David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH] starfire: Clean up properly if firmware loading fails
Date: Tue, 26 Jan 2010 18:51:07 +1300 [thread overview]
Message-ID: <4B5E82CB.6040001@moffatt.org.nz> (raw)
In-Reply-To: <20100125192839.7eaceb2b.akpm@linux-foundation.org>
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@moffatt.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?
>
next prev parent reply other threads:[~2010-01-26 5:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <bug-15091-10286@http.bugzilla.kernel.org/>
2010-01-26 1:08 ` [Bugme-new] [Bug 15091] New: starfire causes kernel BUG when interface goes up Andrew Morton
2010-01-26 1:44 ` Michael
2010-01-26 1:51 ` Andrew Morton
2010-01-26 2:02 ` [PATCH] starfire: Clean up properly if firmware loading fails Ben Hutchings
2010-01-26 2:15 ` Andrew Morton
2010-01-26 2:32 ` Ben Hutchings
2010-01-26 2:58 ` Michael
2010-01-26 3:28 ` Andrew Morton
2010-01-26 5:51 ` Michael [this message]
2010-01-26 5:57 ` Andrew Morton
2010-01-26 14:40 ` Ben Hutchings
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B5E82CB.6040001@moffatt.org.nz \
--to=michael@moffatt.org.nz \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=bhutchings@solarflare.com \
--cc=bugme-daemon@bugzilla.kernel.org \
--cc=bugzilla-daemon@bugzilla.kernel.org \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=stable@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).