Re: Realtek 8723BE unsupported
On Dec 04 11:16:04, da...@gwynne.id.au wrote: > On Sun, Dec 03, 2023 at 06:02:03PM +0100, Jan Stary wrote: > > (please keep replies on the list) > > > > On Dec 03 12:08:08, kolip...@exoticsilicon.com wrote: > > > On Sun, Dec 03, 2023 at 02:35:11PM +0100, Jan Stary wrote: > > > > This is current/amd64 on a HP 260 G2 mini PC (dmesg below). > > > > Everything works, except the wifi seems to be unsupported: > > > > > > > > "Realtek 8723BE" rev 0x00 at pci2 dev 0 function 0 not configured > > > > > > What does pcidump -v show? > > > > First of all, pcidump -v (but not pcidump) fucks up re(4): > > > > rgephy0 detached > > re0 detached > > re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x10: RTL8168GU/8111GU > > (0x5080), msi, address 7c:d3:0a:21:eb:f5 > > rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0 > > re0: cannot create re-stats kstat > > rgephy0 detached > > re0 detached > > re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x10: RTL8168GU/8111GU > > (0x5080), msi, address 7c:d3:0a:21:eb:f5 > > rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0 > > re0: cannot create re-stats kstat > > > > Is anyone seeing that, i.e. devices detaching > > when they are being probed by pcidump? > > > > After doing the pcidump -v localy and rebooting to upload, I get this. > > Note that the Realtek 8168 entry seems mangled (related to the above?). > > pcidump causing a device to detach is a problem, but the kstat bit is a > separate problem too. > > the diff below consolidates the detach code in re(4) and adds the code > to tear the kstat down when the device goes away. With the diff, this is what messages say during pcidump -v: rgephy0 detached re0 detached re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x10: RTL8168GU/8111GU (0x5080), msi, address 7c:d3:0a:21:eb:f5 rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0 So it seems re0 detaches and re-ataches. Understandably, it loses the IP address, re0: flags=8802 mtu 1500 lladdr 7c:d3:0a:21:eb:f5 index 5 priority 0 llprio 3 media: Ethernet autoselect (1000baseT full-duplex) status: active but an /etc/netstart works as on boot and renews the dhcp lease. re0: flags=808843 mtu 1500 lladdr 7c:d3:0a:21:eb:f5 index 5 priority 0 llprio 3 groups: egress media: Ethernet autoselect (1000baseT full-duplex) status: active inet 192.168.11.28 netmask 0xff00 broadcast 192.168.11.255 The diff in the actual pcidump output is indeed in the re section (see previous): @@ -303,10 +303,6 @@ Domain /dev/pci0: 0x00b0: Capability 0x11: Extended Message Signalled Interrupts (MSI-X) Enabled: no; table size 4 (BAR 4:0) 0x00d0: Capability 0x03: Vital Product Data (VPD) - 00 - 00 - 00 - 00 7f: [|vpd] Anyway, why does re detach at all. And does this reveal anything about the original question Realtek 8723BE support? Jan Domain /dev/pci0: 0:0:0: Intel Core 6G Host 0x: Vendor ID: 8086, Product ID: 1904 0x0004: Command: 0106, Status: 2090 0x0008: Class: 06 Bridge, Subclass: 00 Host, Interface: 00, Revision: 08 0x000c: BIST: 00, Header Type: 00, Latency Timer: 00, Cache Line Size: 00 0x0010: BAR empty () 0x0014: BAR empty () 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 103c Product ID: 8184 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 00 Line: 00 Min Gnt: 00 Max Lat: 00 0x00e0: Capability 0x09: Vendor Specific 0:2:0: Intel HD Graphics 520 0x: Vendor ID: 8086, Product ID: 1916 0x0004: Command: 0007, Status: 0010 0x0008: Class: 03 Display, Subclass: 00 VGA, Interface: 00, Revision: 07 0x000c: BIST: 00, Header Type: 00, Latency Timer: 00, Cache Line Size: 00 0x0010: BAR mem 64bit addr: 0xee00/0x0100 0x0018: BAR mem prefetchable 64bit addr: 0xd000/0x1000 0x0020: BAR io addr: 0xf000/0x0040 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 103c Product ID: 8184 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 01 Line: 0b Min Gnt: 00 Max Lat: 00 0x0040: Capability 0x09: Vendor Specific 0x0070: Capability 0x10: PCI Express Max Payload Size: 128 / 128 bytes Max Read Request Size: 128 bytes 0x0100: Enhanced Capability 0x1b: Process Address Space ID 0x0200: Enhanced Capability 0x0f: Address Translation Services 0x0300: Enhanced Capability
Re: Realtek 8723BE unsupported
On Mon, Dec 04, 2023 at 11:16:04AM +1000, David Gwynne wrote:
> On Sun, Dec 03, 2023 at 06:02:03PM +0100, Jan Stary wrote:
> > (please keep replies on the list)
> >
> > On Dec 03 12:08:08, kolip...@exoticsilicon.com wrote:
> > > On Sun, Dec 03, 2023 at 02:35:11PM +0100, Jan Stary wrote:
> > > > This is current/amd64 on a HP 260 G2 mini PC (dmesg below).
> > > > Everything works, except the wifi seems to be unsupported:
> > > >
> > > > "Realtek 8723BE" rev 0x00 at pci2 dev 0 function 0 not configured
> > >
> > > What does pcidump -v show?
> >
> > First of all, pcidump -v (but not pcidump) fucks up re(4):
> >
> > rgephy0 detached
> > re0 detached
> > re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x10: RTL8168GU/8111GU
> > (0x5080), msi, address 7c:d3:0a:21:eb:f5
> > rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0
> > re0: cannot create re-stats kstat
> > rgephy0 detached
> > re0 detached
> > re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x10: RTL8168GU/8111GU
> > (0x5080), msi, address 7c:d3:0a:21:eb:f5
> > rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0
> > re0: cannot create re-stats kstat
> >
> > Is anyone seeing that, i.e. devices detaching
> > when they are being probed by pcidump?
> >
> > After doing the pcidump -v localy and rebooting to upload, I get this.
> > Note that the Realtek 8168 entry seems mangled (related to the above?).
>
> pcidump causing a device to detach is a problem, but the kstat bit is a
> separate problem too.
>
> the diff below consolidates the detach code in re(4) and adds the code
> to tear the kstat down when the device goes away.
Makes sense. One question below.
OK claudio@
> Index: ic/re.c
> ===
> RCS file: /cvs/src/sys/dev/ic/re.c,v
> retrieving revision 1.216
> diff -u -p -r1.216 re.c
> --- ic/re.c 10 Nov 2023 15:51:20 - 1.216
> +++ ic/re.c 4 Dec 2023 01:03:30 -
> @@ -2608,6 +2630,27 @@ freedma:
> destroy:
> bus_dmamap_destroy(sc->sc_dmat, re_ks_sc->re_ks_sc_map);
> free:
> + free(re_ks_sc, M_DEVBUF, sizeof(*re_ks_sc));
> +}
> +
> +void
> +re_kstat_detach(struct rl_softc *sc)
> +{
> + struct kstat *ks = sc->rl_kstat;
> + struct re_kstat_softc *re_ks_sc;
> +
> + if (ks == NULL)
> + return;
> +
> + kstat_remove(ks);
> + re_ks_sc = ks->ks_ptr;
> + kstat_destroy(ks);
> +
> + bus_dmamap_unload(sc->sc_dmat, re_ks_sc->re_ks_sc_map);
> + bus_dmamem_unmap(sc->sc_dmat,
> + (caddr_t)re_ks_sc->re_ks_sc_stats, sizeof(struct re_stats));
> + bus_dmamem_free(sc->sc_dmat, _ks_sc->re_ks_sc_seg, 1);
Shouldn't this use re_ks_sc->re_ks_sc_nsegs?
Or actually why save re_ks_sc_nsegs when it is known to be 1?
It is just confusing to see a difference with re_kstat_attach() in this
regard.
> + bus_dmamap_destroy(sc->sc_dmat, re_ks_sc->re_ks_sc_map);
> free(re_ks_sc, M_DEVBUF, sizeof(*re_ks_sc));
> }
> #endif /* NKSTAT > 0 */
--
:wq Claudio
Re: Realtek 8723BE unsupported
On Sun, Dec 03, 2023 at 06:02:03PM +0100, Jan Stary wrote:
> (please keep replies on the list)
>
> On Dec 03 12:08:08, kolip...@exoticsilicon.com wrote:
> > On Sun, Dec 03, 2023 at 02:35:11PM +0100, Jan Stary wrote:
> > > This is current/amd64 on a HP 260 G2 mini PC (dmesg below).
> > > Everything works, except the wifi seems to be unsupported:
> > >
> > > "Realtek 8723BE" rev 0x00 at pci2 dev 0 function 0 not configured
> >
> > What does pcidump -v show?
>
> First of all, pcidump -v (but not pcidump) fucks up re(4):
>
> rgephy0 detached
> re0 detached
> re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x10: RTL8168GU/8111GU
> (0x5080), msi, address 7c:d3:0a:21:eb:f5
> rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0
> re0: cannot create re-stats kstat
> rgephy0 detached
> re0 detached
> re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x10: RTL8168GU/8111GU
> (0x5080), msi, address 7c:d3:0a:21:eb:f5
> rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0
> re0: cannot create re-stats kstat
>
> Is anyone seeing that, i.e. devices detaching
> when they are being probed by pcidump?
>
> After doing the pcidump -v localy and rebooting to upload, I get this.
> Note that the Realtek 8168 entry seems mangled (related to the above?).
pcidump causing a device to detach is a problem, but the kstat bit is a
separate problem too.
the diff below consolidates the detach code in re(4) and adds the code
to tear the kstat down when the device goes away.
Index: ic/re.c
===
RCS file: /cvs/src/sys/dev/ic/re.c,v
retrieving revision 1.216
diff -u -p -r1.216 re.c
--- ic/re.c 10 Nov 2023 15:51:20 - 1.216
+++ ic/re.c 4 Dec 2023 01:03:30 -
@@ -199,6 +199,7 @@ int re_wol(struct ifnet*, int);
#endif
#if NKSTAT > 0
void re_kstat_attach(struct rl_softc *);
+void re_kstat_detach(struct rl_softc *);
#endif
void in_delayed_cksum(struct mbuf *);
@@ -1128,6 +1129,27 @@ fail_0:
return (1);
}
+void
+re_detach(struct rl_softc *sc)
+{
+ struct ifnet*ifp = >sc_arpcom.ac_if;
+
+#if NKSTAT > 0
+ re_kstat_detach(sc);
+#endif
+
+ /* Remove timeout handler */
+ timeout_del(>timer_handle);
+
+ /* Detach PHY */
+ if (LIST_FIRST(>sc_mii.mii_phys) != NULL)
+ mii_detach(>sc_mii, MII_PHY_ANY, MII_OFFSET_ANY);
+
+ /* Delete media stuff */
+ ifmedia_delete_instance(>sc_mii.mii_media, IFM_INST_ANY);
+ ether_ifdetach(ifp);
+ if_detach(ifp);
+}
int
re_newbuf(struct rl_softc *sc)
@@ -2608,6 +2630,27 @@ freedma:
destroy:
bus_dmamap_destroy(sc->sc_dmat, re_ks_sc->re_ks_sc_map);
free:
+ free(re_ks_sc, M_DEVBUF, sizeof(*re_ks_sc));
+}
+
+void
+re_kstat_detach(struct rl_softc *sc)
+{
+ struct kstat *ks = sc->rl_kstat;
+ struct re_kstat_softc *re_ks_sc;
+
+ if (ks == NULL)
+ return;
+
+ kstat_remove(ks);
+ re_ks_sc = ks->ks_ptr;
+ kstat_destroy(ks);
+
+ bus_dmamap_unload(sc->sc_dmat, re_ks_sc->re_ks_sc_map);
+ bus_dmamem_unmap(sc->sc_dmat,
+ (caddr_t)re_ks_sc->re_ks_sc_stats, sizeof(struct re_stats));
+ bus_dmamem_free(sc->sc_dmat, _ks_sc->re_ks_sc_seg, 1);
+ bus_dmamap_destroy(sc->sc_dmat, re_ks_sc->re_ks_sc_map);
free(re_ks_sc, M_DEVBUF, sizeof(*re_ks_sc));
}
#endif /* NKSTAT > 0 */
Index: ic/revar.h
===
RCS file: /cvs/src/sys/dev/ic/revar.h,v
retrieving revision 1.7
diff -u -p -r1.7 revar.h
--- ic/revar.h 27 Jul 2010 20:53:39 - 1.7
+++ ic/revar.h 4 Dec 2023 01:03:30 -
@@ -18,6 +18,7 @@
intre_intr(void *);
intre_attach(struct rl_softc *, const char *);
+void re_detach(struct rl_softc *);
void re_reset(struct rl_softc *);
intre_init(struct ifnet *);
void re_stop(struct ifnet *);
Index: pci/if_re_pci.c
===
RCS file: /cvs/src/sys/dev/pci/if_re_pci.c,v
retrieving revision 1.56
diff -u -p -r1.56 if_re_pci.c
--- pci/if_re_pci.c 11 Mar 2022 18:00:48 - 1.56
+++ pci/if_re_pci.c 4 Dec 2023 01:03:30 -
@@ -223,19 +223,8 @@ re_pci_detach(struct device *self, int f
{
struct re_pci_softc *psc = (struct re_pci_softc *)self;
struct rl_softc *sc = >sc_rl;
- struct ifnet*ifp = >sc_arpcom.ac_if;
- /* Remove timeout handler */
- timeout_del(>timer_handle);
-
- /* Detach PHY */
- if (LIST_FIRST(>sc_mii.mii_phys) != NULL)
- mii_detach(>sc_mii, MII_PHY_ANY, MII_OFFSET_ANY);
-
- /* Delete media stuff */
- ifmedia_delete_instance(>sc_mii.mii_media, IFM_INST_ANY);
- ether_ifdetach(ifp);
- if_detach(ifp);
+ re_detach(sc);
/* Disable interrupts */
if (sc->sc_ih != NULL)
Index: cardbus/if_re_cardbus.c
===
RCS file:
Re: Realtek 8723BE unsupported
(please keep replies on the list) On Dec 03 12:08:08, kolip...@exoticsilicon.com wrote: > On Sun, Dec 03, 2023 at 02:35:11PM +0100, Jan Stary wrote: > > This is current/amd64 on a HP 260 G2 mini PC (dmesg below). > > Everything works, except the wifi seems to be unsupported: > > > > "Realtek 8723BE" rev 0x00 at pci2 dev 0 function 0 not configured > > What does pcidump -v show? First of all, pcidump -v (but not pcidump) fucks up re(4): rgephy0 detached re0 detached re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x10: RTL8168GU/8111GU (0x5080), msi, address 7c:d3:0a:21:eb:f5 rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0 re0: cannot create re-stats kstat rgephy0 detached re0 detached re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x10: RTL8168GU/8111GU (0x5080), msi, address 7c:d3:0a:21:eb:f5 rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0 re0: cannot create re-stats kstat Is anyone seeing that, i.e. devices detaching when they are being probed by pcidump? After doing the pcidump -v localy and rebooting to upload, I get this. Note that the Realtek 8168 entry seems mangled (related to the above?). bzm# pcidump -v Domain /dev/pci0: 0:0:0: Intel Core 6G Host 0x: Vendor ID: 8086, Product ID: 1904 0x0004: Command: 0106, Status: 2090 0x0008: Class: 06 Bridge, Subclass: 00 Host, Interface: 00, Revision: 08 0x000c: BIST: 00, Header Type: 00, Latency Timer: 00, Cache Line Size: 00 0x0010: BAR empty () 0x0014: BAR empty () 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 103c Product ID: 8184 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 00 Line: 00 Min Gnt: 00 Max Lat: 00 0x00e0: Capability 0x09: Vendor Specific 0:2:0: Intel HD Graphics 520 0x: Vendor ID: 8086, Product ID: 1916 0x0004: Command: 0007, Status: 0010 0x0008: Class: 03 Display, Subclass: 00 VGA, Interface: 00, Revision: 07 0x000c: BIST: 00, Header Type: 00, Latency Timer: 00, Cache Line Size: 00 0x0010: BAR mem 64bit addr: 0xee00/0x0100 0x0018: BAR mem prefetchable 64bit addr: 0xd000/0x1000 0x0020: BAR io addr: 0xf000/0x0040 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 103c Product ID: 8184 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 01 Line: 0b Min Gnt: 00 Max Lat: 00 0x0040: Capability 0x09: Vendor Specific 0x0070: Capability 0x10: PCI Express Max Payload Size: 128 / 128 bytes Max Read Request Size: 128 bytes 0x0100: Enhanced Capability 0x1b: Process Address Space ID 0x0200: Enhanced Capability 0x0f: Address Translation Services 0x0300: Enhanced Capability 0x13: Page Request Interface 0x00ac: Capability 0x05: Message Signalled Interrupts (MSI) Enabled: yes 0x00d0: Capability 0x01: Power Management State: D0 0:8:0: Intel Core GMM 0x: Vendor ID: 8086, Product ID: 1911 0x0004: Command: 0006, Status: 0010 0x0008: Class: 08 System, Subclass: 80 Miscellaneous, Interface: 00, Revision: 00 0x000c: BIST: 00, Header Type: 00, Latency Timer: 00, Cache Line Size: 00 0x0010: BAR mem 64bit addr: 0xef22e000/0x1000 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 103c Product ID: 8184 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 01 Line: 0b Min Gnt: 00 Max Lat: 00 0x0090: Capability 0x05: Message Signalled Interrupts (MSI) Enabled: no 0x00dc: Capability 0x01: Power Management State: D0 0x00f0: Capability 0x13: PCI Advanced Features 0:20:0: Intel 100 Series xHCI 0x: Vendor ID: 8086, Product ID: 9d2f 0x0004: Command: 0106, Status: 0290 0x0008: Class: 0c Serial Bus, Subclass: 03 USB, Interface: 30, Revision: 21 0x000c: BIST: 00, Header Type: 80, Latency Timer: 00, Cache Line Size: 00 0x0010: BAR mem 64bit addr: 0xef21/0x0001 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 103c Product ID: 8184 0x0030:
