Bug 197076 - Only One Port Of Dual Port EC2000S (RTL8111E, r8169) Detected
Summary: Only One Port Of Dual Port EC2000S (RTL8111E, r8169) Detected
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 10.1-RELEASE
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-net (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-01-25 21:28 UTC by webdawg
Modified: 2016-04-14 03:28 UTC (History)
2 users (show)

See Also:


Attachments
output of dmesg, pciconf, and devinfo (25.55 KB, text/plain)
2015-01-25 21:28 UTC, webdawg
no flags Details
dmesg output (67.52 KB, text/plain)
2016-04-14 03:26 UTC, webdawg
no flags Details
pciconf (11.29 KB, text/plain)
2016-04-14 03:27 UTC, webdawg
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description webdawg 2015-01-25 21:28:50 UTC
Created attachment 152132 [details]
output of dmesg, pciconf, and devinfo

FreeBSD will only detect one interface of a dual port expresscard gigabit adapter.

It is a Startech express card detailed here:  http://www.startech.com/Networking-IO/Adapter-Cards/Dual-Port-ExpressCard-Gigabit-Ethernet-NIC~EC2000S

Realtek - RTL8111E chipset.

re0 shows up, but re1 does not.


Attached is some more information from some commands.  Please let me know if you need anything else.
Comment 1 webdawg 2015-01-25 21:30:28 UTC
I tested the card in Linux with success and swapped the laptop with another tested in ArchLinux (detects as r8169) to ensure that it was not a hardware issue.
Comment 2 John Baldwin freebsd_committer freebsd_triage 2015-03-09 17:10:15 UTC
Please try a snapshot of HEAD.  It should try to allocate a PCI bus number for your second device which is currently failing on 10.1.  Note that if a HEAD snapshot doesn't work out of the box, please try setting 'hw.pci.clear_buses=1' in the loader before booting a HEAD kernel.

(The relevant change to merge if this fixes it is r261790)
Comment 3 commit-hook freebsd_committer freebsd_triage 2015-04-01 21:49:39 UTC
A commit references this bug:

Author: jhb
Date: Wed Apr  1 21:48:59 UTC 2015
New revision: 280970
URL: https://svnweb.freebsd.org/changeset/base/280970

Log:
  MFC 261790:
  Add support for managing PCI bus numbers.  As with BARs and PCI-PCI bridge
  I/O windows, the default is to preserve the firmware-assigned resources.
  PCI bus numbers are only managed if NEW_PCIB is enabled and the architecture
  defines a PCI_RES_BUS resource type.
  - Add a helper API to create top-level PCI bus resource managers for each
    PCI domain/segment.  Host-PCI bridge drivers use this API to allocate
    bus numbers from their associated domain.
  - Change the PCI bus and CardBus drivers to allocate a bus resource for
    their bus number from the parent PCI bridge device.
  - Change the PCI-PCI and PCI-CardBus bridge drivers to allocate the
    full range of bus numbers from secbus to subbus from their parent bridge.
    The drivers also always program their primary bus register.  The bridge
    drivers also support growing their bus range by extending the bus resource
    and updating subbus to match the larger range.
  - Add support for managing PCI bus resources to the Host-PCI bridge drivers
    used for amd64 and i386 (acpi_pcib, mptable_pcib, legacy_pcib, and qpi_pcib).
  - Define a PCI_RES_BUS resource type for amd64 and i386.

  PR:		197076

Changes:
_U  stable/10/
  stable/10/sys/amd64/include/resource.h
  stable/10/sys/dev/acpica/acpi_pcib_acpi.c
  stable/10/sys/dev/acpica/acpi_pcib_pci.c
  stable/10/sys/dev/cardbus/cardbus.c
  stable/10/sys/dev/cardbus/cardbusvar.h
  stable/10/sys/dev/pccbb/pccbb.c
  stable/10/sys/dev/pccbb/pccbb_isa.c
  stable/10/sys/dev/pccbb/pccbb_pci.c
  stable/10/sys/dev/pccbb/pccbbvar.h
  stable/10/sys/dev/pci/pci.c
  stable/10/sys/dev/pci/pci_pci.c
  stable/10/sys/dev/pci/pci_private.h
  stable/10/sys/dev/pci/pci_subr.c
  stable/10/sys/dev/pci/pcib_private.h
  stable/10/sys/i386/include/resource.h
  stable/10/sys/sparc64/pci/apb.c
  stable/10/sys/x86/include/legacyvar.h
  stable/10/sys/x86/pci/pci_bus.c
  stable/10/sys/x86/pci/qpi.c
  stable/10/sys/x86/x86/mptable_pci.c
Comment 4 John Baldwin freebsd_committer freebsd_triage 2015-04-01 22:17:06 UTC
I have merged the change that I believe should fix this back to stable/10.  I do not plan on merging this to 9.x, and I do not plan on trying to get this into 10.1 as an EN.  It should be present in 10.2 when that is released.  Please reopen if this fix does not work for you when you test it.
Comment 5 webdawg 2016-03-29 14:11:21 UTC
I have tested, I think, the releases that you mentioned.

It did not seem to work, can you please tell me which release to test with now and I will get it tested this week.

Also, I could not figure out how to set hw.pci.clear_buses=1

I think in the end I did get it set, but can you tell the file I should put it in?

Sorry for the lag on responding to this issue, the hardware I need to test this on I am finally going through testing and working on for other reasons.
Comment 6 John Baldwin freebsd_committer freebsd_triage 2016-03-30 04:12:38 UTC
You would set hw.pci.clear_buses in /boot/loader.conf or at the loader prompt via 'set hw.pci.clear_buses=1'.

If you could get a verbose dmesg from 10.3 snapshot (enable verbose boot in the loader menu or use 'boot -v' at the loader prompt) along with the output of 'pciconf -lBc' that would be useful.
Comment 7 webdawg 2016-04-14 03:26:48 UTC
Created attachment 169304 [details]
dmesg output
Comment 8 webdawg 2016-04-14 03:27:28 UTC
Created attachment 169305 [details]
pciconf
Comment 9 webdawg 2016-04-14 03:28:11 UTC
Still no luck.

I am ready this time with a system to work with if you want to pursue this.

I have attached two new files with what you asked for.