Re: usb rtwn not loaded properly at boot

2018-09-19 Thread Johannes Lundberg 
On Wed, Sep 19, 2018 at 1:40 AM Patrick McMunn 
wrote:

> I filed a bug about this issue:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231441 I have
> encountered
> it with the run USB wireless driver. I haven't tested it with ethernet.
> Does this issue only affect wireless devices, only certain drivers, or all
> network connections?
>

It looks like the regexps are messed up. In this case none of those wifi
and scsi driver would do what's intended.

https://gist.github.com/johalun/c9383ff03cb29e12c3f4978e06ca6413#file-gistfile1-txt-L761-L762



>
> On Tue, Sep 18, 2018 at 6:55 AM Johannes Lundberg 
> wrote:
>
> > On Tue, Sep 18, 2018 at 10:03 AM Johannes Lundberg 
> > wrote:
> >
> > >
> > >
> > > On Tue, Sep 18, 2018 at 9:43 AM Johannes Lundberg 
> > > wrote:
> > >
> > >>
> > >>
> > >> On Tue, Sep 18, 2018 at 9:39 AM Daniel Braniss 
> > >> wrote:
> > >>
> > >>>
> > >>>
> > >>> > On 18 Sep 2018, at 10:32, Johannes Lundberg 
> > >>> wrote:
> > >>> >
> > >>> > On Tue, Sep 18, 2018 at 9:27 AM Yuri Pankov 
> > wrote:
> > >>> >
> > >>> >> Johannes Lundberg wrote:
> > >>> >>> Hi
> > >>> >>>
> > >>> >>> I have (with 12-ALPHA5)
> > >>> >>>
> > >>> >>> /boot/loader.conf
> > >>> >>> rtwn_load="YES"
> > >>> >>> if_urtw_usb_load="YES"
> > >>> >>
> > >>> >> rtwn(4) thinks this should be if_rtwn_usb_load="YES".
> > >>> >>
> > >>> >
> > >>> > Ah yes. Sorry about that. I still suffer confusion from the rename.
> > >>> > Still, it doesn't change anything since if_rtwn_usb was loaded
> > anyway.
> > >>> >
> > >>> >
> > >>> >>> /etc/rc.conf
> > >>> >>> wlans_rtwn0="wlan0"
> > >>> >>> ifconfig_wlan0="WPA DHCP"
> > >>> >>>
> > >>> >>> but still after boot only lo0 exists and all modules are loaded.
> > >>> >>>
> > >>> >>> Manually running
> > >>> >>> ifconfig wlan0 create wlandev rtwn0
> > >>> >>> sets up the interface correctly.
> > >>> >>>
> > >>> >>> In my kernel config I have
> > >>> >>> MODULES_OVERRIDE="usb rtwn_usb rtwn "
> > >>> >>>
> > >>> >>> I'm pretty sure this has worked before... Any clues?
> > >>> >>
> > >>>
> > >>>
> > >>> devd is not calling netif!
> > >>> try running ’service netif start’ and see what happens.
> > >>>
> > >>
> > >> Yep that enables wlan0!
> > >>
> > >>
> > > With wlan0 up and running, unplug and re-plug the wifi adapter will
> > create
> > > rtwn0 device but no wlan0.
> > > Firmware was missing so I added rtwnfw to MODULES_OVERRIDE but it makes
> > no
> > > difference for this problem.
> > >
> > >
> > (cc: imp)
> >
> > Here's devd output:
> >
> > https://gist.github.com/johalun/c9383ff03cb29e12c3f4978e06ca6413
> >
> > Not sure how to interpret this but it looks like it fails to match rtwn0
> at
> >
> >
> https://gist.github.com/johalun/c9383ff03cb29e12c3f4978e06ca6413#file-gistfile1-txt-L761
> >
> >
> >
> >
> > >>> danny
> > >>>
> > >>> > ___
> > >>> > 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"
> > >>>
> > >>>
> > ___
> > 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"
> >
>
>
> --
> Patrick McMunn
>
> - Learn more about the Catholic Faith: http://www.catholic.com/
> - Pray with the Church: http://www.universalis.com/
> ___
> 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"
>
___
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: FreeBSD EFI projects

2018-09-19 Thread Greg V 

On 09/18, Rebecca Cran wrote:

On 9/18/18 4:11 AM, Greg V wrote:



I can confirm that the kernel already worked fine when booted from
32-bit EFI.

I booted an old Mac into HardenedBSD using a 32-bit-EFI build of GRUB2 :)



Was that a 64-bit version of FreeBSD? My understanding is the 32-bit
FreeBSD boots fine, but 64-bit needs work.


Yes, of course it was 64-bit.

I don't think I ever downloaded the 32-bit one...
___
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"

just a FYI

2018-09-19 Thread Jeffrey Bouquet 
 /usr/ports/security/lockdown [ sorry if this is a PR or for ports- ]
altered fstab, login.conf and ttys locking me out of my main machine, probably 
due
to the password hash, but only a daily backup helped me login again and fix the 
damages, with a few files "hardened" maybe but at a cost of uncertainty 
as to whether the net benefit was good/bad once the system is back up, as
it is now.
  It fortunately only took me about an hour.  This would have been much more 
problematic if I had not had 14 years experience in FreeBSD.
  Can someone alter the port to log its actions, create backups, ask permission 
for
each block of edits it is about to undertake, etc, so someone with critical 
server data
or less of a backup doesn't suffer the same? Something like a mergemaster 
would... 
___
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: just a FYI

2018-09-19 Thread Ed Maste 
On 19 September 2018 at 09:28, Jeffrey Bouquet
 wrote:
>  /usr/ports/security/lockdown [ sorry if this is a PR or for ports- ]

Unfortunately this port has no maintainer, so fixing this is going to
need someone to take an interest in the port. I had a quick look at
the script and it looks like it sets obsolete flags that would result
in an unbootable system.

In any case, would you kindly submit a PR for the issue to track it?
I'll try to get it marked FORBIDDEN (or similar) for now.
___
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: FreeBSD EFI projects

2018-09-19 Thread Rodney W. Grimes 
> On 9/18/18 4:11 AM, Greg V wrote:
> 
> >
> > I can confirm that the kernel already worked fine when booted from
> > 32-bit EFI.
> >
> > I booted an old Mac into HardenedBSD using a 32-bit-EFI build of GRUB2 :)
> 
> 
> Was that a 64-bit version of FreeBSD? My understanding is the 32-bit
> FreeBSD boots fine, but 64-bit needs work.

You would be hard pressed to find a system with a 64 bit CPU that
could run 64 bit FreeBSD that had a 32 bit EFI implementation.

Even finding a 32 bit EFI implementation,
at least in the x86 world is very hard to do.

-- 
Rod Grimes rgri...@freebsd.org
___
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: FreeBSD EFI projects

2018-09-19 Thread Greg V 




On Wed, Sep 19, 2018 at 5:34 PM, Rodney W. Grimes 
 wrote:

 On 9/18/18 4:11 AM, Greg V wrote:

 >
 > I can confirm that the kernel already worked fine when booted from
 > 32-bit EFI.
 >
 > I booted an old Mac into HardenedBSD using a 32-bit-EFI build of 
