date:20180804

Re: svn commit: r337340 - in head: [This broke all ci.freebsd.org 's FreeBSD-head-*-build 's, clang based and gcc 4.2.1 based]

2018-08-04 Thread Brad Davis

On Sat, Aug 4, 2018, at 7:43 PM, Mark Millard wrote:
> > Author: brd
> > Date: Sat Aug  4 22:41:17 2018
> > New Revision: 337340
> > URL: 
> > https://svnweb.freebsd.org/changeset/base/337340
> > 
> > 
> > Log:
> >   Move autofs related configs to usr.sbin/autofs/
> >   
> >   This is prep for pkgbase to have config files tagged as such.
> >   
> >   Approved by:  will (mentor)
> >   Differential Revision:
> > https://reviews.freebsd.org/D16492
> . . .
> 
> This broke all the ci.freebsd.org builds of freebsd-head-*-build .
> 
> Using FreeBSD-head-powerpc64-build as an example:
> #6826 (for -r337399 ) worked but #6827 (for -r337400 )
> fails with:
> 
> (cd /usr/src/etc; make -DDB_FROM_SRC __MAKE_CONF=/dev/null SRCCONF=/
> workspace/freebsd-ci/jobs/FreeBSD-head-powerpc64-build/src.conf etc-
> examples)
> cd /usr/src/etc; install -N /usr/src/etc  -o root -g wheel -m 444  
> crontab  devd.conf  devfs.conf  ddb.conf  dhclient.conf  disktab  fbtab  
> gettytab  group  hosts  hosts.allow  hosts.equiv  libalias.conf  
> libmap.conf  login.access  login.conf  mac.conf  motd  netconfig  
> networks  newsyslog.conf  nsswitch.conf  phones  profile  protocols  
> rc.bsdextended  rc.firewall  remote  rpc  services  sysctl.conf  
> syslog.conf  termcap.small etc.powerpc/ttys amd.map auto_master ftpusers 
> inetd.conf /usr/src/usr.bin/locate/locate/locate.rc hosts.lpd printcap /
> usr/src/usr.bin/mail/misc/mail.rc ntp.conf pf.os rc.sendmail csh.cshrc 
> csh.login csh.logout regdomain.xml  nsmb.conf opieaccess  /usr/obj/usr/
> src/powerpc.powerpc64/release/dist/base/usr/share/examples/etc
> install: auto_master: No such file or directory
> *** Error code 71
> 
> Stop.
> make[8]: stopped in /usr/src/etc
> *** Error code 1
> 
> 
> 
> Stop.
> make[7]: stopped in /usr/src/share/examples
> *** Error code 1
> 
> Stop.
> make[6]: stopped in /usr/src/share/examples
> *** Error code 1
> 
> Stop.
> make[5]: stopped in /usr/src/share
> *** Error code 1
> 
> Stop.
> make[4]: stopped in /usr/src
> *** Error code 1
> 
> Stop.
> make[3]: stopped in /usr/src
> *** Error code 1
> 
> Stop.
> make[2]: stopped in /usr/src
> *** Error code 1
> 
> Stop.
> make[1]: stopped in /usr/src
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/src/release

Testing the fix..


Regards,
Brad Davis
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: svn commit: r337340 - in head: [This broke all ci.freebsd.org 's FreeBSD-head-*-build 's, clang based and gcc 4.2.1 based]

2018-08-04 Thread Brad Davis

On Sat, Aug 4, 2018, at 9:48 PM, Brad Davis wrote:
> On Sat, Aug 4, 2018, at 7:43 PM, Mark Millard wrote:
> > > Author: brd
> > > Date: Sat Aug  4 22:41:17 2018
> > > New Revision: 337340
> > > URL: 
> > > https://svnweb.freebsd.org/changeset/base/337340
> > > 
> > > 
> > > Log:
> > >   Move autofs related configs to usr.sbin/autofs/
> > >   
> > >   This is prep for pkgbase to have config files tagged as such.
> > >   
> > >   Approved by:will (mentor)
> > >   Differential Revision:  
> > > https://reviews.freebsd.org/D16492
> > . . .
> > 
> > This broke all the ci.freebsd.org builds of freebsd-head-*-build .
> > 
> > Using FreeBSD-head-powerpc64-build as an example:
> > #6826 (for -r337399 ) worked but #6827 (for -r337400 )
> > fails with:
> > 
> > (cd /usr/src/etc; make -DDB_FROM_SRC __MAKE_CONF=/dev/null SRCCONF=/
> > workspace/freebsd-ci/jobs/FreeBSD-head-powerpc64-build/src.conf etc-
> > examples)
> > cd /usr/src/etc; install -N /usr/src/etc  -o root -g wheel -m 444  
> > crontab  devd.conf  devfs.conf  ddb.conf  dhclient.conf  disktab  fbtab  
> > gettytab  group  hosts  hosts.allow  hosts.equiv  libalias.conf  
> > libmap.conf  login.access  login.conf  mac.conf  motd  netconfig  
> > networks  newsyslog.conf  nsswitch.conf  phones  profile  protocols  
> > rc.bsdextended  rc.firewall  remote  rpc  services  sysctl.conf  
> > syslog.conf  termcap.small etc.powerpc/ttys amd.map auto_master ftpusers 
> > inetd.conf /usr/src/usr.bin/locate/locate/locate.rc hosts.lpd printcap /
> > usr/src/usr.bin/mail/misc/mail.rc ntp.conf pf.os rc.sendmail csh.cshrc 
> > csh.login csh.logout regdomain.xml  nsmb.conf opieaccess  /usr/obj/usr/
> > src/powerpc.powerpc64/release/dist/base/usr/share/examples/etc
> > install: auto_master: No such file or directory
> > *** Error code 71
> > 
> > Stop.
> > make[8]: stopped in /usr/src/etc
> > *** Error code 1
> > 
> > 
> > 
> > Stop.
> > make[7]: stopped in /usr/src/share/examples
> > *** Error code 1
> > 
> > Stop.
> > make[6]: stopped in /usr/src/share/examples
> > *** Error code 1
> > 
> > Stop.
> > make[5]: stopped in /usr/src/share
> > *** Error code 1
> > 
> > Stop.
> > make[4]: stopped in /usr/src
> > *** Error code 1
> > 
> > Stop.
> > make[3]: stopped in /usr/src
> > *** Error code 1
> > 
> > Stop.
> > make[2]: stopped in /usr/src
> > *** Error code 1
> > 
> > Stop.
> > make[1]: stopped in /usr/src
> > *** Error code 1
> > 
> > Stop.
> > make: stopped in /usr/src/release
> 
> Testing the fix..

Fix committed in r337342.  Sorry for the noise.


Regards,
Brad Davis
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

2018-08-04 Thread Kyle Evans

On Sat, Aug 4, 2018 at 3:37 AM, Konstantin Belousov  wrote:
> On Fri, Aug 03, 2018 at 11:27:02PM -0500, Kyle Evans wrote:
>> On Fri, Aug 3, 2018 at 10:10 PM, Eitan Adler  wrote:
>> > Hi all,
>> >
>> > After installing the latest current kernel I get the following panic:
>> >
>> > panic: mutex pmap not owned at ... efirt_machdep.c:255
>> > cpuid =3
>> > time = 1
>> > ...
>> > mtx_assert()
>> > efi_arch_enter()
>> > efirt_modevents()
>> > module_register_init()
>> > mi_startup()
>> > btext()
>> >
>>
>> This seems odd- pmap lock is acquired at [1], then asserted shortly
>> later at [2]... I avoid some of this stuff as well as I can, but is it
>> actually possible for PCPU_GET(...) acquired curpmap to not match
>> curthread->td_proc->p_vmspace->vm_pmap in this context?
>>
>> [1] 
>> https://svnweb.freebsd.org/base/head/sys/dev/efidev/efirt.c?view=markup#l260
>> [2] 
>> https://svnweb.freebsd.org/base/head/sys/amd64/amd64/efirt_machdep.c?view=markup#l254
> There could be that curpcpu not yet synced with proc0 pmap.  It could be
> fixed.
>

He now gets a little further, but ends up with the same panic due to
efirtc_probe trying to get time to verify the rtc's actually
implemented. What kind of approach must we take to ensure curcpu is
synced?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: svn commit: r337340 - in head: [This broke all ci.freebsd.org 's FreeBSD-head-*-build 's, clang based and gcc 4.2.1 based]

2018-08-04 Thread Mark Millard

> Author: brd
> Date: Sat Aug  4 22:41:17 2018
> New Revision: 337340
> URL: 
> https://svnweb.freebsd.org/changeset/base/337340
> 
> 
> Log:
>   Move autofs related configs to usr.sbin/autofs/
>   
>   This is prep for pkgbase to have config files tagged as such.
>   
>   Approved by:will (mentor)
>   Differential Revision:  
> https://reviews.freebsd.org/D16492
. . .

