Re: svn commit: r365419 - in head/sys/dev: ath bwi iwm iwn mwl otus usb/wlan wtap
On Fri, 11 Sep 2020 14:20:22 + "Bjoern A. Zeeb" wrote: > On 11 Sep 2020, at 14:02, Tomoaki AOKI wrote: > > > On Thu, 10 Sep 2020 10:22:05 + > > "Bjoern A. Zeeb" wrote: > > > >> On 9 Sep 2020, at 22:41, Tomoaki AOKI wrote: > >> > >>> This breaks at least iwm. (Other drivers not tested.) > >>> > >>> Messages below are repeatedly shown and no carrier detected. > >>> Manually reverting this commit fixes the issue. > >>> > >>> iwm0: failed to send antennas before calibration: 35 > >>> iwm_run_init_ucode: failed 35 > >>> iwm_init_hw failed 35 > >>> iwm0: could not initiate scan > >>> > >>> > >>> and lesser times messages below. > >>> > >>> iwm0: iwm_send_phy_db_data: Cannot send HCMD of Phy DB cfg section, > >>> 35 > >>> iwm_init_hw failed 35 > >>> iwm0: could not initiate scan > >>> > >> > >> > >> I’ll try to test iwm as well, in case you are faster, can you > >> please > >> try this instead of reverting; the previous version never made it > >> past > >> the first return anymore in the last years it seems, so we can remove > >> the function entirely to keep the status quo: > >> > >> Sorry for the oversight. > > > > Your patch (needed to fix some line wrapping, though) fixed the issue > > for me. Thanks! > > Committed in r365633 in HEAD. stable/12 already has the fix (#if 0ed > the code). > I’ll merged the change in 3 days to keep the code in sync. > > > Thanks a lot for reporting and testing! > > Bjoern Confirmed. Thanks! > ___ > freebsd-curr...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > -- Tomoaki AOKI ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r365419 - in head/sys/dev: ath bwi iwm iwn mwl otus usb/wlan wtap
On Thu, 10 Sep 2020 10:22:05 +
"Bjoern A. Zeeb" wrote:
> On 9 Sep 2020, at 22:41, Tomoaki AOKI wrote:
>
> > This breaks at least iwm. (Other drivers not tested.)
> >
> > Messages below are repeatedly shown and no carrier detected.
> > Manually reverting this commit fixes the issue.
> >
> > iwm0: failed to send antennas before calibration: 35
> > iwm_run_init_ucode: failed 35
> > iwm_init_hw failed 35
> > iwm0: could not initiate scan
> >
> >
> > and lesser times messages below.
> >
> > iwm0: iwm_send_phy_db_data: Cannot send HCMD of Phy DB cfg section, 35
> > iwm_init_hw failed 35
> > iwm0: could not initiate scan
> >
>
>
> I’ll try to test iwm as well, in case you are faster, can you please
> try this instead of reverting; the previous version never made it past
> the first return anymore in the last years it seems, so we can remove
> the function entirely to keep the status quo:
>
> Sorry for the oversight.
Your patch (needed to fix some line wrapping, though) fixed the issue
for me. Thanks!
BTW, I also needed to revert r365549 [1] not to fail build, regardless
your patch is applied or not.
Just now, I noticed a fix is proposed [2] via phablicator by Alan
Somers, but I've not tested it yet.
[1]
https://lists.freebsd.org/pipermail/svn-src-head/2020-September/139761.html
[2]
https://lists.freebsd.org/pipermail/freebsd-current/2020-September/077095.html
Regards.
>
>
> Index: if_iwm.c
> ===
> --- if_iwm.c(revision 365559)
> +++ if_iwm.c(working copy)
> @@ -354,7 +354,6 @@ static struct ieee80211_node *
> static uint8_t iwm_rate_from_ucode_rate(uint32_t);
> static int iwm_rate2ridx(struct iwm_softc *, uint8_t);
> static voidiwm_setrates(struct iwm_softc *, struct iwm_node *,
> int);
> -static int iwm_media_change(struct ifnet *);
> static int iwm_newstate(struct ieee80211vap *, enum
> ieee80211_state, int);
> static voidiwm_endscan_cb(void *, int);
> static int iwm_send_bt_init_conf(struct iwm_softc *);
> @@ -4417,27 +4416,6 @@ iwm_setrates(struct iwm_softc *sc, struct
> iwm_node
> }
> }
>
> -static int
> -iwm_media_change(struct ifnet *ifp)
> -{
> - struct ieee80211vap *vap = ifp->if_softc;
> - struct ieee80211com *ic = vap->iv_ic;
> - struct iwm_softc *sc = ic->ic_softc;
> - int error;
> -
> - error = ieee80211_media_change(ifp);
> - if (error != 0)
> - return (error);
> -
> - IWM_LOCK(sc);
> - if (ic->ic_nrunning > 0) {
> - iwm_stop(sc);
> - iwm_init(sc);
> - }
> - IWM_UNLOCK(sc);
> - return (0);
> -}
> -
> static void
> iwm_bring_down_firmware(struct iwm_softc *sc, struct ieee80211vap
> *vap)
> {
> @@ -6432,8 +6410,8 @@ iwm_vap_create(struct ieee80211com *ic, const char
>
> ieee80211_ratectl_init(vap);
> /* Complete setup. */
> - ieee80211_vap_attach(vap, iwm_media_change,
> ieee80211_media_status,
> - mac);
> + ieee80211_vap_attach(vap, ieee80211_media_change,
> + ieee80211_media_status, mac);
> ic->ic_opmode = opmode;
>
> return vap;
>
>
>
>
> >
> >> Author: bz
> >> Date: Mon Sep 7 15:35:40 2020
> >> New Revision: 365419
> >> URL: https://svnweb.freebsd.org/changeset/base/365419
> >>
> >> Log:
> >> WiFi: fix ieee80211_media_change() callers
> >>
> >> In r178354 with the introduction of multi-bss ("vap") support
> > factoring
> >> out started and with r193340 ieee80211_media_change() no longer
> >> returned
> >> ENETRESET but only 0 or error.
> >> As ieee80211(9) tells the ieee80211_media_change() function should
> >> not
> >> be called directly but is registered with ieee80211_vap_attach()
> > instead.
> >> Some drivers have not been fully converted. After fixing the
> >> return
> >> checking some of these functions were simply wrappers between
> >> ieee80211_vap_attach() and ieee80211_media_change(), so remove the
> > extra
> >> function, where possible as well.
> >>
> >> PR: 248955
> >> Submitted by:Tong Zhang (ztong0001 gmail.com) (original)
> >> MFC after: 3 days
> >> Sponsored by:The FreeBSD Foundation
> >>
> >> Modified:
> >> head/sys/dev/ath/if_ath.c
> >> head/sys/dev/bwi/
Re: svn commit: r365419 - in head/sys/dev: ath bwi iwm iwn mwl otus usb/wlan wtap
This breaks at least iwm. (Other drivers not tested.)
Messages below are repeatedly shown and no carrier detected.
Manually reverting this commit fixes the issue.
iwm0: failed to send antennas before calibration: 35
iwm_run_init_ucode: failed 35
iwm_init_hw failed 35
iwm0: could not initiate scan
and lesser times messages below.
iwm0: iwm_send_phy_db_data: Cannot send HCMD of Phy DB cfg section, 35
iwm_init_hw failed 35
iwm0: could not initiate scan
> Author: bz
> Date: Mon Sep 7 15:35:40 2020
> New Revision: 365419
> URL: https://svnweb.freebsd.org/changeset/base/365419
>
> Log:
> WiFi: fix ieee80211_media_change() callers
>
> In r178354 with the introduction of multi-bss ("vap") support
factoring
> out started and with r193340 ieee80211_media_change() no longer returned
> ENETRESET but only 0 or error.
> As ieee80211(9) tells the ieee80211_media_change() function should not
> be called directly but is registered with ieee80211_vap_attach()
instead.
> Some drivers have not been fully converted. After fixing the return
> checking some of these functions were simply wrappers between
> ieee80211_vap_attach() and ieee80211_media_change(), so remove the
extra
> function, where possible as well.
>
> PR: 248955
> Submitted by: Tong Zhang (ztong0001 gmail.com) (original)
> MFC after: 3 days
> Sponsored by: The FreeBSD Foundation
>
> Modified:
> head/sys/dev/ath/if_ath.c
> head/sys/dev/bwi/if_bwi.c
> head/sys/dev/iwm/if_iwm.c
> head/sys/dev/iwn/if_iwn.c
> head/sys/dev/mwl/if_mwl.c
> head/sys/dev/otus/if_otus.c
> head/sys/dev/usb/wlan/if_run.c
> head/sys/dev/wtap/if_wtap.c
>
> Modified: head/sys/dev/ath/if_ath.c
> ==
> --- head/sys/dev/ath/if_ath.c Mon Sep 7 14:40:33 2020(r365418)
> +++ head/sys/dev/ath/if_ath.c Mon Sep 7 15:35:40 2020(r365419)
> @@ -160,7 +160,6 @@ static intath_init(struct ath_softc *);
> static void ath_stop(struct ath_softc *);
> static int ath_reset_vap(struct ieee80211vap *, u_long);
> static int ath_transmit(struct ieee80211com *, struct mbuf *);
> -static int ath_media_change(struct ifnet *);
> static void ath_watchdog(void *);
> static void ath_parent(struct ieee80211com *);
> static void ath_fatal_proc(void *, int);
(snip)
> Modified: head/sys/dev/iwm/if_iwm.c
> ==
> --- head/sys/dev/iwm/if_iwm.c Mon Sep 7 14:40:33 2020(r365418)
> +++ head/sys/dev/iwm/if_iwm.c Mon Sep 7 15:35:40 2020(r365419)
> @@ -4426,8 +4426,8 @@ iwm_media_change(struct ifnet *ifp)
> int error;
>
> error = ieee80211_media_change(ifp);
> - if (error != ENETRESET)
> - return error;
> + if (error != 0)
> + return (error);
>
> IWM_LOCK(sc);
> if (ic->ic_nrunning > 0) {
> @@ -4435,7 +4435,7 @@ iwm_media_change(struct ifnet *ifp)
> iwm_init(sc);
> }
> IWM_UNLOCK(sc);
> - return error;
> + return (0);
> }
>
> static void
(snip)
--
Tomoaki AOKI
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r358989 - in head/stand/efi: libefi loader loader/arch/arm loader/arch/arm64
On Thu, 19 Mar 2020 14:55:19 +0200 Toomas Soome wrote: > > > > On 19. Mar 2020, at 14:33, Tomoaki AOKI wrote: > > > > On Thu, 19 Mar 2020 00:28:59 +0200 > > Toomas Soome mailto:tso...@me.com>> wrote: > > > >> > >> > >>> On 18. Mar 2020, at 20:41, Ruslan Garipov wrote: > >>> > >>> On 3/18/2020 10:29 PM, Toomas Soome via svn-src-head wrote: > >>>> > >>>> > >>>>> On 18. Mar 2020, at 18:40, Ruslan Garipov wrote: > >>>>> > >>>>> On 3/17/2020 5:16 PM, Tomoaki AOKI wrote: > >>>>>> Hi! Thanks for your respond. > >>>>>> > >>>>>> Unfortunately, no. > >>>>>> I'm running on ThinkPad P52, which has no com connector installed. > >>>>>> No USB serial interface connected. > >>>>>> > >>>>>> `efi-show -g global -v ConOut` on loader prompt shows > >>>>>> > >>>>>> global NV,BS,RS ConOut = > >>>>>> PciRoot(0,0)/Pci((0x1,oxo)/Pci(0x0,0x0)/AcpiAdr(0x80010100) > >>>>>> > >>>>>> Moreover, my previous idea didn't help. > >>>>>> > >>>>>> Neither > >>>>>> console="vidconsole" > >>>>>> console="eficonsole" > >>>>>> console="efi_console" > >>>>>> nor > >>>>>> console="efi" > >>>>>> in /boot/loader.conf works. > >>>>>> > >>>>>> Defining / undefining TERM_EMU on build are untested. > >>>>>> > >>>>>> Is there any setting for /boot/loader.conf to control the behavior? > >>>>>> > >>>>>> > >>>>>> Regards. > >>>>>> > >>>>>> > >>>>>> On Mon, 16 Mar 2020 08:26:56 +0200 > >>>>>> Toomas Soome wrote: > >>>>>> > >>>>>>> Hi! > >>>>>>> > >>>>>>> This means, your system has UART serial device 〓 you can check this > >>>>>>> from loader prompt: efi-show -g global -v ConOut or with efivar from > >>>>>>> running system. This would trigger efi console driver to use > >>>>>>> TERM_EMU, which can be turned off by user and doing that would cause > >>>>>>> ESC sequences to be passed directly to console. Might that be true in > >>>>>>> your case? > >>>>>>> > >>>>>>> rgds, > >>>>>>> toomas > >>>>>>> > >>>>>>>> On 15. Mar 2020, at 17:17, Tomoaki AOKI > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>> Hi. > >>>>>>>> > >>>>>>>> This broke loader menu display on efifb. At least on amd64. > >>>>>>>> ESC sequences without ESC character are shown. > >>>>>>>> Key input (at least 1, 2 and enter) works OK. > >>>>>>>> I suspect outputs for SIO is sent to efifb and ESC codes are ignored. > >>>>>>>> > >>>>>>>> Reverting this fixes the issue. > >>>>> I got the same issue with loader menu when was upgrading from r358827 to > >>>>> r359028 (x86-64). > >>>>> > >>>>> But unfortunately the broken menu is just a part of my problem. The > >>>>> real pain is that a FreeBSD 13.0-CURRENT system hosted by VMware ESXi or > >>>>> Workstation doesn't boot anymore after r358989. An ugly workaround[1] > >>>>> (exiting from the loader menu into the loader prompt, running ls or > >>>>> show, scrolling the result down and then executing boot) I found some > >>>>> time ago doesn't work anymore. After running boot/boot -s/selecting > >>>>> menu item, a hypervisor just shuts session down with the following > >>>>> message: ``The firmware encountered an unexpected exception. The virtual > >>>>> machine cannot boot.'' > >>>>> > >>>>> The virtual guests don't have any UART (even USB) serial devices in > >>>>> their settings. efi-show print
Re: svn commit: r358989 - in head/stand/efi: libefi loader loader/arch/arm loader/arch/arm64
On Thu, 19 Mar 2020 00:28:59 +0200 Toomas Soome wrote: > > > > On 18. Mar 2020, at 20:41, Ruslan Garipov wrote: > > > > On 3/18/2020 10:29 PM, Toomas Soome via svn-src-head wrote: > >> > >> > >>> On 18. Mar 2020, at 18:40, Ruslan Garipov wrote: > >>> > >>> On 3/17/2020 5:16 PM, Tomoaki AOKI wrote: > >>>> Hi! Thanks for your respond. > >>>> > >>>> Unfortunately, no. > >>>> I'm running on ThinkPad P52, which has no com connector installed. > >>>> No USB serial interface connected. > >>>> > >>>> `efi-show -g global -v ConOut` on loader prompt shows > >>>> > >>>> global NV,BS,RS ConOut = > >>>> PciRoot(0,0)/Pci((0x1,oxo)/Pci(0x0,0x0)/AcpiAdr(0x80010100) > >>>> > >>>> Moreover, my previous idea didn't help. > >>>> > >>>> Neither > >>>> console="vidconsole" > >>>> console="eficonsole" > >>>> console="efi_console" > >>>> nor > >>>> console="efi" > >>>> in /boot/loader.conf works. > >>>> > >>>> Defining / undefining TERM_EMU on build are untested. > >>>> > >>>> Is there any setting for /boot/loader.conf to control the behavior? > >>>> > >>>> > >>>> Regards. > >>>> > >>>> > >>>> On Mon, 16 Mar 2020 08:26:56 +0200 > >>>> Toomas Soome wrote: > >>>> > >>>>> Hi! > >>>>> > >>>>> This means, your system has UART serial device 〓 you can check this > >>>>> from loader prompt: efi-show -g global -v ConOut or with efivar from > >>>>> running system. This would trigger efi console driver to use TERM_EMU, > >>>>> which can be turned off by user and doing that would cause ESC > >>>>> sequences to be passed directly to console. Might that be true in your > >>>>> case? > >>>>> > >>>>> rgds, > >>>>> toomas > >>>>> > >>>>>> On 15. Mar 2020, at 17:17, Tomoaki AOKI > >>>>>> wrote: > >>>>>> > >>>>>> Hi. > >>>>>> > >>>>>> This broke loader menu display on efifb. At least on amd64. > >>>>>> ESC sequences without ESC character are shown. > >>>>>> Key input (at least 1, 2 and enter) works OK. > >>>>>> I suspect outputs for SIO is sent to efifb and ESC codes are ignored. > >>>>>> > >>>>>> Reverting this fixes the issue. > >>> I got the same issue with loader menu when was upgrading from r358827 to > >>> r359028 (x86-64). > >>> > >>> But unfortunately the broken menu is just a part of my problem. The > >>> real pain is that a FreeBSD 13.0-CURRENT system hosted by VMware ESXi or > >>> Workstation doesn't boot anymore after r358989. An ugly workaround[1] > >>> (exiting from the loader menu into the loader prompt, running ls or > >>> show, scrolling the result down and then executing boot) I found some > >>> time ago doesn't work anymore. After running boot/boot -s/selecting > >>> menu item, a hypervisor just shuts session down with the following > >>> message: ``The firmware encountered an unexpected exception. The virtual > >>> machine cannot boot.'' > >>> > >>> The virtual guests don't have any UART (even USB) serial devices in > >>> their settings. efi-show prints result similar to what Tomoaki got: > >>> > >>> OK efi-show -g global -v CounOut > >>> global NV,BS,RS ConOut = PciRoot(0x0)/Pci(0x2,0x0)/AcpiAdr(0x80014310) > >>> > >>> Undefining TERM_EMU doesn't help. I had completely removed CFLAGS > >>> assignment with TERM_EMU from stand/efi/libefi/Makefile and rebuilt > >>> kernel/world -- nothing changed. I don't define TERM_EMU in my > >>> make.conf or/and src.conf. > >>> > >>> Reverting this revision fix booting (and menu, of course). > >>> > >>> FreeBSD on physical hardware boots just fine with this revision, but has > >>> corrupted loader menu. > >>> > >>> Toomas, please help us to fix this. I can
Re: svn commit: r358989 - in head/stand/efi: libefi loader loader/arch/arm loader/arch/arm64
Hi! Thanks for your respond.
Unfortunately, no.
I'm running on ThinkPad P52, which has no com connector installed.
No USB serial interface connected.
`efi-show -g global -v ConOut` on loader prompt shows
global NV,BS,RS ConOut =
PciRoot(0,0)/Pci((0x1,oxo)/Pci(0x0,0x0)/AcpiAdr(0x80010100)
Moreover, my previous idea didn't help.
Neither
console="vidconsole"
console="eficonsole"
console="efi_console"
nor
console="efi"
in /boot/loader.conf works.
Defining / undefining TERM_EMU on build are untested.
Is there any setting for /boot/loader.conf to control the behavior?
Regards.
On Mon, 16 Mar 2020 08:26:56 +0200
Toomas Soome wrote:
> Hi!
>
> This means, your system has UART serial device 〓 you can check this from
> loader prompt: efi-show -g global -v ConOut or with efivar from running
> system. This w ould trigger efi console driver to use
> TERM_EMU, which can be turned off by user and doing that would cause ESC
> sequences to be passed directly to console. Might that be true in your case?
>
> rgds,
> toomas
>
> > On 15. Mar 2020, at 17:17, Tomoaki AOKI wrote:
> >
> > Hi.
> >
> > This broke loader menu display on efifb. At least on amd64.
> > ESC sequences without ESC character are shown.
> > Key input (at least 1, 2 and enter) works OK.
> > I suspect outputs for SIO is sent to efifb and ESC codes are ignored.
> >
> > Reverting this fixes the issue.
> >
> > Not tried (not enough time for now as I'm mainly using stable/12),
> > but possibly calling efi_cons_probe() from efi_cons_init() would be
> > needed, as ome codes are moved from the latter to the former.
> >
> >
> >> Author: tsoome
> >> Date: Sat Mar 14 06:36:03 2020
> >> New Revision: 358989
> >> URL: https://svnweb.freebsd.org/changeset/base/358989
> >>
> >> Log:
> >> loader: add comconsole implementation on top of SIO protocol
> >>
> >> Provide comconsole on top of SIO for arm platforms (x86 does use bios
> > version).
> >>
> >> Added:
> >> head/stand/efi/loader/efiserialio.c (contents, props changed)
> >> Modified:
> >> head/stand/efi/libefi/efi_console.c
> >> head/stand/efi/loader/arch/arm/Makefile.inc
> >> head/stand/efi/loader/arch/arm64/Makefile.inc
> >> head/stand/efi/loader/conf.c
> >> head/stand/efi/loader/main.c
> >>
> >> Modified: head/stand/efi/libefi/efi_console.c
> >> ==
> >> --- head/stand/efi/libefi/efi_console.cSat Mar 14 05:57:22
> > 2020(r358988)
> >> +++ head/stand/efi/libefi/efi_console.c
> > Sat Mar 14 06:36:03 2020(r358989)
> >> @@ -377,9 +377,22 @@ efi_cons_respond(void *s __unused, const void *buf __u
> >> {
> >> }
> >>
> >> +/*
> >> + * Set up conin/conout/coninex to make sure we have input ready.
> >> + */
> >> static void
> >> efi_cons_probe(struct console *cp)
> >> {
> >> + EFI_STATUS status;
> >> +
> >> + conout = ST->ConOut;
> >> + conin = ST->ConIn;
> >> +
> >> + status = BS->OpenProtocol(ST->ConsoleInHandle,
> > _input_ex_guid,
> >> + (void **), IH, NULL,
> > EFI_OPEN_PROTOCOL_GET_PROTOCOL);
> >> + if (status != EFI_SUCCESS)
> >> + coninex = NULL;
> >> +
> >>cp->c_flags |= C_PRESENTIN | C_PRESENTOUT;
> >> }
> >>
> >> @@ -889,15 +902,7 @@ efi_cons_init(int arg)
> >>if (conin != NULL)
> >>return (0);
> >>
> >> - conout = ST->ConOut;
> >> - conin = ST->ConIn;
> >> -
> >>conout->EnableCursor(conout, TRUE);
> >> - status = BS->OpenProtocol(ST->ConsoleInHandle,
> > _input_ex_guid,
> >> - (void **), IH, NULL,
> > EFI_OPEN_PROTOCOL_GET_PROTOCOL);
> >> - if (status != EFI_SUCCESS)
> >> - coninex = NULL;
> >> -
> >>if (efi_cons_update_mode())
> >>return (0);
> >>
> >>
> >> Modified: head/stand/efi/loader/arch/arm/Makefile.inc
> >> ==
> >> --- head/stand/efi/loader/arch/arm/Makefile.incSat Mar 14
> > 05:57:22 2020 (r358988)
> >> +++ head/stand/efi/loader/arch/arm/Makefile.incSat Mar 14 06:36:03
> > 2020(r358989)
> >> @@ -1,6 +1,7 @@
> >> # $FreeBSD$
> >>
> >> SRCS+= exec.c \
> >> + efiserialio.c \
> >>start.S
> >>
> >> HAVE_FDT=yes
> >
> > (Snip)
> >
> >> @@ -930,7 +936,6 @@ main(int argc, CHAR16 *argv[])
> >>if (!has_kbd && (howto & RB_PROBE))
> >>howto |= RB_SERIAL | RB_MULTIPLE;
> >>howto &= ~RB_PROBE;
> >> - uhowto = parse_uefi_con_out();
> >>
> >>/*
> >> * Read additional environment variables from the boot device's
> >
> > --
> > Tomoaki AOKI
>
>
--
Tomoaki AOKI
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r358989 - in head/stand/efi: libefi loader loader/arch/arm loader/arch/arm64
Hi.
This broke loader menu display on efifb. At least on amd64.
ESC sequences without ESC character are shown.
Key input (at least 1, 2 and enter) works OK.
I suspect outputs for SIO is sent to efifb and ESC codes are ignored.
Reverting this fixes the issue.
Not tried (not enough time for now as I'm mainly using stable/12),
but possibly calling efi_cons_probe() from efi_cons_init() would be
needed, as ome codes are moved from the latter to the former.
> Author: tsoome
> Date: Sat Mar 14 06:36:03 2020
> New Revision: 358989
> URL: https://svnweb.freebsd.org/changeset/base/358989
>
> Log:
> loader: add comconsole implementation on top of SIO protocol
>
> Provide comconsole on top of SIO for arm platforms (x86 does use bios
version).
>
> Added:
> head/stand/efi/loader/efiserialio.c (contents, props changed)
> Modified:
> head/stand/efi/libefi/efi_console.c
> head/stand/efi/loader/arch/arm/Makefile.inc
> head/stand/efi/loader/arch/arm64/Makefile.inc
> head/stand/efi/loader/conf.c
> head/stand/efi/loader/main.c
>
> Modified: head/stand/efi/libefi/efi_console.c
> ==
> --- head/stand/efi/libefi/efi_console.c Sat Mar 14 05:57:22
2020(r358988)
> +++ head/stand/efi/libefi/efi_console.c
Sat Mar 14 06:36:03 2020(r358989)
> @@ -377,9 +377,22 @@ efi_cons_respond(void *s __unused, const void *buf __u
> {
> }
>
> +/*
> + * Set up conin/conout/coninex to make sure we have input ready.
> + */
> static void
> efi_cons_probe(struct console *cp)
> {
> + EFI_STATUS status;
> +
> + conout = ST->ConOut;
> + conin = ST->ConIn;
> +
> + status = BS->OpenProtocol(ST->ConsoleInHandle,
_input_ex_guid,
> + (void **), IH, NULL,
EFI_OPEN_PROTOCOL_GET_PROTOCOL);
> + if (status != EFI_SUCCESS)
> + coninex = NULL;
> +
> cp->c_flags |= C_PRESENTIN | C_PRESENTOUT;
> }
>
> @@ -889,15 +902,7 @@ efi_cons_init(int arg)
> if (conin != NULL)
> return (0);
>
> - conout = ST->ConOut;
> - conin = ST->ConIn;
> -
> conout->EnableCursor(conout, TRUE);
> - status = BS->OpenProtocol(ST->ConsoleInHandle,
_input_ex_guid,
> - (void **), IH, NULL,
EFI_OPEN_PROTOCOL_GET_PROTOCOL);
> - if (status != EFI_SUCCESS)
> - coninex = NULL;
> -
> if (efi_cons_update_mode())
> return (0);
>
>
> Modified: head/stand/efi/loader/arch/arm/Makefile.inc
> ==
> --- head/stand/efi/loader/arch/arm/Makefile.inc Sat Mar 14
05:57:22 2020 (r358988)
> +++ head/stand/efi/loader/arch/arm/Makefile.inc Sat Mar 14 06:36:03
2020(r358989)
> @@ -1,6 +1,7 @@
> # $FreeBSD$
>
> SRCS+= exec.c \
> + efiserialio.c \
> start.S
>
> HAVE_FDT=yes
(Snip)
> @@ -930,7 +936,6 @@ main(int argc, CHAR16 *argv[])
> if (!has_kbd && (howto & RB_PROBE))
> howto |= RB_SERIAL | RB_MULTIPLE;
> howto &= ~RB_PROBE;
> - uhowto = parse_uefi_con_out();
>
> /*
>* Read additional environment variables from the boot device's
--
Tomoaki AOKI
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r327058 - head/stand/efi/boot1
> On Thu, Dec 21, 2017 at 6:21 AM, Michael Zhilin wrote: >> Author: mizhka >> Date: Thu Dec 21 12:21:35 2017 >> New Revision: 327058 >> URL: https://svnweb.freebsd.org/changeset/base/327058 >> >> Log: >> [boot/efi] scan all display modes rather than sequential try-fail way >> >> This patch allows to scan all display modes in boot1 as loader does. >> >> Before system tried to select optimal display mode by sequential scan of >> modes and if error then stop scanning. This way is not good, because >> if mode N is not present, mode N+1 may exist. >> >> In loader we use conout->Mode->MaxMode to identify maximum number of modes. >> This commit is to use same way in boot1 as in loader. >> >> Reported by: Andrey Pustovetov >> Reviewed by: tsoome >> Differential Revision:https://reviews.freebsd.org/D13541 >> > > HI, > > Just FYI- we've had several reports of this doing the wrong thing for > many people, most recently by Allan yesterday (IIRC). I'm going to > avoid MFC'ing it, I think we should either back this out or figure out > where it's going wrong sooner rather than later. =( > > Thanks, > >Kyle Evans +1. I've been reporting back to mizhka@ what he wants off-list. (First report is on-list. [1]) Please wait MFC for this fixed, and, if possible, report below to mizhka@. *Output of "mode" command of loader console. *Video of broken boot process or photo of broken screen. *CPU model with integrated video. *Which mode worked and which isn't if specified by loader command. *Result of `got list` by loader command. *Result of `uga list` by loader command. As no one other than me posts negative comment to the commit mail here, I've not requested him to revert this. (Requested to do so if someone else reports problem.) FYI: For me, boot1 and loader screen are OK, but once kernel starts, broken screen. So vt (efifb) driver should be fixed to be aware of current (actual) screen mode. [1] https://lists.freebsd.org/pipermail/svn-src-head/2017-December/107598.html -- Tomoaki AOKI<junch...@dec.sakura.ne.jp> ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r327058 - head/stand/efi/boot1
This broke screen after kernel starts.
ThinkPad T420 with nvidia NVS 4200M.
boot1 screen and loader screen (beastie menu) shows up smaller (but not
broken) than usual, and small five interlaced kernel outputs (not
actually readable at all) are shown on top of screen.
So screen resolution setting should be different and not re-initialized
in kernel properly.
*Setting hw.vga.textmode (0 and 1) didn't help.
*Setting resolution (assuming it wouldn't work, though)
via kern.vt.fb.default_mode didn't work as expected.
(the option is for scfb, not for UEFI fb.)
*Removing nvidia.ko and nvidia-modeset.ko from loader.conf
didn't help.
*Last known-to-be-OK revision was r326876 and no other commit
is done to boot1 codes before this rev.
*Using known-to-be-OK rev of boot1.efi, all goes fine.
As some commits are done to toolchain codes, I tried rebuilding
known-to-be-OK boot1.efi with current toolchains and confirmed
working OK.
> Author: mizhka
> Date: Thu Dec 21 12:21:35 2017
> New Revision: 327058
> URL: https://svnweb.freebsd.org/changeset/base/327058
>
> Log:
> [boot/efi] scan all display modes rather than sequential try-fail way
>
> This patch allows to scan all display modes in boot1 as loader does.
>
> Before system tried to select optimal display mode by sequential scan
of
> modes and if error then stop scanning. This way is not good, because
> if mode N is not present, mode N+1 may exist.
>
> In loader we use conout->Mode->MaxMode to identify maximum number of
modes.
> This commit is to use same way in boot1 as in loader.
> Reported by:Andrey Pustovetov
> Reviewed by:tsoome
> Differential Revision: https://reviews.freebsd.org/D13541
>
> Modified:
> head/stand/efi/boot1/boot1.c
>
> Modified: head/stand/efi/boot1/boot1.c
> ==
> --- head/stand/efi/boot1/boot1.c Thu Dec 21 09:21:40 2017
(r327057)
> +++ head/stand/efi/boot1/boot1.c Thu Dec 21 12:21:35
2017(r327058)
> @@ -430,10 +430,10 @@ efi_main(EFI_HANDLE Ximage,
EFI_SYSTEM_TABLE *Xsystab)
> conout = ST->ConOut;
> conout->Reset(conout, TRUE);
> max_dim = best_mode = 0;
> - for (i = 0; ; i++) {
> + for (i = 0; i < conout->Mode->MaxMode; i++) {
> status = conout->QueryMode(conout, i, , );
> if (EFI_ERROR(status))
> - break;
> + continue;
> if (cols * rows > max_dim) {
> max_dim = cols * rows;
> best_mode = i;
--
Tomoaki AOKI<junch...@dec.sakura.ne.jp>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r322941 - head/sys/boot/efi/boot1
On Sat, 2 Sep 2017 11:26:50 -0600 Warner Losh <i...@bsdimp.com> wrote: > On Sat, Sep 2, 2017 at 11:25 AM, Warner Losh <i...@bsdimp.com> wrote: > > > > > > > On Sat, Sep 2, 2017 at 1:43 AM, Tomoaki AOKI <junch...@dec.sakura.ne.jp> > > wrote: > > > >> Hi. > >> > >> This broke boot drive selection functionality by smh@ at r295320 on > >> Feb.5, 2016. [1] > >> Now, even if I forcibly select 2nd HDD via UEFI firmware, boot1.efi > >> (as bootx64.efi) selects /boot/loader.efi on 1st HDD. Each boot > >> partition are ZFS pools. Confirmed previous rev was OK. > >> > >> Attached is the boot log (with EFI_DEBUG). Pool zsysS02 should be > >> selected there instead of zsysS01. As I have no serial console, there > >> can be some typos. (Took video and hand-typed.) > >> > >> The boot order should be as below (what smh@ implemented). > >> > >> 1. ZFS pool on which drive boot1.efi is read from. > >> 2. UFS partition on which drive boot1.efi is read from. > >> 3. If both 1 and 2 are missed, try from UEFI 1st drive and later. > >> > >> P.S. Another possibility (not tested yet): > >> Not forcibly prefer 1st drive, but reversed selection. > >> (If boot1.efi is on 1st drive, loader.efi on 2nd drive is read.) > >> > >> [1] > >> https://lists.freebsd.org/pipermail/svn-src-head/2016-Februa > >> ry/082215.html > > > > > > Looks like the matching function that I replaced this stuff with wasn't > > quite the same. Will fix. I hadn't thought I'd broken it, honestly, since > > the setup I have still worked. The intent was to keep things as they were, > > which clearly didn't happen in at least your case. I'll take a look at the > > logs to see if I can spot the differences between the two setups. The > > intent was to keep functionality, for now, the same. > > > > In the long term, though, this guessing and matching is going to end up > > first as deprecated and then as removed. To be replaced by a boot1.efi that > > follows the EFI Boot Manager protocol where exactly what to load is > > contained in EFI env variables. That's what all my changes to boot1 have > > been working towards. > > > > Warner > > > > P.S. This is the doc I put together for discussion. I'm keeping it updated > as each stage is implemented. > > https://docs.google.com/document/d/1aK9IqF-60JPEbUeSAUAkYjF2W_8EnmczFs6RqCT90Jg/edit > > Lemme know if you have any comments. > > Warner > Read that, and have some comments. (Maybe not enough understood UEFI 2.6 boot manager spec, though) If I understood current code correctly, third on "Current Algorithm" looks incorrect. boot1.efi looks for ZFS, then UFS for all devices, per-device basis. And yes, it cannot specify which partition to boot from. A fix was proposed by Naomichi Nonaka as bug 207940.[1] (Not using UEFI boot manager protocol, though.) This patch no longer applicable to head with recent changes, but applicable for stable/11 with slight fix (attached, working for me). Unfortunately, Naomichi is no longer working on it, as it haven't introduced to head for a long time, and now he knows GRUB2 can chainload loader.efi on ZFS pool. [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207940 For "Proposed Algorithm", some problematic UEFI firmware could miss non-default location. As workaround, current \EFI\BOOT\BOOTx64.efi (within boot1.efifat) should be kept (at least, as an installer option) to fallback. For 2) b), some people could want largest partition number to take precedence over smaller, especially when they create a new partition to test new environment keeping old environment untouched. For 2) c), the administrator should better have opportunity to re-select another device to boot from, especially for -head users. Sometimes head cannot boot after installworld and need convenient way to boot from other device temporarily. (Improperly built loader.efi, broken *.4th, ...) If the machine is at a datacenter, USB memstick wouldn't help, but flexible boot manager could do if there's any remote KVM switch or something alike. *Setting BootNext and restart would be fine, if the UEFI firmware is NOT a problematic one, and BootNext is cleared after successful boot (just like "boot once" for MBR+UFS). *Would be better if something like "BootEmergency" (non-existent for now, automatically selected only when "BootFailed") can be implemented. But maybe cannot, as it should need UEFI firmware support and I couldn't find such a feature in UEFI spec. > > > Author: imp > >> > Date: Sun Aug 27 03:10:16
Re: svn commit: r322941 - head/sys/boot/efi/boot1
On Sat, 2 Sep 2017 11:26:50 -0600
Warner Losh <i...@bsdimp.com> wrote:
> On Sat, Sep 2, 2017 at 11:25 AM, Warner Losh <i...@bsdimp.com> wrote:
>
> >
> >
> > On Sat, Sep 2, 2017 at 1:43 AM, Tomoaki AOKI <junch...@dec.sakura.ne.jp>
> > wrote:
> >
> >> Hi.
> >>
> >> This broke boot drive selection functionality by smh@ at r295320 on
> >> Feb.5, 2016. [1]
> >> Now, even if I forcibly select 2nd HDD via UEFI firmware, boot1.efi
> >> (as bootx64.efi) selects /boot/loader.efi on 1st HDD. Each boot
> >> partition are ZFS pools. Confirmed previous rev was OK.
> >>
> >> Attached is the boot log (with EFI_DEBUG). Pool zsysS02 should be
> >> selected there instead of zsysS01. As I have no serial console, there
> >> can be some typos. (Took video and hand-typed.)
> >>
> >> The boot order should be as below (what smh@ implemented).
> >>
> >> 1. ZFS pool on which drive boot1.efi is read from.
> >> 2. UFS partition on which drive boot1.efi is read from.
> >> 3. If both 1 and 2 are missed, try from UEFI 1st drive and later.
> >>
> >> P.S. Another possibility (not tested yet):
> >> Not forcibly prefer 1st drive, but reversed selection.
> >> (If boot1.efi is on 1st drive, loader.efi on 2nd drive is read.)
> >>
> >> [1]
> >> https://lists.freebsd.org/pipermail/svn-src-head/2016-Februa
> >> ry/082215.html
> >
> >
> > Looks like the matching function that I replaced this stuff with wasn't
> > quite the same. Will fix. I hadn't thought I'd broken it, honestly, since
> > the setup I have still worked. The intent was to keep things as they were,
> > which clearly didn't happen in at least your case. I'll take a look at the
> > logs to see if I can spot the differences between the two setups. The
> > intent was to keep functionality, for now, the same.
> >
> > In the long term, though, this guessing and matching is going to end up
> > first as deprecated and then as removed. To be replaced by a boot1.efi that
> > follows the EFI Boot Manager protocol where exactly what to load is
> > contained in EFI env variables. That's what all my changes to boot1 have
> > been working towards.
> >
> > Warner
> >
Confirmed fixed (on both 1st [stable/11] and 2nd [head] HDD) on r323131.
Thanks for your quick response!
But one thing to mention. There could be problematic UEFI firmware
and functions like this could be kept on required for workaround.
(Like LenovoFix on gpart / geom.)
> P.S. This is the doc I put together for discussion. I'm keeping it updated
> as each stage is implemented.
>
> https://docs.google.com/document/d/1aK9IqF-60JPEbUeSAUAkYjF2W_8EnmczFs6RqCT90Jg/edit
>
> Lemme know if you have any comments.
>
> Warner
Thanks for the info.
Not yet, but I'll read it later and let you know if some comments looks
needed.
Thanks again!
>
> > > Author: imp
> >> > Date: Sun Aug 27 03:10:16 2017
> >> > New Revision: 322941
> >> > URL: https://svnweb.freebsd.org/changeset/base/322941
> >> >
> >> > Log:
> >> > Eliminate redunant device path matching.
> >> >
> >> > Use efi_devpath_match instead of device_paths_match. They are
> >> > functionally the same. Remove device_paths_match from boot1.c and call
> >> > efi_devpath_match instead.
> >> >
> >> > Sponsored by: Netflix
> >> >
> >> > Modified:
> >> > head/sys/boot/efi/boot1/boot1.c
> >> >
> >> > Modified: head/sys/boot/efi/boot1/boot1.c
> >> >
> >> ==
> >> > --- head/sys/boot/efi/boot1/boot1.c Sat Aug 26 23:13:18 2017
> >> (r322940)
> >> > +++ head/sys/boot/efi/boot1/boot1.c Sun Aug 27 03:10:16 2017
> >> (r322941)
> >> > @@ -76,53 +76,6 @@ Free(void *buf, const char *file __unused, int line
> >> __ }
> >> >
> >> > /*
> >> > - * nodes_match returns TRUE if the imgpath isn't NULL and the nodes
> >> match,
> >> > - * FALSE otherwise.
> >> > - */
> >> > -static BOOLEAN
> >> > -nodes_match(EFI_DEVICE_PATH *imgpath, EFI_DEVICE_PATH *devpath)
> >> > -{
> >> > - size_t len;
> >> > -
> >> > - if (imgpath == NULL || imgpath->Type != devpath->Type ||
> >> > - imgpath->SubType != devpath->SubT
Re: svn commit: r322941 - head/sys/boot/efi/boot1
Hi.
This broke boot drive selection functionality by smh@ at r295320 on
Feb.5, 2016. [1]
Now, even if I forcibly select 2nd HDD via UEFI firmware, boot1.efi
(as bootx64.efi) selects /boot/loader.efi on 1st HDD. Each boot
partition are ZFS pools. Confirmed previous rev was OK.
Attached is the boot log (with EFI_DEBUG). Pool zsysS02 should be
selected there instead of zsysS01. As I have no serial console, there
can be some typos. (Took video and hand-typed.)
The boot order should be as below (what smh@ implemented).
1. ZFS pool on which drive boot1.efi is read from.
2. UFS partition on which drive boot1.efi is read from.
3. If both 1 and 2 are missed, try from UEFI 1st drive and later.
P.S. Another possibility (not tested yet):
Not forcibly prefer 1st drive, but reversed selection.
(If boot1.efi is on 1st drive, loader.efi on 2nd drive is read.)
[1]
https://lists.freebsd.org/pipermail/svn-src-head/2016-February/082215.html
> Author: imp
> Date: Sun Aug 27 03:10:16 2017
> New Revision: 322941
> URL: https://svnweb.freebsd.org/changeset/base/322941
>
> Log:
> Eliminate redunant device path matching.
>
> Use efi_devpath_match instead of device_paths_match. They are
> functionally the same. Remove device_paths_match from boot1.c and call
> efi_devpath_match instead.
>
> Sponsored by: Netflix
>
> Modified:
> head/sys/boot/efi/boot1/boot1.c
>
> Modified: head/sys/boot/efi/boot1/boot1.c
> ==
> --- head/sys/boot/efi/boot1/boot1.c Sat Aug 26 23:13:18 2017
> (r322940)
> +++ head/sys/boot/efi/boot1/boot1.c Sun Aug 27 03:10:16 2017
> (r322941)
> @@ -76,53 +76,6 @@ Free(void *buf, const char *file __unused, int line __ }
>
> /*
> - * nodes_match returns TRUE if the imgpath isn't NULL and the nodes
match,
> - * FALSE otherwise.
> - */
> -static BOOLEAN
> -nodes_match(EFI_DEVICE_PATH *imgpath, EFI_DEVICE_PATH *devpath)
> -{
> - size_t len;
> -
> - if (imgpath == NULL || imgpath->Type != devpath->Type ||
> - imgpath->SubType != devpath->SubType)
> - return (FALSE);
> -
> - len = DevicePathNodeLength(imgpath);
> - if (len != DevicePathNodeLength(devpath))
> - return (FALSE);
> -
> - return (memcmp(imgpath, devpath, (size_t)len) == 0);
> -}
> -
> -/*
> - * device_paths_match returns TRUE if the imgpath isn't NULL and all
nodes
> - * in imgpath and devpath match up to their respective occurrences of a
> - * media node, FALSE otherwise.
> - */
> -static BOOLEAN
> -device_paths_match(EFI_DEVICE_PATH *imgpath, EFI_DEVICE_PATH *devpath)
> -{
> -
> - if (imgpath == NULL)
> - return (FALSE);
> -
> - while (!IsDevicePathEnd(imgpath) && !IsDevicePathEnd(devpath))
{
> - if (IsDevicePathType(imgpath, MEDIA_DEVICE_PATH) &&
> - IsDevicePathType(devpath, MEDIA_DEVICE_PATH))
> - return (TRUE);
> -
> - if (!nodes_match(imgpath, devpath))
> - return (FALSE);
> -
> - imgpath = NextDevicePathNode(imgpath);
> - devpath = NextDevicePathNode(devpath);
> - }
> -
> - return (FALSE);
> -}
> -
> -/*
> * devpath_last returns the last non-path end node in devpath.
> */
> static EFI_DEVICE_PATH *
> @@ -318,7 +271,7 @@ probe_handle(EFI_HANDLE h, EFI_DEVICE_PATH
*imgpath, B
> if (!blkio->Media->LogicalPartition)
> return (EFI_UNSUPPORTED);
>
> - *preferred = device_paths_match(imgpath, devpath);
> + *preferred = efi_devpath_match(imgpath, devpath);
>
> /* Run through each module, see if it can load this partition
*/
> for (i = 0; i < NUM_BOOT_MODULES; i++) {
--
Tomoaki AOKI<junch...@dec.sakura.ne.jp>
Loader path: /boot/loader.efi
Initializing modules: ZFS UFS
Load Path: \EFI\BOOT\BOOTX64.EFI
Load Device:
PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x1,0x0,0x0)/HD(1,GPT,38D03E6E-5609-11E5-81A0-0021CC6F1820,0x800,0x32000)
Probing 12 block devices...
probing: PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x0,0x0,0x0)
probe: . not supported
probing: PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x1,0x0,0x0)
probe: . not supported
probing:
PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x0,0x0,0x0)/HD(1,GPT,66922244-636E-11E5-8AD1-0021CC6F1820,0x800,0x64000)
probe: . not supported
probing:
PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x0,0x0,0x0)/HD(2,GPT,AEF62820-636E-11E5-8AD1-0021CC6F1820,0x64800,0x400)
probe: . not supported
probing:
PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x0,0x0,0x0)/HD(3,GPT,E7579EDA-636F-11E5-8AD1-0021CC6F1820,0x65000,0x140)
probe: . not supported
probing:
PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x0,0x0,0x0)/HD(4,GPT,5E4A8AD
Re: svn commit: r315370 - head/sys/vm
> Author: delphij > Date: Thu Mar 16 05:44:16 2017 > New Revision: 315370 > URL: https://svnweb.freebsd.org/changeset/base/315370 > > Log: > The adj_free and max_free values of new_entry will be calculated and > assigned by subsequent vm_map_entry_link(), therefore, remove the > pointless copying. > > Submitted by: alc > MFC after: 3 days Should be X-MFC with: r315272. This modifies what r315272 implements and meaningless without it. Is r315272 planned to be MFC'ed in 3 days? (Originally, 1month.) > > Modified: > head/sys/vm/vm_map.c > > Modified: head/sys/vm/vm_map.c > == > --- head/sys/vm/vm_map.c Thu Mar 16 04:58:12 2017 (r315369) > +++ head/sys/vm/vm_map.c Thu Mar 16 05:44:16 2017(r315370) > @@ -3456,8 +3456,6 @@ vmspace_fork(struct vmspace *vm1, vm_oof > new_entry->start = old_entry->start; > new_entry->end = old_entry->end; > new_entry->avail_ssize = old_entry->avail_ssize; > - new_entry->adj_free = old_entry->adj_free; > - new_entry->max_free = old_entry->max_free; > new_entry->eflags = old_entry->eflags & > ~(MAP_ENTRY_USER_WIRED | MAP_ENTRY_IN_TRANSITION | >MAP_ENTRY_VN_WRITECNT); -- Tomoaki AOKI<junch...@dec.sakura.ne.jp> ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