GRUB2 :)



 Was that a 64-bit version of FreeBSD? My understanding is the 32-bit
 FreeBSD boots fine, but 64-bit needs work.


You would be hard pressed to find a system with a 64 bit CPU that
could run 64 bit FreeBSD that had a 32 bit EFI implementation.


Mac mini 2006 with a Core2Duo instead of the stock CoreDuo (and the 
2007 model's firmware flashed, but I don't think that impacts FreeBSD).


And probably just the 2007 model as well :)

Also, IIRC there were some Intel Atom tablets with 32-bit EFI.

___
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: FreeBSD EFI projects

2018-09-19 Thread Rodney W. Grimes 
> On Wed, Sep 19, 2018 at 5:34 PM, Rodney W. Grimes 
>  wrote:
> >>  On 9/18/18 4:11 AM, Greg V wrote:
> >> 
> >>  >
> >>  > I can confirm that the kernel already worked fine when booted from
> >>  > 32-bit EFI.
> >>  >
> >>  > I booted an old Mac into HardenedBSD using a 32-bit-EFI build of 
> >> GRUB2 :)
> >> 
> >> 
> >>  Was that a 64-bit version of FreeBSD? My understanding is the 32-bit
> >>  FreeBSD boots fine, but 64-bit needs work.
> > 
> > You would be hard pressed to find a system with a 64 bit CPU that
> > could run 64 bit FreeBSD that had a 32 bit EFI implementation.
> 
> Mac mini 2006 with a Core2Duo instead of the stock CoreDuo (and the 
> 2007 model's firmware flashed, but I don't think that impacts FreeBSD).

Yes, that is one of the catagories of rare, a EFI-32 bit system that
was originally shipped with a 32 bit only CPU, that later got upgraded
in the field with a 64 bit CPU, that still runs a EFI-32 bios.
Are you sure the 2007 firmware is EFI32?  I would of thought
since they upgraded the base system to a 64 bit CPU they would
of shipped it with a EFI-64 bios.

> 
> And probably just the 2007 model as well :)
> 
> Also, IIRC there were some Intel Atom tablets with 32-bit EFI.

Atom N2xx and Z5xx series Atom models cannot run x86-64

-- 
Rod Grimes rgri...@freebsd.org
___
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: FreeBSD EFI projects

2018-09-19 Thread Greg V 



On Wed, Sep 19, 2018 at 6:06 PM, Rodney W. Grimes 
 wrote:

 On Wed, Sep 19, 2018 at 5:34 PM, Rodney W. Grimes
  wrote:
 >>  On 9/18/18 4:11 AM, Greg V wrote:
 >>
 >>  >
 >>  > I can confirm that the kernel already worked fine when booted 
from

 >>  > 32-bit EFI.
 >>  >
 >>  > I booted an old Mac into HardenedBSD using a 32-bit-EFI build 
of

 >> GRUB2 :)
 >>
 >>
 >>  Was that a 64-bit version of FreeBSD? My understanding is the 
32-bit

 >>  FreeBSD boots fine, but 64-bit needs work.
 >
 > You would be hard pressed to find a system with a 64 bit CPU that
 > could run 64 bit FreeBSD that had a 32 bit EFI implementation.

 Mac mini 2006 with a Core2Duo instead of the stock CoreDuo (and the
 2007 model's firmware flashed, but I don't think that impacts 
FreeBSD).


Yes, that is one of the catagories of rare, a EFI-32 bit system that
was originally shipped with a 32 bit only CPU, that later got upgraded
in the field with a 64 bit CPU, that still runs a EFI-32 bios.
Are you sure the 2007 firmware is EFI32?  I would of thought
since they upgraded the base system to a 64 bit CPU they would
of shipped it with a EFI-64 bios.


The EFI firmware is technically 64 bit… but it only boots 32-bit 
binaries.


https://everymac.com/mac-answers/snow-leopard-mac-os-x-faq/mac-os-x-snow-leopard-64-bit-macs-64-bit-efi-boot-in-64-bit-mode.html

'Furthermore, it appears that although subsequently released MacBook, 
MacBook Air, and pre-"Mid-2010" Mac mini models all are equipped with 
"Core 2 Duo" 64-bit processors and 64-bit EFIs, Apple has blocked these 
"consumer-targeted" Macs from booting in 64-bit mode. iMac and MacBook 
Pro models released in 2007 with 64-bit EFIs seem to have been blocked 
as well.'



 And probably just the 2007 model as well :)

 Also, IIRC there were some Intel Atom tablets with 32-bit EFI.


Atom N2xx and Z5xx series Atom models cannot run x86-64


Atom Z3740 — "Instruction Set: 64-bit"
https://ark.intel.com/products/76759/Intel-Atom-Processor-Z3740-2M-Cache-up-to-1_86-GHz

The tablet in question: ASUS VivoTab Note 8 (M80TA)
https://www.asus.com/us/Tablets/ASUS_VivoTab_Note_8_M80TA/

___
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: FreeBSD EFI projects

2018-09-19 Thread Rodney W. Grimes 
> On Wed, Sep 19, 2018 at 6:06 PM, Rodney W. Grimes 
>  wrote:
> >>  On Wed, Sep 19, 2018 at 5:34 PM, Rodney W. Grimes
> >>   wrote:
> >>  >>  On 9/18/18 4:11 AM, Greg V wrote:
> >>  >>
> >>  >>  >
> >>  >>  > I can confirm that the kernel already worked fine when booted 
> >> from
> >>  >>  > 32-bit EFI.
> >>  >>  >
> >>  >>  > I booted an old Mac into HardenedBSD using a 32-bit-EFI build 
> >> of
> >>  >> GRUB2 :)
> >>  >>
> >>  >>
> >>  >>  Was that a 64-bit version of FreeBSD? My understanding is the 
> >> 32-bit
> >>  >>  FreeBSD boots fine, but 64-bit needs work.
> >>  >
> >>  > You would be hard pressed to find a system with a 64 bit CPU that
> >>  > could run 64 bit FreeBSD that had a 32 bit EFI implementation.
> >> 
> >>  Mac mini 2006 with a Core2Duo instead of the stock CoreDuo (and the
> >>  2007 model's firmware flashed, but I don't think that impacts 
> >> FreeBSD).
> > 
> > Yes, that is one of the catagories of rare, a EFI-32 bit system that
> > was originally shipped with a 32 bit only CPU, that later got upgraded
> > in the field with a 64 bit CPU, that still runs a EFI-32 bios.
> > Are you sure the 2007 firmware is EFI32?  I would of thought
> > since they upgraded the base system to a 64 bit CPU they would
> > of shipped it with a EFI-64 bios.
> 
> The EFI firmware is technically 64 bit? but it only boots 32-bit 
> binaries.
> 
> https://everymac.com/mac-answers/snow-leopard-mac-os-x-faq/mac-os-x-snow-leopard-64-bit-macs-64-bit-efi-boot-in-64-bit-mode.html
> 'Furthermore, it appears that although subsequently released MacBook, 
> MacBook Air, and pre-"Mid-2010" Mac mini models all are equipped with 
> "Core 2 Duo" 64-bit processors and 64-bit EFIs, Apple has blocked these 
> "consumer-targeted" Macs from booting in 64-bit mode. iMac and MacBook 
> Pro models released in 2007 with 64-bit EFIs seem to have been blocked 
> as well.'

