Build failed in Jenkins: FreeBSD_HEAD #304

[jenkins-admin]

See 

--
[...truncated 325077 lines...]
[192.168.10.2] out: usr.bin/tr/legacy_test:main  ->  passed  [0.091s]
[192.168.10.2] out: usr.bin/join/legacy_test:main  ->  passed  [0.033s]
[192.168.10.2] out: usr.bin/cmp/cmp_test:missing  ->  passed  [0.093s]
[192.168.10.2] out: usr.bin/cmp/cmp_test:skip  ->  passed  [0.085s]
[192.168.10.2] out: usr.bin/grep/grep_test:basic  ->  passed  [0.061s]
[192.168.10.2] out: usr.bin/grep/grep_test:begin_end  ->  passed  [0.073s]
[192.168.10.2] out: usr.bin/grep/grep_test:binary  ->  passed  [0.059s]
[192.168.10.2] out: usr.bin/grep/grep_test:context  ->  passed  [0.114s]
[192.168.10.2] out: usr.bin/grep/grep_test:context2  ->  passed  [0.089s]
[192.168.10.2] out: usr.bin/grep/grep_test:egrep  ->  passed  [0.054s]
[192.168.10.2] out: usr.bin/grep/grep_test:file_exp  ->  passed  [0.065s]
[192.168.10.2] out: usr.bin/grep/grep_test:ignore_case  ->  passed  [0.058s]
[192.168.10.2] out: usr.bin/grep/grep_test:invert  ->  passed  [0.057s]
[192.168.10.2] out: usr.bin/grep/grep_test:negative  ->  passed  [0.053s]
[192.168.10.2] out: usr.bin/grep/grep_test:nonexistent  ->  passed  [0.054s]
[192.168.10.2] out: usr.bin/grep/grep_test:recurse  ->  passed  [0.093s]
[192.168.10.2] out: usr.bin/grep/grep_test:recurse_symlink  ->  passed  [0.081s]
[192.168.10.2] out: usr.bin/grep/grep_test:whole_line  ->  passed  [0.054s]
[192.168.10.2] out: usr.bin/grep/grep_test:word_regexps  ->  passed  [0.056s]
[192.168.10.2] out: usr.bin/grep/grep_test:zgrep  ->  passed  [0.061s]
[192.168.10.2] out: usr.bin/basename/basename_test:basic  ->  passed  [0.142s]
[192.168.10.2] out: usr.bin/basename/basename_test:suffix  ->  passed  [0.089s]
[192.168.10.2] out: usr.bin/soelim/soelim:files  ->  passed  [0.112s]
[192.168.10.2] out: usr.bin/soelim/soelim:stdin  ->  passed  [0.114s]
[192.168.10.2] out: usr.bin/units/basics_test:main  ->  passed  [0.046s]
[192.168.10.2] out: usr.bin/limits/limits_test:cputime_hard_flag  ->  passed  
[3.179s]
[192.168.10.2] out: usr.bin/limits/limits_test:cputime_soft_flag  ->  passed  
[3.151s]
[192.168.10.2] out: usr.bin/bmake/archives/fmt_44bsd/legacy_test:main  ->  
passed  [0.093s]
[192.168.10.2] out: usr.bin/bmake/archives/fmt_44bsd_mod/legacy_test:main  ->  
passed  [0.074s]
[192.168.10.2] out: usr.bin/bmake/archives/fmt_oldbsd/legacy_test:main  ->  
passed  [0.076s]
[192.168.10.2] out: usr.bin/bmake/basic/t0/legacy_test:main  ->  passed  
[0.076s]
[192.168.10.2] out: usr.bin/bmake/basic/t1/legacy_test:main  ->  passed  
[0.065s]
[192.168.10.2] out: usr.bin/bmake/basic/t2/legacy_test:main  ->  passed  
[0.059s]
[192.168.10.2] out: usr.bin/bmake/basic/t3/legacy_test:main  ->  passed  
[0.057s]
[192.168.10.2] out: usr.bin/bmake/execution/ellipsis/legacy_test:main  ->  
passed  [0.068s]
[192.168.10.2] out: usr.bin/bmake/execution/empty/legacy_test:main  ->  passed  
[0.068s]
[192.168.10.2] out: usr.bin/bmake/execution/joberr/legacy_test:main  ->  passed 
 [0.060s]
[192.168.10.2] out: usr.bin/bmake/execution/plus/legacy_test:main  ->  passed  
[0.065s]
[192.168.10.2] out: usr.bin/bmake/shell/builtin/legacy_test:main  ->  passed  
[0.077s]
[192.168.10.2] out: usr.bin/bmake/shell/meta/legacy_test:main  ->  passed  
[0.077s]
[192.168.10.2] out: usr.bin/bmake/shell/path/legacy_test:main  ->  passed  
[0.071s]
[192.168.10.2] out: usr.bin/bmake/shell/path_select/legacy_test:main  ->  
passed  [0.077s]
[192.168.10.2] out: usr.bin/bmake/shell/replace/legacy_test:main  ->  passed  
[0.078s]
[192.168.10.2] out: usr.bin/bmake/shell/select/legacy_test:main  ->  passed  
[0.066s]
[192.168.10.2] out: usr.bin/bmake/suffixes/basic/legacy_test:main  ->  passed  
[0.071s]
[192.168.10.2] out: usr.bin/bmake/suffixes/src_wild1/legacy_test:main  ->  
passed  [0.082s]
[192.168.10.2] out: usr.bin/bmake/suffixes/src_wild2/legacy_test:main  ->  
passed  [0.086s]
[192.168.10.2] out: usr.bin/bmake/syntax/directive-t0/legacy_test:main  ->  
passed  [0.066s]
[192.168.10.2] out: usr.bin/bmake/syntax/enl/legacy_test:main  ->  passed  
[0.067s]
[192.168.10.2] out: usr.bin/bmake/syntax/funny-targets/legacy_test:main  ->  
passed  [0.063s]
[192.168.10.2] out: usr.bin/bmake/syntax/semi/legacy_test:main  ->  passed  
[0.063s]
[192.168.10.2] out: usr.bin/bmake/sysmk/t0/2/1/legacy_test:main  ->  passed  
[0.090s]
[192.168.10.2] out: usr.bin/bmake/sysmk/t1/2/1/legacy_test:main  ->  passed  
[0.154s]
[192.168.10.2] out: usr.bin/bmake/sysmk/t2/2/1/legacy_test:main  ->  passed  
[0.121s]
[192.168.10.2] out: usr.bin/bmake/variables/modifier_M/legacy_test:main  ->  
passed  [0.063s]
[192.168.10.2] out: usr.bin/bmake/variables/modifier_t/legacy_test:main  ->  
passed  [0.073s]
[192.168.10.2] out: usr.bin/bmake/variables/opt_V/legacy_test:main  ->  passed  
[0.061s]
[192.168.10.2] out: usr.bin/bmake/variables/t0/legacy_test:main  ->  passed  
[0.066s]
[192.168.10.2] out: usr.bin/uuencode/legacy_test:main  ->  passed  [0.038s]

Re: What builds go to snapshots?

[Allan Jude]

On 2016-05-22 23:33, Sergey Manucharian wrote:
> Is there any materialistic definition of those builds, which
> become snapshots at [0]?
> 
> - Sergey
> 
> [0] ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/11.0/
> 
> ___
> 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"
> 

The snapshots are built with the scripts/makefiles in the 'release'
subdirectory of the source tree.

-- 
Allan Jude
___
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"

What builds go to snapshots?

[Sergey Manucharian]

Is there any materialistic definition of those builds, which
become snapshots at [0]?

- Sergey

[0] ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/11.0/

___
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: Interesting error during installworld

[David Wolfskill]

On Sun, May 22, 2016 at 04:02:43PM -0700, Conrad Meyer wrote:
> FreeBSD has tail(1).  Does HardenedBSD remove it?  Or is /usr/bin
> missing from your PATH?
> 

I noticed this with a straight vanilla FreeBSD build/install, but
have been busy with "other things" today.

It appears to me that the issue is that certain inistallation tools
(ITOOLS) are installed in a temporary directory -- see ca. lines 860 -
870 of head's src/Makefile.inc1 -- and "tail" hasn't been defined as one
of the required "installation tools."

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

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


signature.asc
Description: PGP signature

Re: Interesting error during installworld

[Conrad Meyer]

FreeBSD has tail(1).  Does HardenedBSD remove it?  Or is /usr/bin
missing from your PATH?

On Sun, May 22, 2016 at 1:21 PM, Shawn Webb  wrote:
> Hey All,
>
> I’m getting this error when doing `make installworld` on recent builds of 
> HEAD. It seems that the error is non-critical as installworld doesn’t 
> actually error out. I’m running HardenedBSD 11-CURRENT on amd64.
>
> sh: tail: not found
> make[4]: "/usr/src/share/mk/bsd.compiler.mk" line 151: warning: "{ echo 
> "__FreeBSD_cc_version" | cc  -m32 -DCOMPAT_32BIT -march=i686 -mmmx -msse 
> -msse2  -L/usr/obj/usr/src/lib32/usr/lib32  --sysroot=/usr/obj/usr/src/lib32  
>  -B/usr/obj/usr/src/lib32/usr/lib32 -isystem 
> /usr/obj/usr/src/lib32/usr/include -E - 2>/dev/null || echo 
> __FreeBSD_cc_version; } | tail -n 1" returned non-zero status
>
> Thanks,
>
> Shawn Webb
> Cofounder and Security Engineer
> HardenedBSD
>
> GPG Key ID:  0x6A84658F52456EEE
> GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE
>
___
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: Interesting error during installworld

[Shawn Webb]

HardenedBSD has it and it’s in /usr/bin. The only utilities that aren’t 
compiled by default in HardenedBSD are freebsd-update and portsnap.

Thanks,

Shawn Webb
Cofounder and Security Engineer
HardenedBSD

GPG Key ID:  0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE

> On May 22, 2016, at 7:02 PM, Conrad Meyer  wrote:
> 
> FreeBSD has tail(1).  Does HardenedBSD remove it?  Or is /usr/bin
> missing from your PATH?
> 
> On Sun, May 22, 2016 at 1:21 PM, Shawn Webb  
> wrote:
>> Hey All,
>> 
>> I’m getting this error when doing `make installworld` on recent builds of 
>> HEAD. It seems that the error is non-critical as installworld doesn’t 
>> actually error out. I’m running HardenedBSD 11-CURRENT on amd64.
>> 
>> sh: tail: not found
>> make[4]: "/usr/src/share/mk/bsd.compiler.mk" line 151: warning: "{ echo 
>> "__FreeBSD_cc_version" | cc  -m32 -DCOMPAT_32BIT -march=i686 -mmmx -msse 
>> -msse2  -L/usr/obj/usr/src/lib32/usr/lib32  --sysroot=/usr/obj/usr/src/lib32 
>>   -B/usr/obj/usr/src/lib32/usr/lib32 -isystem 
>> /usr/obj/usr/src/lib32/usr/include -E - 2>/dev/null || echo 
>> __FreeBSD_cc_version; } | tail -n 1" returned non-zero status
>> 
>> Thanks,
>> 
>> Shawn Webb
>> Cofounder and Security Engineer
>> HardenedBSD
>> 
>> GPG Key ID:  0x6A84658F52456EEE
>> GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE
>> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: pkg chroot issues?

[Baptiste Daroussin]

On Sun, May 22, 2016 at 02:18:07PM -0700, Matthew Macy wrote:
> 
> 
> 
>   On Sun, 22 May 2016 13:43:13 -0700 Tim Kientzle  
> wrote  
>  >  
>  > > On May 22, 2016, at 1:28 PM, K. Macy  wrote: 
>  > >  
>  > >  
>  > >  
>  > > On Sunday, May 22, 2016, Tim Kientzle  wrote: 
>  > > Crochet has some experimental hooks to install packages onto the system 
> being built, but this seems to be hitting problems due to limitations in 'pkg 
> -c'.  In particular, it seems that pkg performs the chroot before it does any 
> network lookups.  This is a problem if the chroot is not a complete system 
> environment (which it cannot be when you're building an image for another 
> system). 
>  > >  
>  > > There's some further discussion on github: 
>  > >  
>  > >   https://github.com/freebsd/crochet/issues/141 
>  > >  
>  > > Any suggestions? 
>  > >  
>  > > Cheers, 
>  > >  
>  > > Tim 
>  > >  
>  > >  
>  > > Just like you need to mount devfs you should have a resolv.conf in your 
> chroot first. Just copy it over before running pkg. This works for me in my 
> image creation script. 
>  >  
>  > Sometimes the image does already have a resolv.conf, but if it does, it's 
> for the target environment (where the image will ultimately be running) and 
> may not be appropriate for the environment where the image is being built. 
>  
> Setting NAMESERVER to "10.0.1.1" crashed pkg for me. Maybe it's been fixed in 
> the meantime. If a resolv.conf already exists I would just rename it before 
> and then rename it back after the call to pkg -c.
> 
Setting nameserver will inject this name server directly via the libc resolv api
so it won't touch the resolv.conf at all no need to back it up

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: pkg chroot issues?

[Matthew Macy]

  On Sun, 22 May 2016 13:43:13 -0700 Tim Kientzle  wrote 
 
 >  
 > > On May 22, 2016, at 1:28 PM, K. Macy  wrote: 
 > >  
 > >  
 > >  
 > > On Sunday, May 22, 2016, Tim Kientzle  wrote: 
 > > Crochet has some experimental hooks to install packages onto the system 
 > > being built, but this seems to be hitting problems due to limitations in 
 > > 'pkg -c'.  In particular, it seems that pkg performs the chroot before it 
 > > does any network lookups.  This is a problem if the chroot is not a 
 > > complete system environment (which it cannot be when you're building an 
 > > image for another system). 
 > >  
 > > There's some further discussion on github: 
 > >  
 > >   https://github.com/freebsd/crochet/issues/141 
 > >  
 > > Any suggestions? 
 > >  
 > > Cheers, 
 > >  
 > > Tim 
 > >  
 > >  
 > > Just like you need to mount devfs you should have a resolv.conf in your 
 > > chroot first. Just copy it over before running pkg. This works for me in 
 > > my image creation script. 
 >  
 > Sometimes the image does already have a resolv.conf, but if it does, it's 
 > for the target environment (where the image will ultimately be running) and 
 > may not be appropriate for the environment where the image is being built. 
 
Setting NAMESERVER to "10.0.1.1" crashed pkg for me. Maybe it's been fixed in 
the meantime. If a resolv.conf already exists I would just rename it before and 
then rename it back after the call to pkg -c.

Cheers.

-M

___
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: pkg chroot issues?

[Tim Kientzle]

> On May 22, 2016, at 1:28 PM, K. Macy  wrote:
> 
> 
> 
> On Sunday, May 22, 2016, Tim Kientzle  wrote:
> Crochet has some experimental hooks to install packages onto the system being 
> built, but this seems to be hitting problems due to limitations in 'pkg -c'.  
> In particular, it seems that pkg performs the chroot before it does any 
> network lookups.  This is a problem if the chroot is not a complete system 
> environment (which it cannot be when you're building an image for another 
> system).
> 
> There's some further discussion on github:
> 
>   https://github.com/freebsd/crochet/issues/141
> 
> Any suggestions?
> 
> Cheers,
> 
> Tim
> 
> 
> Just like you need to mount devfs you should have a resolv.conf in your 
> chroot first. Just copy it over before running pkg. This works for me in my 
> image creation script.

Sometimes the image does already have a resolv.conf, but if it does, it's for 
the target environment (where the image will ultimately be running) and may not 
be appropriate for the environment where the image is being built.

Tim


___
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: pkg chroot issues?

[b...@freebsd.org]

On Sun, May 22, 2016 at 10:31:08PM +0200, b...@freebsd.org wrote:
> On Sun, May 22, 2016 at 01:24:12PM -0700, Tim Kientzle wrote:
> > Crochet has some experimental hooks to install packages onto the system 
> > being built, but this seems to be hitting problems due to limitations in 
> > 'pkg -c'.  In particular, it seems that pkg performs the chroot before it 
> > does any network lookups.  This is a problem if the chroot is not a 
> > complete system environment (which it cannot be when you're building an 
> > image for another system).
> > 
> > There's some further discussion on github:
> > 
> >   https://github.com/freebsd/crochet/issues/141
> > 
> > Any suggestions?
> > 
> I'll reply directly to github thanks for pointing me to the ticket
> 
> Best regards,
> Bapt

As people might only follow this thread and not the ticket here is what I
answered:

pkg supports an option for that which is pkg -o NAMESERVER= to avoid having to
copy resolv.conf it was broken in 1.8 but I fixed it in pkg 1.8.0 which has been
released today.

the problem with pkg -c is that it calls chroot very early. To avoid that
problem we have added pkg -r which does not perform any chroot at all therefore
having not network issue, but the ports tree are is not yet entirely aware of it
and some scripts (preinstall/postinstall) might cause some issues.
at least creating users from the script is safe in that regard. for most simple
case that should work.


Best regards,
Bapt


signature.asc
Description: PGP signature

Re: pkg chroot issues?

[b...@freebsd.org]

On Sun, May 22, 2016 at 01:24:12PM -0700, Tim Kientzle wrote:
> Crochet has some experimental hooks to install packages onto the system being 
> built, but this seems to be hitting problems due to limitations in 'pkg -c'.  
> In particular, it seems that pkg performs the chroot before it does any 
> network lookups.  This is a problem if the chroot is not a complete system 
> environment (which it cannot be when you're building an image for another 
> system).
> 
> There's some further discussion on github:
> 
>   https://github.com/freebsd/crochet/issues/141
> 
> Any suggestions?
> 
I'll reply directly to github thanks for pointing me to the ticket

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: pkg chroot issues?

[K. Macy]

On Sunday, May 22, 2016, Tim Kientzle  wrote:

> Crochet has some experimental hooks to install packages onto the system
> being built, but this seems to be hitting problems due to limitations in
> 'pkg -c'.  In particular, it seems that pkg performs the chroot before it
> does any network lookups.  This is a problem if the chroot is not a
> complete system environment (which it cannot be when you're building an
> image for another system).
>
> There's some further discussion on github:
>
>   https://github.com/freebsd/crochet/issues/141
>
> Any suggestions?
>
> Cheers,
>
> Tim
>
>
Just like you need to mount devfs you should have a resolv.conf in your
chroot first. Just copy it over before running pkg. This works for me in my
image creation script.


-M


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

pkg chroot issues?

[Tim Kientzle]

Crochet has some experimental hooks to install packages onto the system being 
built, but this seems to be hitting problems due to limitations in 'pkg -c'.  
In particular, it seems that pkg performs the chroot before it does any network 
lookups.  This is a problem if the chroot is not a complete system environment 
(which it cannot be when you're building an image for another system).

There's some further discussion on github:

  https://github.com/freebsd/crochet/issues/141

Any suggestions?

Cheers,

Tim

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

Interesting error during installworld

[Shawn Webb]

Hey All,

I’m getting this error when doing `make installworld` on recent builds of HEAD. 
It seems that the error is non-critical as installworld doesn’t actually error 
out. I’m running HardenedBSD 11-CURRENT on amd64.

sh: tail: not found
make[4]: "/usr/src/share/mk/bsd.compiler.mk" line 151: warning: "{ echo 
"__FreeBSD_cc_version" | cc  -m32 -DCOMPAT_32BIT -march=i686 -mmmx -msse -msse2 
 -L/usr/obj/usr/src/lib32/usr/lib32  --sysroot=/usr/obj/usr/src/lib32   
-B/usr/obj/usr/src/lib32/usr/lib32 -isystem /usr/obj/usr/src/lib32/usr/include 
-E - 2>/dev/null || echo __FreeBSD_cc_version; } | tail -n 1" returned non-zero 
status

Thanks,

Shawn Webb
Cofounder and Security Engineer
HardenedBSD

GPG Key ID:  0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: ZFS on root, beadm, and the /boot symlink

[René Ladan]

On 05/22/16 21:11, Allan Jude wrote:
> On 2016-05-22 14:41, Randy Westlund wrote:
>> My system was installed from 10.1 or 10.2 with root on ZFS and geli, but
>> now it tracks current.  It is not an EFI system.  I'm trying to get boot
>> environments to work, but the /boot symlink is throwing me off.
>>
>> I have two pools from the installer's layout; a small bootpool and
>> zroot.  The bootpool mounts at /bootpool and /boot is a symlink to it.
>>
>>> randy@mako /> zfs get mountpoint bootpool
>>> NAME  PROPERTYVALUE   SOURCE
>>> bootpool  mountpoint  /bootpool   local
>>>
>>> randy@mako /> ls -al /boot
>>> lrwxr-xr-x  1 root  wheel  13 Aug 12  2015 /boot -> bootpool/boot
>>
>> When I try to activate a boot environment, I get this error:
>>
>>> root@mako:/ # beadm activate r300358
>>> cp: /tmp/BE-r300358.FS6Xo6ot/boot/zfs/zpool.cache: No such file or directory
>>
>> Because the new boot environment has a symlink to an empty directory:
>>
>>> randy@mako /> ls -al /tmp/BE-r300358.FS6Xo6ot/boot
>>> lrwxr-xr-x  1 root  wheel  13 Aug 12  2015 /tmp/BE-r300358.FS6Xo6ot/boot -> 
>>> bootpool/boot
>>>
>>> randy@mako /> ls -al /tmp/BE-r300358.FS6Xo6ot/bootpool
>>> total 9
>>> drwxr-xr-x   2 root  wheel   2 Aug 18  2015 .
>>> drwxr-xr-x  21 root  wheel  29 May 21 16:23 ..
>>
>> Mergemaster complains about the /boot symlink as well.
>>
>> I'm not sure what the cachefile does or why it's there.  It has a recent
>> modification time, but neither pool seems to reference it.
>>
>>> randy@mako /> zpool get cachefile zroot
>>> NAME   PROPERTY   VALUE  SOURCE
>>> zroot  cachefile  -  default
>>
>>> randy@mako /> zpool get cachefile bootpool
>>> NAME  PROPERTY   VALUE  SOURCE
>>> bootpool  cachefile  -  default
>>
>>> randy@mako /> ls -al /boot/zfs/zpool.cache
>>> -rw-r--r--  1 root  wheel  2512 May 21 16:23 /boot/zfs/zpool.cache
>>
>> What's the proper way to handle the /boot symlink with beadm?
>>
>> Randy
>>
> 
> It is not possible to use boot environments when you have a separate
> bootpool. This is the motivation for my recent work to implement GELI in
> boot2 and loader, to allow you to combine GELI encryption with ZFS boot
> environments, which previously required a second unencrypted pool for
> the loader and kernel.
> 
Ah, I ran into this as well. I installed FreeBSD in UEFI mode from
ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/11.0/ which
creates a separate boot pool as described above.

Although creating the new boot environment went fine, upgrading that to
a pkgbase install with the new boot environment jailed failed when
installing the FreeBSD-runtime package because that installs
/boot/loader.efi and /boot is a dangling symbolic link in that jail.

Regards,
René




signature.asc
Description: OpenPGP digital signature

Re: ZFS on root, beadm, and the /boot symlink

[Randy Westlund]

On Sun, May 22, 2016 at 03:11:52PM -0400, Allan Jude wrote:
> It is not possible to use boot environments when you have a separate
> bootpool. This is the motivation for my recent work to implement GELI in
> boot2 and loader, to allow you to combine GELI encryption with ZFS boot
> environments, which previously required a second unencrypted pool for
> the loader and kernel.

Ah, okay.  Thanks for all your work in this area.  I'll stay tuned.

Randy


signature.asc
Description: PGP signature

Note on CFT image

[Matthew Macy]

  On Sun, 22 May 2016 11:27:28 -0700 Matthew Macy  wrote 
 
 > To improve the user experience I disabled debug logging by default. Before 
 > reporting a non-fatal error  with i915 load the drm2 module first, then: 
 > sysctl dev.drm.drm_debug=-1 to enable full logging. Once you have done that 
 > you can then load i915. The "unimplemented" and "dodgy" warnings are 
 > expected, they're just placeholders to remind me to get back to them. 

 When I specified the disk image name I assumed it was self-evident that 
'YYMMDDHH'  is the date format.  Looking at the access logs it appears that 
many took that literally. You can find the most recent at: 
http://www.bsddesktop.com/images/

Currently there is only one,  disk_16052200.img.xz.

-M

___
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: ZFS on root, beadm, and the /boot symlink

[Allan Jude]

On 2016-05-22 14:41, Randy Westlund wrote:
> My system was installed from 10.1 or 10.2 with root on ZFS and geli, but
> now it tracks current.  It is not an EFI system.  I'm trying to get boot
> environments to work, but the /boot symlink is throwing me off.
> 
> I have two pools from the installer's layout; a small bootpool and
> zroot.  The bootpool mounts at /bootpool and /boot is a symlink to it.
> 
>> randy@mako /> zfs get mountpoint bootpool
>> NAME  PROPERTYVALUE   SOURCE
>> bootpool  mountpoint  /bootpool   local
>>
>> randy@mako /> ls -al /boot
>> lrwxr-xr-x  1 root  wheel  13 Aug 12  2015 /boot -> bootpool/boot
> 
> When I try to activate a boot environment, I get this error:
> 
>> root@mako:/ # beadm activate r300358
>> cp: /tmp/BE-r300358.FS6Xo6ot/boot/zfs/zpool.cache: No such file or directory
> 
> Because the new boot environment has a symlink to an empty directory:
> 
>> randy@mako /> ls -al /tmp/BE-r300358.FS6Xo6ot/boot
>> lrwxr-xr-x  1 root  wheel  13 Aug 12  2015 /tmp/BE-r300358.FS6Xo6ot/boot -> 
>> bootpool/boot
>>
>> randy@mako /> ls -al /tmp/BE-r300358.FS6Xo6ot/bootpool
>> total 9
>> drwxr-xr-x   2 root  wheel   2 Aug 18  2015 .
>> drwxr-xr-x  21 root  wheel  29 May 21 16:23 ..
> 
> Mergemaster complains about the /boot symlink as well.
> 
> I'm not sure what the cachefile does or why it's there.  It has a recent
> modification time, but neither pool seems to reference it.
> 
>> randy@mako /> zpool get cachefile zroot
>> NAME   PROPERTY   VALUE  SOURCE
>> zroot  cachefile  -  default
> 
>> randy@mako /> zpool get cachefile bootpool
>> NAME  PROPERTY   VALUE  SOURCE
>> bootpool  cachefile  -  default
> 
>> randy@mako /> ls -al /boot/zfs/zpool.cache
>> -rw-r--r--  1 root  wheel  2512 May 21 16:23 /boot/zfs/zpool.cache
> 
> What's the proper way to handle the /boot symlink with beadm?
> 
> Randy
> 

It is not possible to use boot environments when you have a separate
bootpool. This is the motivation for my recent work to implement GELI in
boot2 and loader, to allow you to combine GELI encryption with ZFS boot
environments, which previously required a second unencrypted pool for
the loader and kernel.

-- 
Allan Jude
___
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"

ZFS on root, beadm, and the /boot symlink

[Randy Westlund]

My system was installed from 10.1 or 10.2 with root on ZFS and geli, but
now it tracks current.  It is not an EFI system.  I'm trying to get boot
environments to work, but the /boot symlink is throwing me off.

I have two pools from the installer's layout; a small bootpool and
zroot.  The bootpool mounts at /bootpool and /boot is a symlink to it.

> randy@mako /> zfs get mountpoint bootpool
> NAME  PROPERTYVALUE   SOURCE
> bootpool  mountpoint  /bootpool   local
> 
> randy@mako /> ls -al /boot
> lrwxr-xr-x  1 root  wheel  13 Aug 12  2015 /boot -> bootpool/boot

When I try to activate a boot environment, I get this error:

> root@mako:/ # beadm activate r300358
> cp: /tmp/BE-r300358.FS6Xo6ot/boot/zfs/zpool.cache: No such file or directory

Because the new boot environment has a symlink to an empty directory:

> randy@mako /> ls -al /tmp/BE-r300358.FS6Xo6ot/boot
> lrwxr-xr-x  1 root  wheel  13 Aug 12  2015 /tmp/BE-r300358.FS6Xo6ot/boot -> 
> bootpool/boot
> 
> randy@mako /> ls -al /tmp/BE-r300358.FS6Xo6ot/bootpool
> total 9
> drwxr-xr-x   2 root  wheel   2 Aug 18  2015 .
> drwxr-xr-x  21 root  wheel  29 May 21 16:23 ..

Mergemaster complains about the /boot symlink as well.

I'm not sure what the cachefile does or why it's there.  It has a recent
modification time, but neither pool seems to reference it.

> randy@mako /> zpool get cachefile zroot
> NAME   PROPERTY   VALUE  SOURCE
> zroot  cachefile  -  default

> randy@mako /> zpool get cachefile bootpool
> NAME  PROPERTY   VALUE  SOURCE
> bootpool  cachefile  -  default

> randy@mako /> ls -al /boot/zfs/zpool.cache
> -rw-r--r--  1 root  wheel  2512 May 21 16:23 /boot/zfs/zpool.cache

What's the proper way to handle the /boot symlink with beadm?

Randy


signature.asc
Description: PGP signature

Update on CFT error reporting

[Matthew Macy]

To improve the user experience I disabled debug logging by default. Before 
reporting a non-fatal error  with i915 load the drm2 module first, then: sysctl 
dev.drm.drm_debug=-1 to enable full logging. Once you have done that you can 
then load i915. The "unimplemented" and "dodgy" warnings are expected, they're 
just placeholders to remind me to get back to them.


Thanks.
-M

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

repeatable panic on pageout with 945GM

[Michael Butler]

With KDE and compositing enabled, I randomly get the following:

(kgdb) info stack
#0  doadump (textdump=) at pcpu.h:221
#1  0x8064e98e in kern_reboot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:366
#2  0x8064eea1 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:759
#3  0x8064ed13 in panic (fmt=0x0) at
/usr/src/sys/kern/kern_shutdown.c:690
#4  0x809d18ed in vm_fault_hold (map=,
vaddr=, fault_type=,
fault_flags=, m_hold=) at
/usr/src/sys/vm/vm_fault.c:327
#5  0x809cf548 in vm_fault (map=0xf8000200, vaddr=, fault_type=1 '\001', fault_flags=)
at /usr/src/sys/vm/vm_fault.c:273
#6  0x80a1849f in trap_pfault (frame=,
usermode=0) at /usr/src/sys/amd64/amd64/trap.c:741
#7  0x80a17b30 in trap (frame=0xfe00dbec5830) at
/usr/src/sys/amd64/amd64/trap.c:442
#8  0x809fd5a1 in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:236
#9  0x80a0a3bb in pmap_remove_all (m=) at
/usr/src/sys/amd64/amd64/pmap.c:3950
#10 0x809c0c57 in cdev_pager_free_page (object=, m=0xfe0001e410d0) at /usr/src/sys/vm/device_pager.c:214
#11 0x816aff33 in i915_gem_release_mmap (obj=) at
/usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem.c:1691
#12 0x816b104b in i915_gem_object_unbind
(obj=0xf8008ef11400) at
/usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem.c:2738
#13 0x816b47c8 in __i915_gem_shrink (dev_priv=, target=-1, purgeable_only=)
at
/usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem.c:2056
#14 0x816b3f47 in i915_gem_inactive_shrink (arg=) at
/usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem.c:4755
#15 0x809ec628 in vm_pageout () at /usr/src/sys/vm/vm_pageout.c:899
#16 0x80609dcc in fork_exit (callout=0x809ec260
, arg=0x0, frame=0xfe00dbec5c00) at
/usr/src/sys/kern/kern_fork.c:1034
#17 0x809fdade in fork_trampoline () at
/usr/src/sys/amd64/amd64/exception.S:611
#18 0x in ?? ()

Any hints?

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"

4.6 DRM/i915 update CFT (Sandy Bridge?)/IvyBridge/Haswell/Broadwell/SkyLake/KabyLake supported

[Matthew Macy]

I'm happy to announce a call for testers for the 4.6 update of drm and
i915. The driver has been successfully tested on IvyBridge, Haswell,
Broadwell and Skylake. At least basic HW 3D acceleration should work,
VGA and DP out are known to work. Video decode has only been tried
once and that did not work.

At this point I'm most interested in taking an inventory of what is
broken where. My priorities are common sense:

a) stability
b) fixing 2D artifacts
c) fixing 3D problems
d) video decode 
d) output support
e) other features

