Hide Forgot
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
Created attachment 534324 [details] Ram's patch part1
Created attachment 534325 [details] Ram's patch part2
(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.
------- 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?
(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?
(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.