That is not EFI32, so that is not a test case for how FreeBSD boots 

   
on EFI32 systems.  That is a restriction apple artificially placed
in the implementation.

> >>  And probably just the 2007 model as well :)
> >> 
> >>  Also, IIRC there were some Intel Atom tablets with 32-bit EFI.
> > 
> > Atom N2xx and Z5xx series Atom models cannot run x86-64
> 
> Atom Z3740 ? "Instruction Set: 64-bit"
> https://ark.intel.com/products/76759/Intel-Atom-Processor-Z3740-2M-Cache-up-to-1_86-GHz

The above does not say Atom Z3xxx.  If you find a Atom
N2xx or Z5xx based system it most certainly has a EFI32.

> 
> The tablet in question: ASUS VivoTab Note 8 (M80TA)
> https://www.asus.com/us/Tablets/ASUS_VivoTab_Note_8_M80TA/

I can not find enough detail to know for certain that tablet
actually has which version of EFI.
You are saying it has EFI32?  And if so based on what information?

-- 
Rod Grimes rgri...@freebsd.org
___
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: FreeBSD EFI projects

2018-09-19 Thread Greg V 




On Wed, Sep 19, 2018 at 6:31 PM, Rodney W. Grimes 
 wrote:

 On Wed, Sep 19, 2018 at 6:06 PM, Rodney W. Grimes
  wrote:
 >>  On Wed, Sep 19, 2018 at 5:34 PM, Rodney W. Grimes
 >>   wrote:
 >>  >>  On 9/18/18 4:11 AM, Greg V wrote:
 >>  >>
 >>  >>  >
 >>  >>  > I can confirm that the kernel already worked fine when 
booted

 >> from
 >>  >>  > 32-bit EFI.
 >>  >>  >
 >>  >>  > I booted an old Mac into HardenedBSD using a 32-bit-EFI 
build

 >> of
 >>  >> GRUB2 :)
 >>  >>
 >>  >>
 >>  >>  Was that a 64-bit version of FreeBSD? My understanding is 
the

 >> 32-bit
 >>  >>  FreeBSD boots fine, but 64-bit needs work.
 >>  >
 >>  > You would be hard pressed to find a system with a 64 bit CPU 
that

 >>  > could run 64 bit FreeBSD that had a 32 bit EFI implementation.
 >>
 >>  Mac mini 2006 with a Core2Duo instead of the stock CoreDuo (and 
the

 >>  2007 model's firmware flashed, but I don't think that impacts
 >> FreeBSD).
 >
 > Yes, that is one of the catagories of rare, a EFI-32 bit system 
that
 > was originally shipped with a 32 bit only CPU, that later got 
upgraded

 > in the field with a 64 bit CPU, that still runs a EFI-32 bios.
 > Are you sure the 2007 firmware is EFI32?  I would of thought
 > since they upgraded the base system to a 64 bit CPU they would
 > of shipped it with a EFI-64 bios.

 The EFI firmware is technically 64 bit? but it only boots 32-bit
 binaries.

 
https://everymac.com/mac-answers/snow-leopard-mac-os-x-faq/mac-os-x-snow-leopard-64-bit-macs-64-bit-efi-boot-in-64-bit-mode.html
 'Furthermore, it appears that although subsequently released 
MacBook,
 MacBook Air, and pre-"Mid-2010" Mac mini models all are equipped 
with
 "Core 2 Duo" 64-bit processors and 64-bit EFIs, Apple has blocked 
these
 "consumer-targeted" Macs from booting in 64-bit mode. iMac and 
MacBook
 Pro models released in 2007 with 64-bit EFIs seem to have been 
blocked

 as well.'


That is not EFI32, so that is not a test case for how FreeBSD boots
on EFI32 systems.  That is a restriction apple artificially placed
in the implementation.


Yeah, maybe not the best test case, but probably the most common one.
What matters to users is that a 32-bit loader (bootia32.efi) is 
required, whether artificially or not.



 >>  And probably just the 2007 model as well :)
 >>
 >>  Also, IIRC there were some Intel Atom tablets with 32-bit EFI.
 >
 > Atom N2xx and Z5xx series Atom models cannot run x86-64

 Atom Z3740 ? "Instruction Set: 64-bit"
 
https://ark.intel.com/products/76759/Intel-Atom-Processor-Z3740-2M-Cache-up-to-1_86-GHz


The above does not say Atom Z3xxx.  If you find a Atom
N2xx or Z5xx based system it most certainly has a EFI32.



 The tablet in question: ASUS VivoTab Note 8 (M80TA)
 https://www.asus.com/us/Tablets/ASUS_VivoTab_Note_8_M80TA/


I can not find enough detail to know for certain that tablet
actually has which version of EFI.
You are saying it has EFI32?  And if so based on what information?


Heard from someone that it only took 32-bit efi binaries.

Other Z3xxx users report the same:
https://askubuntu.com/questions/775498/ubuntu-on-32-bit-uefi-only-based-tablet-pc



___
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: Some delete-old detrius

2018-09-19 Thread Sean Bruno 


On 9/18/18 8:48 PM, Mark Millard wrote:
> A problem here is that the references should be to usr.bin instead
> of usr/bin . See:
> 
> https://lists.freebsd.org/pipermail/svn-src-head/2018-September/118426.html
> 
> which reports for svn commit: r336601 - head:
> 
> QUOTE
> Looks like this head/ObsoleteFiles.inc update has a typo
> in each thing added to OLD_FILES . . .
> 
> # ls -lTdt /usr/tests/usr.bin/indent/*
> -r--r--r--  1 root  wheel   121 Sep 13 22:53:30 2018 
> /usr/tests/usr.bin/indent/Kyuafile
> . . .
> -r--r--r--  1 root  wheel   295 Sep 13 22:53:29 2018 
> /usr/tests/usr.bin/indent/binary.0
> -r--r--r--  1 root  wheel92 May  1 19:35:24 2018 
> /usr/tests/usr.bin/indent/sac.0.pro
> -r--r--r--  1 root  wheel   130 May  1 19:35:24 2018 
> /usr/tests/usr.bin/indent/sac.0.stdout
> -r--r--r--  1 root  wheel   122 May  1 19:35:24 2018 
> /usr/tests/usr.bin/indent/sac.0
> -r--r--r--  1 root  wheel94 May  1 19:35:24 2018 
> /usr/tests/usr.bin/indent/nsac.0.pro
> -r--r--r--  1 root  wheel   130 May  1 19:35:24 2018 
> /usr/tests/usr.bin/indent/nsac.0.stdout
> -r--r--r--  1 root  wheel   123 May  1 19:35:24 2018 
> /usr/tests/usr.bin/indent/nsac.0
> 
> vs. ( note usr.bin vs. usr/bin ):
> 
> Modified: head/ObsoleteFiles.inc
> ==
> --- head/ObsoleteFiles.incSun Jul 22 12:04:21 2018(r336600)
> +++ head/ObsoleteFiles.incSun Jul 22 12:45:02 2018(r336601)
> @@ -38,6 +38,13 @@
>  #   xargs -n1 | sort | uniq -d;
>  # done
>  
> +# 20180722: indent(1) option renamed, test files follow
> +OLD_FILES+=usr/bin/indent/tests/nsac.0
> +OLD_FILES+=usr/bin/indent/tests/nsac.0.pro
> +OLD_FILES+=usr/bin/indent/tests/nsac.0.stdout
> +OLD_FILES+=usr/bin/indent/tests/sac.0
> +OLD_FILES+=usr/bin/indent/tests/sac.0.pro
> +OLD_FILES+=usr/bin/indent/tests/sac.0.stdout
>  # 20180721: move of libmlx5.so.1 and libibverbs.so.1
>  OLD_LIBS+=usr/lib/libmlx5.so.1
>  OLD_LIBS+=usr/lib/libibverbs.so.1
> END QUOTE
> 
> This was after having the nsac and sac kyua tests report
> failures in my environment, long after they should have
> not existed.
> 
> 
> 
> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)
> 
> 

