Bug 754859

Summary: Load moduale be2net failed
Product: [Fedora] Fedora Reporter: IBM Bug Proxy <bugproxy>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 16CC: gansalmon, itamar, jkachuck, jonathan, kernel-maint, madhu.chinakonda, wgomerin
Target Milestone: ---   
Target Release: ---   
Hardware: ppc64   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-02-28 18:01:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Ram's patch part1
none
Ram's patch part2 none

Description IBM Bug Proxy 2011-11-17 22:30:25 UTC 
After using the modprobe be2net, dmesg shows the following error information:

[   13.104276] be2net 0004:01:00.0: device not available (can't reserve [mem 0x00000000-0x000fffff 64bit])
[   13.104608] be2net 0004:01:00.0: Emulex OneConnect 10Gbps NIC(be3) initialization failed
[   13.104811] be2net: probe of 0004:01:00.0 failed with error -22
[   13.104990] be2net 0004:01:00.1: device not available (can't reserve [mem 0x00000000-0x000fffff 64bit])
[   13.105216] be2net 0004:01:00.1: Emulex OneConnect 10Gbps NIC(be3) initialization failed
[   13.105417] be2net: probe of 0004:01:00.1 failed with error -22

The information shown from lspci:

0004:01:00.0 Ethernet controller: Emulex Corporation OneConnect 10Gb NIC (be3) (rev 02)
0004:01:00.1 Ethernet controller: Emulex Corporation OneConnect 10Gb NIC (be3) (rev 02)

which means the adapter using driver be2net has already been registered to the PCI bus.

== Comment  2011.11.11 02:41:39 ==
After using Paul's kernel tree, the kernel can be booted; and after applying Ram's patch, the be2net can be loaded and the nic appeared. I am currently testing the performance to ensure the driver works properly.

== Comment: 2011.11.14 20:53:27 ==
These patches are submitted upstream. The maintainer is willing to take the patches, if he gets some tested-by  mails from a couple of people.  Once that is done, and hopefully no one reports any issues, we should be able to backport the patches to Fedora kernel.

RP
Comment 1 IBM Bug Proxy 2011-11-17 22:30:39 UTC 
Created attachment 534324 [details]
Ram's patch part1
Comment 2 IBM Bug Proxy 2011-11-17 22:30:49 UTC 
Created attachment 534325 [details]
Ram's patch part2
Comment 3 Josh Boyer 2011-11-22 17:48:29 UTC 
(In reply to comment #1)
> Created attachment 534324 [details]
> Ram's patch part1

http://thread.gmane.org/gmane.linux.kernel.pci/12070/focus=12459
Comment 4 Josh Boyer 2011-11-22 17:50:15 UTC 
(In reply to comment #2)
> Created attachment 534325 [details]
> Ram's patch part2

http://thread.gmane.org/gmane.linux.kernel.pci/12070/focus=12460
Comment 5 Josh Boyer 2011-11-22 17:52:27 UTC 
Neither of those are in Linus tree, or linux-next.  We'll wait a bit longer to see what direction they take upstream.
Comment 6 IBM Bug Proxy 2012-01-16 20:31:44 UTC 
------- Comment From clnperez.com 2012-01-16 15:26 EDT-------
(In reply to comment #22)
> (In reply to comment #1)
> > Created attachment 534324 [details]
> > Ram's patch part1
>
> http://thread.gmane.org/gmane.linux.kernel.pci/12070/focus=12459
>
> (In reply to comment #2)
> > Created attachment 534325 [details]
> > Ram's patch part2
>
> http://thread.gmane.org/gmane.linux.kernel.pci/12070/focus=12460
>
> Neither of those are in Linus tree, or linux-next.  We'll wait a bit longer to
> see what direction they take upstream.

Has anything changed with these?
Comment 7 Josh Boyer 2012-01-16 21:07:30 UTC 
(In reply to comment #6)
> ------- Comment From clnperez.com 2012-01-16 15:26 EDT-------
> (In reply to comment #22)
> > (In reply to comment #1)
> > > Created attachment 534324 [details]
> > > Ram's patch part1
> >
> > http://thread.gmane.org/gmane.linux.kernel.pci/12070/focus=12459
> >
> > (In reply to comment #2)
> > > Created attachment 534325 [details]
> > > Ram's patch part2
> >
> > http://thread.gmane.org/gmane.linux.kernel.pci/12070/focus=12460
> >
> > Neither of those are in Linus tree, or linux-next.  We'll wait a bit longer to
> > see what direction they take upstream.
> 
> Has anything changed with these?

The "PCI: defer enablement of SRIOV BARS" patch is in the 3.2 kernel release, and F16 will be moving to that later this week.  The other patch is upstream in Linus' tree for what will become the 3.3 tree.

I don't know why they were accepted split across two releases.  Are both really needed to fix the issue?
Comment 8 Josh Boyer 2012-02-28 18:01:29 UTC 
(In reply to comment #7)
> (In reply to comment #6)
> > ------- Comment From clnperez.com 2012-01-16 15:26 EDT-------
> > (In reply to comment #22)
> > > (In reply to comment #1)
> > > > Created attachment 534324 [details]
> > > > Ram's patch part1
> > >
> > > http://thread.gmane.org/gmane.linux.kernel.pci/12070/focus=12459
> > >
> > > (In reply to comment #2)
> > > > Created attachment 534325 [details]
> > > > Ram's patch part2
> > >
> > > http://thread.gmane.org/gmane.linux.kernel.pci/12070/focus=12460
> > >
> > > Neither of those are in Linus tree, or linux-next.  We'll wait a bit longer to
> > > see what direction they take upstream.
> > 
> > Has anything changed with these?
> 
> The "PCI: defer enablement of SRIOV BARS" patch is in the 3.2 kernel release,
> and F16 will be moving to that later this week.  The other patch is upstream in
> Linus' tree for what will become the 3.3 tree.

F16 has been on 3.2 for a while now.

> I don't know why they were accepted split across two releases.  Are both really
> needed to fix the issue?

Since nobody replied, I guess the answer is now.  Closing this bug out.