This broke all the ci.freebsd.org builds of freebsd-head-*-build .

Using FreeBSD-head-powerpc64-build as an example:
#6826 (for -r337399 ) worked but #6827 (for -r337400 )
fails with:

(cd /usr/src/etc; make -DDB_FROM_SRC __MAKE_CONF=/dev/null 
SRCCONF=/workspace/freebsd-ci/jobs/FreeBSD-head-powerpc64-build/src.conf 
etc-examples)
cd /usr/src/etc; install -N /usr/src/etc  -o root -g wheel -m 444  crontab  
devd.conf  devfs.conf  ddb.conf  dhclient.conf  disktab  fbtab  gettytab  group 
 hosts  hosts.allow  hosts.equiv  libalias.conf  libmap.conf  login.access  
login.conf  mac.conf  motd  netconfig  networks  newsyslog.conf  nsswitch.conf  
phones  profile  protocols  rc.bsdextended  rc.firewall  remote  rpc  services  
sysctl.conf  syslog.conf  termcap.small etc.powerpc/ttys amd.map auto_master 
ftpusers inetd.conf /usr/src/usr.bin/locate/locate/locate.rc hosts.lpd printcap 
/usr/src/usr.bin/mail/misc/mail.rc ntp.conf pf.os rc.sendmail csh.cshrc 
csh.login csh.logout regdomain.xml  nsmb.conf opieaccess  
/usr/obj/usr/src/powerpc.powerpc64/release/dist/base/usr/share/examples/etc
install: auto_master: No such file or directory
*** Error code 71

Stop.
make[8]: stopped in /usr/src/etc
*** Error code 1



Stop.
make[7]: stopped in /usr/src/share/examples
*** Error code 1

Stop.
make[6]: stopped in /usr/src/share/examples
*** Error code 1

Stop.
make[5]: stopped in /usr/src/share
*** Error code 1

Stop.
make[4]: stopped in /usr/src
*** Error code 1

Stop.
make[3]: stopped in /usr/src
*** Error code 1

Stop.
make[2]: stopped in /usr/src
*** Error code 1

Stop.
make[1]: stopped in /usr/src
*** Error code 1

Stop.
make: stopped in /usr/src/release







===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

install: auto_master: No such file or directory

2018-08-04 Thread Lars Schotte

somehow installworld fails lately

===> share/examples (install)
if [ -L /usr/share/examples/BSD_daemon ]; then  rm -f 
/usr/share/examples/BSD_daemon;  fi
if [ -L /usr/share/examples/FreeBSD_version ]; then  rm -f 
/usr/share/examples/FreeBSD_version;  fi
if [ -L /usr/share/examples/IPv6 ]; then  rm -f /usr/share/examples/IPv6;  fi
if [ -L /usr/share/examples/bootforth ]; then  rm -f 
/usr/share/examples/bootforth;  fi
if [ -L /usr/share/examples/csh ]; then  rm -f /usr/share/examples/csh;  fi
if [ -L /usr/share/examples/diskless ]; then  rm -f 
/usr/share/examples/diskless;  fi
if [ -L /usr/share/examples/drivers ]; then  rm -f /usr/share/examples/drivers; 
 fi
if [ -L /usr/share/examples/etc ]; then  rm -f /usr/share/examples/etc;  fi
if [ -L /usr/share/examples/find_interface ]; then  rm -f 
/usr/share/examples/find_interface;  fi
if [ -L /usr/share/examples/ibcs2 ]; then  rm -f /usr/share/examples/ibcs2;  fi
if [ -L /usr/share/examples/indent ]; then  rm -f /usr/share/examples/indent;  
fi
if [ -L /usr/share/examples/ipfw ]; then  rm -f /usr/share/examples/ipfw;  fi
if [ -L /usr/share/examples/jails ]; then  rm -f /usr/share/examples/jails;  fi
if [ -L /usr/share/examples/kld ]; then  rm -f /usr/share/examples/kld;  fi
if [ -L /usr/share/examples/libvgl ]; then  rm -f /usr/share/examples/libvgl;  
fi
if [ -L /usr/share/examples/mdoc ]; then  rm -f /usr/share/examples/mdoc;  fi
if [ -L /usr/share/examples/netgraph ]; then  rm -f 
/usr/share/examples/netgraph;  fi
if [ -L /usr/share/examples/perfmon ]; then  rm -f /usr/share/examples/perfmon; 
 fi
if [ -L /usr/share/examples/ppi ]; then  rm -f /usr/share/examples/ppi;  fi
if [ -L /usr/share/examples/ppp ]; then  rm -f /usr/share/examples/ppp;  fi
if [ -L /usr/share/examples/printing ]; then  rm -f 
/usr/share/examples/printing;  fi
if [ -L /usr/share/examples/ses ]; then  rm -f /usr/share/examples/ses;  fi
if [ -L /usr/share/examples/scsi_target ]; then  rm -f 
/usr/share/examples/scsi_target;  fi
if [ -L /usr/share/examples/sunrpc ]; then  rm -f /usr/share/examples/sunrpc;  
fi
if [ -L /usr/share/examples/ypldap ]; then  rm -f /usr/share/examples/ypldap;  
fi
if [ -L /usr/share/examples/bhyve ]; then  rm -f /usr/share/examples/bhyve;  fi
if [ -L /usr/share/examples/uefisign ]; then  rm -f 
/usr/share/examples/uefisign;  fi
if [ -L /usr/share/examples/hast ]; then  rm -f /usr/share/examples/hast;  fi
if [ -L /usr/share/examples/libusb20 ]; then  rm -f 
/usr/share/examples/libusb20;  fi
(cd /usr/src/etc; make MK_MAKE_CHECK_USE_SANDBOX=yes etc-examples)
cd /usr/src/etc; install  -o root -g wheel -m 444  crontab  devd.conf  
devfs.conf  ddb.conf  dhclient.conf  disktab  fbtab  gettytab  group  hosts  
hosts.allow  hosts.equiv  libalias.conf  libmap.conf  login.access  login.conf  
mac.conf  motd  netconfig  networks  newsyslog.conf  nsswitch.conf  phones  
profile  protocols  rc.bsdextended  rc.firewall  remote  rpc  services  
sysctl.conf  syslog.conf  termcap.small etc.amd64/ttys amd.map auto_master 
ftpusers inetd.conf /usr/src/usr.bin/locate/locate/locate.rc hosts.lpd printcap 
/usr/src/usr.bin/mail/misc/mail.rc ntp.conf pf.os rc.sendmail csh.cshrc 
csh.login csh.logout regdomain.xml  nsmb.conf opieaccess  
/usr/share/examples/etc
install: auto_master: No such file or directory
*** Error code 71

Stop.
make[6]: stopped in /usr/src/etc
*** Error code 1

Stop.
make[5]: stopped in /usr/src/share/examples
*** Error code 1

Stop.
make[4]: stopped in /usr/src/share
*** Error code 1

Stop.
make[3]: stopped in /usr/src
*** Error code 1

Stop.
make[2]: stopped in /usr/src
*** Error code 1

Stop.
make[1]: stopped in /usr/src
*** Error code 1

Stop.
make: stopped in /usr/src
# less UPDATING 
# svn up
Updating '.':
At revision 337340.


-- 
 Lars Schotte
 Mudroňova 13
92101 Piešťany
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: SVN r337340 breaks installworld and mergemaster

2018-08-04 Thread Lars Schotte

Yes, I get that too.

On Sat, 4 Aug 2018 19:31:14 -0400
Michael Butler  wrote:

> make installworld results in ..
> 
> (cd /usr/src/etc; make MK_MAKE_CHECK_USE_SANDBOX=yes etc-examples)
> cd /usr/src/etc; install  -o root -g wheel -m 444  crontab  devd.conf
> devfs.conf  ddb.conf  dhclient.conf  disktab  fbtab  gettytab  group
> hosts  hosts.allow  hosts.equiv  libalias.conf  libmap.conf
> login.access  login.conf  mac.conf  motd  netconfig  networks
> newsyslog.conf  nsswitch.conf  phones  profile  protocols
> rc.bsdextended  rc.firewall  remote  rpc  services  sysctl.conf
> syslog.conf  termcap.small etc.amd64/ttys amd.map auto_master ftpusers
> inetd.conf /usr/src/usr.bin/locate/locate/locate.rc
> /usr/src/usr.bin/mail/misc/mail.rc ntp.conf pf.os rc.sendmail
> csh.cshrc csh.login csh.logout regdomain.xml  nsmb.conf opieaccess
> /usr/share/examples/etc
> 
> install: auto_master: No such file or directory
> *** Error code 71
> 
> Stop.
> make[6]: stopped in /usr/src/etc
> *** Error code 1
> 
> Stop.
> 
> mergemaster complains of ..
> 
> imb@vm01:/home/imb> sudo mergemaster -FUi
> 
> *** Creating the temporary root environment in /var/tmp/temproot
>  *** /var/tmp/temproot ready for use
>  *** Creating and populating directory structure in /var/tmp/temproot
> 
> install: auto_master: No such file or directory
> 
>   *** FATAL ERROR: Cannot 'cd' to /usr/src and install files to
>   the temproot environment
> 
>   imb
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "freebsd-current-unsubscr...@freebsd.org"