So, what should we even do here?  It sort of looks like this entire
section should be purged or something.

There was a bit of error committing this section I guess.

sean



signature.asc
Description: OpenPGP digital signature

Update to 12.0-RELEASE schedule

2018-09-19 Thread Glen Barber 
The 12.0-RELEASE schedule will slip while we wait for some last-minute
work-in-progress to be completed before branching stable/12.

The most notable work-in-progress is upgrading the in-tree OpenSSL to
version 1.1.1, to avoid being stuck with an outdated OpenSSL when 1.0.x
reaches end of life on January 1, 2020.  There is a bit of non-trivial
intrusiveness with this update, notably incompatibility with other
in-tree utilities such as OpenSSH, Kerberos, and NTP.

At present, the 12.0-RELEASE schedule will slip by at least one week to
allow time for this work to be completed so the changes are in the tree
prior to the stable/12 branch.

The 12.0 schedule has been updated on the website at:

https://www.freebsd.org/releases/12.0R/schedule.html

Thank you in advance for your patience.

Glen
On behalf of:   re@



signature.asc
Description: PGP signature

Re: FreeBSD EFI projects

2018-09-19 Thread Toomas Soome 



> On 19 Sep 2018, at 18:31, Rodney W. Grimes 
>  wrote:
> 
>> On Wed, Sep 19, 2018 at 6:06 PM, Rodney W. Grimes 
>>  wrote:
 On Wed, Sep 19, 2018 at 5:34 PM, Rodney W. Grimes
  wrote:
>> On 9/18/18 4:11 AM, Greg V wrote:
>> 
>>> 
>>> I can confirm that the kernel already worked fine when booted 
 from
>>> 32-bit EFI.
>>> 
>>> I booted an old Mac into HardenedBSD using a 32-bit-EFI build 
 of
>> GRUB2 :)
>> 
>> 
>> Was that a 64-bit version of FreeBSD? My understanding is the 
 32-bit
>> FreeBSD boots fine, but 64-bit needs work.
> 
> You would be hard pressed to find a system with a 64 bit CPU that
> could run 64 bit FreeBSD that had a 32 bit EFI implementation.
 
 Mac mini 2006 with a Core2Duo instead of the stock CoreDuo (and the
 2007 model's firmware flashed, but I don't think that impacts 
 FreeBSD).
>>> 
>>> Yes, that is one of the catagories of rare, a EFI-32 bit system that
>>> was originally shipped with a 32 bit only CPU, that later got upgraded
>>> in the field with a 64 bit CPU, that still runs a EFI-32 bios.
>>> Are you sure the 2007 firmware is EFI32?  I would of thought
>>> since they upgraded the base system to a 64 bit CPU they would
>>> of shipped it with a EFI-64 bios.
>> 
>> The EFI firmware is technically 64 bit? but it only boots 32-bit 
>> binaries.
>> 
>> https://everymac.com/mac-answers/snow-leopard-mac-os-x-faq/mac-os-x-snow-leopard-64-bit-macs-64-bit-efi-boot-in-64-bit-mode.html
>> 'Furthermore, it appears that although subsequently released MacBook, 
>> MacBook Air, and pre-"Mid-2010" Mac mini models all are equipped with 
>> "Core 2 Duo" 64-bit processors and 64-bit EFIs, Apple has blocked these 
>> "consumer-targeted" Macs from booting in 64-bit mode. iMac and MacBook 
>> Pro models released in 2007 with 64-bit EFIs seem to have been blocked 
>> as well.'
> 
> That is not EFI32, so that is not a test case for how FreeBSD boots   
>   
>  
> on EFI32 systems.  That is a restriction apple artificially placed
> in the implementation.
> 
 And probably just the 2007 model as well :)
 
 Also, IIRC there were some Intel Atom tablets with 32-bit EFI.
>>> 
>>> Atom N2xx and Z5xx series Atom models cannot run x86-64
>> 
>> Atom Z3740 ? "Instruction Set: 64-bit"
>> https://ark.intel.com/products/76759/Intel-Atom-Processor-Z3740-2M-Cache-up-to-1_86-GHz
>>  
>> 
> 
> The above does not say Atom Z3xxx.  If you find a Atom
> N2xx or Z5xx based system it most certainly has a EFI32.
> 
>> 
>> The tablet in question: ASUS VivoTab Note 8 (M80TA)
>> https://www.asus.com/us/Tablets/ASUS_VivoTab_Note_8_M80TA/ 
>> 
> 
> I can not find enough detail to know for certain that tablet
> actually has which version of EFI.
> You are saying it has EFI32?  And if so based on what information?
> 

I have Lenovo MIIX-300 and it has UEFI32.

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: Some delete-old detrius

2018-09-19 Thread Mark Millard 
On 2018-Sep-19, at 9:14 AM, Sean Bruno  wrote:

> On 9/18/18 8:48 PM, Mark Millard wrote:
>> A problem here is that the references should be to usr.bin instead
>> of usr/bin . See:
>> 
>> https://lists.freebsd.org/pipermail/svn-src-head/2018-September/118426.html
>> 
>> which reports for svn commit: r336601 - head:
>> 
>> QUOTE
>> Looks like this head/ObsoleteFiles.inc update has a typo
>> in each thing added to OLD_FILES . . .
>> 
>> # ls -lTdt /usr/tests/usr.bin/indent/*
>> -r--r--r--  1 root  wheel   121 Sep 13 22:53:30 2018 
>> /usr/tests/usr.bin/indent/Kyuafile
>> . . .
>> -r--r--r--  1 root  wheel   295 Sep 13 22:53:29 2018 
>> /usr/tests/usr.bin/indent/binary.0
>> -r--r--r--  1 root  wheel92 May  1 19:35:24 2018 
>> /usr/tests/usr.bin/indent/sac.0.pro
>> -r--r--r--  1 root  wheel   130 May  1 19:35:24 2018 
>> /usr/tests/usr.bin/indent/sac.0.stdout
>> -r--r--r--  1 root  wheel   122 May  1 19:35:24 2018 
>> /usr/tests/usr.bin/indent/sac.0
>> -r--r--r--  1 root  wheel94 May  1 19:35:24 2018 
>> /usr/tests/usr.bin/indent/nsac.0.pro
>> -r--r--r--  1 root  wheel   130 May  1 19:35:24 2018 
>> /usr/tests/usr.bin/indent/nsac.0.stdout
>> -r--r--r--  1 root  wheel   123 May  1 19:35:24 2018 
>> /usr/tests/usr.bin/indent/nsac.0
>> 
>> vs. ( note usr.bin vs. usr/bin ):
>> 
>> Modified: head/ObsoleteFiles.inc
>> ==
>> --- head/ObsoleteFiles.inc   Sun Jul 22 12:04:21 2018(r336600)
>> +++ head/ObsoleteFiles.inc   Sun Jul 22 12:45:02 2018(r336601)
>> @@ -38,6 +38,13 @@
>> #   xargs -n1 | sort | uniq -d;
>> # done
>> 
>> +# 20180722: indent(1) option renamed, test files follow
>> +OLD_FILES+=usr/bin/indent/tests/nsac.0
>> +OLD_FILES+=usr/bin/indent/tests/nsac.0.pro
>> +OLD_FILES+=usr/bin/indent/tests/nsac.0.stdout
>> +OLD_FILES+=usr/bin/indent/tests/sac.0
>> +OLD_FILES+=usr/bin/indent/tests/sac.0.pro
>> +OLD_FILES+=usr/bin/indent/tests/sac.0.stdout
>> # 20180721: move of libmlx5.so.1 and libibverbs.so.1
>> OLD_LIBS+=usr/lib/libmlx5.so.1
>> OLD_LIBS+=usr/lib/libibverbs.so.1
>> END QUOTE
>> 
>> This was after having the nsac and sac kyua tests report
>> failures in my environment, long after they should have
>> not existed.
>> 
>> 
>> 
>> ===
>> Mark Millard
>> marklmi at yahoo.com
>> ( dsl-only.net went
>> away in early 2018-Mar)
>> 
>> 
> 
> So, what should we even do here?  It sort of looks like this entire
> section should be purged or something.
> 
> There was a bit of error committing this section I guess.

As near as I can tell the fix would be something like:

# svnlite diff /usr/src/ObsoleteFiles.inc
Index: /usr/src/ObsoleteFiles.inc
===
--- /usr/src/ObsoleteFiles.inc  (revision 338675)
+++ /usr/src/ObsoleteFiles.inc  (working copy)
@@ -48,12 +48,12 @@
 # 20180725: Cleanup old libcasper.so.0
 OLD_LIBS+=lib/libcasper.so.0
 # 20180722: indent(1) option renamed, test files follow
-OLD_FILES+=usr/bin/indent/tests/nsac.0
-OLD_FILES+=usr/bin/indent/tests/nsac.0.pro
-OLD_FILES+=usr/bin/indent/tests/nsac.0.stdout
-OLD_FILES+=usr/bin/indent/tests/sac.0
-OLD_FILES+=usr/bin/indent/tests/sac.0.pro
-OLD_FILES+=usr/bin/indent/tests/sac.0.stdout
+OLD_FILES+=usr/tests/usr.bin/indent/nsac.0
+OLD_FILES+=usr/tests/usr.bin/indent/nsac.0.pro
+OLD_FILES+=usr/tests/usr.bin/indent/nsac.0.stdout
+OLD_FILES+=usr/tests/usr.bin/indent/sac.0
+OLD_FILES+=usr/tests/usr.bin/indent/sac.0.pro
+OLD_FILES+=usr/tests/usr.bin/indent/sac.0.stdout
 # 20180721: move of libmlx5.so.1 and libibverbs.so.1
 OLD_LIBS+=usr/lib/libmlx5.so.1
 OLD_LIBS+=usr/lib/libibverbs.so.1


This is sort of like the older part of the file:

# 20170322: rename  to _test to match the FreeBSD test suite name scheme
OLD_FILES+=usr/tests/usr.bin/col/col
OLD_FILES+=usr/tests/usr.bin/diff/diff
OLD_FILES+=usr/tests/usr.bin/ident/ident
OLD_FILES+=usr/tests/usr.bin/mkimg/mkimg
OLD_FILES+=usr/tests/usr.bin/sdiff/sdiff
OLD_FILES+=usr/tests/usr.bin/soelim/soelim
OLD_FILES+=usr/tests/usr.sbin/pw/pw_config
OLD_FILES+=usr/tests/usr.sbin/pw/pw_etcdir
OLD_FILES+=usr/tests/usr.sbin/pw/pw_groupadd
OLD_FILES+=usr/tests/usr.sbin/pw/pw_groupdel
OLD_FILES+=usr/tests/usr.sbin/pw/pw_groupmod
OLD_FILES+=usr/tests/usr.sbin/pw/pw_lock
OLD_FILES+=usr/tests/usr.sbin/pw/pw_useradd
OLD_FILES+=usr/tests/usr.sbin/pw/pw_userdel
OLD_FILES+=usr/tests/usr.sbin/pw/pw_usermod
OLD_FILES+=usr/tests/usr.sbin/pw/pw_usernext



===
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"

ALPHA4 panic in VM

2018-09-19 Thread Steve Kargl 
I have the kernel and core file if more information is needed.

% cat info.2
Dump header from device: /dev/ada0p3
  Architecture: amd64
  Architecture Version: 2
  Dump Length: 2348281856
  Blocksize: 512
  Compression: none
  Dumptime: Wed Sep 19 12:29:59 2018
  Hostname: troutmask.apl.washington.edu
  Magic: FreeBSD Kernel Dump
  Version String: FreeBSD 12.0-ALPHA4 #0 r338505: Thu Sep  6 13:45:34 PDT 2018
ka...@troutmask.apl.washington.edu:/usr/obj/usr/src/amd64.amd64/sys/SPEW
  Panic String: page fault
  Dump Parity: 2676008548
  Bounds: 2
  Dump Status: good

