Date: Fri, 24 May 2019 16:01:35 -0700 (PDT) From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> To: Justin Hibbits <chmeeedalf@gmail.com> Cc: Alexey Dokuchaev <danfe@freebsd.org>, Piotr Kubaj <pkubaj@freebsd.org>, svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r348250 - head/sys/powerpc/conf Message-ID: <201905242301.x4ON1Zju098365@gndrsh.dnsmgr.net> In-Reply-To: <20190524152941.40f7e239@titan.knownspace>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Fri, 24 May 2019 20:22:52 +0000 > Alexey Dokuchaev <danfe@freebsd.org> wrote: > > > On Fri, May 24, 2019 at 03:16:51PM -0500, Justin Hibbits wrote: > > > On Fri, 24 May 2019 20:01:59 +0000 (UTC) Piotr Kubaj wrote: > > > > New Revision: 348250 > > > > URL: https://svnweb.freebsd.org/changeset/base/348250 > > > > > > > > Log: > > > > Add snd_hda(4) to GENERIC64 used by powerpc64. > > > > > > > > amd64 also has snd_hda(4) in GENERIC. > > > > > > > > Modified: > > > > head/sys/powerpc/conf/GENERIC64 > > > > ... > > > > > > To note: This was done because there's a strange bug in the snd_hda > > > module, with the hdaa component. For some reason it either doesn't > > > find all the internal components it needs, or something, because > > > there's a NULL dereference when trying to call a kobj method in > > > hdaa_attach(). > > > > So this commit essentially masks the real bug somewhere rather than > > fixing it, is this what you're saying? > > > > ./danfe > > It's a viable workaround to a problem that reaches a wide audience. > Since it works built-in, I found it acceptable. I probably should have > filed a bug for it a year ago when I hit it and worked around it, but it > could also very well be a compiler issue. > > By the way, it works fine on powerpc (32-bit) loaded as a module. Please do file a bug report now, please do mark the line in GENERIC64 with a comment XXX This is needed to work around foo so that it is documented why it is there and someone removing it does not go down a rabit hole others have already been down, and so that some day someone may go down that rabbit hole of there own free will and fix this for us. Paving over the top of obscure bugs with a hackish fix is ok, not documenting this state of affairs is not, IMHO. > - Justin -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201905242301.x4ON1Zju098365>