-- 
 Lars Schotte
 Mudroňova 13
92101 Piešťany
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

programs like gdb core dump

2018-08-04 Thread Erich Dollansky

Hi,

I compiled me yesterday this system:

12.0-CURRENT FreeBSD 12.0-CURRENT #1 r337285:

When restarting fortune core dumps. When trying to load the core dump,
gdb core dumps.

The message is always:

Bad system call (core dumped)

Trying to install ports results in the same effect.

Erich
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

SVN r337340 breaks installworld and mergemaster

2018-08-04 Thread Michael Butler

make installworld results in ..

(cd /usr/src/etc; make MK_MAKE_CHECK_USE_SANDBOX=yes etc-examples)
cd /usr/src/etc; install  -o root -g wheel -m 444  crontab  devd.conf
devfs.conf  ddb.conf  dhclient.conf  disktab  fbtab  gettytab  group
hosts  hosts.allow  hosts.equiv  libalias.conf  libmap.conf
login.access  login.conf  mac.conf  motd  netconfig  networks
newsyslog.conf  nsswitch.conf  phones  profile  protocols
rc.bsdextended  rc.firewall  remote  rpc  services  sysctl.conf
syslog.conf  termcap.small etc.amd64/ttys amd.map auto_master ftpusers
inetd.conf /usr/src/usr.bin/locate/locate/locate.rc
/usr/src/usr.bin/mail/misc/mail.rc ntp.conf pf.os rc.sendmail csh.cshrc
csh.login csh.logout regdomain.xml  nsmb.conf opieaccess
/usr/share/examples/etc

install: auto_master: No such file or directory
*** Error code 71

Stop.
make[6]: stopped in /usr/src/etc
*** Error code 1

Stop.

mergemaster complains of ..

imb@vm01:/home/imb> sudo mergemaster -FUi

*** Creating the temporary root environment in /var/tmp/temproot
 *** /var/tmp/temproot ready for use
 *** Creating and populating directory structure in /var/tmp/temproot

install: auto_master: No such file or directory

  *** FATAL ERROR: Cannot 'cd' to /usr/src and install files to
  the temproot environment

imb
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Status of OpenSSL 1.1.1

2018-08-04 Thread Benjamin Kaduk

On Fri, Aug 03, 2018 at 07:02:18AM -0400, Eric McCorkle wrote:
> On 08/03/2018 04:44, Warner Losh wrote:
> > 
> > 
> > On Thu, Aug 2, 2018 at 5:45 PM, Benjamin Kaduk  > > wrote:
> > 
> > On Wed, Aug 01, 2018 at 10:05:28AM -0400, Eric McCorkle wrote:
> > > On 08/01/2018 09:02, Warner Losh wrote:
> > > >
> > > >
> > > > On Wed, Aug 1, 2018, 12:31 PM Eric McCorkle
> > mailto:e...@metricspace.net>
> > > > >> wrote:
> > > >
> > > >     Hi folks,
> > > >
> > > >     I'm wondering what's the status of OpenSSL 1.1.1 integration
> > into base?
> > > >     More specifically, is there a repo or a branch that's
> > started the
> > > >     integration?  I'm aware of the wiki page and the list of
> > port build
> > > >     issues, but that seems to be based on replacing the base
> > OpenSSL with a
> > > >     port build (similar to the way one replaces it with LibreSSL).
> > > >
> > > >     I have some work I'd like to do that's gating on sorting out the
> > > >     kernel/loader crypto situation, and I'd very much like to
> > see OpenSSL
> > > >     1.1.1 get merged, so I can start to look into doing that.
> > > >
> > > >
> > > > There are patches to use bear SSL for the loader. OpenSSL is
> > simply too
> > > > large to use due to limits the loader operates under.
> > >
> > > I was going to look into the feasibility of doing something like what
> > > LibreSSL does with portable, where they extract a subset of the full
> > > library designed to be embedded in the kernel, loader, etc.
> > >
> > > I think it ought to be possible to do something like that, but it
> > really
> > > ought to be done in a tree with 1.1.1 integrated.
> > >
> > 
> > It wouldn't be terribly easy or effective, IMO.  OpenSSL wasn't designed
> > with such modularity in mind.
> > 
> > 
> > Others that have tried have found OpenSSL to be way too large for the
> > boot loader and a completely impossible to subset enough to get things
> > small enough due to the intertwingled nature of things.
> 
> To what extent, if any, does this change in 1.1.1, though?
> 

Probably not enough -- while libssl got a bit reorganized, libcrypto hasn't
changed much.

-Ben

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

2018-08-04 Thread Konstantin Belousov

On Sat, Aug 04, 2018 at 08:28:25PM +0100, Warner Losh wrote:
> When I looked at it, I'd assumed there would be VA range we'd assign to the
> PAs in the EFI table that at the loader and kernel would agree on. The DMAP
> does this on x64 and aarch64, but that's not an option for armv7 nor i386.

It is not DMAP.

Amd64 works by assumption that ROM BIOS and its memory are located at
the physical addresses below 4G. Since kernel is always mapped at upper
half of the virtual address space, we hope that identity mapping for RT
memory can be established over the user half of the VA.

Apparently arm64 makes the same assumption.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

2018-08-04 Thread Warner Losh

On Sat, Aug 4, 2018, 8:21 PM Emmanuel Vadot  wrote:

> On Sat, 04 Aug 2018 09:47:11 -0600
> Ian Lepore  wrote:
>
> > On Sat, 2018-08-04 at 18:43 +0300, Konstantin Belousov wrote:
> > > On Sat, Aug 04, 2018 at 09:25:47AM -0600, Ian Lepore wrote:
> > > >
> > > > On Sat, 2018-08-04 at 18:22 +0300, Konstantin Belousov wrote:
> > > > >
> > > > > On Sat, Aug 04, 2018 at 09:58:43AM -0500, Kyle Evans wrote:
> > > > > >
> > > > > >
> > > > > > On Sat, Aug 4, 2018 at 9:51 AM, Ian Lepore 
> wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > [...]
> > > > > > > What do we do on 32-bit arm that has no dmap but may have efi
> > > > > > > runtime
> > > > > > > support?
> > > > > > >
> > > > > > This should probably just be compiled out for !arm64 && !x86 -
> its
> > > > > > sole purpose was to compensate for outdated loader.efi that
> hasn't
> > > > > > done the SetVirtualAddressMap. EFI on 32-bit ARM is "new" enough
> > > > > > that
> > > > > > it shouldn't have this problem.
> > > > > Does EFI on 32bit arm have RT support ?
> > > > I suspect the uboot implementation doesn't, but I can't think of any
> > > > reason why other implementations are not possible/available. In
> > > > particular, even 32bit arm supports virtualization and such an
> > > > environment could provide rt support.
> > > No, I mean, does our kernel has RT support on armv7 ?  I only
> implemented
> > > necessary VM tricks for amd64, then it was ported to arm64, and in both
> > > cases it relies on 64bit address space and specific location of the
> KVA.
> >
> > I didn't realize the kernel implementation was arch-specific. So I
> > guess this comes under the category of "we'll solve that problem when
> > something comes along that provides efi rt for arm32."
>
>  U-Boot doesn't provide a runtime service, I never tested the available
> port of EDK2 for BBB or RPI, I guess they boot the kernel in
> HYP/non-secure mode and install an runtime in secure world along with
> some
>

When I looked at it, I'd assumed there would be VA range we'd assign to the
PAs in the EFI table that at the loader and kernel would agree on. The DMAP
does this on x64 and aarch64, but that's not an option for armv7 nor i386.

Warner

>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

2018-08-04 Thread Emmanuel Vadot

On Sat, 04 Aug 2018 09:47:11 -0600
Ian Lepore  wrote:

> On Sat, 2018-08-04 at 18:43 +0300, Konstantin Belousov wrote:
> > On Sat, Aug 04, 2018 at 09:25:47AM -0600, Ian Lepore wrote:
> > > 
> > > On Sat, 2018-08-04 at 18:22 +0300, Konstantin Belousov wrote:
> > > > 
> > > > On Sat, Aug 04, 2018 at 09:58:43AM -0500, Kyle Evans wrote:
> > > > > 
> > > > > 
> > > > > On Sat, Aug 4, 2018 at 9:51 AM, Ian Lepore  wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> [...]
> > > > > > What do we do on 32-bit arm that has no dmap but may have efi
> > > > > > runtime
> > > > > > support?
> > > > > > 
> > > > > This should probably just be compiled out for !arm64 && !x86 - its
> > > > > sole purpose was to compensate for outdated loader.efi that hasn't
> > > > > done the SetVirtualAddressMap. EFI on 32-bit ARM is "new" enough
> > > > > that
> > > > > it shouldn't have this problem.
> > > > Does EFI on 32bit arm have RT support ?
> > > I suspect the uboot implementation doesn't, but I can't think of any
> > > reason why other implementations are not possible/available. In
> > > particular, even 32bit arm supports virtualization and such an
> > > environment could provide rt support.
> > No, I mean, does our kernel has RT support on armv7 ?  I only implemented
> > necessary VM tricks for amd64, then it was ported to arm64, and in both
> > cases it relies on 64bit address space and specific location of the KVA.
> 
> I didn't realize the kernel implementation was arch-specific. So I
> guess this comes under the category of "we'll solve that problem when
> something comes along that provides efi rt for arm32."

 U-Boot doesn't provide a runtime service, I never tested the available
port of EDK2 for BBB or RPI, I guess they boot the kernel in
HYP/non-secure mode and install an runtime in secure world along with
some psci firmware.

-- 
Emmanuel Vadot  
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

2018-08-04 Thread Ian Lepore

On Sat, 2018-08-04 at 18:43 +0300, Konstantin Belousov wrote:
> On Sat, Aug 04, 2018 at 09:25:47AM -0600, Ian Lepore wrote:
> > 
> > On Sat, 2018-08-04 at 18:22 +0300, Konstantin Belousov wrote:
> > > 
> > > On Sat, Aug 04, 2018 at 09:58:43AM -0500, Kyle Evans wrote:
> > > > 
> > > > 
> > > > On Sat, Aug 4, 2018 at 9:51 AM, Ian Lepore  wrote:
> > > > > 
> > > > > 
> > > > > 
[...]
> > > > > What do we do on 32-bit arm that has no dmap but may have efi
> > > > > runtime
> > > > > support?
> > > > > 
> > > > This should probably just be compiled out for !arm64 && !x86 - its
> > > > sole purpose was to compensate for outdated loader.efi that hasn't
> > > > done the SetVirtualAddressMap. EFI on 32-bit ARM is "new" enough
> > > > that
> > > > it shouldn't have this problem.
> > > Does EFI on 32bit arm have RT support ?
> > I suspect the uboot implementation doesn't, but I can't think of any
> > reason why other implementations are not possible/available. In
> > particular, even 32bit arm supports virtualization and such an
> > environment could provide rt support.
> No, I mean, does our kernel has RT support on armv7 ?  I only implemented
> necessary VM tricks for amd64, then it was ported to arm64, and in both
> cases it relies on 64bit address space and specific location of the KVA.

I didn't realize the kernel implementation was arch-specific. So I
guess this comes under the category of "we'll solve that problem when
something comes along that provides efi rt for arm32."

-- Ian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

2018-08-04 Thread Konstantin Belousov

On Sat, Aug 04, 2018 at 09:25:47AM -0600, Ian Lepore wrote:
> On Sat, 2018-08-04 at 18:22 +0300, Konstantin Belousov wrote:
> > On Sat, Aug 04, 2018 at 09:58:43AM -0500, Kyle Evans wrote:
> > > 
> > > On Sat, Aug 4, 2018 at 9:51 AM, Ian Lepore  wrote:
> > > > 
> > > > On Sat, 2018-08-04 at 08:56 -0500, Kyle Evans wrote:
> > > > > 
> > > > > On Sat, Aug 4, 2018 at 8:13 AM, Konstantin Belousov  > > > > gmail.
> > > > > com> wrote:
> > > > > > 
> > > > > > 
> > > > > > On Sat, Aug 04, 2018 at 08:05:24AM -0500, Kyle Evans wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > On Sat, Aug 4, 2018 at 3:37 AM, Konstantin Belousov  > > > > > > bel@gm
> > > > > > > ail.com> wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On Fri, Aug 03, 2018 at 11:27:02PM -0500, Kyle Evans
> > > > > > > > wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > This seems odd- pmap lock is acquired at [1], then
> > > > > > > > > asserted
> > > > > > > > > shortly
> > > > > > > > > later at [2]... I avoid some of this stuff as well as I
> > > > > > > > > can,
> > > > > > > > > but is it
> > > > > > > > > actually possible for PCPU_GET(...) acquired curpmap to
> > > > > > > > > not
> > > > > > > > > match
> > > > > > > > > curthread->td_proc->p_vmspace->vm_pmap in this context?
> > > > > > > > > 
> > > > > > > > > [1] https://svnweb.freebsd.org/base/head/sys/dev/efidev
> > > > > > > > > /efirt
> > > > > > > > > .c?view=markup#l260
> > > > > > > > > [2] https://svnweb.freebsd.org/base/head/sys/amd64/amd6
> > > > > > > > > 4/efir
> > > > > > > > > t_machdep.c?view=markup#l254
> > > > > > > > There could be that curpcpu not yet synced with proc0
> > > > > > > > pmap.  It
> > > > > > > > could be
> > > > > > > > fixed.
> > > > > > > > 
> > > > > > > > But it is not clear to me why efi_arch_enter() is called
> > > > > > > > there.  I see
> > > > > > > > the check for GetTime belonging to the range described by
> > > > > > > > a map
> > > > > > > > descriptor.
> > > > > > > > I do not see why do you need an enter into the EFI
> > > > > > > > context for
> > > > > > > > comparing
> > > > > > > > integers.
> > > > > > > This probably could have been documented better, but
> > > > > > > efi_runtime
> > > > > > > pointer may (always?) point into runtime service memory
> > > > > > > that
> > > > > > > isn't
> > > > > > > valid/available at that point, so we get a fault and panic
> > > > > > > when
> > > > > > > dereferencing it to grab rt_gettime address. We ran into
> > > > > > > this
> > > > > > > wall
> > > > > > > when adding the check originally.
> > > > > > Wouldn't it be enough to access it by translating physical
> > > > > > address
> > > > > > into
> > > > > > DMAP ?
> > > > > Ah, sure, sure. [1] is proper form, yeah?
> > > > > 
> > > > > [1] https://people.freebsd.org/~kevans/efi-dmap.diff
> > > > What do we do on 32-bit arm that has no dmap but may have efi
> > > > runtime
> > > > support?
> > > > 
> > > This should probably just be compiled out for !arm64 && !x86 - its
> > > sole purpose was to compensate for outdated loader.efi that hasn't
> > > done the SetVirtualAddressMap. EFI on 32-bit ARM is "new" enough
> > > that
> > > it shouldn't have this problem.
> > Does EFI on 32bit arm have RT support ?
> 
> I suspect the uboot implementation doesn't, but I can't think of any
> reason why other implementations are not possible/available. In
> particular, even 32bit arm supports virtualization and such an
> environment could provide rt support.

No, I mean, does our kernel has RT support on armv7 ?  I only implemented
necessary VM tricks for amd64, then it was ported to arm64, and in both
cases it relies on 64bit address space and specific location of the KVA.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

2018-08-04 Thread Ian Lepore