% more core.txt.2
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 11
fault virtual address   = 0xb8000719a428
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x808213ab
stack pointer   = 0x28:0xfe0099d0b710
frame pointer   = 0x28:0xfe0099d0b730
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 = 65343 (Web Content)
trap number = 12
panic: page fault
cpuid = 1
time = 1537385399
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0099d0b3c0
vpanic() at vpanic+0x1a3/frame 0xfe0099d0b420
panic() at panic+0x43/frame 0xfe0099d0b480
trap_fatal() at trap_fatal+0x35f/frame 0xfe0099d0b4d0
trap_pfault() at trap_pfault+0x49/frame 0xfe0099d0b530
trap() at trap+0x2a3/frame 0xfe0099d0b640
calltrap() at calltrap+0x8/frame 0xfe0099d0b640
--- trap 0xc, rip = 0x808213ab, rsp = 0xfe0099d0b710, rbp = 
0xfe0099d0b730 ---
swap_release_by_cred() at swap_release_by_cred+0x1b/frame 0xfe0099d0b730
vm_object_terminate() at vm_object_terminate+0x27d/frame 0xfe0099d0b780
vm_object_deallocate() at vm_object_deallocate+0x457/frame 0xfe0099d0b7e0
_vm_map_unlock() at _vm_map_unlock+0xb9/frame 0xfe0099d0b800
vm_map_remove() at vm_map_remove+0x99/frame 0xfe0099d0b830
vmspace_exit() at vmspace_exit+0xcd/frame 0xfe0099d0b870
exit1() at exit1+0x4ab/frame 0xfe0099d0b8e0
sys_sys_exit() at sys_sys_exit+0xd/frame 0xfe0099d0b8f0
amd64_syscall() at amd64_syscall+0x219/frame 0xfe0099d0ba30
fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe0099d0ba30
--- syscall (1, FreeBSD ELF64, sys_sys_exit), rip = 0x2013433da, rsp = 
0x7fffdc98, rbp = 0x3 ---
Uptime: 12d22h19m36s
__curthread () at ./machine/pcpu.h:230
230 __asm("movq %%gs:%1,%0" : "=r" (td)
(kgdb) #0  __curthread () at ./machine/pcpu.h:230
#1  doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:366
#2  0x805c595b in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:446
#3  0x805c5d93 in vpanic (fmt=, ap=0xfe0099d0b460)
at /usr/src/sys/kern/kern_shutdown.c:872
#4  0x805c5b83 in panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:799
#5  0x8087cd7f in trap_fatal (frame=0xfe0099d0b650, 
eva=18446664908991472680) at /usr/src/sys/amd64/amd64/trap.c:928
#6  0x8087cdd9 in trap_pfault (frame=0xfe0099d0b650, usermode=0)
at /usr/src/sys/amd64/amd64/trap.c:760
#7  0x8087c483 in trap (frame=0xfe0099d0b650)
at /usr/src/sys/amd64/amd64/trap.c:441
#8  
#9  0x808213ab in swap_release_by_cred (decr=28672, 
cred=0xb8000719a400) at /usr/src/sys/vm/swap_pager.c:296
#10 0x8083e07d in vm_object_destroy (object=)
at /usr/src/sys/vm/vm_object.c:703
#11 vm_object_terminate (object=0xf807cecf7400)
at /usr/src/sys/vm/vm_object.c:836
#12 0x8083d357 in vm_object_deallocate (object=0xf807cecf7400)
at /usr/src/sys/vm/vm_object.c:684
#13 0x80833459 in vm_map_entry_deallocate (
system_map=, 
entry=) at /usr/src/sys/vm/vm_map.c:3001
#14 vm_map_process_deferred () at /usr/src/sys/vm/vm_map.c:541
#15 _vm_map_unlock (map=, file=, 
line=) at /usr/src/sys/vm/vm_map.c:554
#16 0x80837989 in vm_map_remove (map=0xf8019c58, start=4096, 
end=140737488355328) at /usr/src/sys/vm/vm_map.c:3199
#17 0x8083322d in vmspace_dofree (vm=)
at /usr/src/sys/vm/vm_map.c:342
#18 vmspace_exit (td=0xf80007524000) at /usr/src/sys/vm/vm_map.c:423
#19 0x8058c7ab in exit1 (td=0xf80007524000, rval=, 
signo=) at /usr/src/sys/kern/kern_exit.c:402
#20 0x8058c2fd in sys_sys_exit (td=0x7000, uap=)
at /usr/src/sys/kern/kern_exit.c:180
#21 0x8087d609 in syscallenter (td=0xf80007524000)
at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:135
#22 amd64_syscall (td=0xf80007524000, traced=0)
at /usr/src/sys/amd64/amd64/trap.c:1043
#23 
#24 0x0002013433da in ?? ()



-- 
Steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscri

Re: ALPHA4 panic in VM

2018-09-19 Thread Mark Johnston 
On Wed, Sep 19, 2018 at 01:01:52PM -0700, Steve Kargl wrote:
> I have the kernel and core file if more information is needed.
> 
> % cat info.2
> Dump header from device: /dev/ada0p3
   Architecture: amd64
>   Architecture Version: 2
>   Dump Length: 2348281856
>   Blocksize: 512
>   Compression: none
>   Dumptime: Wed Sep 19 12:29:59 2018
>   Hostname: troutmask.apl.washington.edu
>   Magic: FreeBSD Kernel Dump
>   Version String: FreeBSD 12.0-ALPHA4 #0 r338505: Thu Sep  6 13:45:34 PDT 2018
> ka...@troutmask.apl.washington.edu:/usr/obj/usr/src/amd64.amd64/sys/SPEW
>   Panic String: page fault
>   Dump Parity: 2676008548
>   Bounds: 2
>   Dump Status: good
> 
> % more core.txt.2
> Fatal trap 12: page fault while in kernel mode
> cpuid = 1; apic id = 11
> fault virtual address   = 0xb8000719a428

This seems to be the result of a bit-flip.  cred is 0xb8000719a400,
which is almost but not quite in the direct map.  In particular we have:

(kgdb) frame 10 

#10 0x8083e07d in vm_object_destroy (object=) at 
/usr/src/sys/vm/vm_object.c:703
703 swap_release_by_cred(object->charge, object->cred); 

(kgdb) p object
$8 = 

(kgdb) p *(vm_object_t)$r13 
   