At this time "prime" (needed for switching between GPUs, compute
APIs, and DRI3) is not yet supported. All the pieces are in place but
support existing functionality is a higher priority. Userptr (mapping
user memory in to the driver) requires VM changes. Support is
planned, but likely post-11.


A few caveats are in order:
- The only reported test on Sandy Bridge indicated severe artifacts.
- Arrandale (pre-Sandy Bridge) and earlier are not yet supported by
  this update. The intel_i810 code has been heavily localized for 
  FreeBSD making it more difficult to integrate. Thus there are
  holes in the gmch support.
- This update is 64-bit only. There is no good reason to be running
  in 32-bit mode on any of the hardware supported by this driver.
- Although it works fine for me on my Skylake the one other tester
  I have reports from indicates that the driver isn't actually
  attaching and creating aliases for the drm device nodes.

Please send issue/success reports to the freebsd-x11 mailing list.
I may be preoccupied with work matters for periods of time. Sending
it to the list makes sure that the messages don't get lost.


If you encounter problems with startx, please try loading the i915
kmod in isolation and make sure that it switches correctly to vt_fb.
If you're not running efifb you'll notice a change in resolution.
If it works but is slow or has artifacts you may try switching to
UXA by removing  /etc/X11/xorg.conf.d/20-intel.conf (if you're using
the USB image). If you've built from source, try configuring SNA
instead. SNA is much better behaved for me.

The usual rules apply for kernel debugging. There should be copious
information on that in the handbook and elsewhere. If that proves
to be problematic for people I will send out a follow up mail.

A couple observations:

- The FreeBSD PTB insist that a debugger be in tree but that it
  pre-date GPL2, consequently kernels are, by default compiled with
  DWARF2 which is very poor at retain debug information in the
  presence of any optimization. If this is a problem, either
  recompile everything with -O0 (add CFLAGS += -O0 in drm2 and
  i915kms Makefiles, and pass COPTFLAGS=-O0 to buildkernel) or
  install a newer kgdb from ports.

- The purpose of encrypted swap is that the data on disk be
  unrecoverable. This is somewhat at cross purposes with savecore.
  So don't do that.
  

Now that this is out I will be switching gears to bringing up amdgpu
and radeon support. I have no hardware that uses the radeon driver
so I will have to rely on Jean for testing and support there.


Those of you wishing to try your hand at testing from source can
fetch our repo from github at:


https://github.com/iotamudelta/freebsd-base-graphics

Make sure to check out the drm-next-4.6 branch.


If you'd rather just try it on a usb pen driver you can also
obtain a prebuilt memstick image with this branch installed
along with xorg and some commonly used ports at: 

http://www.bsddesktop.com/images/disk_YYMMDDHH.img.xz

There is no root password and the user/pw is joeuser/joeuser.


If you're curious about what's on it, the script used to
create the image is here:

http://www.bsddesktop.com/images/usbcreate.sh


If you'd like to help out with collecting data on what
laptops are supported please run Warren Block's
notebookstats script:

http://www.bsddesktop.com/images/notebookstats

It's also installed under /usr/local/bin on the image.

If I've missed anything please let me know and I will follow up.

-M


___
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: Recent -current cpucontrol panic: [cpuctl, 129]: cannot bind to target cpu 1

[Andrey Chernov]

On 22.05.2016 12:32, Konstantin Belousov wrote:
> On Sun, May 22, 2016 at 12:19:32PM +0300, Andrey Chernov wrote:
>> On 22.05.2016 10:14, Konstantin Belousov wrote:
>>> On Sun, May 22, 2016 at 09:47:08AM +0300, Andrey Chernov wrote:
 With microcode_update_enable="YES" in rc.conf:

 db:0:kdb.enter.panic>  show pcpu
 cpuid= 1
 dynamic pcpu = 0xfe02ac1fd300
 curthread= 0xf8000ae75a00: pid 736 "cpucontrol"
 curpcb   = 0xfe023754eb80
 fpcurthread  = none
 idlethread   = 0xf800022b5000: tid 13 "idle: cpu1"
 curpmap  = 0xf8000af02138
 tssp = 0x80c1cf78
 commontssp   = 0x80c1cf78
 rsp0 = 0xfe023754eb80
 gs32p= 0x80c237d0
 ldt  = 0x80c23810
 tss  = 0x80c23800
 db:0:kdb.enter.panic>  bt
 Tracing pid 736 tid 100121 td 0xf8000ae75a00
 kdb_enter() at kdb_enter+0x3b/frame 0xfe023754e620
 vpanic() at vpanic+0x19f/frame 0xfe023754e6a0
 kassert_panic() at kassert_panic+0x126/frame 0xfe023754e710
 cpuctl_do_cpuid_count() at cpuctl_do_cpuid_count+0x85/frame
 0xfe023754e750
 cpuctl_ioctl() at cpuctl_ioctl+0x389/frame 0xfe023754e800
 devfs_ioctl_f() at devfs_ioctl_f+0x156/frame 0xfe023754e860
 kern_ioctl() at kern_ioctl+0x204/frame 0xfe023754e8c0
 sys_ioctl() at sys_ioctl+0x171/frame 0xfe023754e9a0
 amd64_syscall() at amd64_syscall+0x28e/frame 0xfe023754eab0
 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe023754eab0
 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8009778ea, rsp =
 0x7fffe788, rbp = 0x7fffe7d0 ---
>>>
>>> Show verbose dmesg of your boot.
>>
>> Attached.
> Thanks.
> 
>>
>>> What scheduler do you use ?
>>
>> ULE
>>
>>> In the fired KASSERT, add printout of td->td_oncpu and show the updated
>>> panic message.
>>
>> I add, but can't reproduce this bug again so far.
>>
> Do you have core file for the panic ?  If yes, it would be at least
> interesting to see the output of 'p *td' in kgdb.
> 

No, just textdump.

___
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: Recent -current cpucontrol panic: [cpuctl, 129]: cannot bind to target cpu 1

[Konstantin Belousov]