On Sat, 2018-08-04 at 18:22 +0300, Konstantin Belousov wrote:
> On Sat, Aug 04, 2018 at 09:58:43AM -0500, Kyle Evans wrote:
> > 
> > On Sat, Aug 4, 2018 at 9:51 AM, Ian Lepore  wrote:
> > > 
> > > On Sat, 2018-08-04 at 08:56 -0500, Kyle Evans wrote:
> > > > 
> > > > On Sat, Aug 4, 2018 at 8:13 AM, Konstantin Belousov  > > > gmail.
> > > > com> wrote:
> > > > > 
> > > > > 
> > > > > On Sat, Aug 04, 2018 at 08:05:24AM -0500, Kyle Evans wrote:
> > > > > > 
> > > > > > 
> > > > > > On Sat, Aug 4, 2018 at 3:37 AM, Konstantin Belousov  > > > > > bel@gm
> > > > > > ail.com> wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > On Fri, Aug 03, 2018 at 11:27:02PM -0500, Kyle Evans
> > > > > > > wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > This seems odd- pmap lock is acquired at [1], then
> > > > > > > > asserted
> > > > > > > > shortly
> > > > > > > > later at [2]... I avoid some of this stuff as well as I
> > > > > > > > can,
> > > > > > > > but is it
> > > > > > > > actually possible for PCPU_GET(...) acquired curpmap to
> > > > > > > > not
> > > > > > > > match
> > > > > > > > curthread->td_proc->p_vmspace->vm_pmap in this context?
> > > > > > > > 
> > > > > > > > [1] https://svnweb.freebsd.org/base/head/sys/dev/efidev
> > > > > > > > /efirt
> > > > > > > > .c?view=markup#l260
> > > > > > > > [2] https://svnweb.freebsd.org/base/head/sys/amd64/amd6
> > > > > > > > 4/efir
> > > > > > > > t_machdep.c?view=markup#l254
> > > > > > > There could be that curpcpu not yet synced with proc0
> > > > > > > pmap.  It
> > > > > > > could be
> > > > > > > fixed.
> > > > > > > 
> > > > > > > But it is not clear to me why efi_arch_enter() is called
> > > > > > > there.  I see
> > > > > > > the check for GetTime belonging to the range described by
> > > > > > > a map
> > > > > > > descriptor.
> > > > > > > I do not see why do you need an enter into the EFI
> > > > > > > context for
> > > > > > > comparing
> > > > > > > integers.
> > > > > > This probably could have been documented better, but
> > > > > > efi_runtime
> > > > > > pointer may (always?) point into runtime service memory
> > > > > > that
> > > > > > isn't
> > > > > > valid/available at that point, so we get a fault and panic
> > > > > > when
> > > > > > dereferencing it to grab rt_gettime address. We ran into
> > > > > > this
> > > > > > wall
> > > > > > when adding the check originally.
> > > > > Wouldn't it be enough to access it by translating physical
> > > > > address
> > > > > into
> > > > > DMAP ?
> > > > Ah, sure, sure. [1] is proper form, yeah?
> > > > 
> > > > [1] https://people.freebsd.org/~kevans/efi-dmap.diff
> > > What do we do on 32-bit arm that has no dmap but may have efi
> > > runtime
> > > support?
> > > 
> > This should probably just be compiled out for !arm64 && !x86 - its
> > sole purpose was to compensate for outdated loader.efi that hasn't
> > done the SetVirtualAddressMap. EFI on 32-bit ARM is "new" enough
> > that
> > it shouldn't have this problem.
> Does EFI on 32bit arm have RT support ?

I suspect the uboot implementation doesn't, but I can't think of any
reason why other implementations are not possible/available. In
particular, even 32bit arm supports virtualization and such an
environment could provide rt support.

-- Ian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

2018-08-04 Thread Konstantin Belousov

On Sat, Aug 04, 2018 at 09:58:43AM -0500, Kyle Evans wrote:
> On Sat, Aug 4, 2018 at 9:51 AM, Ian Lepore  wrote:
> > On Sat, 2018-08-04 at 08:56 -0500, Kyle Evans wrote:
> >> On Sat, Aug 4, 2018 at 8:13 AM, Konstantin Belousov  >> com> wrote:
> >> >
> >> > On Sat, Aug 04, 2018 at 08:05:24AM -0500, Kyle Evans wrote:
> >> > >
> >> > > On Sat, Aug 4, 2018 at 3:37 AM, Konstantin Belousov  >> > > ail.com> wrote:
> >> > > >
> >> > > > On Fri, Aug 03, 2018 at 11:27:02PM -0500, Kyle Evans wrote:
> >> > > > >
> >> > > > >
> >> > > > > This seems odd- pmap lock is acquired at [1], then asserted
> >> > > > > shortly
> >> > > > > later at [2]... I avoid some of this stuff as well as I can,
> >> > > > > but is it
> >> > > > > actually possible for PCPU_GET(...) acquired curpmap to not
> >> > > > > match
> >> > > > > curthread->td_proc->p_vmspace->vm_pmap in this context?
> >> > > > >
> >> > > > > [1] https://svnweb.freebsd.org/base/head/sys/dev/efidev/efirt
> >> > > > > .c?view=markup#l260
> >> > > > > [2] https://svnweb.freebsd.org/base/head/sys/amd64/amd64/efir
> >> > > > > t_machdep.c?view=markup#l254
> >> > > > There could be that curpcpu not yet synced with proc0 pmap.  It
> >> > > > could be
> >> > > > fixed.
> >> > > >
> >> > > > But it is not clear to me why efi_arch_enter() is called
> >> > > > there.  I see
> >> > > > the check for GetTime belonging to the range described by a map
> >> > > > descriptor.
> >> > > > I do not see why do you need an enter into the EFI context for
> >> > > > comparing
> >> > > > integers.
> >> > > This probably could have been documented better, but efi_runtime
> >> > > pointer may (always?) point into runtime service memory that
> >> > > isn't
> >> > > valid/available at that point, so we get a fault and panic when
> >> > > dereferencing it to grab rt_gettime address. We ran into this
> >> > > wall
> >> > > when adding the check originally.
> >> > Wouldn't it be enough to access it by translating physical address
> >> > into
> >> > DMAP ?
> >> Ah, sure, sure. [1] is proper form, yeah?
> >>
> >> [1] https://people.freebsd.org/~kevans/efi-dmap.diff
> >
> > What do we do on 32-bit arm that has no dmap but may have efi runtime
> > support?
> >
> 
> This should probably just be compiled out for !arm64 && !x86 - its
> sole purpose was to compensate for outdated loader.efi that hasn't
> done the SetVirtualAddressMap. EFI on 32-bit ARM is "new" enough that
> it shouldn't have this problem.
Does EFI on 32bit arm have RT support ?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

2018-08-04 Thread Kyle Evans

On Sat, Aug 4, 2018 at 9:51 AM, Ian Lepore  wrote:
> On Sat, 2018-08-04 at 08:56 -0500, Kyle Evans wrote:
>> On Sat, Aug 4, 2018 at 8:13 AM, Konstantin Belousov > com> wrote:
>> >
>> > On Sat, Aug 04, 2018 at 08:05:24AM -0500, Kyle Evans wrote:
>> > >
>> > > On Sat, Aug 4, 2018 at 3:37 AM, Konstantin Belousov > > > ail.com> wrote:
>> > > >
>> > > > On Fri, Aug 03, 2018 at 11:27:02PM -0500, Kyle Evans wrote:
>> > > > >
>> > > > >
>> > > > > This seems odd- pmap lock is acquired at [1], then asserted
>> > > > > shortly
>> > > > > later at [2]... I avoid some of this stuff as well as I can,
>> > > > > but is it
>> > > > > actually possible for PCPU_GET(...) acquired curpmap to not
>> > > > > match
>> > > > > curthread->td_proc->p_vmspace->vm_pmap in this context?
>> > > > >
>> > > > > [1] https://svnweb.freebsd.org/base/head/sys/dev/efidev/efirt
>> > > > > .c?view=markup#l260
>> > > > > [2] https://svnweb.freebsd.org/base/head/sys/amd64/amd64/efir
>> > > > > t_machdep.c?view=markup#l254
>> > > > There could be that curpcpu not yet synced with proc0 pmap.  It
>> > > > could be
>> > > > fixed.
>> > > >
>> > > > But it is not clear to me why efi_arch_enter() is called
>> > > > there.  I see
>> > > > the check for GetTime belonging to the range described by a map
>> > > > descriptor.
>> > > > I do not see why do you need an enter into the EFI context for
>> > > > comparing
>> > > > integers.
>> > > This probably could have been documented better, but efi_runtime
>> > > pointer may (always?) point into runtime service memory that
>> > > isn't
>> > > valid/available at that point, so we get a fault and panic when
>> > > dereferencing it to grab rt_gettime address. We ran into this
>> > > wall
>> > > when adding the check originally.
>> > Wouldn't it be enough to access it by translating physical address
>> > into
>> > DMAP ?
>> Ah, sure, sure. [1] is proper form, yeah?
>>
>> [1] https://people.freebsd.org/~kevans/efi-dmap.diff
>
> What do we do on 32-bit arm that has no dmap but may have efi runtime
> support?
>

This should probably just be compiled out for !arm64 && !x86 - its
sole purpose was to compensate for outdated loader.efi that hasn't
done the SetVirtualAddressMap. EFI on 32-bit ARM is "new" enough that
it shouldn't have this problem.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

2018-08-04 Thread Ian Lepore

