Re: DragonFly 2.0 (almost) works on D945GCLF/Intel Atom

["Edward O'Callaghan" <victoredwardocallaghan@xxxxxxxxx>]

That's a total hack ! :/

This isn't your run of the mill Realtek rtls NIC that is rtl-8100/8139
compatible. Starting with the 8101E line, the chips started to use a
PCI-express lane off the south bridge and they had MAC interfaces and
registers that looked a lot more like the RGE or RTL-8169 (gigabit)
series of NICs, only with a fast 10/100 PHY. And while the hardware
PCI registers (either lspci or prtconf or /usr/X11/bin/scanpci) all
indicate that this version of NIC was RTL8101E, the smbios Intel
provides with this board shows that the NIC is actually an 8102EL - a
slightly modified version of the 8101E. For all intents and purposes,
the chips are the same, except for Hardware Checksum support. The old
initialization support for hwcksum isn't the same register, and was
either removed (because it's a slow NIC) or changed.
It would be better the contact the HW manufacture and find out the
correct register. I had this same problem in OpenSolaris but its fixed
in snv_99 I believe. So you could check our code.
http://bugs.opensolaris.org/view_bug.do?bug_id=6717107
http://src.opensolaris.org/source/

Thanks,
Edward O'Callaghan.

2008/9/30 Mitja Horvat <pinkfluid@gmail.com>:
> Hello all,
>
> I recently purchased an Intel D945GCLF Mini-ITX motherboard with Intel
> Atom. I got DragonFly up and running on it out of the box except for
> the network, card which required a minor patch.
>
> It even runs X with KDE 4.1.1 with DRI support and sound. pciconf -v
> currently shows only 1 undetected device, and that it seems is a SMBus
> device (which I guess I can enable with "device smbus"):
>
> none2@pci0:31:3:        class=0x0c0500 card=0x464c8086 chip=0x27da8086
> rev=0x01 hdr=0x00
>    vendor   = 'Intel Corporation'
>    device   = '82801G (ICH7 Family) SMBus Controller'
>    class    = serial bus
>    subclass = SMBus
>
> Apart from that, the network card is a Realtek 8102EL, which is not
> detected with a vanilla kernel. I modified the "re" driver source code
> to include the hardware revision of the 8102EL and disable the
> hardware checksum features of the card (they don't work probably
> because it has changed), see patch below.
>
> There's only few minor issues with the network card still present;
> when the kernel boots I occasionally get the following error message
> and the kernel crashes just before it should start booting into
> userspace:
>
> Sep 26 06:34:26  kernel: re0: MII without any phy!
>
> Setting the "debug.acpi.disabled" variable to "bus timer" seems to
> completely cure the problem, however I'm still wondering if it is
> something wrong with the patch or if it is an isolated ACPI issue.
>
> So my question is, is the patch correct or I just encountered an ACPI issue?
>
> PS: For anyone replying to this e-mail, please add me to CC since I'm
> not suscribed to the mailing list.
>
> Regards,
> Mitja Horvat
>
> diff -bru src/sys/dev/netif/re/if_re.c src.hack/sys/dev/netif/re/if_
> re.c
> --- src/sys/dev/netif/re/if_re.c        2008-06-25 11:02:33 +0000
> +++ src.hack/sys/dev/netif/re/if_re.c   2008-09-28 02:19:24 +0000
> @@ -166,6 +166,8 @@
>                "RealTek 8139C+ 10/100BaseTX" },
>        { PCI_VENDOR_REALTEK, PCI_PRODUCT_REALTEK_RT8101E, RE_HWREV_8101E,
>                "RealTek 8101E PCIe 10/100baseTX" },
> +       { PCI_VENDOR_REALTEK, PCI_PRODUCT_REALTEK_RT8101E, RE_HWREV_8102EL,
> +               "RealTek 8102EL PCIe 10/100baseTX" },
>        { PCI_VENDOR_REALTEK, PCI_PRODUCT_REALTEK_RT8168, RE_HWREV_8168_SPIN1,
>                "RealTek 8168/8111B PCIe Gigabit Ethernet" },
>        { PCI_VENDOR_REALTEK, PCI_PRODUCT_REALTEK_RT8168, RE_HWREV_8168_SPIN2,
> @@ -208,6 +210,7 @@
>        { RE_HWREV_8169_8110SC, RE_8169,        0,              "8169SC" },
>        { RE_HWREV_8100E,       RE_8169,        RE_F_HASMPC,    "8100E" },
>        { RE_HWREV_8101E,       RE_8169,        RE_F_PCIE,      "8101E" },
> +       { RE_HWREV_8102EL,      RE_8169,        RE_F_PCIE,      "8102EL" },
>        { 0, 0, 0, NULL }
>  };
>
> @@ -1228,8 +1231,22 @@
>        ifp->if_ioctl = re_ioctl;
>        ifp->if_start = re_start;
>        ifp->if_capabilities = IFCAP_VLAN_MTU | IFCAP_VLAN_HWTAGGING;
> -       if (hwrev != RE_HWREV_8168C)    /* XXX does not work yet */
> +
> +       switch (hwrev)
> +       {
> +               case RE_HWREV_8168C:
> +               case RE_HWREV_8102EL:
> +                       /*
> +                        * XXX Hardware checksum does not work yet on 8168C
> +                        * and 8102EL. Disble it.
> +                        */
> +                       ifp->if_capabilities &= ~IFCAP_HWCSUM;
> +                       break;
> +               default:
>                ifp->if_capabilities |= IFCAP_HWCSUM;
> +                       break;
> +       }
> +
>  #ifdef DEVICE_POLLING
>        ifp->if_poll = re_poll;
>  #endif
> diff -bru src/sys/dev/netif/re/if_rereg.h src.hack/sys/dev/netif/re/if_rereg.h
> --- src/sys/dev/netif/re/if_rereg.h     2008-04-27 15:10:37 +0000
> +++ src.hack/sys/dev/netif/re/if_rereg.h        2008-09-28 02:18:12 +0000
> @@ -147,6 +147,7 @@
>  #define RE_HWREV_8168_SPIN1    0x30000000
>  #define RE_HWREV_8100E         0x30800000
>  #define RE_HWREV_8101E         0x34000000
> +#define RE_HWREV_8102EL        0x24800000
>  #define RE_HWREV_8168_SPIN2    0x38000000
>  #define RE_HWREV_8168_SPIN3    0x38400000
>  #define RE_HWREV_8168C         0x3c000000
>



-- 
All Documents adhered to the ISO/IEC 26300  standard file format for
electronic office documents, such as spreadsheets, charts,
presentations and word processing documents from this email address.
The author does not take responsibility of the recipients inability to
read international standards and who use proprietary products such as
MS Office.
See: http://www.openoffice.org/
Edward O'Callaghan.
--
http://fedoraproject.org/wiki/EdwardOcallaghan
http://moonshine.opn4.org/
http://www.pcbsd.org/