On Sun, May 22, 2016 at 12:19:32PM +0300, Andrey Chernov wrote:
> On 22.05.2016 10:14, Konstantin Belousov wrote:
> > On Sun, May 22, 2016 at 09:47:08AM +0300, Andrey Chernov wrote:
> >> With microcode_update_enable="YES" in rc.conf:
> >>
> >> db:0:kdb.enter.panic>  show pcpu
> >> cpuid= 1
> >> dynamic pcpu = 0xfe02ac1fd300
> >> curthread= 0xf8000ae75a00: pid 736 "cpucontrol"
> >> curpcb   = 0xfe023754eb80
> >> fpcurthread  = none
> >> idlethread   = 0xf800022b5000: tid 13 "idle: cpu1"
> >> curpmap  = 0xf8000af02138
> >> tssp = 0x80c1cf78
> >> commontssp   = 0x80c1cf78
> >> rsp0 = 0xfe023754eb80
> >> gs32p= 0x80c237d0
> >> ldt  = 0x80c23810
> >> tss  = 0x80c23800
> >> db:0:kdb.enter.panic>  bt
> >> Tracing pid 736 tid 100121 td 0xf8000ae75a00
> >> kdb_enter() at kdb_enter+0x3b/frame 0xfe023754e620
> >> vpanic() at vpanic+0x19f/frame 0xfe023754e6a0
> >> kassert_panic() at kassert_panic+0x126/frame 0xfe023754e710
> >> cpuctl_do_cpuid_count() at cpuctl_do_cpuid_count+0x85/frame
> >> 0xfe023754e750
> >> cpuctl_ioctl() at cpuctl_ioctl+0x389/frame 0xfe023754e800
> >> devfs_ioctl_f() at devfs_ioctl_f+0x156/frame 0xfe023754e860
> >> kern_ioctl() at kern_ioctl+0x204/frame 0xfe023754e8c0
> >> sys_ioctl() at sys_ioctl+0x171/frame 0xfe023754e9a0
> >> amd64_syscall() at amd64_syscall+0x28e/frame 0xfe023754eab0
> >> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe023754eab0
> >> --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8009778ea, rsp =
> >> 0x7fffe788, rbp = 0x7fffe7d0 ---
> > 
> > Show verbose dmesg of your boot.
> 
> Attached.
Thanks.

> 
> > What scheduler do you use ?
> 
> ULE
> 
> > In the fired KASSERT, add printout of td->td_oncpu and show the updated
> > panic message.
> 
> I add, but can't reproduce this bug again so far.
> 
Do you have core file for the panic ?  If yes, it would be at least
interesting to see the output of 'p *td' in kgdb.

___
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: Recent -current cpucontrol panic: [cpuctl, 129]: cannot bind to target cpu 1

[Andrey Chernov]

On 22.05.2016 10:14, Konstantin Belousov wrote:
> On Sun, May 22, 2016 at 09:47:08AM +0300, Andrey Chernov wrote:
>> With microcode_update_enable="YES" in rc.conf:
>>
>> db:0:kdb.enter.panic>  show pcpu
>> cpuid= 1
>> dynamic pcpu = 0xfe02ac1fd300
>> curthread= 0xf8000ae75a00: pid 736 "cpucontrol"
>> curpcb   = 0xfe023754eb80
>> fpcurthread  = none
>> idlethread   = 0xf800022b5000: tid 13 "idle: cpu1"
>> curpmap  = 0xf8000af02138
>> tssp = 0x80c1cf78
>> commontssp   = 0x80c1cf78
>> rsp0 = 0xfe023754eb80
>> gs32p= 0x80c237d0
>> ldt  = 0x80c23810
>> tss  = 0x80c23800
>> db:0:kdb.enter.panic>  bt
>> Tracing pid 736 tid 100121 td 0xf8000ae75a00
>> kdb_enter() at kdb_enter+0x3b/frame 0xfe023754e620
>> vpanic() at vpanic+0x19f/frame 0xfe023754e6a0
>> kassert_panic() at kassert_panic+0x126/frame 0xfe023754e710
>> cpuctl_do_cpuid_count() at cpuctl_do_cpuid_count+0x85/frame
>> 0xfe023754e750
>> cpuctl_ioctl() at cpuctl_ioctl+0x389/frame 0xfe023754e800
>> devfs_ioctl_f() at devfs_ioctl_f+0x156/frame 0xfe023754e860
>> kern_ioctl() at kern_ioctl+0x204/frame 0xfe023754e8c0
>> sys_ioctl() at sys_ioctl+0x171/frame 0xfe023754e9a0
>> amd64_syscall() at amd64_syscall+0x28e/frame 0xfe023754eab0
>> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe023754eab0
>> --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8009778ea, rsp =
>> 0x7fffe788, rbp = 0x7fffe7d0 ---
> 
> Show verbose dmesg of your boot.

Attached.

> What scheduler do you use ?

ULE

> In the fired KASSERT, add printout of td->td_oncpu and show the updated
> panic message.

I add, but can't reproduce this bug again so far.

___
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: 4.6 DRM/i915 update CFT (Sandy Bridge?)/IvyBridge/Haswell/Broadwell/SkyLake/KabyLake supported

[Slawa Olhovchenkov]

On Sun, May 22, 2016 at 12:26:49AM -0700, Matthew Macy wrote:

> I'm happy to announce a call for testers for the 4.6 update of drm and 
> i915. The driver has been successfully tested on IvyBridge, Haswell, 
> Broadwell and Skylake. At least basic HW 3D acceleration should work, 
> VGA and DP out are known to work. Video decode has only been tried 
> once and that did not work. 
> 
> At this point I'm most interested in taking an inventory of what is 
> broken where. My priorities are common sense: 
> 
> a) stability 
> b) fixing 2D artifacts 
> c) fixing 3D problems 
> d) video decode 
> d) output support 
> e) other features 
> 
> At this time "prime" (needed for switching between GPUs, compute 
> APIs, and DRI3) is not yet supported. All the pieces are in place but 
> support existing functionality is a higher priority. Userptr (mapping 
> user memory in to the driver) requires VM changes. Support is 
> planned, but likely post-11. 

Can you do commit placeholder changes for VM for future MFC?
___
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"

4.6 DRM/i915 update CFT (Sandy Bridge?)/IvyBridge/Haswell/Broadwell/SkyLake/KabyLake supported

[Matthew Macy]

I'm happy to announce a call for testers for the 4.6 update of drm and 
i915. The driver has been successfully tested on IvyBridge, Haswell, 
Broadwell and Skylake. At least basic HW 3D acceleration should work, 
VGA and DP out are known to work. Video decode has only been tried 
once and that did not work. 

At this point I'm most interested in taking an inventory of what is 
broken where. My priorities are common sense: 

a) stability 
b) fixing 2D artifacts 
c) fixing 3D problems 
d) video decode 
d) output support 
e) other features 

At this time "prime" (needed for switching between GPUs, compute 
APIs, and DRI3) is not yet supported. All the pieces are in place but 
support existing functionality is a higher priority. Userptr (mapping 
user memory in to the driver) requires VM changes. Support is 
planned, but likely post-11. 


A few caveats are in order: 
- The only reported test on Sandy Bridge indicated severe artifacts. 
- Arrandale (pre-Sandy Bridge) and earlier are not yet supported by 
  this update. The intel_i810 code has been heavily localized for 
  FreeBSD making it more difficult to integrate. Thus there are 
  holes in the gmch support. 