On Sat, 2018-08-04 at 08:56 -0500, Kyle Evans wrote:
> On Sat, Aug 4, 2018 at 8:13 AM, Konstantin Belousov  com> wrote:
> > 
> > On Sat, Aug 04, 2018 at 08:05:24AM -0500, Kyle Evans wrote:
> > > 
> > > On Sat, Aug 4, 2018 at 3:37 AM, Konstantin Belousov  > > ail.com> wrote:
> > > > 
> > > > On Fri, Aug 03, 2018 at 11:27:02PM -0500, Kyle Evans wrote:
> > > > > 
> > > > > 
> > > > > This seems odd- pmap lock is acquired at [1], then asserted
> > > > > shortly
> > > > > later at [2]... I avoid some of this stuff as well as I can,
> > > > > but is it
> > > > > actually possible for PCPU_GET(...) acquired curpmap to not
> > > > > match
> > > > > curthread->td_proc->p_vmspace->vm_pmap in this context?
> > > > > 
> > > > > [1] https://svnweb.freebsd.org/base/head/sys/dev/efidev/efirt
> > > > > .c?view=markup#l260
> > > > > [2] https://svnweb.freebsd.org/base/head/sys/amd64/amd64/efir
> > > > > t_machdep.c?view=markup#l254
> > > > There could be that curpcpu not yet synced with proc0 pmap.  It
> > > > could be
> > > > fixed.
> > > > 
> > > > But it is not clear to me why efi_arch_enter() is called
> > > > there.  I see
> > > > the check for GetTime belonging to the range described by a map
> > > > descriptor.
> > > > I do not see why do you need an enter into the EFI context for
> > > > comparing
> > > > integers.
> > > This probably could have been documented better, but efi_runtime
> > > pointer may (always?) point into runtime service memory that
> > > isn't
> > > valid/available at that point, so we get a fault and panic when
> > > dereferencing it to grab rt_gettime address. We ran into this
> > > wall
> > > when adding the check originally.
> > Wouldn't it be enough to access it by translating physical address
> > into
> > DMAP ?
> Ah, sure, sure. [1] is proper form, yeah?
> 
> [1] https://people.freebsd.org/~kevans/efi-dmap.diff

What do we do on 32-bit arm that has no dmap but may have efi runtime
support?

-- Ian

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

2018-08-04 Thread Konstantin Belousov

On Sat, Aug 04, 2018 at 08:56:58AM -0500, Kyle Evans wrote:
> On Sat, Aug 4, 2018 at 8:13 AM, Konstantin Belousov  
> wrote:
> > On Sat, Aug 04, 2018 at 08:05:24AM -0500, Kyle Evans wrote:
> >> On Sat, Aug 4, 2018 at 3:37 AM, Konstantin Belousov  
> >> wrote:
> >> > On Fri, Aug 03, 2018 at 11:27:02PM -0500, Kyle Evans wrote:
> >> >>
> >> >> This seems odd- pmap lock is acquired at [1], then asserted shortly
> >> >> later at [2]... I avoid some of this stuff as well as I can, but is it
> >> >> actually possible for PCPU_GET(...) acquired curpmap to not match
> >> >> curthread->td_proc->p_vmspace->vm_pmap in this context?
> >> >>
> >> >> [1] 
> >> >> https://svnweb.freebsd.org/base/head/sys/dev/efidev/efirt.c?view=markup#l260
> >> >> [2] 
> >> >> https://svnweb.freebsd.org/base/head/sys/amd64/amd64/efirt_machdep.c?view=markup#l254
> >> > There could be that curpcpu not yet synced with proc0 pmap.  It could be
> >> > fixed.
> >> >
> >> > But it is not clear to me why efi_arch_enter() is called there.  I see
> >> > the check for GetTime belonging to the range described by a map 
> >> > descriptor.
> >> > I do not see why do you need an enter into the EFI context for comparing
> >> > integers.
> >>
> >> This probably could have been documented better, but efi_runtime
> >> pointer may (always?) point into runtime service memory that isn't
> >> valid/available at that point, so we get a fault and panic when
> >> dereferencing it to grab rt_gettime address. We ran into this wall
> >> when adding the check originally.
> > Wouldn't it be enough to access it by translating physical address into
> > DMAP ?
> 
> Ah, sure, sure. [1] is proper form, yeah?
> 
> [1] https://people.freebsd.org/~kevans/efi-dmap.diff

I would brace it with #ifdef PHYS_TO_DMAP, #error otherwise.
Also, it might make sense to check against dmaplimit as well (on arm64
it is called PHYS_IN_DMAP(), sight).

So it might make sense to define MD function in arch/efirt_machdep.c
to translate table' address into the KVA.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Linux process causes kernel panic

2018-08-04 Thread Konstantin Belousov

On Sat, Aug 04, 2018 at 01:12:17PM +0100, Johannes Lundberg wrote:
> No panic over night with that tunable so it seems you're on the right
> track.

Please try this, on top of r337316.

diff --git a/sys/amd64/linux/linux_machdep.c b/sys/amd64/linux/linux_machdep.c
index 6c5b014853f..434ea0eac07 100644
--- a/sys/amd64/linux/linux_machdep.c
+++ b/sys/amd64/linux/linux_machdep.c
@@ -78,6 +78,9 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 
+#include 
+#include 
+
 #include 
 #include 
 #include 
@@ -88,8 +91,6 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 
-#include 
-
 int
 linux_execve(struct thread *td, struct linux_execve_args *args)
 {
@@ -276,3 +277,48 @@ linux_set_cloned_tls(struct thread *td, void *desc)
 
return (0);
 }
+
+int futex_xchgl_nosmap(int oparg, uint32_t *uaddr, int *oldval);
+int futex_xchgl_smap(int oparg, uint32_t *uaddr, int *oldval);
+DEFINE_IFUNC(, int, futex_xchgl, (int, uint32_t *, int *), static)
+{
+
+   return ((cpu_stdext_feature & CPUID_STDEXT_SMAP) != 0 ?
+   futex_xchgl_smap : futex_xchgl_nosmap);
+}
+
+int futex_addl_nosmap(int oparg, uint32_t *uaddr, int *oldval);
+int futex_addl_smap(int oparg, uint32_t *uaddr, int *oldval);
+DEFINE_IFUNC(, int, futex_addl, (int, uint32_t *, int *), static)
+{
+
+   return ((cpu_stdext_feature & CPUID_STDEXT_SMAP) != 0 ?
+   futex_addl_smap : futex_addl_nosmap);
+}
+
+int futex_orl_nosmap(int oparg, uint32_t *uaddr, int *oldval);
+int futex_orl_smap(int oparg, uint32_t *uaddr, int *oldval);
+DEFINE_IFUNC(, int, futex_orl, (int, uint32_t *, int *), static)
+{
+
+   return ((cpu_stdext_feature & CPUID_STDEXT_SMAP) != 0 ?
+   futex_orl_smap : futex_orl_nosmap);
+}
+
+int futex_andl_nosmap(int oparg, uint32_t *uaddr, int *oldval);
+int futex_andl_smap(int oparg, uint32_t *uaddr, int *oldval);
+DEFINE_IFUNC(, int, futex_andl, (int, uint32_t *, int *), static)
+{
+
+   return ((cpu_stdext_feature & CPUID_STDEXT_SMAP) != 0 ?
+   futex_andl_smap : futex_andl_nosmap);
+}
+
+int futex_xorl_nosmap(int oparg, uint32_t *uaddr, int *oldval);
+int futex_xorl_smap(int oparg, uint32_t *uaddr, int *oldval);
+DEFINE_IFUNC(, int, futex_xorl, (int, uint32_t *, int *), static)
+{
+
+   return ((cpu_stdext_feature & CPUID_STDEXT_SMAP) != 0 ?
+   futex_xorl_smap : futex_xorl_nosmap);
+}
diff --git a/sys/amd64/linux/linux_support.s b/sys/amd64/linux/linux_support.s
index a9f02160be2..391f76414f2 100644
--- a/sys/amd64/linux/linux_support.s
+++ b/sys/amd64/linux/linux_support.s
@@ -38,7 +38,7 @@ futex_fault:
movl$-EFAULT,%eax
ret
 
-ENTRY(futex_xchgl)
+ENTRY(futex_xchgl_nosmap)
movqPCPU(CURPCB),%r8
movq$futex_fault,PCB_ONFAULT(%r8)
movq$VM_MAXUSER_ADDRESS-4,%rax
@@ -49,25 +49,58 @@ ENTRY(futex_xchgl)
xorl%eax,%eax
movq%rax,PCB_ONFAULT(%r8)
ret
-END(futex_xchgl)
+END(futex_xchgl_nosmap)
 