$9 = {
...
  cred = 0xb8000719a400,
  charge = 28672,
  umtx_data = 0x0
}
(kgdb) p *(struct ucred *)0xf8000719a400
$10 = {
  cr_ref = 5737, 
  cr_uid = 1001, 
  cr_ruid = 1001, 
  cr_svuid = 1001, 
  cr_ngroups = 7, 
  cr_rgid = 1001, 
  cr_svgid = 1001, 
  cr_uidinfo = 0xf80007285500, 
  cr_ruidinfo = 0xf80007285500, 
  cr_prison = 0x80a9de10 , 
... 

That is, flipping one of the bits in the fault address leads me to a
valid ucred.  This could in principle be the result of a software bug,
but I'd be more inclined to suspect the hardware.
___
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: ALPHA4 panic in VM

2018-09-19 Thread Steve Kargl 
On Wed, Sep 19, 2018 at 05:02:11PM -0400, Mark Johnston wrote:
> On Wed, Sep 19, 2018 at 01:01:52PM -0700, Steve Kargl wrote:
> > I have the kernel and core file if more information is needed.
> > 
> > % cat info.2
> > Dump header from device: /dev/ada0p3
>Architecture: amd64
> >   Architecture Version: 2
> >   Dump Length: 2348281856
> >   Blocksize: 512
> >   Compression: none
> >   Dumptime: Wed Sep 19 12:29:59 2018
> >   Hostname: troutmask.apl.washington.edu
> >   Magic: FreeBSD Kernel Dump
> >   Version String: FreeBSD 12.0-ALPHA4 #0 r338505: Thu Sep  6 13:45:34 PDT 
> > 2018
> > ka...@troutmask.apl.washington.edu:/usr/obj/usr/src/amd64.amd64/sys/SPEW
> >   Panic String: page fault
> >   Dump Parity: 2676008548
> >   Bounds: 2
> >   Dump Status: good
> > 
> > % more core.txt.2
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 1; apic id = 11
> > fault virtual address   = 0xb8000719a428
> 
> This seems to be the result of a bit-flip.  cred is 0xb8000719a400,
> which is almost but not quite in the direct map.  In particular we have:
> 
> (kgdb) frame 10   
>   
> #10 0x8083e07d in vm_object_destroy (object=) at 
> /usr/src/sys/vm/vm_object.c:703
> 703 swap_release_by_cred(object->charge, object->cred);   
>   
> (kgdb) p object
> $8 =   
>   
> (kgdb) p *(vm_object_t)$r13   
>  
> $9 = {
> ...
>   cred = 0xb8000719a400,
>   charge = 28672,
>   umtx_data = 0x0
> }
> (kgdb) p *(struct ucred *)0xf8000719a400
> $10 = {
>   cr_ref = 5737, 
>   cr_uid = 1001, 
>   cr_ruid = 1001, 
>   cr_svuid = 1001, 
>   cr_ngroups = 7, 
>   cr_rgid = 1001, 
>   cr_svgid = 1001, 
>   cr_uidinfo = 0xf80007285500, 
>   cr_ruidinfo = 0xf80007285500, 
>   cr_prison = 0x80a9de10 , 
> ... 
> 
> That is, flipping one of the bits in the fault address leads me to a
> valid ucred.  This could in principle be the result of a software bug,
> but I'd be more inclined to suspect the hardware.

Mark,

Thanks for looking into the problem.  This system has
been running for probably 2 years or so without issues.
I guess it's time to pull out memtest86+ (or similar)
to see if hardware is starting to fail.

-- 
Steve
___
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: ALPHA4 panic in VM

2018-09-19 Thread Mark Johnston 
On Wed, Sep 19, 2018 at 02:11:56PM -0700, Steve Kargl wrote:
> On Wed, Sep 19, 2018 at 05:02:11PM -0400, Mark Johnston wrote:
> > On Wed, Sep 19, 2018 at 01:01:52PM -0700, Steve Kargl wrote:
> > > I have the kernel and core file if more information is needed.
> > > 
> > > % cat info.2
> > > Dump header from device: /dev/ada0p3
> >Architecture: amd64
> > >   Architecture Version: 2
> > >   Dump Length: 2348281856
> > >   Blocksize: 512
> > >   Compression: none
> > >   Dumptime: Wed Sep 19 12:29:59 2018
> > >   Hostname: troutmask.apl.washington.edu
> > >   Magic: FreeBSD Kernel Dump
> > >   Version String: FreeBSD 12.0-ALPHA4 #0 r338505: Thu Sep  6 13:45:34 PDT 
> > > 2018
> > > 
> > > ka...@troutmask.apl.washington.edu:/usr/obj/usr/src/amd64.amd64/sys/SPEW
> > >   Panic String: page fault
> > >   Dump Parity: 2676008548
> > >   Bounds: 2
> > >   Dump Status: good
> > > 
> > > % more core.txt.2
> > > Fatal trap 12: page fault while in kernel mode
> > > cpuid = 1; apic id = 11
> > > fault virtual address   = 0xb8000719a428
> > 
> > This seems to be the result of a bit-flip.  cred is 0xb8000719a400,
> > which is almost but not quite in the direct map.  In particular we have:
> > 
> > (kgdb) frame 10 
> > 
> > #10 0x8083e07d in vm_object_destroy (object=) at 
> > /usr/src/sys/vm/vm_object.c:703
> > 703 swap_release_by_cred(object->charge, object->cred); 
> > 
> > (kgdb) p object
> > $8 = 
> > 
> > (kgdb) p *(vm_object_t)$r13 
> >
> > $9 = {
> > ...
> >   cred = 0xb8000719a400,
> >   charge = 28672,
> >   umtx_data = 0x0
> > }
> > (kgdb) p *(struct ucred *)0xf8000719a400
> > $10 = {
> >   cr_ref = 5737, 
> >   cr_uid = 1001, 
> >   cr_ruid = 1001, 
> >   cr_svuid = 1001, 
> >   cr_ngroups = 7, 
> >   cr_rgid = 1001, 
> >   cr_svgid = 1001, 
> >   cr_uidinfo = 0xf80007285500, 
> >   cr_ruidinfo = 0xf80007285500, 
> >   cr_prison = 0x80a9de10 , 
> > ... 
> > 
> > That is, flipping one of the bits in the fault address leads me to a
> > valid ucred.  This could in principle be the result of a software bug,
> > but I'd be more inclined to suspect the hardware.
> 
> Mark,
> 
> Thanks for looking into the problem.  This system has
> been running for probably 2 years or so without issues.
> I guess it's time to pull out memtest86+ (or similar)
> to see if hardware is starting to fail.

I'm not sure whether you're using ECC RAM, but if not, the system is
susceptible to silent random bit flips.
___
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: FreeBSD EFI projects

2018-09-19 Thread Rebecca Cran 



On 9/19/18 9:06 AM, Rodney W. Grimes wrote:

Yes, that is one of the catagories of rare, a EFI-32 bit system that
was originally shipped with a 32 bit only CPU, that later got upgraded
in the field with a 64 bit CPU, that still runs a EFI-32 bios.
Are you sure the 2007 firmware is EFI32?  I would of thought
since they upgraded the base system to a 64 bit CPU they would
of shipped it with a EFI-64 bios.



I'm not sure if there's a firmware upgrade for it, but I have a MacBook 
Pro from around that time that definitely has a 32-bit EFI: it only runs 
32-bit binaries, and had a 32-bit version of MacOS X installed despite 
having a 64-bit Core2Duo CPU.



--
Rebecca

___
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: FreeBSD EFI projects

2018-09-19 Thread Rebecca Cran 

On 9/19/18 3:53 AM, Greg V wrote:



Yes, of course it was 64-bit.

I don't think I ever downloaded the 32-bit one...



And are you sure it was booted via EFI and not the BIOS emulation CSM 
(Compatibility Support Module)? I'm fairly sure we _don't_ support 
booting a 64-bit kernel from 32-bit EFI yet.



--
Rebecca

___
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: just a FYI

2018-09-19 Thread Jeffrey Bouquet 



On Wed, 19 Sep 2018 09:58:19 -0400, Ed Maste  wrote:

> On 19 September 2018 at 09:28, Jeffrey Bouquet
>  wrote:
> >  /usr/ports/security/lockdown [ sorry if this is a PR or for ports- ]
> 
> Unfortunately this port has no maintainer, so fixing this is going to
> need someone to take an interest in the port. I had a quick look at
> the script and it looks like it sets obsolete flags that would result
> in an unbootable system.
> 
> In any case, would you kindly submit a PR for the issue to track it?
> I'll try to get it marked FORBIDDEN (or similar) for now.
> ___
> 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"


Bug # 231489 submitted. 
___
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: FreeBSD EFI projects

2018-09-19 Thread Ed Maste 
On 19 September 2018 at 10:34, Rodney W. Grimes
 wrote:
>
> You would be hard pressed to find a system with a 64 bit CPU that
> could run 64 bit FreeBSD that had a 32 bit EFI implementation.

The Minnowboard Turbot has an Atom E3826, and has four precompiled
Tianocore UEFI firmware releases available: 32 and 64 bit in release
and debug builds. It's probably the most approachable development
platform for UEFI work on FreeBSD.
___
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: Update to 12.0-RELEASE schedule

2018-09-19 Thread Tim Rice 



On 09/19/18 09:22, Glen Barber wrote:
> The 12.0-RELEASE schedule will slip while we wait for some last-minute
> work-in-progress to be completed before branching stable/12.
>
> The most notable work-in-progress is upgrading the in-tree OpenSSL to
> version 1.1.1, to avoid being stuck with an outdated OpenSSL when 1.0.x
> reaches end of life on January 1, 2020.  There is a bit of non-trivial
> intrusiveness with this update, notably incompatibility with other
> in-tree utilities such as OpenSSH, Kerberos, and NTP.
FYI, OpenSSH got openssl-1.1.x API support on Sep 13 starting with
this commit.

> commit 482d23bcacdd3664f21cc82a5135f66fc598275f
> Author: d...@openbsd.org 
> Date:   Thu Sep 13 02:08:33 2018 +
>
> upstream: hold our collective noses and use the openssl-1.1.x API in
>
> OpenSSH; feedback and ok tb@ jsing@ markus@
>
> OpenBSD-Commit-ID: cacbcac87ce5da0d3ca7ef1b38a6f7fb349e4417


> At present, the 12.0-RELEASE schedule will slip by at least one week to
> allow time for this work to be completed so the changes are in the tree
> prior to the stable/12 branch.
>
> The 12.0 schedule has been updated on the website at:
>
> https://www.freebsd.org/releases/12.0R/schedule.html
>
> Thank you in advance for your patience.
>
> Glen
> On behalf of: re@
>

-- 
Tim Rice


___
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: FreeBSD EFI projects

2018-09-19 Thread Rebecca Cran 

On 9/19/18 5:13 PM, Ed Maste wrote:



The Minnowboard Turbot has an Atom E3826, and has four precompiled
Tianocore UEFI firmware releases available: 32 and 64 bit in release
and debug builds. It's probably the most approachable development
platform for UEFI work on FreeBSD.



Oh, that's a really good point - thanks! I happen to have a Minnowboard 
Turbot currently sitting unused.



--
Rebecca

___
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: FreeBSD EFI projects

2018-09-19 Thread Warner Losh 
On Wed, Sep 19, 2018 at 4:33 PM Rebecca Cran  wrote:

> Oh, that's a really good point - thanks! I happen to have a Minnowboard
> Turbot currently sitting unused.
>

One other idea, unrelated to the 32-bit UEFI to boot 64-bit kernel, is to
see about mining tsoome@'s port of FreeBSD boot loader to OpenIndiana. He's
done a lot of cool things that would be useful to bring in, but need
someone with a UEFI clue to do it. He's not had the time to get them
reviewed and tested in our environment, if I understand correctly. You
might want to reach out to him to see if there's things that would be
useful. The biggest one I can think of is that his efi show variable code
knows about standard UEFI variables and prints them out interpreted, not in
unhelpful without the standard handy binary form like our loader does.

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: FreeBSD EFI projects

2018-09-19 Thread Rodney W. Grimes 
> 
> On 9/19/18 9:06 AM, Rodney W. Grimes wrote:
> > Yes, that is one of the catagories of rare, a EFI-32 bit system that
> > was originally shipped with a 32 bit only CPU, that later got upgraded
> > in the field with a 64 bit CPU, that still runs a EFI-32 bios.
> > Are you sure the 2007 firmware is EFI32?  I would of thought
> > since they upgraded the base system to a 64 bit CPU they would
> > of shipped it with a EFI-64 bios.
> 
> 
> I'm not sure if there's a firmware upgrade for it, but I have a MacBook 
> Pro from around that time that definitely has a 32-bit EFI: it only runs 
> 32-bit binaries, and had a 32-bit version of MacOS X installed despite 
> having a 64-bit Core2Duo CPU.

I am courous as to what people are using to decide that
it is a EFI32 bios.  I see some things that can be run
under OSX that tells you, but I am looking for something
more generic.

I did find this little tid bit about Apple and what they did
with some EFI implementations:
http://refit.sourceforge.net/info/apple_efi.html

It does appear as if Apple did ship EFI32 for a long time
compared to other x86 vendors, even making them special
fat binaries that can run on either EFI32 or EFI64, but
that only works if you have an Apple EFI implementation.

Apple defanitly has made Chaos of EFI, you can't even
use the version being 1.10 as an indicator, as they
shipped 64 bit EFI with a 1.10 version, EFI did not
officially at 64 bit support until 2.0.

-- 
Rod Grimes rgri...@freebsd.org
___
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: FreeBSD EFI projects

2018-09-19 Thread Rodney W. Grimes 
> On 9/19/18 3:53 AM, Greg V wrote:
> 
> >
> > Yes, of course it was 64-bit.
> >
> > I don't think I ever downloaded the 32-bit one...
> 
> 
> And are you sure it was booted via EFI and not the BIOS emulation CSM 
> (Compatibility Support Module)? I'm fairly sure we _don't_ support 
> booting a 64-bit kernel from 32-bit EFI yet.

I concur.  Infact I think we fall pretty hard on our face in the
loader code if you run on EFI32 without CSM.

-- 
Rod Grimes rgri...@freebsd.org
___
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: FreeBSD EFI projects

2018-09-19 Thread Toomas Soome 
I still have it all in the queue, just the paid work is taking its toll and 
then FreeBSD and illumos  :)

Next week I am on vacation trip but then I’ll be back and kicking. 

Rgds,
Toomas

Sent from my iPhone

> On 20 Sep 2018, at 02:37, Warner Losh  wrote:
> 
>> On Wed, Sep 19, 2018 at 4:33 PM Rebecca Cran  wrote:
>> 
>> Oh, that's a really good point - thanks! I happen to have a Minnowboard
>> Turbot currently sitting unused.
>> 
> 
> One other idea, unrelated to the 32-bit UEFI to boot 64-bit kernel, is to
> see about mining tsoome@'s port of FreeBSD boot loader to OpenIndiana. He's
> done a lot of cool things that would be useful to bring in, but need
> someone with a UEFI clue to do it. He's not had the time to get them
> reviewed and tested in our environment, if I understand correctly. You
> might want to reach out to him to see if there's things that would be
> useful. The biggest one I can think of is that his efi show variable code
> knows about standard UEFI variables and prints them out interpreted, not in
> unhelpful without the standard handy binary form like our loader does.
> 
> 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"
___
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"