- This update is 64-bit only. There is no good reason to be running 
  in 32-bit mode on any of the hardware supported by this driver. 
- Although it works fine for me on my Skylake the one other tester 
  I have reports from indicates that the driver isn't actually 
  attaching and creating aliases for the drm device nodes. 

Please send issue/success reports to the freebsd-x11 mailing list. 
I may be preoccupied with work matters for periods of time. Sending 
it to the list makes sure that the messages don't get lost. 


If you encounter problems with startx, please try loading the i915 
kmod in isolation and make sure that it switches correctly to vt_fb. 
If you're not running efifb you'll notice a change in resolution. 
If it works but is slow or has artifacts you may try switching to 
UXA by removing  /etc/X11/xorg.conf.d/20-intel.conf (if you're using 
the USB image). If you've built from source, try configuring SNA 
instead. SNA is much better behaved for me. 

The usual rules apply for kernel debugging. There should be copious 
information on that in the handbook and elsewhere. If that proves 
to be problematic for people I will send out a follow up mail. 

A couple observations: 

- The FreeBSD PTB insist that a debugger be in tree but that it 
  pre-date GPL2, consequently kernels are, by default compiled with 
  DWARF2 which is very poor at retain debug information in the 
  presence of any optimization. If this is a problem, either 
  recompile everything with -O0 (add CFLAGS += -O0 in drm2 and 
  i915kms Makefiles, and pass COPTFLAGS=-O0 to buildkernel) or 
  install a newer kgdb from ports. 

- The purpose of encrypted swap is that the data on disk be 
  unrecoverable. This is somewhat at cross purposes with savecore. 
  So don't do that. 
  

Now that this is out I will be switching gears to bringing up amdgpu 
and radeon support. I have no hardware that uses the radeon driver 
so I will have to rely on Jean for testing and support there. 


Those of you wishing to try your hand at testing from source can 
fetch our repo from github at: 


https://github.com/iotamudelta/freebsd-base-graphics 

Make sure to check out the drm-next-4.6 branch. 


If you'd rather just try it on a usb pen driver you can also 
obtain a prebuilt memstick image with this branch installed 
along with xorg and some commonly used ports at: 

http://www.bsddesktop.com/images/disk_YYMMDDHH.img.xz 

There is no root password and the user/pw is joeuser/joeuser. 


If you're curious about what's on it, the script used to 
create the image is here: 

http://www.bsddesktop.com/images/usbcreate.sh 


If you'd like to help out with collecting data on what 
laptops are supported please run Warren Block's 
notebookstats script: 

http://www.bsddesktop.com/images/notebookstats 

It's also installed under /usr/local/bin on the image. 

If I've missed anything please let me know and I will follow up. 

-M 

___
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: Recent -current cpucontrol panic: [cpuctl, 129]: cannot bind to target cpu 1

[Konstantin Belousov]

On Sun, May 22, 2016 at 09:47:08AM +0300, Andrey Chernov wrote:
> With microcode_update_enable="YES" in rc.conf:
> 
> db:0:kdb.enter.panic>  show pcpu
> cpuid= 1
> dynamic pcpu = 0xfe02ac1fd300
> curthread= 0xf8000ae75a00: pid 736 "cpucontrol"
> curpcb   = 0xfe023754eb80
> fpcurthread  = none
> idlethread   = 0xf800022b5000: tid 13 "idle: cpu1"
> curpmap  = 0xf8000af02138
> tssp = 0x80c1cf78
> commontssp   = 0x80c1cf78
> rsp0 = 0xfe023754eb80
> gs32p= 0x80c237d0
> ldt  = 0x80c23810
> tss  = 0x80c23800
> db:0:kdb.enter.panic>  bt
> Tracing pid 736 tid 100121 td 0xf8000ae75a00
> kdb_enter() at kdb_enter+0x3b/frame 0xfe023754e620
> vpanic() at vpanic+0x19f/frame 0xfe023754e6a0
> kassert_panic() at kassert_panic+0x126/frame 0xfe023754e710
> cpuctl_do_cpuid_count() at cpuctl_do_cpuid_count+0x85/frame
> 0xfe023754e750
> cpuctl_ioctl() at cpuctl_ioctl+0x389/frame 0xfe023754e800
> devfs_ioctl_f() at devfs_ioctl_f+0x156/frame 0xfe023754e860
> kern_ioctl() at kern_ioctl+0x204/frame 0xfe023754e8c0
> sys_ioctl() at sys_ioctl+0x171/frame 0xfe023754e9a0
> amd64_syscall() at amd64_syscall+0x28e/frame 0xfe023754eab0
> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe023754eab0
> --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8009778ea, rsp =
> 0x7fffe788, rbp = 0x7fffe7d0 ---

Show verbose dmesg of your boot.
What scheduler do you use ?

In the fired KASSERT, add printout of td->td_oncpu and show the updated
panic message.
___
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"

Recent -current cpucontrol panic: [cpuctl, 129]: cannot bind to target cpu 1

[Andrey Chernov]

With microcode_update_enable="YES" in rc.conf:

db:0:kdb.enter.panic>  show pcpu
cpuid= 1
dynamic pcpu = 0xfe02ac1fd300
curthread= 0xf8000ae75a00: pid 736 "cpucontrol"
curpcb   = 0xfe023754eb80
fpcurthread  = none
idlethread   = 0xf800022b5000: tid 13 "idle: cpu1"
curpmap  = 0xf8000af02138
tssp = 0x80c1cf78
commontssp   = 0x80c1cf78
rsp0 = 0xfe023754eb80
gs32p= 0x80c237d0
ldt  = 0x80c23810
tss  = 0x80c23800
db:0:kdb.enter.panic>  bt
Tracing pid 736 tid 100121 td 0xf8000ae75a00
kdb_enter() at kdb_enter+0x3b/frame 0xfe023754e620
vpanic() at vpanic+0x19f/frame 0xfe023754e6a0
kassert_panic() at kassert_panic+0x126/frame 0xfe023754e710
cpuctl_do_cpuid_count() at cpuctl_do_cpuid_count+0x85/frame
0xfe023754e750
cpuctl_ioctl() at cpuctl_ioctl+0x389/frame 0xfe023754e800
devfs_ioctl_f() at devfs_ioctl_f+0x156/frame 0xfe023754e860
kern_ioctl() at kern_ioctl+0x204/frame 0xfe023754e8c0
sys_ioctl() at sys_ioctl+0x171/frame 0xfe023754e9a0
amd64_syscall() at amd64_syscall+0x28e/frame 0xfe023754eab0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe023754eab0
--- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8009778ea, rsp =
0x7fffe788, rbp = 0x7fffe7d0 ---
___
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"