Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 1 Dec 2022 20:19:12 -0700
From:      Warner Losh <imp@bsdimp.com>
To:        Mark Millard <marklmi@yahoo.com>
Cc:        ehem+freebsd@m5p.com, freebsd-arch <freebsd-arch@freebsd.org>
Subject:   Re: Giant Locked drivers
Message-ID:  <CANCZdfrSpNU05z2NFo6JoRoJvMxrhG5iDwWt=4sSc8fDJ8m0Yg@mail.gmail.com>
In-Reply-To: <9C63C7CB-0416-4F7F-80DB-28C5002A5F36@yahoo.com>
References:  <9C63C7CB-0416-4F7F-80DB-28C5002A5F36.ref@yahoo.com> <9C63C7CB-0416-4F7F-80DB-28C5002A5F36@yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000fc319c05eecfcddd
Content-Type: text/plain; charset="UTF-8"

On Thu, Dec 1, 2022, 8:13 PM Mark Millard <marklmi@yahoo.com> wrote:

> Elliott Mitchell <ehem+freebsd_at_m5p.com> wrote on
> Date: Fri, 02 Dec 2022 00:33:00 UTC :
>
> > On Tue, Nov 15, 2022 at 10:37:36AM -0700, Warner Losh wrote:
> > > When set to 0, you get today's behavior. If set to 1, it will no longer
> > > allow drivers that don't request MPSAFE interrupt handlers from
> registering
> > > (the interrupt setup will return an error).
> > >
> > > This will allow us to understand what is lost if we throw the switch,
> and
> > > allow users to proactively test their systems to see if they are
> > > affected or not (and if they are, if they want to live without the
> > > functionality, or want to fund work in the area).
> > >
> > > Comments?
> >
> > . . .
> >
> >
> > In other news in two handy VMs. On x86: (a full VM with hardware
> emulation)
> >
> > atkbd0: [GIANT-LOCKED]
> > psm0: [GIANT-LOCKED]
> > WARNING: Device "psm" is Giant locked and may be deleted before FreeBSD
> 14.0.
> >
> > On ARM64: (basically pure VM with no emulated hardware)
> >
> > <nothing>
> >
> > So right now everyone is reporting x86 console devices and nothing else.
>
> In
> https://lists.freebsd.org/archives/freebsd-arch/2022-November/000290.html
> I reported that RPi*'s list:
>
> WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD
> 14.0.
>
> The other two types of small board computers that I have
> access to do not have software support for the video.
>
> I've no evidence beyond those tests to know if the issue is
> specific to the RPi*'s vs. more general.
>
> > This suggests the x86 console is urgent for giant removal. Then perhaps
> > it will be viable to default to disabled (or perhaps something else will
> > float to the top).
>


I have the start of patches for newbus.

But the console complex is trick since it's one of the few places multiple
drivers are all locked by Giant and some care is needed.

Warner

--000000000000fc319c05eecfcddd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" =
class=3D"gmail_attr">On Thu, Dec 1, 2022, 8:13 PM Mark Millard &lt;<a href=
=3D"mailto:marklmi@yahoo.com">marklmi@yahoo.com</a>&gt; wrote:<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">Elliott Mitchell &lt;ehem+<a href=3D"http://fre=
ebsd_at_m5p.com" rel=3D"noreferrer noreferrer" target=3D"_blank">freebsd_at=
_m5p.com</a>&gt; wrote on<br>
Date: Fri, 02 Dec 2022 00:33:00 UTC :<br>
<br>
&gt; On Tue, Nov 15, 2022 at 10:37:36AM -0700, Warner Losh wrote:<br>
&gt; &gt; When set to 0, you get today&#39;s behavior. If set to 1, it will=
 no longer<br>
&gt; &gt; allow drivers that don&#39;t request MPSAFE interrupt handlers fr=
om registering<br>
&gt; &gt; (the interrupt setup will return an error).<br>
&gt; &gt; <br>
&gt; &gt; This will allow us to understand what is lost if we throw the swi=
tch, and<br>
&gt; &gt; allow users to proactively test their systems to see if they are<=
br>
&gt; &gt; affected or not (and if they are, if they want to live without th=
e<br>
&gt; &gt; functionality, or want to fund work in the area).<br>
&gt; &gt; <br>
&gt; &gt; Comments?<br>
&gt; <br>
&gt; . . .<br>
&gt; <br>
&gt; <br>
&gt; In other news in two handy VMs. On x86: (a full VM with hardware emula=
tion)<br>
&gt; <br>
&gt; atkbd0: [GIANT-LOCKED]<br>
&gt; psm0: [GIANT-LOCKED]<br>
&gt; WARNING: Device &quot;psm&quot; is Giant locked and may be deleted bef=
ore FreeBSD 14.0.<br>
&gt; <br>
&gt; On ARM64: (basically pure VM with no emulated hardware)<br>
&gt; <br>
&gt; &lt;nothing&gt;<br>
&gt; <br>
&gt; So right now everyone is reporting x86 console devices and nothing els=
e.<br>
<br>
In <a href=3D"https://lists.freebsd.org/archives/freebsd-arch/2022-November=
/000290.html" rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists=
.freebsd.org/archives/freebsd-arch/2022-November/000290.html</a><br>
I reported that RPi*&#39;s list:<br>
<br>
WARNING: Device &quot;fb&quot; is Giant locked and may be deleted before Fr=
eeBSD 14.0.<br>
<br>
The other two types of small board computers that I have<br>
access to do not have software support for the video.<br>
<br>
I&#39;ve no evidence beyond those tests to know if the issue is<br>
specific to the RPi*&#39;s vs. more general.<br>
<br>
&gt; This suggests the x86 console is urgent for giant removal. Then perhap=
s<br>
&gt; it will be viable to default to disabled (or perhaps something else wi=
ll<br>
&gt; float to the top).<br></blockquote></div></div><div dir=3D"auto"><br><=
/div><div dir=3D"auto"><br></div><div dir=3D"auto">I have the start of patc=
hes for newbus.</div><div dir=3D"auto"><br></div><div dir=3D"auto">But the =
console complex is trick since it&#39;s one of the few places multiple driv=
ers are all locked by Giant and some care is needed.=C2=A0</div><div dir=3D=
"auto"><br></div><div dir=3D"auto">Warner=C2=A0</div></div>

--000000000000fc319c05eecfcddd--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrSpNU05z2NFo6JoRoJvMxrhG5iDwWt=4sSc8fDJ8m0Yg>