Date: Thu, 12 Dec 2013 03:14:40 +1100 From: Edward O'Callaghan <eocallaghan@alterapraxis.com> To: freebsd-net@freebsd.org Subject: Re: Intel Controllers [Rant] Message-ID: <20131212031440.692889f7.eocallaghan@alterapraxis.com> In-Reply-To: <7BE40656-3BF7-4D16-9E8F-392E612093D1@FreeBSD.org> References: <1386634847.38473.YahooMailNeo@web121606.mail.ne1.yahoo.com> <1386697668.8944.57916449.7576FC53@webmail.messagingengine.com> <CAKAfi7x8SJD7bCLbr2YUKK6nCQgAvZYoGiuqDfBTvweDYGwOYQ@mail.gmail.com> <7BE40656-3BF7-4D16-9E8F-392E612093D1@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/5+okA/p+KM91IgnO+zNPrCT Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 10 Dec 2013 12:16:57 -0600 Mark Felder <feld@FreeBSD.org> wrote: >=20 > On Dec 10, 2013, at 12:13, Jim Thompson <jim@netgate.com> wrote: >=20 > > On Tue, Dec 10, 2013 at 11:47 AM, Mark Felder <feld@freebsd.org> > > wrote: > >> On Mon, Dec 9, 2013, at 18:20, Barney Cordoba wrote: > >>> Why is it that every time I get a new MB it has yet-another intel > >>> controller on it? How are you supposed to write good drivers that > >>> support 9000 different controllers? As much as I appreciate the > >>> progression of CPU technology, they > >>> would serve the community better by making up their damn minds > >>> and just build 1 or 2 controller for each > >>> target market. > >>>=20 > >>=20 > >> I'm pretty sure an entirely new driver doesn't need to be written > >> for each new controller. I assume like with most things (network > >> cards, wifi chips, etc) it's usually a matter of adding its > >> identifier to the driver code. > >=20 > > It goes beyond that. In the simplest case, then yes, things are > > as you say. > >=20 > > But chips have bugs, which require work-arounds, or other slightly > > strange stuff. > >=20 > > Case(s) in-point: > >=20 > > The 82575 assigns queues using vectors via a bitmask > > The Intel 82576 chip uses a table that essentially consists of 2 > > columns with 8 rows. The ordering is column-major (like Fortran > > arrays). > > On 82580 and newer adapters the scheme is similar to 82576, however > > instead of ordering column-major, the ordering is row-major (like C > > or Pascal). > >=20 > > These chips are all supported via the igb driver. > >=20 > > Some parts supported by the igb driver use MSI-X interrupts, others > > don't. > >=20 > > On i350, i354, i210, and i211, loopback VLAN packets have the tag > > byte-swapped. > >=20 > > The list of issues is by no means limited to the above. > >=20 > > Jim >=20 > That sounds tedious. Thanks to those of you that tirelessly hack away > at these quirks. >=20 > When I first replied to this post I thought I was reading another > list and the discussion was about disk controllers which don't seem > to be so troublesome >=20 >=20 Another thing that can happen, given some hw rev. is that you in one rev. if you write values into registers in the wrong order you can actually get the hardware into undocumented states. This ends badly, typically locking up the hardware requiring soft-resets, although on occasion that may not even be sufficient ! Other times you may need to wait some time after banging on a register, typically overly long periods with Intel gear. In some cases you can actually irreparable damage the hw just because you did not wait and/or order some register twiddling correctly O_o Basically x86 sucks. Both Sun, IBM & Sgi designed things correctly with things like PROM's. The Intel UEFI firmware attempts to replicate these late 80's, early 90's ideas and fails horribly. The only hope aside from IBM POWER has been left with ARM, however that is quickly becoming a fragmented mess.. Cheers, --=20 ______________________________________________________________________ Edward O'Callaghan, Director and Principal consultant. https://www.alterapraxis.com | eocallaghan@alterapraxis.com Altera Praxis Pty Ltd, // Discretions in cybersecurity ACN 165 424 064. // reconnaissance and adversary mitigation. ______________________________________________________________________ --Sig_/5+okA/p+KM91IgnO+zNPrCT Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCgAGBQJSqI91AAoJENeyf/ug44dtlB4QALvVa+vD2qu+zdPZRvF/2C3E ct91P/N4MFseK8oBaCRGkelMj1gNgVIe8CHVZNSg8arknDAD+1hTmi09WiWM/147 j2mlX7JPoNS9+YPkxmROORNefNPlyiTs2YYVZmQ/kXyYVGOkbQhQM2wfD/xYVSn5 666mNhGxT5pLHYKNkQPaARC7hZDzBfcJbb6IikvD2kmMa8uYPuIocAf0L7btTXgB pwNYJmNJWPPF35tDQN73c07D85JDComJeX25EC2DTtL62yVRHCFVSkz5nkVUcNsh V/F3Ywnt0f6EStdTqQet4KWnSvsgx0RYxghsGgJ9MuPeEPu/Qq41MH7s0/HjWgxN YT8NAi1N0fuO7IGAszkHRD9Zz2IEwPHbNNYoXkcaVsUfFqpUu9Kw7gE9iI0LO1wC JSaNBTWDVieN0csU6VB1ILeQZetaQURxlwHbx0u0Y3SbRWsWLzM0e3XMeTmVrQ6y wGI+Vyp9irg4GRqfAE9fWfYSmyfVlFm6daKOsUsE3/WGy0lkvmsB6i7I07NIJw5z gxGB+HWih8CWSo4O7fzDPkSBhG9tTqrNvSQz/cO//hGNCcDAZlhFb5kKZeWz/Q+W ap+yn6eZ0ZDQBCvhnR1filVwRhLapQN20Z672Kyz0XJkSDjpkS0VhkCpxDAT7BEZ tnPOI7oGx0LtI+S6ujdY =tnGM -----END PGP SIGNATURE----- --Sig_/5+okA/p+KM91IgnO+zNPrCT--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131212031440.692889f7.eocallaghan>