-ENTRY(futex_addl)
+ENTRY(futex_xchgl_smap)
movqPCPU(CURPCB),%r8
movq$futex_fault,PCB_ONFAULT(%r8)
movq$VM_MAXUSER_ADDRESS-4,%rax
cmpq%rax,%rsi
ja  futex_fault
+   stac
+   xchgl   %edi,(%rsi)
+   clac
+   movl%edi,(%rdx)
+   xorl%eax,%eax
+   movq%rax,PCB_ONFAULT(%r8)
+   ret
+END(futex_xchgl_smap)
+
+ENTRY(futex_addl_nosmap)
+   movqPCPU(CURPCB),%r8
+   movq$futex_fault,PCB_ONFAULT(%r8)
+   movq$VM_MAXUSER_ADDRESS-4,%rax
+   cmpq%rax,%rsi
+   ja  futex_fault
+#ifdef SMP
+   lock
+#endif
+   xaddl   %edi,(%rsi)
+   movl%edi,(%rdx)
+   xorl%eax,%eax
+   movq%rax,PCB_ONFAULT(%r8)
+   ret
+END(futex_addl_nosmap)
+
+ENTRY(futex_addl_smap)
+   movqPCPU(CURPCB),%r8
+   movq$futex_fault,PCB_ONFAULT(%r8)
+   movq$VM_MAXUSER_ADDRESS-4,%rax
+   cmpq%rax,%rsi
+   ja  futex_fault
+   stac
 #ifdef SMP
lock
 #endif
xaddl   %edi,(%rsi)
+   clac
movl%edi,(%rdx)
xorl%eax,%eax
movq%rax,PCB_ONFAULT(%r8)
ret
-END(futex_addl)
+END(futex_addl_smap)
 
-ENTRY(futex_orl)
+ENTRY(futex_orl_nosmap)
movqPCPU(CURPCB),%r8
movq$futex_fault,PCB_ONFAULT(%r8)
movq$VM_MAXUSER_ADDRESS-4,%rax
@@ -85,9 +118,31 @@ ENTRY(futex_orl)
xorl%eax,%eax
movq%rax,PCB_ONFAULT(%r8)
ret
-END(futex_orl)
+END(futex_orl_nosmap)
 
-ENTRY(futex_andl)
+ENTRY(futex_orl_smap)
+   movqPCPU(CURPCB),%r8
+   movq$futex_fault,PCB_ONFAULT(%r8)
+   movq$VM_MAXUSER_ADDRESS-4,%rax
+   cmpq%rax,%rsi
+   ja  futex_fault
+   movl(%rsi),%eax
+1: movl%eax,%ecx
+   orl %edi,%ecx
+   stac
+#ifdef SMP
+   lock
+#endif
+   cmpxchgl %ecx,(%rsi)
+   clac
+   jnz 1b
+   movl%eax,(%rdx)
+   xorl%eax,%eax
+   movq%rax,PCB_ONFAULT(%r8)
+   ret
+

Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

2018-08-04 Thread Kyle Evans

On Sat, Aug 4, 2018 at 8:13 AM, Konstantin Belousov  wrote:
> On Sat, Aug 04, 2018 at 08:05:24AM -0500, Kyle Evans wrote:
>> On Sat, Aug 4, 2018 at 3:37 AM, Konstantin Belousov  
>> wrote:
>> > On Fri, Aug 03, 2018 at 11:27:02PM -0500, Kyle Evans wrote:
>> >>
>> >> This seems odd- pmap lock is acquired at [1], then asserted shortly
>> >> later at [2]... I avoid some of this stuff as well as I can, but is it
>> >> actually possible for PCPU_GET(...) acquired curpmap to not match
>> >> curthread->td_proc->p_vmspace->vm_pmap in this context?
>> >>
>> >> [1] 
>> >> https://svnweb.freebsd.org/base/head/sys/dev/efidev/efirt.c?view=markup#l260
>> >> [2] 
>> >> https://svnweb.freebsd.org/base/head/sys/amd64/amd64/efirt_machdep.c?view=markup#l254
>> > There could be that curpcpu not yet synced with proc0 pmap.  It could be
>> > fixed.
>> >
>> > But it is not clear to me why efi_arch_enter() is called there.  I see
>> > the check for GetTime belonging to the range described by a map descriptor.
>> > I do not see why do you need an enter into the EFI context for comparing
>> > integers.
>>
>> This probably could have been documented better, but efi_runtime
>> pointer may (always?) point into runtime service memory that isn't
>> valid/available at that point, so we get a fault and panic when
>> dereferencing it to grab rt_gettime address. We ran into this wall
>> when adding the check originally.
> Wouldn't it be enough to access it by translating physical address into
> DMAP ?

Ah, sure, sure. [1] is proper form, yeah?

[1] https://people.freebsd.org/~kevans/efi-dmap.diff
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: "Can't load kernel" after r337232 -> r337285 update (amd64)

2018-08-04 Thread David Wolfskill

On Sat, Aug 04, 2018 at 02:31:56PM +0300, Toomas Soome wrote:
> ... 
> It probably r337271, could you check https://reviews.freebsd.org/D16588? 
>  
> 
> rgds,
> toomas
> 

Success:

FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #69  
r337285M/337285:1200076: Sat Aug  4 03:55:21 PDT 2018 
r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64

Thank you!  I have updated the review to mention this, as well.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Trump is gaslighting us: https://www.bbc.com/news/world-us-canada-44959300

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

2018-08-04 Thread Konstantin Belousov

On Sat, Aug 04, 2018 at 08:05:24AM -0500, Kyle Evans wrote:
> On Sat, Aug 4, 2018 at 3:37 AM, Konstantin Belousov  
> wrote:
> > On Fri, Aug 03, 2018 at 11:27:02PM -0500, Kyle Evans wrote:
> >>
> >> This seems odd- pmap lock is acquired at [1], then asserted shortly
> >> later at [2]... I avoid some of this stuff as well as I can, but is it
> >> actually possible for PCPU_GET(...) acquired curpmap to not match
> >> curthread->td_proc->p_vmspace->vm_pmap in this context?
> >>
> >> [1] 
> >> https://svnweb.freebsd.org/base/head/sys/dev/efidev/efirt.c?view=markup#l260
> >> [2] 
> >> https://svnweb.freebsd.org/base/head/sys/amd64/amd64/efirt_machdep.c?view=markup#l254
> > There could be that curpcpu not yet synced with proc0 pmap.  It could be
> > fixed.
> >
> > But it is not clear to me why efi_arch_enter() is called there.  I see
> > the check for GetTime belonging to the range described by a map descriptor.
> > I do not see why do you need an enter into the EFI context for comparing
> > integers.
> 
> This probably could have been documented better, but efi_runtime
> pointer may (always?) point into runtime service memory that isn't
> valid/available at that point, so we get a fault and panic when
> dereferencing it to grab rt_gettime address. We ran into this wall
> when adding the check originally.
Wouldn't it be enough to access it by translating physical address into
DMAP ?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

2018-08-04 Thread Kyle Evans

On Sat, Aug 4, 2018 at 3:37 AM, Konstantin Belousov  wrote:
> On Fri, Aug 03, 2018 at 11:27:02PM -0500, Kyle Evans wrote:
>>
>> This seems odd- pmap lock is acquired at [1], then asserted shortly
>> later at [2]... I avoid some of this stuff as well as I can, but is it
>> actually possible for PCPU_GET(...) acquired curpmap to not match
>> curthread->td_proc->p_vmspace->vm_pmap in this context?
>>
>> [1] 
>> https://svnweb.freebsd.org/base/head/sys/dev/efidev/efirt.c?view=markup#l260
>> [2] 
>> https://svnweb.freebsd.org/base/head/sys/amd64/amd64/efirt_machdep.c?view=markup#l254
> There could be that curpcpu not yet synced with proc0 pmap.  It could be
> fixed.
>
> But it is not clear to me why efi_arch_enter() is called there.  I see
> the check for GetTime belonging to the range described by a map descriptor.
> I do not see why do you need an enter into the EFI context for comparing
> integers.

This probably could have been documented better, but efi_runtime
pointer may (always?) point into runtime service memory that isn't
valid/available at that point, so we get a fault and panic when
dereferencing it to grab rt_gettime address. We ran into this wall
when adding the check originally.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: "Can't load kernel" after r337232 -> r337285 update (amd64)

2018-08-04 Thread David Wolfskill

On Sat, Aug 04, 2018 at 02:31:56PM +0300, Toomas Soome wrote:
> ... 
> 
> It probably r337271, could you check https://reviews.freebsd.org/D16588? 
>  
> 
> rgds,
> toomas
> 

Thanks; I'll give that a try & report back.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Trump is gaslighting us: https://www.bbc.com/news/world-us-canada-44959300

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: "Can't load kernel" after r337232 -> r337285 update (amd64)

2018-08-04 Thread Toomas Soome




> On 4 Aug 2018, at 14:19, David Wolfskill  wrote:
> 
> Yesterday, the daily build/smoike-test of head yielded:
> 
> FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #68  
> r337232M/337232:1200076: Fri Aug  3 03:52:52 PDT 2018 
> r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  
> amd64
> 
> (This is on my laptop; my build machine is busy doing the Saturday
> "catch-up" packages build in partial preparation for tomorrow.)
> 
> This morning, after what seemed to be an "uneventful" build/install...
> well, I didn't even get a loader menu.  (This was on the slice that
> uses the Forth loader.  I haven't updated the slice that uses the
> Lua loader today.)
> 
> Extracting the uname string from the installed kernel taht won't
> load, I see:
> 
> FreeBSD 12.0-CURRENT #69  r337285M/337285:1200076: Sat Aug  4 03:55:21 PDT 
> 2018
>r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY
> FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 
> 6.0.1)
> 
> Links to various bits of possible interest are at
>  -- in particular, the
> 
> | amd64
> | 
> | laptop head uname list dmesg build typescript -- updated daily 
> 
> part -- though the links are for the last successfully-booted kernel,
> which would be yesterday's (r337232).
> 
> I can boot from other slices OK -- as I type, I'm on the stable/11 slice:
> FreeBSD g1-215.catwhisker.org 11.2-STABLE FreeBSD 11.2-STABLE #699  
> r337280M/337285:1102501: Sat Aug  4 03:38:52 PDT 2018 
> r...@g1-215.catwhisker.org:/common/S1/obj/usr/src/sys/CANARY  amd64
> 
> so given a clue or two, I may be able to do some poking & report results.
> 
> Peace,
> david
> -- 
> David H. Wolfskillda...@catwhisker.org
> Trump is gaslighting us: https://www.bbc.com/news/world-us-canada-44959300
> 
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.


It probably r337271, could you check https://reviews.freebsd.org/D16588? 
 

rgds,
toomas


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Linux process causes kernel panic

2018-08-04 Thread Johannes Lundberg

On Fri, Aug 3, 2018 at 9:43 PM Konstantin Belousov 
wrote:

> On Fri, Aug 03, 2018 at 09:26:08PM +0100, Johannes Lundberg wrote:
> > Hi
> >
> > After install new kernel+world built from today's checkout I keep getting
> > the same crash over and over. Never had this problem before. The previous
> > kernel was from 3 weeks ago.
> >
> > Looks familiar to anyone?
> >
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 0; apic id = 00
> > fault virtual address= 0xfffe665c
> > fault code= supervisor write data, protection violation
> > instruction pointer= 0x20:0x82282db3
> > stack pointer= 0x0:0xfe004c74c8c8
> > frame pointer= 0x0:0xfe004c74c980
> > code segment= base 0x0, limit 0xf, type 0x1b
> > = DPL 0, pres 1, long 1, def32 0, gran 1
> > processor eflags= interrupt enabled, resume, IOPL = 0
> > current process= 1579 (wcgrid_zika_vina_7.)
> > trap number= 12
> > panic: page fault
> > cpuid = 0
> > time = 1533327428
> > KDB: stack backtrace:
> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> > 0xfe004c74c580
> > vpanic() at vpanic+0x1a3/frame 0xfe004c74c5e0
> > panic() at panic+0x43/frame 0xfe004c74c640
> > trap_fatal() at trap_fatal+0x35f/frame 0xfe004c74c690
> > trap_pfault() at trap_pfault+0x62/frame 0xfe004c74c6e0
> > trap() at trap+0x2ba/frame 0xfe004c74c7f0
> > calltrap() at calltrap+0x8/frame 0xfe004c74c7f0
> > --- trap 0xc, rip = 0x82282db3, rsp = 0xfe004c74c8c8, rbp =
> > 0xfe004c74c980 ---
> > futex_xchgl() at futex_xchgl+0x23/frame 0xfe004c74c980
> > ia32_syscall() at ia32_syscall+0x29f/frame 0xfe004c74cab0
> > int0x80_syscall_common() at int0x80_syscall_common+0x9c/frame 0x401
> > Uptime: 7m29s
> > Dumping 411 out of 8056
> MB:..4%..12%..24%..32%..43%..51%..63%..74%..82%..94%
> > Dump complete
>
> Post first 40 lines from the verbose dmesg boot of your machine.
>
> I have a guess what is going on, I need the dmesg to confirm.
> If my guess is correct, you can use a workaround by setting the
> "hw.cpu_stdext_disable=0x0010" tunable at the loader prompt for now.
>

No panic over night with that tunable so it seems you're on the right
track.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

"Can't load kernel" after r337232 -> r337285 update (amd64)

2018-08-04 Thread David Wolfskill

Yesterday, the daily build/smoike-test of head yielded:

FreeBSD g1-215.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #68  
r337232M/337232:1200076: Fri Aug  3 03:52:52 PDT 2018 
r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64

(This is on my laptop; my build machine is busy doing the Saturday
"catch-up" packages build in partial preparation for tomorrow.)

This morning, after what seemed to be an "uneventful" build/install...
well, I didn't even get a loader menu.  (This was on the slice that
uses the Forth loader.  I haven't updated the slice that uses the
Lua loader today.)

Extracting the uname string from the installed kernel taht won't
load, I see:

FreeBSD 12.0-CURRENT #69  r337285M/337285:1200076: Sat Aug  4 03:55:21 PDT 2018
r...@g1-215.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY
FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 
6.0.1)

Links to various bits of possible interest are at
 -- in particular, the

| amd64
| 
| laptop head uname list dmesg build typescript -- updated daily 

part -- though the links are for the last successfully-booted kernel,
which would be yesterday's (r337232).

I can boot from other slices OK -- as I type, I'm on the stable/11 slice:
FreeBSD g1-215.catwhisker.org 11.2-STABLE FreeBSD 11.2-STABLE #699  
r337280M/337285:1102501: Sat Aug  4 03:38:52 PDT 2018 
r...@g1-215.catwhisker.org:/common/S1/obj/usr/src/sys/CANARY  amd64

so given a clue or two, I may be able to do some poking & report results.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Trump is gaslighting us: https://www.bbc.com/news/world-us-canada-44959300

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

2018-08-04 Thread Konstantin Belousov

On Fri, Aug 03, 2018 at 11:27:02PM -0500, Kyle Evans wrote:
> On Fri, Aug 3, 2018 at 10:10 PM, Eitan Adler  wrote:
> > Hi all,
> >
> > After installing the latest current kernel I get the following panic:
> >
> > panic: mutex pmap not owned at ... efirt_machdep.c:255
> > cpuid =3
> > time = 1
> > ...
> > mtx_assert()
> > efi_arch_enter()
> > efirt_modevents()
> > module_register_init()
> > mi_startup()
> > btext()
> >
> 
> This seems odd- pmap lock is acquired at [1], then asserted shortly
> later at [2]... I avoid some of this stuff as well as I can, but is it
> actually possible for PCPU_GET(...) acquired curpmap to not match
> curthread->td_proc->p_vmspace->vm_pmap in this context?
> 
> [1] 
> https://svnweb.freebsd.org/base/head/sys/dev/efidev/efirt.c?view=markup#l260
> [2] 
> https://svnweb.freebsd.org/base/head/sys/amd64/amd64/efirt_machdep.c?view=markup#l254
There could be that curpcpu not yet synced with proc0 pmap.  It could be
fixed.

But it is not clear to me why efi_arch_enter() is called there.  I see
the check for GetTime belonging to the range described by a map descriptor.
I do not see why do you need an enter into the EFI context for comparing
integers.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: svn commit: r337340 - in head: [This broke all ci.freebsd.org 's FreeBSD-head-*-build 's, clang based and gcc 4.2.1 based]

Re: svn commit: r337340 - in head: [This broke all ci.freebsd.org 's FreeBSD-head-*-build 's, clang based and gcc 4.2.1 based]

Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

Re: svn commit: r337340 - in head: [This broke all ci.freebsd.org 's FreeBSD-head-*-build 's, clang based and gcc 4.2.1 based]

install: auto_master: No such file or directory

Re: SVN r337340 breaks installworld and mergemaster

programs like gdb core dump

SVN r337340 breaks installworld and mergemaster

Re: Status of OpenSSL 1.1.1

Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

Re: Linux process causes kernel panic

Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

Re: "Can't load kernel" after r337232 -> r337285 update (amd64)

Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

Re: "Can't load kernel" after r337232 -> r337285 update (amd64)

Re: "Can't load kernel" after r337232 -> r337285 update (amd64)

Re: Linux process causes kernel panic

"Can't load kernel" after r337232 -> r337285 update (amd64)

Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

29 matches

Site Navigation

Mail list logo

Footer information